How-To on the serial module's mode NMEA

Builds / Use Cases
1

A feature no one except me needed yet was implemented, a way to display position packets from the mesh to certain types of Garmin devices.

Likely to work on: Any garmin that understands WPL NMEA0183 sentences. (Mostly marine versions) and any meshtastic device.
Tested on: Garmin GPSMap276C and T-Beam V1 and TLora V1.1.16

Partially tested on: GPSmap 60C (Does not really understand how WPL sentences work and tries to create a new waypoint for each received waypoint which can quickly lead into a giant mess of waypoints, not really recommended. Maybe someone with a newer 60 series device can test?)

What it does: Nodes in a mesh that send out position packets will have their long name outputted to serial via NMEA0183 sentences, this can be read by some Garmin (and possibly other?) GPS devices.

Use-case: Probably mostly mobile of some sort (snowmobiles, cars, snow cats etc, but possible with hand held GPS)

Why on earth use this: In Iceland we can have very crazy weathers and one of our weird hobbies is to be on the middle of a glacier while doing said hobbies. This can lead to a lot of people wandering around in circles trying to find each other during a blizzard (or huts, or something else). Being able to spot each other on the GPS device instead of trying to understand what people are saying over the radio when giving out coordinates saves time, and possibly lives or just the dignity. Perhaps someone else (maybe Aussies or other remote communities) have use cases for something like this.

Prerequisites: Configure your device via a preferred method of choice so you can send and receive messages between nodes once you’ve verified that head onto next step.

This is (afaik) only available via CLI. I admit, I’m a terminal guy and will live and die by the CLI as the easiest method of quickly configure a device (if you want to automate it a bit in case of reflashing device, on linux/macos read about bash shell scripting, this is probably possible via powershell or WSL as well)

FOR T-BEAM
Meshtastic –port yourserialporthere --set serial.mode NMEA --set serial.txd 15 --set serial.rxd 35 --set serial.baud BAUD_4800 --set serial.enabled true

Yes but what does all this mean?
Serial.mode NMEA = sets the mode to NMEA output (and maybe later if I’m nice to an input)
Serial.txd = The transmit data port on your meshtastic device, this is outgoing information for anyone as confused as I was when I first started looking into this.
Serial.rxd 35 = The receiving port of the meshtastic device, not used but can cause weird crashes if left unconfigured.
Serial.baud BAUD_4800 = the speed of the connection. NMEA0183 standard is 4800bps which most Garmin devices seem to respect, and frankly don’t allow you to change at all. No idea why the BAUD thing is in there but it matters a lot I’ve found.
Serial.enabled true = enables the serial connection.

This should work to enable NMEA sentence output from your device.

Yes, but what then? Good question, I’m glad you asked.

HARDWARE
PINOUTS:
Garmin GPSMap276C: Garmin GPSMAP power and data cable pinout diagram @ pinoutguide.com
MAX3232: https://datasheets.maximintegrated.com/en/ds/MAX2320EVKIT-MAX2327EVKIT.pdf

