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?