Purpose of AT+RECV and AT+RECVC

[Paul Klapperich]

I’m currently evaluating the mDots using the factory firmware, and I noticed the AT+RECV command to receive packets as well as the AT+RECVC. But it seems that sending a message from the conduit really just puts the message in a queue and waits for the mDot to initiate communication before transmitting. This makes sense for the construction of low-powered devices; standard use case is something like mDot on a battery spends most of it’s time in sleep state, wakes on timer/pin activity to transmit some status and then go back to sleep.

I found on which confirms the intentional nature of this

Because Conduit and mDots are currently designed for the LoRa Class A specification, the Conduit can only send a packet to an mDot during one of the two receive windows the mDot opens after transmitting a packet to the Conduit.

But then why do AT+RECV and AT+RECVC exist? And if there are several messages queued to send in the conduit, is it possible to send them all after the mDot sends 1 message, or is it always 1 message received for 1 message sent to the conduit?

[Jason Reiss]

The conduit will send only one message downlink per uplink.
Otherwise there would be some format needed in order to concatenate two packets.

AT+DP (data pending) will tell the end-point if there are more messages available on the server.

AT+RECV shows the last packet received, which was also displayed after AT+SEND

AT+RECVC is used to for testing receive functionality of the radio outside of LoRaWAN when doing compliance testing

More info can be found in our AT Command Guide
http://www.multitech.com/manuals/s000643_1_1.pdf

[Author]

Posts