More messages than expected on application server.
-
My device sends messages of 12 bytes via cdp server udp to the application server. This works fine however several times per day I get an extra message with a length of 201 bytes. I logged al message from the device but these messages are not sent by the device.
-
@Martijn-Kooijman Yes, I had the same problems, took me a few days to improve it but I am still not satisfied. At first it seemed to run fine with 6 s delay after a SARA power up and reset, but messages sometimes were crazy long (never sent that), or skipped. A 30 s delay did give improvements. But, even after a 30 s delay a message may not arrive (about 1 in 10 in Allthingstalk). I do have the modem set to NB, to speed things up, but still it is slow. Today I increased to 35 s but no further improvement, still some messages are skipped. I am sending every 15 min 6 bytes, sometimes there is only one message in an hour! Reception is perfect. So my hope would be that a new firmware would make it faster.
-
@Crowdsourcer This is likely a firmware or T-Mobile network issue. In my experience Ublox modems are very reliable. Also be aware that UDP is unconfirmed and therefore some packet loss is inevitable. If you don’t want any packet loss you should look at COAP or LWM2M
-
It surprized me that several messages did not arrive because I had good results with the Sigfox implementation of IoT (if reception was good). @Stefan-de-Lange : So I will look into COAP, do you have some advice to get me started?
-
Update: the UFL antenna connector may not have been tightly connected, it was angled up a bit. It seems that these connectors soon develop some play after some light use. I will update you if this solved it.
-
@Stefan-de-Lange I dont see packet loss I receive more messages than I should! I can ignore them because they are a different size than my messages but it seems strange that more mossages are coming in than send by the device. Could it have something to do with the fact that I dont receive downlink messages anymore?
Also I am using community atm for testing so coap is not an option I think? -
No, antenna plug seems fine, still 30% message loss this afternoon.
-
@Crowdsourcer What is your interval I am senden every 30mins and see no loss Only more messages. But dont receive downlink does downlink work for you?
-
@Martijn-Kooijman *sending
-
@Martijn-Kooijman I think you may have a problem with the data packing. You probably defined a String datatosend, then datatosend=(const char*)&payload; where payload is an array of several bytes of data you want to send (like with TTN)? It goes nuts sometimes, but not always, so you may think it works but it is not correct, even if you have declared it with attribute((packed)). Solution: just send an int array (After AT+USOST=…).
-
@Crowdsourcer It could be but I receive all messages I expect + someimes an extra message of length >200 bytes 1,5 minute later, my structure is:
typedef struct attribute ((packed)) message {
uint8_t l1;
uint8_t l2;
uint8_t l3;
uint8_t n1;
uint8_t n2;
uint8_t n3;
uint8_t x1;
uint8_t x2;
uint8_t m;
uint8_t v;
uint8_t y;
uint8_t z;
}Message;Message msg;
which I send as:
Udp.write((uint8_t*)&msg, 12); -
I also tried this with a nice struct, tried char* or uint8_t*)&msg,… and also got now and then huge messages for no reason. Depending on the first values I got everything right or nothing in the rest of the variables. So I changed it to:
payload[0] = (byte) ((temperature_coded & 0xFF00) >> 8 );
payload[1] = (byte) ((temperature_coded & 0X00FF) );
etc… (temperature is a 16 bit value)
and send payload directly, never bogus or double messages anymore! Important to declare payload as: char payload[size]
It could be a SAMD issue, just try it and let me know if it solves your problem. -
@Crowdsourcer Thanks, I will try it and will let you know the results! Do you also use downlinks and do they arrive on the device?
-
No, I haven’t checked downlinks yet, so far I didn’t need them.
-
@Crowdsourcer Ok I did the changes assuggested, and until now no long extra messages… but I just checked the logs from yesterday and the day before and it didnt occur the last 1,5 days either (I think I reregistered the application server then.
Anaway thanks again for the suggestion! -
@Martijn-Kooijman Probably linked to certain values that did not occur these days (low values were causing problems for me). Also your double messages problem should be gone now.
-
Well I still have double messages however I think thats because I use deep sleep and do atpwroff to turn of the sara module.
-
Sleep or deepsleep gave the same power consumption, so I only use sleep.
Switching modem off to conserve power it worked best to switch of power to the modem: digitalWrite(SARA_PWR_ON, LOW);
It reduces current to about 1.2 mA during sleep, this is a bit disappointing. Do you achieve lower values? -
@Crowdsourcer I guess I was unclear I do the following:
- close udpsocket
- do a ATPWROFF to turn off Sara
- modem power down.
I havent measured yet but with the MKRFOX1200 we had a sleep current around 100 uA but this seemed to be very device specific some were 80 uA others 120 uA. I would expect somithing similar with the MKRNB1500 as the modem is turned off. I will do a quick measurement tomorrow and let you know the results
-
@Martijn-Kooijman @Crowdsourcer According to datasheet SARA R4 will do 8uA in sleep mode.
-
Yes, I know, but there are more IC’s on that board: encription, charger, arduino, etc. and they too should have a low sleep currents. So far, I haven’t found anybody to get this board below 1 mA in sleep… (measured from the LiPo current).
-
@Crowdsourcer That would be very bad. 1 mA is way too high for sleep mode.
-
See also: https://forum.arduino.cc/index.php?topic=622051.0