I have a dedicated serial channel (serial.mode SIMPLE) that is received by a TBEAM node which is attached to my computer via USB. Is it possible to setup this node so that the serial data is transmitted to the COM port that is the USB interface? How do I set up the transmit and receive pins? Also due to the program running on the computer which receives this data, the baud rate has to be 38400. Is this possible?
Yes, you should be able to override the serial console (Serial Module Configuration | Meshtastic), but you’re probably the first one to try this with the serial.mode SIMPLE. You shouldn’t set any TX/RX pins then.
You can also set the baud rate: Serial Module Configuration | Meshtastic
awesome - trying now. Should I still set serial.enabled to true?
Yes.
The documentation says it might only work in NMEA and CalTopo mode, so let’s see how it goes.
Wiped and reflashed 2.1.19. Set the followings:
meshtastic --port COM18 --set lora.region US
meshtastic --port COM18 --ch-index 0 --ch-set name OOC1 --ch-set psk 0x010203040506
meshtastic --port COM18 --set serial.mode SIMPLE --set serial.baud BAUD_4800
meshtastic --port COM18 --set telemetry.environment_screen_enabled false
meshtastic --port COM18 --ch-index 1 --ch-set name serial --ch-set psk none --ch-set uplink_enabled true --ch-set downlink_enabled true
Then listened on COM18 with HTerm at 4800 baud (i’m also connected with my Android so I can see the debug panel). Get seemingly random junk on hterm. When my other TBeam transmits some data, I see the serial packet arrive in the debug panel. Also a flurry of data is shown on the HTerm, but none of it is correct (Turns out when I change HTerm to 115200 I receive debug messages. However even at 115200 no serial data is not being output on COM18).
Tried the whole thing again after
meshtastic --port COM18 --set serial.enabled true
No change. Bummer, too good to be true.
You didn’t set serial.override_console_serial_port true, right?
You need that, otherwise it will indeed show the normal serial logs.
However, take into account that after doing that, you cannot set any settings anymore via serial. So if you want to disable it again you would have to do that via Bluetooth.
After setting that, HTerm outputs WARN and INFO messages at 4800 baud, but also no data.
Wait - the data might be there! This is what HTerm captured the two symbols after the word neighbors might be it. Is there a way to turn off all the log stuff?
INFO | 18:45:53 80 [Router] Received routing from=0x93896cec, id=0x6d449a08, portnum=64, payloadlen=19
INFO | 18:45:53 80 [Router] Rebroadcasting received floodmsg to neighbors
Ó
INFO | 18:45:53 80 Telling client we have new packets 7
INFO | 18:45:53 80 BLE notify fromNum
INFO | 18:45:54 80 From Radio onread
INFO | 18:45:54 80 getFromRadio=STATE_SEND_PACKETS
INFO | 18:45:54 81 From Radio onread
WARN | 18:46:03 90 [Router] User provided a too short AES128 key - padding
INFO | 18:46:03 90 [Router] Received nodeinfo from=0x93896cec, id=0x6d449a0a, portnum=4, payloadlen=44
INFO | 18:46:03 90 [Router] Asked module ‘nodeinfo’ to send a response
INFO | 18:46:03 90 [Router] Received routing from=0x93896cec, id=0x6d449a0a, portnum=4, payloadlen=44
INFO | 18:46:04 90 [Router] Rebroadcasting received floodmsg to neighbors
WARN | 18:46:04 91 [Router] User provided a too short AES128 key - padding
INFO | 18:46:04 91 [Router] Asked module ‘routing’ to send a response
Ah, yes when you set serial.override_console_serial_port true it only gets rid of the DEBUG logs.
Maybe you can try setting device.debug_log_enabled false as well.
Looks like it was the beginning of the data, but half of it is missing. The STX is there and the first 2 bytes, but the remainder of about 20 bytes, up to and including the ETX is missing.
Actually device.serial_enabled false seems to be the appropriate setting.
With the above I now have no debug, warning, info or anything. Pretty quiet… There were 4 bytes of junk when I first enabled the override_console_serial_port.
Unfortunately I still only get the first 3 bytes of the message. Reliably. Every time the sending node sends data, I see the first three in HTerm, but the whole message in the Debug Panel of the attached android.
My third byte is 0x0D (a.k.a. Carriage Return). Could there be some errant logic somewhere that kills the remainder of the output because it found the carriage return?
Good catch, might be indeed.
But the logic is just a simple printf() statement: https://github.com/meshtastic/firmware/blob/master/src/modules/SerialModule.cpp#L252
Maybe it also depends on how your serial monitor handles it.
I was wondering about HTerm, but I plugged the device that is generating the data directly into the computer to see what gets spat out, and it showed the full data correctly:
02 D3 0D 00 64 00 8C 65 5E 11 32 C1 CE 00 07 00 F8 E7 03
Now that I look at this the printf is the problem because the 4th byte is 0x00, and that’s a string terminator. The code in question needs to be changed to a fwrite(stdout, buffer, data-packet-length) – syntax may be wrong - I haven’t touched C++ in a while.
I don’t have the build environment to implement this change. Is this something I need to do, or can I ask politely if you could submit this???!?
Thanks
Hmm, having a string with a null terminator is indeed problematic. Can you get around without sending that?
I don’t think fwrite() is a supported function by the Arduino framework, so I’m unsure how to implement this. You can always open an issue for this: Sign in to GitHub · GitHub
No unfortunately. The sending device is not changeable. Will definitely send binary data. The Serial arduino class is derived from HardwareSerial and Stream.
Thanks for all your help. I’ll open an issue and I see that HardwareSerial inherits a method called Write(buf, size) that should do the trick. I use Visual Studio (not VS Code), and I build IoT stuff with VisualMicro, maybe I can put together a test before submitting a change request / pull request.
Thanks again.
1 Like
Created bug report #2669.