Over the years I've had students doing "people net" style meshing,
BATMAN, opportunistic routing, stuff for warzones or emergency coms
for disaster areas.
We learned a great place to test this is festivals.
Lots of endpoint mobility. New nodes coming in and out of the
network. Terrible 4/4G cell coverage, so few alternatives. Dead
batteries. Shadow zones. Fairly chilled out delivery time constraints.
Everything you need to tweak your protocols.
I hope someone into playing with this will set up a larger scale
experiment at Glastonbury, Burning Man or another big music festival.
We have tested it successfully with 4 nodes last week at the Fusion Festival in Germany - one of those where you have to battle constant cellular network outages - and were surprised to randomly see fellow meshtastic users extending the mesh network. It was one of those "open source technology is amazing" moments :D.
I bet! I can imagine festivals being a good disaster simulation.
Meshtastic appears to use a simple flooding algorithm which is appropriate to what I understand to be the application - a small group of outdoorspeople keeping tabs on each other with short messages. One of my takeaways from a similar project I worked on in a past life was that flooding works well for use cases like that and just about anything more sophisticated is a pretty serious research project. BATMAN etc looks like fun to experiment with.
> what I understand to be the application - a small group of outdoorspeople keeping tabs on each other with short messages.
One really neat thing (in my opinion) about Meshtastic, it that it has support for GPS location in it's message scheme, so GPS equipped devices (or devices paired to phones with GPS on) can see where other mesh members are relative to them. This is really cool in the festival-type use case. Being able to easily see where your crew is whenever you want is great.
I have this same need and am preparing an evaluation of Meshtastic in the field this month.
I'm part of a volunteer EMS division within a paid fire department and we staff foot teams and medical carts at large events at our 90,888-capacity stadium (football, concerts, etc; well over 100k including tailgaters at our biggest game of the year) and music festivals with 10-40k attendees on the adjacent golf course.
While we have fancy Motorola APX 8000XE, our on-site dispatch wholly lacks visibility into unit locations and the abysmal cell service precludes software solutions leveraging mobile phones.
Doesn't Motorola have location tracking systems which integrate or add-on to their radio systems? I know we used to have this on some of our VHF radios.
You could also look at using APRS for location tracking...
Edit: Also - you should be able to set up your phones with priority network access on FirstNet, right?
>Doesn't Motorola have location tracking systems which integrate or add-on to their radio systems?
Yes, the APX8000 has support for location tracking but we decided it'd be inappropriate to request anything of the regional communications center since they have their hands full with far more meaningful improvements to the 12 cities (40-odd fire stations) they support. Also, while I see value in tracking unit locations at our music festival events in particular, it falls well short of necessary.
>You could also look at using APRS for location tracking...
APRS would require we all have technician licenses and suitably equipped 2M radios. While a few of us are hams, it's not feasible to request dozens of volunteer EMTs go through that. Also APRS tracker hardware is at least twice as expensive as LilyGo's LoRa options ($55 for a T-Echo or $65-85 for a T-Beam w/case and battery vs $115 for the cheapest APRS tracker I've found--QRP Labs' LightAPRS [1]--not including designing a case and power delivery).
>Also - you should be able to set up your phones with priority network access on FirstNet, right?
We are indeed eligible for wireless priority services on our personal phones. AT&T FirstNet includes data priority but the couple members who got it didn't see an improvement. Verizon Frontline offers data priority but no one's opted in yet and T-Mobile only offers voice priority so low confidence in its viability.
Fundamentally, Meshtastic's attractiveness is not only in its low hardware cost but the lack of friction in not requiring anything of anyone beyond "hey, clip this thing on your bag, thanks."
> APRS would require we all have technician licenses
If you were using the "normal" APRS frequency, but if you set up your own iGate, you could run it in the public safety band, couldn't you? (If you had a frequency licensed and coordinated of course.)
Alternately, you could get a business band license and run it there. In that case, each individual doesn't need a license, just an org.
Sure, I could coordinate or license a frequency and build or acquire radios to use APRS but why? It requires greater effort, risk, and expense for the same result as the off-the-shelf solution.
Burning Man is one of the the primary usecases of one of the core devs, so yeah, it should definitely get some good exercise in that kind of context. Another acquaintance is a PAX admin and looking into it for similar reasons.
I've not been following along too closely for the last couple of years (not a lot of need for or opportunity to use it in Covid lockdown times), but the original lead dev's most memorable (for me) main use case was for paragliding. Being able to see where your friends are (and who's in good lift) as a group of paragliders would be very useful. Having a reliable long-is range way of letting your friends know where you landed out would obviously be super useful as well.
I'd love to see a protocol designed for that sort of thing that hops from phone to phone without explicit intervention from the user.
No setting up a wifi hotspot and having people connect to you. No need to be connected to wifi at all. No fucking with Bluetooth.
I'm not even sure if there's a way to do it but that's what I really want. Carrying a separate LoRa device is just one more thing I'll forget to pack or charge.
Bluetooth LE is aiming at something slightly different. When people say several kilometres with LoRa, they do mean in actual real-world applications.
Two LoRa transceivers with dinky antennas indoors will do > 1 km in a suburban environment. With a well-sited outdoor antenna for one of the transceivers that will increase to 5+ km. Two well-sited outdoor antennas can do 20+ km if they have line-of-sight.
There's nothing else quite like it at the moment. Cellular networks are close, but higher bandwidth, power, and of course, licensed spectrum. One could cover an entire large city with a LoRa network with a dozen well-placed nodes. Its most common application to date is along those lines, with utility meters and such.
Is that something a typical phone can do though? Is it just a bluetooth config thing that a phone typically has access to modify, or is BLE Long Range a specific set of electronics/antennas that you won't find in your spare Samsung device?
I'm not a cell phone expert. Some, maybe most, recent cell phones should be able to do BLE LR with their bluetooth radio. It is a specific modulation scheme and it does require the BLE transmitter to be capable of particular power levels. It does not require a special antenna.
“My car can go 450 miles per hour 0-60 in 1.7 seconds”
Well cool story bro but the speed limit is still 65. LoRa is an amazing technology for exactly what you describe but festivals are basically “I have very little line of sight but a fuckton of devices.”
This leads to two different solutions, high bandwidth short wave communication bouncing between everyone, and putting towers above everyone which is what cell companies do. Ground to ground LoRa is neat but not necessarily better.
I've used Meshtastic as small (5000-ish person) festivals, and even with higher bandwidth settings and stock rubber ducky antennas, ground to ground ranges through trees and people of around 1km worked just fine (with the expected shadows behind hills). This was only a small number of devices, I have no idea how badly performance would drop off if 10% or 50% of the attendees were trying to tx/rx Meshtastic or LoRaWAN signals.
LoRa is designed to handle hundreds of devices in the same area since the commercial use case is densely deployed nodes. The spreading factor is orthogonal so it is able to multiplex in the same frequency assuming your data rate is constrained enough for the largest spread factor.
There's a bit more on involved with gateways and coordination that you don't get in P2P mode but the PHY has the pieces you need I'd you wanted to do something similar.
Over my decades of visiting Glastonbury I can report that cellphone coverage has gone from “it works for some calls but no data” to “perfect 3G data everywhere on site”. The cell phone infrastructure companies ship in lots of portable masts.
What about LoRa and Xray Satellite Comm? Couldnt you set up like noded repeaters as well for a ground back up / stronger signal along side as well? I have a bunch different arduino coding to do it, but finding a group of people to actually try to implement it wider scale deems to be harder than one would think. lmfao
they test this stuff regularly at festival and sporting events. i met a guy walking around outside lands with a suitcase full of phones. he was working for verizon to ensure the mobile base stations were appropriately powered
Around October 2020, there was a group of people putting up battery powered LoRa repeater nodes in the hills around Los Angeles. I had a few LilyGo TTGO units, one with DisasterRadio and one with Meshtastic installed.
I could get occasional packets through to one of the nodes that was about 6 miles away (line-of-sight).
My conclusion was that for a city, a much higher transceiver density would be needed if you wanted viable communications. It's not outside the realm of possibility. The units themselves are less than $20/each in bulk, and could be powered with a $5 solar panel/battery rig. Placement of the units would be key.
I saw some Hong Kong activists online post designs for "throwable" battery-powered units. The idea there was to toss out dozens of them during events where non-internet mesh communications would be needed. Seems like an interesting use case, although jamming and the end points (e.g., burner phones with WiFi->LoRa or Bluetooth->LoRa) are still the weak points in a scheme like that.
I bought a couple of these from aliexpress fully assembled[0] (along with some massive terrifying batteries[1]). They're cool little devices. You can send messages via the app on your phone or by plugging them into your computer via USB. There's evidently also some wifi connectivity that I haven't experimented with at all.
Message shows up in the chat room on the phone and on the other devices linked to the room. Planning to play with them for camping Soon™.
I'm not sure about Meshtastic, but in LoRaWAN, with the largest spreading factor (= maximum range) the maximum packet size is 11 bytes. And you get maybe one packet per second at most. Meshtastic is its own protocol and uses repeaters (and wider channels?), so I would expect them to do better, but not several orders of magnitude better.
I worked on LoRaWAN systems a couple years ago, and from what I found the biggest determinant of performance was what frequency band you're in. US915 has a 400ms dwell time limit for single transmissions, while EU868 has a 1% duty cycle limit. LoRa was designed for sending small amounts of data infrequently -- that's the "low-power" in LPWAN. Where I worked we were pushing it to the limits to get a couple hundred bytes per second at close range. LoRa does have some nice properties and I'm glad to see people using it outside of LoRaWAN, which is somewhat bulky for point-to-point communication.
Meshtastic can carry a bit more data per packet -- 200-ish bytes, IIRC -- but the same duty cycle/dwell time constraints apply.
The routing model also makes it hard to add more than a few dozen nodes to a mesh. For small groups over wide distances that's absolutely fine, but it isn't a great option if you want to connect large numbers of _people_, unless said people are clustered around a few devices sharing WiFi or BLE connection time. (Meshtastic also doesn't really support this use case b/c of a "one device == one user/identity/mailbox" model, but that's an application-level choice, not something imposed by the underlying network.)
In the US, the 70 cm ham band is 420 - 450 MHz. The transceiver you referenced is listed for 410 - 441 MHz. It could be used by a licensed ham to transmit data, if he/she determines how to modify or control it to avoid transmitting on the 410 - 420 MHz frequencies. It would also be necessary to send station identification[0] per Section 97.119(a) of the rules, which requires an amateur station to transmit its “assigned call sign on its transmitting channel at the end of each communication, and at least every 10 minutes during a communication.”
It would also be necessary to assure that any harmonics of 433 MHZ were within regulated limits.
EDIT: ETCI has specified 433 - 434 MHz as a LoRa band. In the US, the ARRL band plan[1] specifies those frequencies as auxiliary/repeater links, so they should be usable for LoRa, assuming no local frequency coordination disputes arise. The radio in question should be configured by the ham for that frequency.
EDIT2: In the US, and in general worldwide, hams can only communicate with other hams. So, 433 MHz LoRa would be limited to a mesh exclusively between hams, and with the necessary identification added. Unless you have specific reasons for using higher power, are a ham, and know what you're doing, it would be wise to use standard commercial LoRa radios, and stick to the 902 - 928 MHz radios in the US. (Which is shared with the 33 cm ham band - but the LoRa radios are low power.)
In the stipulated Lora bands in most countries generally you get increased wattage allowable, but only allowed to transmit 1% of the time, or similar.
This is less punitive than it seems, especially with the preamble "chirp" you can keep a link "alive" with a handful of seconds every ten minutes or so, without transmitting a message.
If the Rx woke up once a minute for a few seconds on a synched clock, then you are never more than a minute away from a message. This also aids in power management for battery life.
I am not sure how it would be policed, and what time period is acceptable for measuring, eg per hour, or is it ok one weekend a year at 20% continuous duty cycle, and technically is it per device or per user, and so on. (I think I know the reasonable answers to these questions, just saying).
But intent obviously is with higher power and range to ensure a minimum number of devices can operate in a given region.
But you can broadcast, so one transmission can hit many other users, and they could re-broadcast on your behalf as a store and forward type protocol, all for one transmission by you.
I tried it some time ago, and the only way to communicate was to join a channel with someone you already knew (so basically it needed two(+) people to synchronize first in person or over some other channel, and then chat via meshtastic).
Is there something that supports a "public" chatroom? Something that would allow you to set up a node on a window in a large city, become a point in a mesh and be able to join a chatroom with all the other people (that you don't know yet) and chat there?
I don't personally know anyone else who'd use this over some "normal" chat platform, but live in a building high enough to be able to set a possibly usable meshpoint to connect with other enthousiasts and chat about random stuff there.
> Selecting a default or any of the simple values from the following table will use publicly known encryption keys. They're shipped with Meshtastic source code and thus, anyone can listen to messages encrypted by them. They're great for testing and public channels.
In $west_coast_city I've gotten a fair amount of random pings on default settings.
Other projects (using other base technologies) like https://www.arednmesh.org/ are more focused on joining an already-existing network than making your own.
The Pocket Popcorn Computer might be closer to what you are looking for, if and when it will be ready for purchase.
https://pocket.popcorncomputer.com/
There's a LoRa model of the Popcorn Pocket P.C. which will have a physical keyboard and run Linux, however they're a couple years behind manufacturing schedule so it's a little doubtful if it'll ever actually be for sale.
You still can't get this on one package but the closest I've come so far is using a LoRa capable feather board [0] and a keyboard feathering [1]. This gets you much of the way there.
M17 is possibly what you're looking for? Not specifically mesh but could be used similarly or extended. It's a a protocol that provides data and digital voice transmissions and works (with some modification) on a few existing commercial grade handheld radios running OpenRTX open source firmware. The only thing we need is a radio that has a Bluetooth module.
Having looked at things like this before (including Meshtastic) the thing that stuck out to me about Reticulum is that it’s carrier-agnostic. LoRa is cool, but being able to extend the network over arbitrary channels sounds very appealing.
Reticulum also needs a general-purpose computer -- RPi, laptop, etc. -- that can run the Python daemon that actually handles network traffic.
Meshtastic doesn't use or provide a TCP/IP stack (aside from a limited TUN interface wrapper which is really more of a proof-of-concept) but any device that can connect to a node using WiFi, BLE, or USB serial can use the network.
Yeah, that does seem to be the main downside from what I can tell. Although Meshtastic devices seem to generally require a companion device to use most of their functionality, so I wonder how much that matters at this stage.
I definitely would like a small stand-alone communicator type device at some point though, and yes, that’s probably more feasible with Meshtastic at this point. (Though there are Feather boards that can run Linux too which I’ve thought about playing around with.)
But doesn't carrier agnostic in this context mean that it is very hard to coordinate with people to have compatible hardware?
A nice compatible routing protocol does not help when people have a mix of LoRa, commodity 2.4GHz and 5GHz wifi as the physical layer.
And then add in more esoteric stuff like 3.6GHz CBRS, 433MHz NPR-70, 900MHz Ubiquiti radios or new 802.11ah sub-1GHz radios.
Maybe, but if you want to connect networks between two nearby towns for example, it’d be nice to be able to run that off commodity hardware that’s a bit higher-bandwidth than what you’ll get on LoRa.
And realistically I suspect that people using it for the same sort of use cases they’d use Meshtastic for will be using the same LILYGO (and similar) hardware.
“My knowlegde about Meshtastic is a bit limited, so I might get some details wrong, but from what I understand, Meshtastic is more or less an application. It is focused on carrying out a single task well, in a way that is easy to understand and deploy, but that also means that it will not really do anything else than that task, and stop working well if you push it close to, or outside, its intended operational domain.
Reticulum itself is a general purpose communications stack. It will handle any sort of digital communication for you, from sending a single data packet to sending messages or streaming a video call, to serving a library of all human knowledge. But it will not do so itself. Someone will have to write the applications that utilise Reticulum to do those tasks. This also means that Reticulum, in itself, will not allow anyone to have a chat with someone else. You need an application using Reticulum for that, and a Reticulum network.
Right now, only a handful of programs and applications exist that use Reticulum. One of those systems is LXMF, a distributed messaging protocol that enables direct (and offline) messaging between users and machines. There is currently several LXMF clients available that people can use on mobile devices and computers. This is similar to Meshtastic, in that they both serve the same end-goal, of sending messages between users.
I don't know how open or interoperable the Meshtastic protocol is, but I do know that LXMF is very open and easy to integrate in other system, and messages passed with LXMF can be transported over any number of mediums, such as LoRa, WiFi, packet radio or over the Inernet. And you can mix and match the mediums as you please. This is possible since the messaging system is built on top of Reticulum (a general purpose networking stack), and it then gains all the capabilities of it (such as efficient multihop routing, global addressing, strong encryption, good privacy and so on).
I hope this clarifies it a bit. If not please ask away and I will try to answer as best I can!“
Remember that if anyone manages to get any kind of mesh network working that regular users can use, they will get immediate and very hard pushback from mobile network providers.
People will stop spending $1000/year to have a cell connection if they can browse the web and message friends using your mesh network for free.
My prediction is that no one will ever get the "join us now and share the bandwidth" model of mesh networking to work for any reasonable definition of "work", for both technical and social/political/human-being reasons. No industry conspiracy will be necessary.
Mesh networks will always perform poorly. Each wireless hop cuts throughout in half. People don’t want their device’s battery charge and timeslots used to relay other people’s traffic. To simulate the slowness, use Tor full time.
The bandwidth issue could be helped by having multiple radios like LoRaWAN does right? I think they use up to 8 radios on 8 different channels to have simultaneous data transfer with multiple clients.
I heard about it (here), a couple of years ago. I think the main reason that I didn't get involved, was because there's quite a bit of "some assembly required" with the project.
I don't really have a problem with that, but I wasn't really up to setting up a tech bench, all over, again.
I was trying to work with a proprietary system, and they were quite uncooperative. Once I have the wraps on the project I'm doing now, I may see what I can do.
You're correct that if you buy the most popular board for it (LilyGO T-Beam) from the source, you need to do some light soldering to get the screen on, and need to figure out a case on your own. That said, there's now an ecosystem of people on Etsy and other places who'll sell you a pre-soldered board in a nice printed case, e.g. everything under https://www.etsy.com/shop/QuantumShadow3D. Maybe worth considering if you just want to kick the tires without literally getting your hands dirty.
My dance card is a bit full, now, but this is the kind of stuff that makes my heart warm. I've been messing with hardware forever (my current project is all software).
Is that the main guy behind Meshtastic? I'd probably just get a couple of the prebuilt radios, but not until it was time for me to start working on the project.
AIUI he's not affiliated with the project, just makes good cases. If your interest is in financially supporting the project, there's stickers (https://meshtastic.discourse.group/t/limited-run-meshtastic-...) and donations (https://opencollective.com/meshtastic). I think LilyGO said something about donating a portion of sales of devices pre-flashed with Meshtastic to the project but I haven't kept up with that thread.
I was hacking on this back in 2019 but never finished it, glad this open source project came about and looking forward to trying it out on my next hike! Found a great case for the modules on here too https://www.thingiverse.com/thing:5200457 !
Does meshtastic still have the problem that if there are too many nearby devices they will "capture" messages and use up all their hop count before they make it far?
I work with similar systems a lot, given the modulation and power output, 1-10km would be a reasonable range band, 10km being line of sight under real world conditions, 1km being light urban propagation. It could theoretically be much worse in a dense urban environment with a high noise floor but I think you can safely put it around or slightly better than the performance of those blister pack FRS walkie talkies.
For comparison, my APRS mobilinkd modem attached to a 5 Watt handheld 144mhz radio will routinely do an order of magnitude better and the same modem on my 50w mobile car radio will approach two orders (double the base range plus additional antenna efficiencies).
We learned a great place to test this is festivals.
Lots of endpoint mobility. New nodes coming in and out of the network. Terrible 4/4G cell coverage, so few alternatives. Dead batteries. Shadow zones. Fairly chilled out delivery time constraints. Everything you need to tweak your protocols.
I hope someone into playing with this will set up a larger scale experiment at Glastonbury, Burning Man or another big music festival.