Topic: WS-1400 ObserverIP clock

[2Tall]

I installed a new WS-1400-IP yesterday and noticed, through the web interface, that the time on the ObserverIP is about 4 minutes fast.  The ObserverIP is running firmware version 3.16.

Now, 24 hours later and having rebooted and power cycled the ObserverIP, the time is still about 4 minutes fast.  Where and when does the ObserverIP get its time?  As an aside, I'm waiting until I've finished testing before I raise the height of the sensor array and register it with WU.  Thanks.

[dolfs]

Mine is about 4 minutes fast as well (and the date is way off). I then ran a tcpdump to see if it even attempts to get the time, and from where. I rebooted the unit and observed. The only thing, network wise, that happens is DHCP traffic (mine is configured to use it), and nothing else. There is no attempt to contact an NTP server as far as I can see (only observed for 10 minutes).
It may be that it only attempts NTP once a day or so and I simply have not looked in the right time window, although one would think it should always happen on a reboot.

None of this is fatal in my case, as I do not use it to upload to WU, using a MeteoBridge instead (which keeps its own time), but I suspect daily rain total rollovers etc. will be off (although the overall effect may be negligible).

[kmahler]

dolfs,

I have read with interest your comments on the WS-1400-IP. As you are aware, I'm having issues with the anemometer on mine not spinning until wind speeds exceed 4mph and then stopping again when they decrease to 3.5mph. I may have found the issue with my problem and hope to be able to report back in a few days.

As for the time issues on the observerIP, I suspect it does not have a real time clock included in the circuitry. Like you, I'm a network guy. I worked as an engineer for Cisco for many years and hold a CCIE certification. NTP would be a simple solution if the board had a clock that it could set with the data it received. But, this device was made specifically to work with WU and I guess they felt saving the $3 on the chip was worth the trade off.  I'm not sure I agree. 

This unit clearly has some limitations. In retrospect, I wish I'd have gone with a Davis Vantage Vue even though it would have cost more.

[dolfs]

I'm curious to hear what you find out regarding the spinning threshold for your unit, compared to mine.

I hope you are not wrong about the time issue. I do observe that the time presented in the LiveData screen continues updating even if it is refreshed in between two requests to Wunderground. I can be sure of it being in between using network packet sniffing. So at the very least this implies some kind of software based clock, perhaps hardware?

Fine Offset has informed me that they are investigating the option of adding an NTP client. If the clock is software only, its drift rate could then determine how often this client code should be activated to maintain a certain quality standard of the unit's clock. Assuming that no sub-second accuracy is needed, this requirement might not be too onerous.

Assuming this time issue gets fixed, hardware clock or software + NTP, and assuming your "spinning lift-off" issue is not representative in general, I would say that for its price the Ambient solution remains quite attractive. I agree the Davis solutions are overall better, and in some respects significantly better, but not everybody can afford the price. I've been reading some reports of failing sensors an replacement cost. Often times the replacement cost is more than a completely new Ambient unit.

Of course, all of this does not say anything about one's requirements as far as calibration, sensor separation, reproducibility etc. Davis clearly has the edge there, but not everyone may need that.

[2Tall]

I received the answer to my question from Ambient Weather Support on March 28th.  According to them, the clock for the WS-1400 is set from the WU servers.  The reason given is so that the PWS and WU servers are always in sync time wise.  They suspected that the 4 minute time discrepancy likely occurred when the servers were recently moved to Amazon. 

The plan was for Ambient Weather support to notify WU of the time discrepancy so that an adjustment could be made.  It appears that it was done by March 29th, as the clock on my PWS was corrected by that date.  Either that or my station started syncing its clock with the server(s) that handles my live data.  I didn't register my PWS with WU until late afternoon/evening of March 28th.

[kmahler]

They suspected that the 4 minute time discrepancy likely occurred when the servers were recently moved to Amazon. 

I have worked in IT my entire life. Accurate time is essential for the smallest of Data Centers to operate properly. It is absolutely impossible that AWS (Amazon Web Services) was 4 minutes off. Stock trades happen through AWS. Stock traders are concerned about milliseconds of delay even less. AWS was not off 4 minutes.

[2Tall]

The ObserverIP, to my knowledge, doesn't have a battery backup for its onboard clock.  Therefore, it has to set itself from a resource on the network.  My router's clock is/was spot on. According to Ambient Weather, that resource is provided by WU.  The fact that the problem, which had existed for several days, was corrected shortly after contacting AW and registering my station with WU, suggests to me that WU does provide the source of time for the onboard clock.  I have no direct knowledge as to what hardware constitutes the time source they provide for the PWS or how their, presumably, dedicated servers are managed.

[dolfs]

The answers to all of this can be found in my thread about known issues. I've been working with Fine Offset and Ambient to get various things fixed or improved.

In short (all of this confirmed in working with Fine Offset engineering directly):

• The ObserverIP has an onboard hardware clock, but it does need to be set to a correct value at boot time and every so often afterwards to prevent unacceptable drift. There is no battery backup, so this clock is not preserved across reboots or power outages.
• The common mechanism for this would be an NTP client, but they do not currently have that in their firmware. Instead they are taking time from a response header from wunderground.com. NTP is now being considered.
• This also means that if they do not communicate successfully with wunderground.com, time does not get set/corrected.
• They are NOT taking time from AWS, but wunderground.com is hosted on AWS, hence perhaps this confusion. Presumably, but unknown, wunderground.com servers do use NTP and thus have a fairly accurate clock. This causes the clock on the ObserverIP, once set correctly, to be somewhat accurate, but there are problems with the approach, as outlined in my other thread.
• The 4 minute discrepancy and the fact that two of us had 4 minutes may have been coincidence. The move to Amazon would not have caused this this delay. Due to another problem (see the thread), the move to Amazon would have caused the ObserverIP to stop reporting (see other thread and failure to lookup DNS more than once). This eventually would have caused you to reboot the ObserverIP. As soon as it communicates with wunderground.com successfully once, the time would have been reasonable (within a second or so) again. Certainly in my case, when I had the 4 minute delay, it seemed totally coincidence. I am not updating to wunderground, so my unit was never setting/correcting the time. The time of day happened to be 4 minutes off, but the year was 2000!

[2Tall]

I don't think Ambient Weather support was suggesting that the time discrepancy was attributed to the new hosting provider, Amazon.  But rather, something may have gone awry during the migration process.

Their reported approach of parsing the header from the upstream server to set/update the clock reminds me of how most cellular devices keep their clocks synced via the upstream network. Perhaps a trend?