You’ll need a UART to RS232 (should be RS422 but who cares about standards anyway?) converter. The MAX3232 is probably your best friend here, it’s easily available as breakout boards (Sparkfun, aliexpress, etc) or as a standalone DIP chip perfect for prototyping. (I used the more evil brother MAX3323 which is annoying but the only thing I could find quickly in my centre of the north Atlantic remote island, the reason for it being annoying is because it has enable pins for transmit and receive which are kind of not needed here (But if you only have access to 3323 like me remember to put Tenable to high). Also remember that VCC on the RS232 MUST BE 3.3V otherwise you might release some smoke (figuratively speaking but still technically true).

Since this is a one way communication (ie. the meshtastic device doesn’t (yet, maybe?) do anything useful with all that juicy NMEA0183 sentences you only need to connect the TXD (the one you set with the CLI) FROM the meshtastic device TO serial INPUT of the Garmin device. For the (my so beloved) 276C device it’s either yellow (serial 1) or green (serial 2). The datasheet for whatever garmin device you have will have a schematic showing which are inputs and outputs from the Garmin device respectfully.

On the garmin device you HAVE to enable the serial port and pick WHICH serial port you use (most Garmin devices have at least multiple serial ports, since it theoretically works on RS422 which is a multiple listeners single transmitter standard that nobody seems to bother following properly)

Yes but nothing works and how do I debug this?
Just connect your favourite RS232 to USB converter to a UART to TTL converter and connect the RX line of the converter to the RXD line of the Garmin device and remember to connect GND otherwise you might get very mixed results.

Finally, what terminal to use? You can use the meshtastic –no-proto or just whatever terminal you prefer, I like screen, and the command for that is ‘screen /dev/serialportofmydevice0 4800’
Tera Term for windows is also excellent and so is Minicom and probably billions of other vty programs out there, just pick your poison.

Debugging when nothing works after following this thread’s advice closely.
I probably screwed up in documentation, you can find me as Ravenwolf on the meshtastic Discord server and I’ll gladly assist, and update this (or wherever this documentation may reside).

Pictures of the testing procedure, I’ll eventually mash this into a nice PCB for more permanent use and publish the cad files.

Position of node BY705 (my work car btw) on a Garmin GPSMap276C device.

WPL Test
WPL Test1531×1148 378 KB

The MAX3323 (in your case it should be MAX3232) sitting in an oversized box with connections to the T-Beam. From the T-Beam you’ll need TXD, GND and 3.3V pin.

MAXwhateverHack
MAXwhateverHack1531×1148 174 KB

Side effects and quirks:
The NMEA serial module also outputs xxGGA message, which is the location from the gps module of the meshtastic device, this is nice since it can be used for a lot of software that understands NMEA0183 sentences, like OziExplorer as a GPS device! Neat huh? Except that WPL doesn’t seem to work and I’m a bit infuriated by that.

10 Likes
2

Excellent write-up! Thank you for sharing.

3

I wanted this too! Thanks for the write up.
I am trying to get it working with a Montana 700.

If i have understood correctly i need an additional board to convert the serial output of the T-Beam (UART) so that it is in the RS232 format that Garmin expects.

Are you able to confirm if this board will do what I need ? https://www.mouser.co.uk/ProductDetail/SparkFun/BOB-11189?qs=WyAARYrbSnZHhEoBjkcdyg%3D%3D

1 Like
4

Yes, that board will work.

The reason for the level converter is that most RS232 devices expect +/-12V or around (sometimes 5V can be enough, for all the garmin devices I’ve tried it’s not enough). However the esp32 on the TBeam expects 3.3V and mixing those voltages without a level converter usually ends up with the lower voltage device breaking. So the level converter is needed, the MAX3232 is neat since it works on both 3.3V and 5V for the TTL (T-Beam’s) side. But you have to remember to power it with 3.3V from the T-Beam. I just realised I probably should add a schematic of the connection just to avoid confusion.

2 Likes
5

meshtastic2Garmin
meshtastic2Garmin3178×2130 46.6 KB

2 Likes
6

Thank you so much. I’ll report back once I’ve connected it all up.

1 Like
7

Could you show us some more examples of this in the field? Does the location of your node change, or does it just add a new point each time it updates?

1 Like
8

The behavior depends a bit on the device you use to receive the NMEA0183 sentences from the Meshtastic radio. On the Garmin 276C each node’s longname appears as a waypoint, and that waypoint’s position is updated on the Garmin device as the radio receives update on the node’s position. On some Garmin devices a new waypoint is created each time with unique last characters (on my GPSmap 60CX last two characters are renamed in some order). This is probably not very usable since the whole map becomes cluttered with different waypoints.

The use case isn’t only with Garmin but other devices that can receive NMEA0183 could exploit this as well.

Im waiting for more meshtastic devices and I’ll record a short video on the behavior once they arrive.

If this answer wasn’t clear enough feel free to let me know.

1 Like
9

That was very clear thank you. Please update when you’ve done some more testing, I find it to be a very interesting use case. Too bad these garmin devices are a mess to communicate with

1 Like
10

I wouldn’t say they are a mess to communicate with, most of them work very well with NMEA0183, it’s just that out of the few devices I have tested this with myself, this particular handheld has been problematic. AFAIK it should work with any device that supports NMEA0183 input.

1 Like
11

Hello,

I activated the NMEA output on a T-Beam with firmwares 2.1.0 and 2.1.5 (the last one at writing time), and the sentences are of this form:
$GNGGA,1681483.279,46XX.XXXX,N,005XX.XXXX,E,0,12,0089,0231,M,0047,M,0,0000*53
The time (field 2) seems to be an epoch string (1681483.279 in my sample) and the NMEA documentation says that it should be like hhmmss.ss.
Is it an issue ?

12

Hi
While it is indeed a bug it shouldn’t affect the overall use of the module (apart from time not being updated from the GPS).

13

I see that you opened a Github issue for that, thank you very much!

14

I can confirm on a Montana 700 it effectively moves the waypoint on update.

I am just back from a week of usage and it proved to be stable and reliable. Very happy with the results.

IMG_3860
IMG_38601536×2048 418 KB

As mentioned above , it pulls through the long name of the node. I had mine set to update every 30 seconds.

2 Likes
15

That’s very cool and good to hear that it worked well. Do you mind sharing the hardware setup?

16

There will be a fix for this in the next update. I already tested a pr from caveman99 that works.

1 Like
17

@samuelhj BIG THANKS FOR THIS ONE!! I’ve tinkered with this a yr or 2 ago. I just tried on my echomap and I’ve validated it’s rxing the nema strings, but I don’t think it’ll accept the GNGGA since it won’t display any waypoints.

Does anyone have any ideas on how to convert it w/o integrating an additional device?

Update-Might’ve found it looks like there is an option in defined in NMEAGPS.cpp

I’ll update what happens.

18

The way points come from the $WPL sentence. The Garmin device should not do anything with the $GNGGA sentence. There is also a new option that I haven’t tried which is the caltopo option under serial mode, which periodcly displays all received nodes position as $WPL.

19

That did it! Thanks @samuelhj!!!

20

If the caltopo option works and not the NMEA mode then I’m guessing that there probably weren’t any nodes sending out updates (NMEA mode only updates location when a nodes location is received on the radio sending to the Garmin device). So sometimes it can take a while for nodes to be updated or displayed on the Garmin, or at least that’s been my experience. Occasionally on my Garmin for instance, even though a valid WPL sentence is received, it will not show on the Garmin, which I’m suspecting to have something to do with the processor being just busy doing something else at that particular moment. I haven’t really noticed this as much when out in the field actually using it with couple of devices, for example on a glacier, probably because I’m not waiting for anything to happen, rather just taking a look every once in a while to see where other people are located.