I am using an AirLink LS 300 with a 4.4.4 firmware. Everything was working normally until I installed a Lua Application with the Developer Studio for ALEOS. After that, the system always sets the time to January 1st 2000, 00:00:00 every time it reboots. I checked the system logs from the AceManager and before the installation the system was reading the time from the “Radio Network”. Using an NTP server is not an option because the 3G interface will not have access to the Internet in our deployment and the Ethernet interface will link to a local network of IoT devices.
Another problem is that the AirLink LS300 fails to boot successfully with the Ethernet cable plugged in. After successful boot with no Ethernet cable, plugging in the Ethernet cable causes no problems. I am using a Windows PC in this setup.
I tried to reset the device to factory defaults but this didn’t work. Which is curious because the Lua Application installation was erased in this reset.
I have another AirLink LS 300 device, using the same firmware, with the same Lua application installed and there are no problems with the system clock. The system clock is very important for our solution because we have to run scheduled tasks on the IoT devices.
Another point that I feel I should mention is that after installing the Lua application in the problematic gateway, the application is properly reported in the ACEManager and the AT commands. This is not the case with the other gateway, where everything else works properly.
All gateway configuration options are identical in both gateways. They operate on the same APN.
The installation of a Lua application shouldn’t have impact on system time management.
Like you said, even after the Reset To Factory Default (i.e. no AAF app anymore), you still have the issue.
The system time is not persisted. It is reset at each boot, then updated using one of available sources (Cellular-NITZ, GPS, NTP, …).
When the problem your describes occurs, does it last for a long time? Does the device obtain the GPS fix in that case too?
The other thing is about the second gateway where the AAF app is NOT “reported in the ACEManager and the AT commands”.
Is it possible the AAF app is running on the device using the AAF Studio “Run as -> Lua remote application” feature?
If that’s the case: the app is not installed and won’t be reported in above mentioned fields, and you may use the “Export -> Local application package” to install it.
A bit more context: the RTC (clock) is not battery backed (this is a hardware limitation). So whenever the device boots it tries to get time from either NITZ (i.e. cellular network), GPS (if activated), NTP (if activated).
If none of this option are possible the device will not be able to synchronize the time and will fallback to the date that you reported.
Note: this is kind of unrelated to Lua/AAF that just use system time as given by the system.
Thank you for the swift responses. We did some extra troubleshooting and tried operating the two Airlink LS 300 gateways with the SIM cards switched, and the problem disappeared from the one and appeared on the other. We probably have a faulty SIM.
As to the issue with the Ethernet cable, disabling the DHCP service on the gateway solved the problem. The gateway was configured to be part of the office network, which has its own DHCP service.
Before sending the SIM card for a replacement, I checked again that indeed there was a problem. The problem was gone. In the meantime, I had used the device for test installs from end users which included (unnecessary) firmware updates, using the Ethernet interface, not checking whether the 3G network is fully functional.
However, the problem is the same: after I install the ALEOS application, the system cannot get the time from the 3G network. I observed this time that enabling the ALEOS framework in the device did not produce any change.
Unfortunately that does seem to be related to the application framework so there is not much I can do. Your prb is how to setup system time from the Cellular network (on ALEOS). Do you have an FSE or support contact (distributor) you could ask to ?
Thank you for the swift reply. Trying the options for the SIM PIN (Don’t change, Enable, Disable) revealed that the “Enable” option temporarily solves the issue: on the next reboot the device will perform the clock synchronization successfully. On the subsequent reboot it won’t.
The SIM PIN option changes every time to “Don’t change” after reboot. The same holds with other device which has a different SIM, although there is no problem there.
The device succeeds in synchronizing the clock 1 hour and 1 minute after boot. This has been verified 3 times so far. I have no clue about what changes at that particular moment.