NTP-based WIFI time for v1 clocks

More
3 months 6 days ago #10502 by Froula
I read through the thread on the user-contributed code for providing NTP service-based time updates and remote setting of clock parameters via the WIFI module. This was working for me with an older version(version 48) of the v1 clocks. The code was to be integrated into the v1 official source code.

However, the v1 code is now at version 56 and the included WIFI module code still does not have NTP support., although the latest v2 code does. However the v2 code with NTP support appears to work only for version 54 and is untested even for that.

Was this effort abandoned for v1 hardware?

I am unable to get even the latest v1 wifi module code to compile for a NodeMCU ESP-12E module, although an older version works just fine.

Figuring out what code works with which hardware has been a bit of a nightmare with the multiple repositories, support boards and web sites. I think I have it figured out now, but there does not seem to be a working NTP solution for the latest v1 code.

Best,

Don

Please Log in or Create an account to join the conversation.

More
3 months 6 days ago #10503 by Ian
Hi Don, I'm going to have to look into it. I'm pretty sure I back-ported everything, but am not sure if it simply didn't make it into a release, or if I have it on a computer somewhere and need to push it.

The plan is of course to have feature parity if that's attainable. Some things can't be done (PIR on V1 for example) but otherwise, the idea is to have the same code for everything.

Please Log in or Create an account to join the conversation.

More
3 months 6 days ago #10504 by Froula
Thanks, Ian.

The code in the latest 6-tube V1 repository is definitely the older non-NTP version, but with updated version 56 support. This does not compile for me with a NodeMCU ESP-12E board.

bitbucket.org/isparkes/nixiefirmwarev1/src/master/

I was able t get the beta code referenced in the old thread compiled:

WifiTime-v355-mjs.beta.zip

However, when connected in parallel to the RTC, I cannot get the I2C connection to communicate. I believe there is some kind of version checking that prevents it connecting to a version 56 v1 board.

The latest v2 WIFI module code here:

bitbucket.org/isparkes/nixiefirmwarev2/src/master/

...will not compile for me. The v1 support there is for a revision a few versions back, so it would likely not work even if it compiled for the ESP-12E with updated Arduino libraries.

Best regards,

Don

Please Log in or Create an account to join the conversation.

More
3 months 6 days ago #10508 by Ian
The I2C protocal is different between V1 and V2: There are extra options that need to be managed for things like the PIR. I'll make an update for it, or find the one I already did. It's supposed to work as you are expecting, but clearly something went wrong on the way.

I end up juggling too many versions and designs, and things get left on the desk, and then forgotten.
The following user(s) said Thank You: Froula

Please Log in or Create an account to join the conversation.

More
3 months 6 days ago #10510 by MikeS
Ian, the code has some conditionals based on the I2C comms version. What I provided supports v54 and v62. Anything else it will report as "unknown," and won't work. I don't know what v56 is comparable to, or if it's different than either.

Anyway, search for "v1v54" and/or "v2v62" to see what the code is doing.
The following user(s) said Thank You: Ian

Please Log in or Create an account to join the conversation.

More
3 months 5 days ago #10512 by Ian
Hey Mike, thanks for the info!

I'm probably going to rework the I2C protocol. It sort of developed organically and has outgrown its original scope. Getting the current config as a "block" all in one go new feels like a dead end - it caused me to add the "protocol field" to try to keep track of the contents of the block and now managing multiple versions is getting onerous.

I'm likely to get individual elements from the clock on demand, so that any clock can respond to the fields it knows about, and respond "I don't know" to the ones it does not know about. This is likely to allow me to manage the code base better and let the user know when something is wrong. On the other hand, it would also be a good idea to just tell the user in the GUI if there is a protocol version failure.

Please Log in or Create an account to join the conversation.

Moderators: AccutronTy_EeberfestIan
Time to create page: 0.181 seconds

Search

Tube Suppliers

Go to top
JSN Boot template designed by JoomlaShine.com