Meshtastic compatible with


As a noobie to the forum, I’m doing a lot of reading to get to grips with the technology and its capabilities. I wanted to ask if the Meshtastic will be able to utilise existing gateways on the



possibly someday, but not in release 1.0 (which is still 2-3 mos away?).

More likely though: we’ll add a feature so that if any of the nodes in the mesh has internet connectivity via its phone, that phone will then route text messages and MQTT (or some other space efficient datagram protocol) packets for any other node in the mesh.


Wow that would be brilliant

adding a post here from Nicolas (asking the same thing) on the android app alpha tester email list. I’ll point him at this thread :wink:

First, thanks for your nice project. I can’t wait to test it, I will receive two TTGO T-Beam to do that in the next days with my Xiaomi MI8 and my wife’s Redmi Note 7.

I have a question: do you plan to use existing TTN LoRaWAN gateway network to deliver messages between meshes or if devices are out of reach? That’s something that Pycom plans to do with their Pygos and it would increase coverage a lot IMHO.

Best regards,



Instead of the phone would it make sense that any node with a wifi connection (not attached to a phone) could backhaul the messages. I’m thinking a central heltec32 or t-beam connected to home wifi and always on and mounted on the roof and willing to relay messages. This could be useful to connect multiple mini-networks together and still be accessible.


yes, that would be fairly straightforward also. good idea.

In this conversation, is only the LoRa device the “node”? In my use-case, it’s fairly likely that mesh users will have internet access via phone more often than LoRa nodes would have wifi access to internet.

Got buy-in from at least 7 more local users last night. None have a geeky bone in their body, and love the idea. Due to their normal movement patterns, they’ll spend a considerable time:

  1. In LoRa range, communicating locally (100% in)
  2. Outside LoRa range, and in 4G range, and wanting to connect to others in the mesh inside LoRa range. (50% in)
  3. Outside LoRa range, and in 4G range, and wanting to connect to others in the mesh outside LoRa range. (100% out). In this instance, not requiring them to always have the LoRa device, and still being able to access the mesh (routed over internet), would be a better user experience.

Covering only Scenario #1 would be a big help, but if all 3 were covered, I would expect better adoption. It’s a hassle to guess who’s in the LoRa mesh and switch apps accordingly. This is a point of friction we (several have InReach devices) experience now because the app (and/or phone number) changes depending on our knowledge of the others’ location.

Speaking of nodes, has anyone pinged the N-O-D-E channel guy? Lots of interest in LoRa mesh comms over there a while back, and a few devs offering to contribute, but I don’t think they got anywhere:


re: those three scenarios
I think #1 will be quite solid sometime within the next two months :wink:
I bet gateway functionality will be working and solid within four months?

re: NODE - never heard of it but yeah - lots of possible shared effort there.

1 Like

Cool. Yeah, not too worried about the timeline. By the time my AliExpress order arrives, you’ll probably be on v2.37. :laughing:

I was mainly trying to figure out if there was consensus on whether the gateway would be via phone, LoRa device, or both.

we could leverage existing TTN gateways to retransmit Meshtastic messages in order to increase range

Hmm - I’m not sure that is a great way to go for the following reason: When I started experimenting with LoRa I installed a TTN gateway (which I still run) in the hills above San Francisco with very good coverage of the bay area. The usage that gateway gets is quite low and the coverage of TTN gateways (seems pretty spotty).

Personally I’m a bigger fan of letting either of the two following meshtastic nodes automatically serve as gateways for their mesh (if that node has internet connectivity):

  • The android app can gateway for the mesh it is connected to anytime it has internet via wifi or 4G
  • Any of the mesh devices that have wifi hardware (which is all of the ESP32 based boards, tebeam, heltec, whatever) should be able to be connected to a wifi network and if connected it will then gateway for the mesh. So any of these $20ish boards could magically become a gateway

(To be clear neither of these two variants are implemented yet but I thing we should do this as soon as 1.0 is finished)


I know this is an old threat but would really like to see this feature added. I just got 2 boards a few days ago and plan to use for hang gliding competitions and XC flights. In this use case there would typically be a group of 4-5 pilots and one driver creating a mesh. Currently we use and which both work off the cell network, however, once over about 3,000 feet cell reception is lost which can happen for a very long time on a good day. Meshtastic should solve the altitude problem and issues with flying in areas with poor cell reception, but pilots can end up being spread out beyond the range of a device and lose the mesh. However if posititions / msgs were synced up and sent over the cell network when available this would be a rock solid solution.

On a separate note it would be great if there was an option to display, altitude next to the name on both the map page and in the list. Would also be great to be able to choose other units besides metric.

  • Charles
1 Like

Oh yes I’m a P4 rating paraglider pilot (and used to do a fair amount of xc) and one of my “end goal” meshtastic use cases is glider pilots.

Awesome, wish I knew how to program better so I could chip in on the development. would be great except for the cell reception issue and the cost. I pay $20 a year which is fine and other pilots would likely do the same but to create a larger group it goes to $50 a month. At $35-45 all in for the boards, case, battery etc. I can make 4-5 and just give to all pilots in my car. Unless the is free it would also be great if I run a virtual machine on my NAS to host the database that all the meshtastics sync to through the web.


Just wondered if anybody had got any further on this?

Hmm. I think my comments above are still the current state. At the current rate that feature should be in and solid by the end of Feb.

Checking in to see where we are in March

alas, I ended up working on multichannel support first (before the MQTT gateway). So at my current rate (and adding support for some new hardware) I think MQTT gateway is looking more like June?


Thanks for the update. Still following. Would be great to run meshtastic on my phone in background and have position synced up with driver and other pilots either via Lora or cell. What would be amazing is to have alt-air app get location of other pilots from meshtastic so i could follow pilot group in air and have real time position, altitutude and climb rate of others. At that point i could get the new smaller board and embed in my alt air II pod.