What is wrong with this MQTT-SN bridge?

Question

I am using this MQTT-SN bridge, with no changes except that I rigged it to give a hex dump of the buffer if it does not contain a valid MQTT-SN packet.

I am experiencing a strange problem: sometimes I find the bridge works perfectly well, and other times I find the problem I describe below. I have an ESP32 microcontroller which is just publishing a message here and there to say it's alive. It queries various sensors (humidity, dust ...) as well, and publishes the results also, as you will see. It's writing to a LoRa module, and correspondingly I have a LoRa module on a USB stick which is plugged into my laptop. Then I run

./mqtt-sn-serial-bridge -b 19200 /dev/ttyUSB0

to see output like the following:

2019-09-17 12:20:18 ERROR Error reading rest of packet from serial port: 0, 22
2019-09-17 12:20:19 WARN  Read 10 bytes but packet length is 165 bytes.
....|.....  0xa5 0x08 0xa0 0xa6 0x7c 0x84 0x85 0x0c 0x86 0x85 
2019-09-17 12:20:19 WARN  Read 17 bytes but packet length is 37 bytes.
%..@..H.........f   0x25 0xc5 0x0c 0x40 0x87 0x84 0x48 0x04 0x85 0x9c 0xc4 0x85 0x88 0xc4 0x86 0xee 0x66 
2019-09-17 12:20:21 WARN  Read 8 bytes but packet length is 40 bytes.
(.....xD    0x28 0xa5 0x04 0xc0 0xa2 0x87 0x78 0x44 
2019-09-17 12:20:23 WARN  Read 8 bytes but packet length is 67 bytes.
C.......    0x43 0xa5 0x0a 0xc0 0x82 0x0a 0x06 0xf6

If I run screen /dev/ttyUSB0 19200 8n1 I get something like this:

bf5fish5 is a live"b9H0.000000 relative humidity
                                                bf5PM2.5 = 10bf5PM10 = 11bf5fish5 is a live"b9H0.000000 relative humidity
                                                                                                                         bf5PM2.5 = 10bf5PM10 = 11

What I found remarkable is that while screen can get human readable characters, the MQTT-SN bridge just seems to get garbage.

Does anyone have any experience with this bridge? I'm unsure whether the problem is with the bridge itself or somehow with the LoRa substrate. Or can anyone see where I'm going wrong?

OmarL · Accepted Answer

Baud rate

What I found remarkable is that while screen can get human readable characters, the MQTT-SN bridge just seems to get garbage.

This turned out to be the important part of tracking down the problem. GNU screen set the baud rate, but mqtt-sn-serial-bridge wasn't doing so. That turns out to be because

$ ./mqtt-sn-serial-bridge -?
Usage: mqtt-sn-serial-bridge [opts] <device>

  -b <baud>      Set the baud rate. Defaults to 13.
  -d             Increase debug level by one. -d can occur multiple times.
  -dd            Enable extended debugging - display packets in hex.
  -h <host>      MQTT-SN host to connect to. Defaults to '127.0.0.1'.
  -p <port>      Network port to connect to. Defaults to 1883.
  --fe           Enables Forwarder Encapsulation. Mqtt-sn packets are encapsulated according to MQTT-SN Protocol Specification v1.2, chapter 5.5 Forwarder Encapsulation.

the option -b doesn't take a baudrate for its argument. See, its default is 13, quite a strange baudrate, isn't it. It takes a number, which gets handed over to some lower level API that sets the baudrate. On my system, these numbers, and their corresponding baudrates are:

 0:      0
 50:     1
 75:     2
 110:    3
 134:    4
 150:    5
 200:    6
 300:    7
 600:    8
 1200:   9
 1800:   10
 2400:   11
 4800:   12
 9600:   13
 19200:  14
 38400:  15
 57600:  4097
 115200: 4098
 230400: 4099

So you can use -b 13 to set the baudrate to 9600. Or use -b 14 to set the baudrate to 19200. This was really unintuitive to me, so ~~[I forked the project][1] to make sure that -b takes the actual baud rate~~ But, this has been fixed since.

What is wrong with this MQTT-SN bridge?

One Answer

Baud rate

Add your own answers!

Ask a Question