vAnArhist
commented
2 years ago We are attempting to Join and send messages to MachineQ (MQ). MQ recommends sending a message immediately after a JoinAccept on the same channel that was used for the successful JoinRequest. We think this is so MQ can send a channel mask to inform our device which channels are "legal" to transmit on. If we don't do this, we can monitor (unconfirmed) packets being sent, but not received by MQ. Eventually, a message does go out on a "legal" channel and is received by MQ and MQ eventually responds with a channel mask, but a lot of data is lost prior to this happening. We suspect that these messages are not received because they were not sent on the "correct" channel. Since we don't seem to see API access to specify what channel a send should go out on, we decided to try to send a Confirmed Message. We expected to see the packet go out (which we do), but if it goes out on a "not-legal" channel, and therefore no ACK is received, to see other attempts (assuming each attempt would use a different channel). We don't see any retries. The Confirmed message is never ACK'd and the device simply attempts to send its periodic data (with many early messages not arriving at MQ).
Our assumption is that to send a Confirmed Message one simply uses LMHandlerSend() with a type that indicates LORAMAC_HANDLER_CONFIRMED_MSG and that the MAC layer handles the retries, etc. Is there something that we're missing?
Thanks!
Hi @DrEdHepler ! Any luck with that? Seeing the same behavior with Area8C. Seems that on server side they use 1.0.2 spec.
We are attempting to Join and send messages to MachineQ (MQ). MQ recommends sending a message immediately after a JoinAccept on the same channel that was used for the successful JoinRequest. We think this is so MQ can send a channel mask to inform our device which channels are "legal" to transmit on. If we don't do this, we can monitor (unconfirmed) packets being sent, but not received by MQ. Eventually, a message does go out on a "legal" channel and is received by MQ and MQ eventually responds with a channel mask, but a lot of data is lost prior to this happening. We suspect that these messages are not received because they were not sent on the "correct" channel. Since we don't seem to see API access to specify what channel a send should go out on, we decided to try to send a Confirmed Message. We expected to see the packet go out (which we do), but if it goes out on a "not-legal" channel, and therefore no ACK is received, to see other attempts (assuming each attempt would use a different channel). We don't see any retries. The Confirmed message is never ACK'd and the device simply attempts to send its periodic data (with many early messages not arriving at MQ).
Our assumption is that to send a Confirmed Message one simply uses LMHandlerSend() with a type that indicates LORAMAC_HANDLER_CONFIRMED_MSG and that the MAC layer handles the retries, etc. Is there something that we're missing?
Thanks!