Satellite Internet / Real Time Clock

I received my IoTaWatt today (thanks). Still trying to make sure my problems aren’t related to my network, but wanted to post a question about satellite internet.

I have Satellite (ViaSat). It works fine for normal PC/Mobile use, but has slow latency. About 750ms ping times. I saw one thread saying to take it to another location to set the clock. Are there known issues using the IoTaWatt on satellite? Or have issues already been fixed with a firmware update?

I booted up my new IoTaWatt and managed to get it to connect to my Wifi (“gg”). Configured my DHCP server for the IoTaWatt MAC address. Everything is working as expected. It’s on my lan, dhcp’d properly, and making DNS queries to my local DNS server. I also setup network rules (iptables/nat) to give it full internet access.

But I can’t seem to get the time to sync. This is the extent of my log from bootup to restart (when I try to see if it needs a “kick”).

SD initialized.
Real Time Clock not initialized.
Version 02_03_18
Reset reason: Power on
Trace: 39:78[188], 104:224[174], 130:246[132], 161:236[4], 91:224[160], 89:168[101], 55:99[190], 229:227[87], 18:37[35], 218:232[243], 134:105[52], 139:5[125], 29:26[47], 8:198[137], 101:195[163], 12:77[126], 253:157[15], 143:77[37], 24:228[173], 173:35[104], 190:106[35], 126:152[158], 153:66[251], 240:242[55], 45:51[32], 73:195[176], 220:80[216], 229:5[42], 37:93[59], 3:71[208], 127:36[75], 153:74[188]
ESP8266 ChipID: 6910484
SPIFFS mounted.
Local time zone: -5
device name: IotaWatt, version: 3
Connecting with WiFiManager.
MDNS responder started for hostname IotaWatt
LLMNR responder started for hostname IotaWatt
HTTP server started
timeSync: service started.
statService: started.
WiFi connected. SSID=gg, IP=, channel=1, RSSI -46db
Updater: service started. Auto-update class is MINOR
Updater: Auto-update is current for class MINOR.

I don’t see any errors or retries. Does it only try once and give up, or keep trying?

From my server, I see it contacting DNS every 10-20 seconds. And the occasional broadcast. Still not 100% sure it’s getting out, or if it’s even trying.

Apologies in advance if something in my network is misconfigured. Have been messing with it for a few hours. Still trying various things, but I’m pretty sure the network is good.

Would satellite internet cause something like this (latency too slow)?

Thanks again,

FYI. I also tried /command?disconnect=yes to reconnect to a mobile network/hot spot, but had the same result (Real Time Clock not initialized). That’s all the ISP’s I can test right now.

I don’t have any experience with satellite internet or any way to develop and/or test functionality with it. It’s pretty clear that your IoTaWatt has not acquired a time fix to set the RTC.

I can see that the timeSync service has started, and it should be repeatedly trying to get the time from Whatever DSN resource is available should be resolving that URL to an IP address, and then timeSync send a UDP NTP request to the IP. When the RTC is not set, the timeout for the request is 10 seconds.

There is logic to validate any time that is returned. Essentially the IoTaWatt wants two consecutive time fixes that agree within one second to set the clock. That may be a problem with your internet connection because the timeout is a whopping 10 seconds and the latency is assumed to be symmetrical.

What others have done is take the IoTaWatt to a terrestrial internet and allow the RTC to be set, then move it to the internet challenged location. The RTC typically is +/- 1 second per day, so it should be reasonably accurate for a long time. Others have had success adding a cellular internet to their LAN through a phone hot-spot from time to time.

Although all the pieces are there to run without internet, unfortunately, the time is something that has to be resolved before that can happen.

I have a home automation system that allows users to set the device’s time from the current web browser’s time. Their hardware does not have a battery backed up RTC, so this feature is necessary if you have to restart the device without any internet. I had to do this during Hurricane Florence a few months back, to make sure all of my home automations ran at the correct time. Once the internet was back up, the automatic time-synch feature took over to make sure things stayed in synch.

Perhaps this is a feature that could somehow be added to IoTaWatt? Just an idea… :slight_smile:

and a good one. I’ve had that feature in mind for awhile now, just no urgency to put it in. I’m in the middle of doing PVoutput support right now, but I’ll see if maybe I can add that at the tail end of the project before I cut a release.

1 Like

Tried the mobile connection again this morning and managed to get it working. Haven’t truly debugged what was happening.

I should look at the code, but it’s easier to ask @overeasy : ) Wondering if the validation requires two consecutive time syncs within 1 second (which I can’t do on satellite), or if it sets itself on the first sample, then checks again later (could be 10 minutes later) to see if it’s still within 1 second of the “official” time.

Thanks @ogiewon, I was also trying to figure out a way to fool the iotawatt into thinking was my local NTP server. But fortunately I didn’t have to mess with that. Maybe after future investigation, I can see if my local NTP server (which syncs with can “feed” the iotawatt. Or possibly a configurable time server in the firmware(?) so it can be changed to a local server.

Thanks as always. On to more fun stuff, like cracking open my electrical panel!

1 Like

It requires two successful requests, but not necessarily within one second, or even without one or more intervening failed requests. Just two consecutive successful requests that agree with each other to the resolution of one second.

It would be good to allow users to set the name/IP address of the time servers to validate/use. It is considered a best practice for NTP to do that. Having the default be is fine as it load balances.

Doing this allows people, who know what they are doing use a local NTP provider, which can work when the internet is down.