6 years, 5 months ago.

Receive data

Do you have sample code to send data from the conduit to the mDot? I have the successfully inserted into the MQTT server on the Conduit as I can subscribe to the down channel and see the data there, but in my mDot code, i keep getting an error of -5 returned from calling "recv".

Question relating to:

Library for LoRa communication using MultiTech MDOT. Lora, mdot, multitech

see this page on the MultiTech Developer Site for more info

posted by Mike Fiore 04 Jan 2016

2 Answers

6 years, 5 months ago.

The recv() function only checks to see if the mDot has received any data from the gateway.

The mDot automatically handles data coming back from the gateway. It opens receive windows at predefined times after transmitting to receive a downstream packet from the gateway. This is because the LoRaWan spec for Class A operation only allows a downstream transmission right after an upstream transmission.

recv() documenation in mDot.h

/** Fetch data received from the gateway
  * this function only checks to see if a packet has been received - it does not open a receive window
  * send() must be called before recv()
  * @param data a vector to put the received data into
  * @returns MDOT_OK if packet was successfully received
int32_t recv(std::vector<uint8_t>& data);

I suggest opening a support case on the MultiTech Support Portal if you need assistance with your Conduit gateway.

Thanks Mike for the response. So would i do something like:

send-data while (true) { if (recv() == MDOT_OK) { break; } else { wait(1.0); } }

posted by Anthony Huy 04 Jan 2016

Not quite. The mDot only receives data from the gateway right after transmitting, so calling recv() in a loop after a single send() is pointless. If you're expecting a packet from the gateway you need to do the following:

  • send a packet - it can have an empty payload
  • call recv() to see if the gateway sent anything back

If you're expecting a packet, and want to wait for it, keep doing these two steps until you get it. If you never get it, it's an issue on the gateway side.

Also, it's a bad idea to use wait() in your mDot applications. The mDot library uses mbed rtos, which means multiple threads are running. Anytime rtos is involved, any waiting should be done using osDelay() instead of wait(). The osDelay function sleeps that thread and allows others to process instead of just blocking like wait().

posted by Mike Fiore 04 Jan 2016

Can I get some clarification: (1) Will the "recv" function actually return the data to me in the structure I pass in? (2) Will that data be the ascii value of the string that I loaded up the MQTT in the conduit? (3) Do I need to use the function "openRxWindow"?

posted by Anthony Huy 04 Jan 2016

1) Yes, you pass a reference to a vector of bytes into recv() and it fills that vector with the RX data.

2) You pass a vector of uint8_t, so the data is in raw binary. It is simple to translate it to a std::string or a char* however.

3) No, you don't need to call openRxWindow().

posted by Mike Fiore 05 Jan 2016

Mike, On the multitech web site the following was mentioned for the Class A Device. "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."

Is that accurate? So does that mean as soon as I complete an uplink successfully, if I make a recv call, I should get some data back if there is a downlink ready to happen. So what is the scenario where there second downlink attempt would be made and in my code would it be better to wait for the second downlink window to occur if my first call to the recv returned nothing? If I need to execute an osDelay as you suggest, what would be the ideal time I will need to wait?

Thanks, Aj

posted by Ajay Kashyap 17 Jul 2016


That is accurate. If you call mDot::send with like the example does, the call won't return until after the transaction is complete. If data came back from the server, it will be available at that point and you won't need any additional delay.



posted by Mike Fiore 18 Jul 2016
6 years, 5 months ago.

I just found this: https://developer.mbed.org/users/mfiore/code/mDot_test_rx/ It helped me with exactly the same problem as you're having.

. Finding examples and good explanations on mDot is proving very difficult.