I’ve been using the Nova in the recommended way: Linux, PPP, TCP/IP (and even MQTT) for some time. While this works quite well, it uses more bandwidth that I had hoped for.
For future applications, I think I might try just using Datagrams, which add some overhead, but far less than TCP (albeit with loss of reliability), thus keeping to a low-bandwidth profile. Of course it is possible in Linux to effectively turn off TCP (say, by using firewall rules), I’m not sure if this is compatible with PPP.
The other idea is just to directly talk to the U-Blox modem. For instance, I see here
AT+CGACT=1
OK
AT+upsd=0,1,"hologram"
OK
AT+upsda=0,3
OK
AT+usocr=17,87
+USOCR: 0
OK
AT+USOST=0,"xxx.xxx.xxx.xxx",7777,5
@ send 5 bytes to com port
+USOST: 0,5
OK
+UUSORD: 0,11 Bytes received from server
AT+usorf=0,255 Read 255 bytes only gets 11 in buffer.
+USORF: 0,"xxx.xxx.xxx.xxx",7777,11,"Hello There"
OK
+UUSORD: 0,26 more bytes from server
AT+usorf=0,255
+USORF: 0,"xxx.xxx.xxx.xxx",7777,26,"2018-02-11T20:30:03.675347"
OK
I see that in the datasheet, but what if an incoming datagram arrives at about the same time, could +UUSORD: 0,17 be injected first, or really at any time? In other words, I’m asking if the +USOST: 0,5 is guaranteed to be atomically the response to the transmit.
+UUSORD is the modem saying that it has received data packets.
Data packets stay in the receive buffer until they are read with AT+USORF.
Multiple packets can be retained in the receive buffer before reading them. FIFO
So, you have control over when to read them.
You might use a type of State Machine to handle what is received, when and why… etc…
But to ensure that no services (on Linux) leak any TCP communication or even other datagram transmission, one probably also has to set up iptable filtering to reject anything which might try TCP. Doable for sure, though maybe simpler by modem commands.