Protobuf transactions on Serial port not working

1

I have a question on the Serial port related matters as reality is not meeting expectation.

For completeness also I upgraded all my MT nodes to 2.2.24 this morning. Previously I have two at 2.2.19 and one 2.2.17.
My nodes are all Lilygo T-Lora v2.1-1.6

I have a number of nodes that I am trying to communicate with and can do this successfully with the serial ports set as TEXTMSG mode. Where I get the short name followed by the message, as expected.

I then converted each node to PROTO mode and changed the data sent (external processor driven) from ascii text to protobuf encoded (as ToRadio using the Arduino example). This works to the point of I see the text message appear on the screen of the node, but nothing is passed through to the serial port.

My expectation is I should be getting the protobuf encoded data (FromRadio framing) sent to my processor via the serial port, but I get nothing. I can change one node to be TEXTMSG and this then shows up the message sent as protobuf from a different node. This shows as Short name: message. So, the message is being sent via the mesh but being decoded by the MT node and not being passed through when the serial port is in PROTO mode, but is when as TEXTMSG.

I am sending these messages (as the Arduino example) as a broadcast destination (0xFFFFFFFF) so all nodes should receive.

I can also send the text messages on different channels, using the protobuf encoding.

I also see the messages from the mesh appear in my local mqtt broker log on topic msh/2/c/LongFast/!25c28a10 (the mac address of the node) for primary channel. Also, msh/2/c/serial/!25c28a10 for channel 1 messages (this channel is named serial).

TEXTMSG → TEXTMSG = working
PROTO → TEXTMSG = working
PROTO → PROTO = not working
TEXTMSG → PROTO = not working (but initial expectation was that it wouldn’t)

I have the units hooked up to computers around my office. USB port for using meshtastic CLI and a USB-Serial adapter connected to the serial output. One unit I have swapped out for an external processor connected to the serial port, this is the one sending the protobuf encoded messages which the payload is just a string followed by the milliseconds of unit uptime eg “Hello - 1234567” .

Sending unit
C:\Users\Stephen>meshtastic --port COM12 --get serial
Connected to radio
serial:
enabled: true
echo: true
rxd: 13
txd: 14
baud: BAUD_9600
mode: PROTO

MQTT unit (receiver of message)
steve@Stephen-Bench:~$ meshtastic --get serial
Connected to radio
serial:
enabled: true
rxd: 13
txd: 14
baud: BAUD_9600
mode: PROTO

Baud rate is 9600 as this was easy to interface to an existing project (which can be changed I just chose not to, yet. Also the data rate of data to send is not hampered by the Serial/UART speed). Unless this is the cause, I see the default is 38400.

I have not explored further than trying to send messages on the serial port. Although it would seem like you can interact with the MT config from the Serial port.

So that is that. Not sure where to go from here.
Hopefully this is enough information to at least begin sorting this out.

Cheers,
Steve

2

Hi Steve,

Are you using the SendReceiveClient example of the Arduino client as is? It needs to initiate a connection with the device before you’ll receive all the protobuf encoded packets via the common API. The example does this by calling mt_request_node_report() (naming is odd, I agree). The device can only be connected to one client at a time, so if you’re also connected via USB, BLE or Wi-Fi to another client, this will not work (or they are fighting for the packets).

You can set a callback for text messages with set_text_message_callback(), or create your own callback for a specific packet you want if you modify the library function handle_mesh_packet().

TEXT_MSG → PROTO should also work. When the device receives a packet via LoRa, it doesn’t know how that packet was sent; it can be via a phone, web client, serial, etc.

Hope this helps.

3

Yes I am using the Arduino client “as is” although I ported it to a Microchip PIC24 but it appears to work. (mostly the porting was untangling the c and headers, setting up the HW peripherals: timer to give a 1ms tick, uart, SPI, ADC, etc). The loop() is mostly the same although I have tinkered with the text message that is sent, but that is somewhat irrelevant as the message is being sent.

I see the error in my ways, I missed porting some of the setup() function, namely the calls to mt_request_node_report(). Partly (mostly) attributed to attention to detail and partly my original goal with porting was to make sure I could successfully encode and decode the protobuf messages on my target processor before proceeding (The learning curve to pb was steeper than I expected), so once I got that working in the debugger I then proceeded to send this out the SP. I had made the assumption that if I was sending on the serial port successfully I should be receiving as equally successfully. Not so it appears.

I have added in the function call to the mt_request_node_report() and the MT s now passing protobuf messages out of the SP. As you suggested it would.

So all the {anything} → PROTO are working as well now. Onwards and upwards.
Thank you very much for your help.

Side question: is there any particular method of binding a single channel (or group) to the serial output (eg just channel 1) or to exclude a channel (zero)?
It is not a huge problem if the pb packet is sent to the serial port and then the (application) processor does the discrimination, although this will cause an interrupt (wake up) on every packet (telemetry, etc which I don’t need for my intended application which is a low power sensor). Although I may want to send telemetry info from my application processor (although these could be sent on the bound channel and picked up at the head end, or may be packaged in my own pb frame in which case then I deal with it however I choose)

Thanks again,
Steve

4

Good to hear it’s working now.

Side question: is there any particular method of binding a single channel (or group) to the serial output (eg just channel 1) or to exclude a channel (zero)?

Unfortunately I don’t think that’s possible without modifying the firmware.