Sending messages to WisBlock over MQTT

Hello Folks,

I am using the Wisblock 4631 development Kit and using The Things Network for testing.

I am successfully able to send the WisBlock a JSON message over MQTT but the data I am sending is not being decoded properly on the Wisblock side the way I thought it should be.

In TTN, I selected the device, selected Messaging, selected Downlink, selected JSON and Pressed the Schedule Downlink Button after entering the following JSON text.

   {"downlinks":[{"f_port": 1,"frm_payload":"AQ==","priority": "NORMAL"}]}

The base64 value of 01 (AQ==) is being passed

I can see the Serialprintf statement being triggered, and my loop is being triggered, but my data size is 0 and the data is blank,

    LoRa Packet received on port 1, size:0, rssi:-33, snr:11, data:

Here is the lorawan_rx_handler being used.

  void lorawan_rx_handler(lmh_app_data_t *app_data)
    Serial.printf("LoRa Packet received on port %d, size:%d, rssi:%d, snr:%d, data:%s\n",
            app_data->port, app_data->buffsize, app_data->rssi, app_data->snr, app_data->buffer);
    int i = 0;

    while (i < 20)

Any Ideas? Do I have to send the data differently? I will keep searching but thought someone here will show the errors of my ways :slight_smile: Thanks for your help.

I found this link from the forum

How to send data TO a Wisblock RAK4630/RAK4631 from the RAK2245 Concentrator Gateway - #3 by carlrowan

Which suggested using the following JSON

{“data”:“TXlUZXN0V29ya3Mh”, “fport”:2, “confirmed”:true}

But still, see data size as zero and no data. Will keep hunting this down…

In TTN, did you set the correct downlink de/encoder?

I never tried to send downlinks with JSON, but there is some explanation in the TTN docs

Payload formatters - Javascript
Downlink Encoder

If you get it to work, please teach me how to do it :wink:

I’m working on the same project but can’t figure out what to connect the outputs to on the Rak.

@beegee , Thank you for the reply. I will look at those links closely and see if I can make heads or tails out of it.

Can I ask, the fact that I can make the LED lights blink like a disco club means that the WisBlock is receiving something from TTN.

Is the app_data->buffer truly empty or just not printable. Is the WisBlock expecting something different or some spcific format? Is there anything else I can glean/debug from the Wisblock/Arduino side on this received packet ? Is it in a log somewhere that you are aware of ? If the incomming packet was coming into my home network I would use Wireshark to inspect the packet down to the byte level…

My plan is to switch to Helium ultimately since there is way more coverage here in North America based on my testing but do want the final solution to be capable of working on both networks.



Not sure if this is what you are asking but the Arduino sketch receives data from the lorawan_rx_handler() function. I am using the built in LED lights on the board for testing.

The RX callback is working fine.
If you look at your log output
LoRa Packet received ==> Something arrived
on port 1 ==> it is coming from fPort 1
size:0 ==> but there is NO data, size is ZERO
rssi:-33 ==> signal strength
snr:11 ==> signal to noise ratio
data: ==> empty, because size is ZERO

Did you try to send manually a packet? You will see it works.

From what I understand, to send the packets from MQTT (or whatever) though the LNS (TTN or Helium, doesn’t matter), there must be an downlink encoder, but that is empty by default, that’s why the packet size is ZERO.

So the missing step here is how to send data from MQTT to the LNS, encode the data so that it can be sent by the LNS. And on that part I cannot help. I am concentrating on the WisBlock code side, not on the LNS.

Reading a little bit, this

should come from a MQTT client, not sure if it is the same format used in the manual downlink/Json in the TTN console.

I found this: which looks different.

Maybe I am just confused with Chirpstack downlinks

Just guessing it is the same in TTN.

Thanks @geege. Yes, I am trying the TTN console to send the message manually, not trying MQTT yet. Once I get it working in the TTN console, it should be straightforward.

Thanks for all your links and help. I will keep at it. I’ve been in the business long enough to know that "if you beat the data enough, it will confess :wink:

Have not been able to spend much time on passing the data. Will keep playing with this. In the meantime, in case someone else reads down this path, I do see that I can pass in a different port number which can trigger the things I wanted anyway in the rx handler with a switch on app_data->port which can be passed in very easily, so I will go with this for now… Thanks again for the help

   case 1:
       Serial.printf("Port %d triggered. Sending back an acknowlegement message.\n\r", app_data->port);
   case 2:
       g_message_schedule = 120;
       Serial.printf("Port %d triggered. Setting message schedule to %d minutes.\n\r", app_data->port, g_message_schedule/60);

When using the fPort, keep in mind that only port 1 to 253 can be used. Port 0 and ports above 253 are reserved by the LoRaWAN protocol

1 Like