Setup
I am using the Nova (SARA-R410M) on a Raspberry Pi 3 B+ running the latest raspian os (Buster). This hardware is intended to function as a gateway. It receives IoT data from remote sensors via RF (XBee S2C), formats it and then sends it to a cloud server via MQTT. Everything works. Sometimes.
I am using Ruby SerialPort for USB serial communications to the Nova. I have a hologram sim card which connects to “hologram” via a local carrier (Rogers, in Canada, I believe). I am able to send SMS messages via a serial terminal (minicom, in this case).
Operation
I am able to identify the correct USB port, open it, send various commands to the Nova. These include basic config commands such as AT, ATE0, AT+CCID, AT+CGSN (which returns 15,99), basic MQTT commands such as port setup (AT+UMQTT=1,<port>) and server setup (AT+UMQTT=2,<domain>), both of which return success. However, when I attempt to login into the MQTT agent - AT+UMQTTC=1 - I get an error return code (1,0). Subsequently issuing AT+UMQTTER returns 350,-20043, which is listed as “MQTT TCP connection error (QAPI MQTT)”.
Other observations
The odd time, the login is successful and I can follow up with MQTT publish to a topic commands, which then work and are the whole point of all this.
It doesn’t seem to matter where the MQTT agent is (eg test.mosquitto.org, or AWS, etc) - they all fail
It also fails when I send to the Nova from the serial terminal
If I issue a mosquitto_pub -h… from the command line in the RPi, it works fine. This command logs into the MQTT agent and sends the topic and message.
I didn’t have to do anything further with Rogers - the Hologram sim card worked ‘out of the box’. Apparently Rogers has rolled out their CAT-M support and Hologram is on board.
Next
The issue appears to be in the transport layer. I suppose there are a lot of moving parts that integrate a number of newer technologies and I suspect there are lots of bugs in the system.
My next step might have been to bypass the hologram MQTT api and implement a basic MQTT library myself. But this would rely on the SARA R4 IP transport layer, where I believe the current issues are lurking. Writing such an MQTT library would probably run into the same issues. Hence my posting here…
Hmm with an RPI and Nova you dont need to use the AT commands (although I agree it should work). You can use the Nova in the same way as a USB wifi adapter and it will appear as a generic network port you can use in the same way as wifi / ethernet. Basically use python mqtt libraries and the linux TCP/IP stack over the nova network connection.
You say you are using the “Hologram MQTT API” but it looks like you are using the U-Blox AT command API.
You also say:
If I issue a mosquitto_pub -h… from the command line in the RPi, it works fine. This command logs into the MQTT agent and sends the topic and message.
Is this using the Nova as your network connection as I mentioned above? If so you should just do it that way.
There are some downsides to this (you cant send AT commands at the same time to get modem state / reconfigure / etc, also like Wifi / ethernet other software inducing the OS may try to use the network to download updates / etc.) But if it works there are ways to address these concerns. In general I try to avoid the complex application layers on embedded modems because of issues I have experienced and difficulty debugging.
Correct, I meant to say I was using the AT command API. All communications with the R4 are ultimately serial so I don’t think using the MQTT API vs AT commands would make a difference.
I should also have mentioned that I already have a working gateway running on the RPi. The data is sent to the RPi via an XBee network. A Ruby app uses an MQTT gem to connect and send data to an MQTT agent in the cloud via local WiFi to the internet. All pretty standard stuff, but not without issues.
This is the whole point of the cellular ‘upgrade’: to replace the WiFi network with a cellular network. The main reason is that to use WiFi the gateway has to reside physically and logically in my clients’ local area network. This has turned out to be problematic for a number of reasons: clients unplugged the gateway or moved it to an untested location, or the client’s router was flaky making it difficult to join the network, or to stay connected once you have. IOW, with the WiFi solution there were a lot of ways to fail even if the gateway hardware and software worked perfectly.
Hence this cellular experiment using Hologram and Nova with the R410M. I am interested in the “issues you have experienced” and how you resolved them.
During further testing I moved the hardware to a location that gave slightly better signal quality (20-21 vs 17-19) and that seemed to improve things a little. That is, MQTT login (AT+UMQTT=1) succeeded more often after a fresh start. However, eventually I get an error doing an MQTT publish (AT+UMQTT=2,0,0<topic>,<message>) after which all subsequent publishes also fail. The error is usually something like -20041: MQTT Socket fatal error (QAPI MQTT) or -20043: MQTT TCP connection error (QAPI MQTT) or -20027: MQTT Connection is in bad state (QAPI MQTT). I also see 28: No MQTT connection when attempting UMQTTC which is probably the consequence of the former errors. Attempting to reconnect to the agent invariably fails. It usually takes a reboot of the RPi to restore the Nova to a ‘usable’ state. Sometimes it takes more than one reboot. Then the above scenario repeats (login, publish data… fail, reboot).
This may simply be the result of a weak signal. However, like using any cellular device, this is part of the normal operating procedure. I feel there must be a way to ‘restore’ the Nova back to a usable state without a power cycle. I have experimented doing a reset (AT+CFUN=15) but that didn’t seem to work (or maybe I didn’t wait long enough afterward, or perhaps there is other initialization that needs to be done after, or…?). Any suggestions for a clean restart would be greatly appreciated.