Fault/low signal tolerant sketch for use with thingspeak

This is a continuation of the work found here:

https://forum.arduino.cc/t/sketch-to-http-post-to-thingspeak-and-what-i-have-learned-so-far/658503

Here is the code:

https://docs.google.com/document/d/1Nuj6hWJ7Ra03G463l6qcb8k6oGoWYt2K7CoJckuIQKQ/edit?usp=sharing

The whole idea was to make a sketch that could tolerate the wide range of issues that can arise when using this modem(SARA R410M) in very low signal.

I started from the ground up and decided to handle all communication with the modem. Each command is sent to the modem with a timeout. During this timeout period the main loop can be doing other things. The main loop builds a char array containing the modem response. No delays can be used in the main loop!

The sketch updates thingspeak fields every 10 mins. It also reads commands from field 5 of the thingspeak channel. "ledon" & "ledoff" will toggle the onboard LED. The best way to send commands to the channel is with android app "Restler". Below is an example config:


Major changes since last thread:

  1. To ensure all unused sockets are closed, "AT+USOCL" is used to close each socket (0-6).
  2. Instead of passing a hostname to "AT+USOCO", an IP address is resolved ahead of time using: "AT+UDNSRN". If USOCO is passed a hostname, it will have to look up the IP address on it's own. This consumes data and can take a fair amount of time. Instead, the sketch uses UDNSRN to look up an IP address once every hour.

Made the following changes:

  1. +UDNSRN does not use the standard "+CME ERROR" upon error. Instead it just replies "'ERROR"'. I changed the sendCommand() function to look for this.
  2. Some http servers reply with "content-length" instead typical "Content-Length". It will now look for both.

Just keeping this thread alive. I have some changes/fixes that I will apply to this sample soon.

Chhhcckk...A small step to a new MKR library...chhhhkghh... a giant leap for all mkr1500 users..chhhchghckhh

I still have some updates on this that allow longer http server responses. I just haven't had a chance to integrate them into this sample program. Hopefully soon.

1 Like

Sounds good! I'm about to migrate all tasks to the server and just use mqtt..

I have updated this with some improvements/fixes.

  • It can now handle server responses that are longer than the modem buffer.

  • Fix two char arrays that were not long enough:
    char thingspeakIp[16];
    char socketCloseIndicator[11];

  • Added functionality to soft reset modem if it gets stuck and only replies with "Error" to AT command "AT+UDNSRN".

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.