MDot Recieve and retries.

[Ajay K]

This was mentioned regarding LORA. “For Class A end-devices, each uplink transmission is followed by two short downlink receive windows in which only one packet can be received. The second receive window is only opened when a packet is not received within the first window.”

1) Should I run the mdot->recv method as soon as I have transmitted successfully?

2) If so according to the documentation for Class A end devices there could be two receive windows, how are they spaced in terms of time between the two receive windows? If I don’t receive any packet, should I retry a fewer times with a delay until a certain timeout? What would be the ideal timeout for a failed receive, assuming there was an expected downlink.

3) Also during transmits for uplinks, should there be time delay between successive transmits based on the spread factor? If so how does one determine the delay between the transmits?

Thanks,
Ajay.

[Jason Reiss]

Just one call to mdot->recv is needed.
The windows will be opened behind the scenes.

https://developer.mbed.org/teams/MultiTech/code/mDot_AT_firmware/file/6a12bf1f6723/CommandTerminal/CmdSendString.cpp

Otherwise see lines 46 and 754 to handle receive asynchronously with a custom event class.

void CommandTerminal::RadioEvent::MacEvent(LoRaMacEventFlags* flags, LoRaMacEventInfo* info);
https://developer.mbed.org/teams/MultiTech/code/mDot_AT_firmware/file/6a12bf1f6723/CommandTerminal/CommandTerminal.cpp

[Ajay K]

Thanks Jason for your response.

1) If I got it right the first link I would execute a transmit followed by a recv and this would be the synchronous operation. I guess this should work out in most scenarios correct and more or less a blocking call.

2) The second link describes the asynchronous operation. However I am a little confused about it, since in the serial loop method once the transmit is executed, there seems to be a recv being called. So when does the RadioEvent:: MacEvent(LoRaMacEventFlags* flags, LoRaMacEventInfo* info) get invoked? Also the if condition in the code below is when data is received and rxBuffer is a pointer to a vector of bytes?

if (flags->Bits.Rx) {
if (serial_data_mode) {
logDebug(“Rx %d bytes”, info->RxBufferSize);
if (info->RxBufferSize > 0) {
_serial.write((char*) info->RxBuffer, info->RxBufferSize);
}
}

}

Ideally I would prefer making a non blocking call via the send and receive the data asynchronously, so that none of the threads are blocked for IO.

Thanks,
Ajay.

[Ajay K]

Jason,

Just wanted to clarify regarding the asynchronous functionality. Do I have to explicitly call a recv method on the mDot object or is it good enough to call the Send and the corresponding LoraMacEvents will fire as shown in the source code that you shared and eventually the recv event would fire?

Thanks,
Ajay.

[Jason Reiss]

After Send the MacEvent will fire for TxDone and RxTimeout (not packet received) or RxDone (packet received).

recv() does not need to be called it is used to retrieve the data in blocking operations.

See libmDot headers for event info.
https://developer.mbed.org/teams/MultiTech/code/libmDot/file/121e4c454964/LoRaMac/LoRaMacEvent.h

[Ajay K]

Thanks Jason for your response. Makes things a lot easier to manage in an asynchronous fashion and the events make it lot easier to manage the next uplink as well.

Thanks,
Ajay.

[Ajay K]

Hi Jason,

I have a follow up question. mDot API has an getIsTransmitting function to check if there is current uplink in progress. However after a send is executed in a non-blocking mode and as I would have subscribed to the LORA MAC Events, I would receive the various events as described by you in the earlier.

My Question is since I would be executing a Send in a non-blocking mode and lets say there was a down link packet expected. Would I be able to transmit immediately or the receive needs to complete before any transmit can occur? If so would I need to use some kind of thread synchronization such as MBED’s thread Signaling, since I am assuming the LORA MAC events are running on a different thread.

Thanks,
Ajay

[Ajay K]

Any thoughts related to the sends while the downlink packet is being processed by the Lora MAC events? Does the MDot API handle this scenario without any custom code being written?

[Author]

Posts