Stuck in infinite loop trying to sync to NTP server on ESP8266 - c

I am working on a project with an ESP8266 and trying to use a setClock function that, to my understanding, should configure the time based off of the NTP server defined in the 'TIMEZONE' variable. However, when I upload the program it gets stuck in the while loop because 'now' is getting set at 0 every iteration through the loop and gets incremented by 1 for every two iterations.
I'm assuming this means I am either defining TIMEZONE as the wrong NTP server (though I'm not sure how that would cause this issue) or the device isn't connecting to the NTP server properly.
This is where TIMEZONE is defined
// Pick a timezone from https://github.com/esp8266/Arduino/blob/master/cores/esp8266/TZ.h
#define TIMEZONE TZ_America_Kentucky_Louisville
and this is the setClock function
void setClock() {
// General C time functions: https://en.wikipedia.org/wiki/C_date_and_time_functions
configTime(TIMEZONE, "pool.ntp.org");
Serial.print("Waiting for NTP time sync: ");
time_t now = time(nullptr);
// 1546300800 = 01/01/2019 # 12:00am (UTC)
while (now < 1546300800) {
delay(500);
//Serial.print(".");
Serial.print(now);
Serial.print(\n);
now = time(nullptr);
}
Output
Attaching servo...done.
Initializing display...done.
Connecting to WiFi 'test'............done. IP 192.168.137.3
Waiting for NTP time sync: 4
4
5
5
6
6
7
I have verified that the ESP8266 is connected to the internet properly and the program also verifies it in the output.
I also tried commenting out the for loop to see if it would run anyway but the program says local time is 0:00 Jan 1 1970 which I know is just because the time is 0 seconds. This, however, causes the next part of my program to fail because it is using the time for x.509 validation.

Related

ALSA ignores configuration

I have an audio box that can be connected via USB to my laptop.
I've written a C application that uses the ALSA API to open a communication channel with this audio box.
The communication should be established at 8kHz, running with a 10ms period size (that is 80 samples).
If I'm connecting the audio box to my laptop and then start the app, it seems that the min period size supported is 170 (e.g. snd_pcm_hw_params_get_period_size_min sets min period size to 170), while snd_pcm_hw_params_set_period_size_near sets the period size to 170.
Looking to /proc/asound/name-of-the-card/stream0, I can see Momentary freq = 48000 Hz (0x30.0000), but the sampling rate requested by me is 8kHz.
Also, snd_pcm_hw_params_set_rate_near call, is not changing the value that I've passed.
By starting the app first and then connecting the audio box to my laptop, snd_pcm_hw_params_get_period_size_min sets the min period size to 16 and when calling snd_pcm_hw_params_set_period_size_near, the period size is set to 80 (which represents what I want to achieve).
Checking again /proc/asound/name-of-the-card/stream0, I can see Momentary freq = 8000 Hz (0x8.0000), that is correct.
I have to mention that my app is trying to open the card associated with the audio box and if the operation doesn't succeed, is retrying the open it every 200ms until succeeds.
My feeling is that in the second case when the period size is set accordingly, my application sets the configuration before the system does (I'm not sure if the system does this).
I've tried to modify defaults.pcm.dmix.rate to 8000 in /usr/share/alsa/alsa.conf, but in this case the period size that is returned by acting as in the first scenario is 1024.
Below are some configurations from /usr/share/alsa/alsa.conf if this helps.
defaults.pcm.minperiodtime 5000 # in us
defaults.pcm.ipc_key 5678293
defaults.pcm.ipc_gid audio
defaults.pcm.ipc_perm 0666
defaults.pcm.dmix.max_periods 0
defaults.pcm.dmix.channels 2
defaults.pcm.dmix.rate 48000
Is there a config file that has a higher priority than what I want to configure via the API?

GSM Telit GL865-QUAD AT command, error: 314 (SIM card busy)

I'm trying to communicate with GSM click module (Telit GL865-QUAD module) via UART with AT command. First I want to read all received messages, but for some reason I got error 314, meaning that SIM card is busy. Other answers from GSM are ok.
So this is my config (sending few at commands in a row):
AT\r\n (check GSM)
ATE0\r\n (echo disable)
AT+CMGF=1\r\n (set SMS text mode)
AT+IPR?\r\n (query current baud rate)
AT+CMGL=\"ALL\"\r\n (finally read all messages)
All commands have 1 second delay after gsm get positive (OK) answer. For example: send AT\r\n wait for OK and then wait 1 second; after that delay send another AT command.
Result: I got fine response from GSM when I sent first 4 AT command. But after the fifth one the modem returns error 310 (sometimes) followed by error 314:
AT+CMGL="ALL"
+CMS ERROR: 310
AT+CMGL="ALL"
+CMS ERROR: 314\r\n
I tried it with 2 different SIM cards and got same result.
Any idea or comment are welcome.
First of all, GE865-QUAD is an old device, so I recommend that you at least update it to the latest FW version. You can query current FW version of any GSM modem by issuing AT+CGMR AT command.
Edit: since you have a really old version (10.00.144 is dated 2009/2010!) I STRONGLY recommend updating it, since many bugs could have been fixed since then. You will be able to get last version from Telit site, and to flash it via UART.
Errors explanation
You seem to obtain error 314 preceeded, sometimes by error 310.
+CMEE Error: 314 means SIM busy, as correctly stated by your question subject
+CMEE Error: 310 means SIM not inserted
Possible solutions
First of all, make sure that the SIM is correctly inserted. It has to be pushed all its way in. I suppose you correctly inserted it, but a check has to be done.
Then, since you state that
I try with 2 sim cards and got same result.
I suggest you to check the contacts of the SIM holder (because it is unlikely that both your SIMs have bad electric contacts). In fact the SIM busy status, usually reached when a SIM is actually read (e.g. full phonebook) could also mean that some unconsistent action happened (also SIM failure massage can be shown in those cases).
Make sure you wait enough for SIM ready. In fact, even if SIM initialization usually takes less than a second, in some old SIM models might happen that a longer time is needed.
Telit provides a command to query SIM status: AT#QSS. As descripted by the AT guide, it enables an unsolicited message for any SIM status change. But it also allows allows, through its read command to query the status asynchronously:
AT#QSS?
Read command reports whether the unsolicited indication #QSS is currently enabled or not, along with the SIM status, in the format:
#QSS: mode,status
mode - the verbosity level of #QSS URC, set with AT#QSS=mode. Default value is 0; 2 enables the maximum verbosity level.
status - current SIM status
0 - SIM NOT INSERTED
1 - SIM INSERTED
2 - SIM INSERTED and PIN UNLOCKED (Note: available only if mode=2!)
3 - SIM INSERTED and READY (SMS and Phonebook access are possible) (Note: available only if mode=2!)
So you have to wait until status 3 is reached. I suggest issuing read command every 1/2 seconds until the desired status is reached. Issuing commands that involve the SIM storage before that status is reached will lead to SIM Busy error.
Very important: since status=3 will be shown only with mode=2, issue the following concatenated AT command in order to discover if the SIM INSERTED and READY status has been actually received without enabling URCs:
AT#QSS=2;#QSS?;#QSS=0
In this way, mode=2 is set just before the read command so that the full status list is supported. Then mode is restored to value 0, avoiding URCs to appear.
Make sure that the PIN has been inserted!
The SIM could be locked with the PIN code. Verify it by querying AT+CPIN?. If the response is +CPIN: SIM Ready you are fine. Otherwise, If the response is +CPIN: SIM PIN, you have to insert the PIN code by issuing
AT+CPIN=<PIN>
I found what was problem. Power supply for GSM did not have enough Amps.. For GSM you must provide 3.3V and 3A from power supply unit. GSM don't have 6.5W power consumption if you think that GSM need 3A all the time. GSM have peaks of current up to 2A and thats why you need more Amps.

How to fix MEMP_SYS_TIMEOUT in sntp client on stm32

On an STM32H7, I run LwIP, to learn more about raw API (NOSYS = 1).
Now, UDP (and TCP) server and client work just fine.
I'm next setting up an NTP client.
I initialize it this way (in sntp_client.c):
#define SNTP_CONF_IPADDR0 185
#define SNTP_CONF_IPADDR1 255
#define SNTP_CONF_IPADDR2 55
#define SNTP_CONF_IPADDR3 20
sntp_setoperatingmode(SNTP_OPMODE_POLL);
sntp_setservername(0, (char*)"pool.ntp.org");
sntp_init();
After start, I get the error
Assertion "sys_timeout: timeout != NULL, pool MEMP_SYS_TIMEOUT is empty"
failed at line 212 in
..\..\..\Middlewares\Third_Party\LwIP\src\core\timeouts.c
In Wireshark, I see no NTP packages are traced.
In sntp_init, sntp_request(NULL); is called, after which the time-out shows up.
What do I need to check next?
My source is here, the important part in in sntp_client.c:
https://github.com/bkht/LAN8742A_KSZ8851SNL_LwIP

NTP not syncing immediately on windows

I am trying to sync with NTP server, but server is responding with below messages.
Below are the wireshark captures.
Flags: 0x0c
11.. .... = Leap Indicator: unknown (clock unsynchronized) (3)
..00 1... = Version number: NTP Version 1 (1)
.... .100 = Mode: server (4)
Peer Clock Stratum: unspecified or invalid (0)
Peer Polling Interval: invalid (0)
Peer Clock Precision: 0.000008 sec
Root Delay: 0.0000 sec
Reference Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
My ntp.conf file has below enteries:
server 127.127.1.0
fudge 127.127.1.0 stratum 0
restrict 127.127.1.0
After some 3 minutes the sync is happening properly.But its not happening immediately.
Can anybody help me in resolving.
The fudge 127.127.1.0 stratum 0 line is telling ntp that your local server has the accuracy of an atomic clock. I doubt this is the case...
My guess is that your local clock is being used as a time source because of this line.
I believe that 0 should be a 10, which will tell ntp that unless there is another server in your ntp.conf that has a better time source(a higher stratum), do not use your local clock as a time source. This line is typically added to be used as a last resort.
ntp typically takes around 3 to 5 minutes to sync by default. Two things that can speed this up:
Use the iburst option in your ntp.conf
Manually sync to a time source using ntpd -gq

Using DHCP libraries results infinite loop

I have a code that uses DHCP libararies(package : 4.2.6) to get the hardware address of the DHCP client connected to the system. During this process after DHCP objects got initialized, i tried dhcp_connect() as follows which results into an infinte loop.
dhcpctl_initialize ();
status=dhcpctl_connect (&connection, "127.0.0.1", 7911, 0);
When i tried to debug the issue, i found a function "omapi_wait_for_completion"(in ompai/dispatch.c), has a do-while check for waiter object and its status, the object should change its state to ready to come out of the this loop, but this is never happened which results into an infinite loop.
Here i am just copying the loop as a reference.
do {
status = omapi_one_dispatch ((omapi_object_t *)waiter, t);
if (status != ISC_R_SUCCESS)
return status;
} while (!waiter || !waiter -> ready);
NOTE:
There is no issue when i run the binary generated from the code in system command line, but when i trigger the same command through an application we have this issue.
The application that triggers my binary doesn't uses DHCP libraries or files.
Please note that same binary with the same application is working
fine with older DHCP package (3.0.5).
Thanks in advance for your help.

Resources