@intstarep , I have seen many of your posts and you seem to know more than anyone about the modem issues in the MKR NB 1500 and the libraries. I hope you can help me.
I have three issues I hope you can help me with.
I am using the Arduino IDE 2.1.1, I updated the modem firmware to L0.00.00.05.11, A.02.16. I have a Hologram SIM. I have no problem connecting to the GPRS network. I have successfully sent SMS messages, and other example programs with success.
Issue1. I want to use UDP to Listen on a port (e.g. 2000). I based my program on the example program GPRSUdpNtpClient. With my program and the provided example program, the first time I run the program it works and I receive UDP packets. If I reset the board, or make a change and upload the program, then it doesn't work. The AT+USOLI=0,2000 causes ERROR to occur. The the correct socket number is being used. Powering down the board causes the program to work OK. Is there a fix for this? A safe way to reset the modem in my code perhaps? I see several discussions about this on the forum, but not a clear answer, at least to me, as to best solve this problem.
Issue2. Listening on UDP port 2000 I have sent a UDP packet via the hologram dashboard messaging tab, and using the generated webhook. I do receive the packets I send, but they come on average 1.5 to 2 minutes after the UDP packet was sent. Is there anything in the modem that would cause the reception of a UDP packet to take so long? To rule out the MKRNB library, I used the SerialSARA program and sent AT+USOCR=17, it returned +USOCR: 0, then AT+USOLI=0,2000. (never had any error doing this), The same time lag occurs. I wondered if the modem received the UDP immediately, and did not pass it on, but waited until some timer ran out and then sent the +UUSORF: 0,12 later? The time delay has been from 16 seconds to 15 minutes later, averaging 1.5 - 2 minutes. I was expecting a delay no longer than 1 second. Any ideas?
Issue3. I have had good luck running almost all of the example programs. In particular Sending SMS messages works great. I get no response at all with the Receive SMS program. Normally I would have to pay for a phone number from Hologram in order to receive an SMS. In the Hologram dashboard messaging area they have a way to simulate sending SMS to the device and that was what I used. This last issue is not as important as issue 1 and 2, but thought I would throw it out there.
Hello @twesthoff, thanks for the compliment, it's true, i spent a lot of time between the modem and the board but i also don't know exactly whats going on there...thats why i migrated every functionality to the server and i only use mqqt today: i open only one tcp socket for the connection to the mqtt broker, listen to a topic for the connection to the board and write to another topic for sending data. That works stable on all boards (MKR 1010, 1400,1500) with the same code. Since that migration i have no issues with the modem anymore but i'm also out of that topic but i try to help you:
Issue 1) Probably another example for timing problems between the MKNB lib and the modem. For the reset, there are codes likes
This is an example for the MKR1400, but you'll find also for MKR1500. The problem is that the modem is still powered and if stuck, this trigger of the reset pin has no effect. So as you experienced, only power cut resets the modem. IMHO there is no solution than a working code for this problem because it's a hardware issue.
Issue 2) No ideas, i spent too much time trying to resolve and understand these sort of timing problems without real success. The thing is, that the modem behaves different due to signal strenght, other AT commands, the moon, the stars, whatever. In your code you expect to send a AT command and then get the AT answer for that command in expected time. But it's not like that. Sometimes you get a answer for another socket, an error, whatever, it's not predictable. And also VERY hard to debug because the only info is "ERROR" and it's all over that AT console..thats why i gave up trying to solve those problems. Sorry i can't deliver a more motivating answer.
3) I remember i had the same issues with the MKR1500, it was a firmware problem, the modem loaded just one sms from the mobile network and then i had to reset the board. Try to update to the latest firmware. My solution was to migrate the communication from user to the device also towards mqtt. I coded a simple PWA website to be installed on the mobile (With the new Safari you can also use notifications now instead of SMS). This PWA sends a GET/POST to the server which sends a MQTT message to the topic towards the device.
Summary: I can't help you properly with your issues, instead i can only explain how i solved the problems, until now with very good results, it works with all boards with the same code without issues.
Good luck!
Thank you for the response! For the reset code you showed, is the SARA_RESETN supposed to go HIGH again later?
Or, is entire code you showed, reset and power on/off,supposed to both be used as one procedure to attempt to reset the modem?
I have good signal strength, value 26, so that is good.
I tried the Arduino example MQQT program and it worked. There was a delay there too receiving. From time MQQT message was sent until I saw the receive message was average of 16 seconds. If two messages sent close together the second came almost real time. If messages sent with longer times between, like 1-2 minutes, then message received was 16 seconds after sending. The 16 second delay was why I wanted to try the UDP, which surprisingly was worse.
I have support ticket in with U-blox. I wonder what they will say...
Looking at SARA R410M commands, I see the modem has native support for MQTT built in. Did you use that?
It's hard to support such an issue, i would expect nothing. Your description sound to me for bad signal. Keep in mind that MKR1500 uses the NB Band only, so it's possible to get a good signal but the band is disabled on the antenna you use. I had the same issue, thats why i went back to MKR 1400. Make sure LTE-M is enabled in your area or you will be misleaded.
I started a new MKRNB once (My real name is Cpt. Holzschnauz) for that set of commands
it works but it's unfinished (merge requests welcome) since i use the wonderful MQTT lib from Joel:
My recipe is to use the MKR1400 instead of a MKR1500 because the LTE-M is not available worldwide. Then is check the signal quality for a minimum value and establish a TCP socket for the MQTT lib from Joel. After that, eveything is over MQTT, sending SMS over a service (Routee.net). Or i use the MKR1010 with a LTE Modem that is capable for all bands worldwide (RUT 950 Teltonika with worldwide coverage).
I would like to see a MKR1600 with full LTE capability (a new U-Blox modem) from Arduino. I don't understand why its not here due to the fact that the U-Blox Chips are pin compatible.
Probably sandeepmistry (Sandeep Mistry) · GitHub is missing.
Thanks for info. I have a lot to read now. Here in the US, 1400 will not work. No GSM available for at least a year now.
What country do you live in? I had already guessed your other name on Github
I am fairly sure I am connected using LTE-M. I will check to see.
I agree, the MKR 1600 would be a GREAT thing to have, and so easy to do like you said. Where i used to work we had equipment that could remove and replace the modem, but I don't have access to that now. Sad.
Here is reply from U-Blox. Yes! They did answer. Confirmed my suspicions...
Hi Tom,
How are you sending the UDP packet to the modem? If you are sending the UDP packet from the Messaging tab in the Hologram Dashboard, I believe this is an issue with latency of the dashboard / Hologram network because I see the same behavior when sending UDP packets in this way. However, there are no known issues with reception of UDP packets on the SARA-R410M-02B, it should present the +UUSORD URC as soon as the network delivers the packet. We have many customers using SARA-R410M-02B for UDP listening sockets in volume deployments and have not received any reports of issues. u-blox has sold roughly 12 million SARA-R410M-02B modems.
I would suggest reaching out to Hologram to investigate why it is taking so long to deliver the packet to the modem. They should be able to perform an IP trace to check how the packet is moving through their network.
Issue 2 has been causing me some grief as well. As I understand it because UDP is fire and forget there is no guarantee of delivery or presumably when! Playing around with various networks in the UK seems to show different operators have different timeouts on their routers ARP tables, this means that quite frequently the first UDP packet is lost. As a rule of thumb for me I have had some success by sending the same message three times about fifteen seconds apart. You then need a message counter/ID so that you don't action the same message more than once. Doing this might speed up your UDP delivery and then again it might not.
@ithinkivegotthehangofthis I think the time to traverse the Internet is very similar for UDP vs TCP so delays shouldn't much different. As you said UDP is fire and forget, so it is best to have some kind of application layer protocol to make sure they get there. I agree, sending multiple times is also a good idea. I often add a number, kind of like a timestamp, if I send multiple UDP packets. The receiving end compares the number and ignores those with the same number, or in other words, only accepts when the number has changed. That way any number can be sent with the same number and only one will be considered valid.
In this case, since there is no way to send data directly to the SIM device from the Internet, Hologram has a Webhook that you can send to their Server(?) with data appended, which they then forward on to the SIM device. It appears that path is very slow, or they have a bug in that process.
It my be just a UDP thing. It may have been designed for TCP with UDP as an afterthought.
I'd like to try setting the Webhook for TCP and seeing if it goes through their system faster.
I haven't figured out how to do that yet with the Arduino library. I'm also not sure that the webhook allows two way communication. It is something I would like to try though.
After weeks of Hologram tech support, and U-blox tech support the following solved the problem:
This is what did it! Response is now always under 3 seconds. Disables eDRX, the network can put the modem to sleep for a period of time after inactivity as I understand it.
AT+CEDRXS=0,4
This turns off power save mode (optional):
AT+CPSMS=0
