Hi ya'll, so we've spent a few weeks making device software and an android app to convert a $30 chinese gps/radio into a long range mesh radio for hikers. It is working fairly well now (though still an alpha) and we'd love more people to try it and/or have fun coding on it.
We got about 30 users (and some devs from this hackaday article) but we'd love more users and devs to join this happy-happy project:
That's awesome, this kind of thing was the first idea I had when I saw the LoRa radios, but was far too lazy to start doing :p still have the hardware at home; ill see if I can install it later.
He's gotta be assuming the nodes have clear line of sight and fresnel zone. The maximum distance for the link budget in a perfect situation. In practice it probably cuts off at the nearest rise in the ground or depression.
But they're still cool and I still want some for non-hiking applications. With the very low power idle and low cost they could be set up with solar panels in the tops of trees or in similar high height above terrain positions.
There is probably very low noise out in hiking environments.
Yes, attenuation due to terrain is going to be a killer, but my experience with non line of sight 900 MHz links blasting through trees leads me to believe it would be workable for low bit rate data between a series of hikers along the same trail.
It is sending only location and text messages so intermittent link status or re-tries due to temporarily terrain/foliage obstructions will not cause degradation in service that you would experience trying to watch netflix over this mesh.
You're wrong. It's a mistake to treat terrain and foliage as the same thing. I have extensive experience with 3 completely different, narrowband and wideband, 902-928 MHz radio data systems as well as just playing around in the range with my software defined radios (hackrf, rtlsdr, etc).
902-928 has almost no advantage over 2.4 GHz when it comes to line of sight issues with terrain. In fact, it's more problematic due to the increased size of the fresnel zone. Sure, it does better through trees but a slight rise of ground is just as much of a problem for 915 and 2400. The freq here isn't helping much. It's the chirp and LORA modulation helping the link budget. But no line of sight is no line of sight.
It sounds like you agree 900 MHz will be much better than 2.4 GHz in this non line of sight application so long as the obstructions are trees and foliage and not terrain.
I would expect to be able to send a few bytes between two stations maybe 400m apart through non-line of sight forest with 900 MHz and both stations at the same elevation. Certainly the grandparent quoting miles would be for mountain top to mountain top.
This stack overflow question has some nice pictures of the LoRa "chirps". They use rising/falling frequency modulation to allow operation at startlingly low signal to noise ratios.
(Also, the hardware they're using is fairly generic, and pretty much all the vendors selling them offer them in 915/920MHz and also 868MHz and 433MHz variants. I've seen claims of over 10km range with 433MHz LoRa gear without special antennas or clear line-of-sight...)
LoRa has very peculiar modulation scheme that in the end is not CDMA-ish spread spectrum but an interesting way how to extend straight FSK into spread spectrum modulation with respectable processing gain and interference rejection.
I recall reading that part of the design was so that not only was it good at rejecting interference, but that it also caused little interference to other users of the spectrum.
If someone else's ISM radio is using a specific frequency (perhaps with CDMA or TDMA), a "chirp" that's spears over about a hundred kHz and -20db or so down in the noise is unlikely to bother them, but is quite useable/reliable for the LORA gear to detect.
I used to get about a mile on 900MHz Ricochet radios, one of which was sitting on a chair in the living room, the other of which was sitting on the passenger seat of my car. Around a mile, the usable data rate would fall below 4800bps, and my NMEA packets would stop going through.
I find it entirely believable that a lower data-rate modulation could get better range than that, even on less power and worse antennas.
Oh yes, line of sight makes a big difference (also working as mesh helps for forwarding packets). Also we use a very high spreading factor so the bit rate becomes super low (with lots of chirps)
Hmm... I'm pretty sure MURS allows for this type of traffic as of the last rules revision and would be ideal for this use with the higher power allowance, but MURS is a USA only thing so that kinda limits you if the goal is something that works all around the world.
OP is also talking about using off the shelf LoRa boards and their project is more about the software, so they are stuck with the bands available on the commercial LoRa transceivers those boards use.
I actually fly FPV drones and it’s amazing how far I can go and what obstacles I can penetrate with my 915mhz 2W control link with very usable latency (good antennas makes a huge difference as mentioned by others). 2-5km through thick city buildings etc at times.
This is so cool... I spent six months doing research on a routing layer for mesh Android devices (using Bluetooth and Wifi). This would probably make a lot of what I originally tried out a lot easier.
Edit: The issue was making a jump from a local cluster to another cluster far away as local messaging was easy but the further out, the harder it became to maintain connectivity since the amount of devices entering and leaving a mesh became a factor. We actually thought of using amateur radio (to basically allow you to extend the range using them for transfer)
My solution for this kind of thing is to support a router that connects to the internet. Then on the internet side run a DHT so all the internet routers/gateways can find each other. Each router would keep track of the devices they have seen recently, and publish them to a DHT. Much how running a bittorrent client for a particular torrent publishes that fact to the DHT so anyone on the planet can find peers of that torrent.
So if Bob at a ski resort in Colorado want to message someone in Germany his message would propagate around the mesh until a gateway noticed it was for a client that hasn't ever been seen by that gateway. The gateway/router would do a DHT lookup, and would find a router in Germany had seen that user recently and forward the message there. Next time that router heard (directly or indirectly) that the recipient was online it would forward it (directly or through store and forward) to the user. Sure this process might take minutes, but generally it would still be useful.
Imagine an island like Haiti or Puerto Rico is hit by a storm and only one in 5000 people has a cell signal or sat uplink. Add a mesh and just a few uplinks for the whole island and important communications could get through. Maybe even putting a sat uplink on a car that could drive around and allow messages in/out even just once a day could be quite valuable. This of course needs to be combined with store/forward messages and the other various delay tolerant network features.
Seems much more useful than using HF radios to scan the planet for open Ham <-> email gateways. I was rather amused to hear that to communicate across Puerto Rico they often ended up sending messages through an email gateway they could reach in Italy... just to get messages across the island.
One of the other things we have been doing with Serval in the Mesh Extender devices is making it possible to connect external radios, including HF radios from Codan and Barrett, for really long range inter-cluster communications.
Looks awesome! Downloading the app, going to try it out on my T-BEAM that's been sitting dusty, and will definitely have an opportunity to test it soon.
Radio amateurs might be some suitable beta testers for you. It being an open source radio system fits right into the mission and spirit of amateur radio.
However, I'll take the cynical route and say mesh radios, for the general public, are still not very popular. Gotenna and Beartooth, among others appear to be common and popular, and highly reviewed, but in my hikes and ski trips, I haven't seen or heard from a single one. I've seen FAR more basic FRS radios, and SPOT satellite messengers.
Gotenna is stupid expensive. And spot is pretty evil (or at least the instances I've encountered it).
I think what most of the public expects from a radio device is PTT audio. Which isn't going to work with these low bitrate lora devices. I think if they got conditioned to some of this form factor, it would catch on a lot better.
I'm not involved with the project, but I think you can probably get this running. The hardware is cheap, the install instructions are pretty straightforward, and if you know which end of a USB cable is which, you'll be able to bumble through.
Keep notes as you do, and that can feed directly into improving the documentation to be more noob-friendly.
You'll find more ways to get involved from there, including just using and sharing the project with friends.
Yeah I'm interested. I've been building something like this solo, but don't have the skill set to write a mobile app to go with it. I've got the spare parts to make a dozen widgets with a comparable feature set, but family life is keeping me from doing much of it. I know a guy in disaster response who would love to get his hands on a working prototype set to geek out over.
The LORA stuff is pretty cool in that the radio stack (if you can call it so, it's super little code) is open source and you can get complete modules with an STM32 and the associated LoRa radio circuitry and just add power and an antenna.
Maybe resubmit this post so the link works. I would love this for music festivals. They have some solutions but they are hundreds of dollars. If people in the group could put this on a backpack it would be a game-changer. Music festivals also have a big problem with internet access. If they could put host a few powerful repeaters in the middle with electrical and have 5% of attendees (staff) with these they could probably cover the entire place. Send out lineup changes or emergency notices.
Off-topic, but once I stumbled upon an open source WiFi tower designed for an engineering thesis, and the use-case was a music festival; comparing to cellphone networks that are deployed with a truck, this was way cheaper and configurable.
Solutions of hundreds of dollars? For what exactly?
Reminds me of the movie Hackers where they used buzzers. And why not? The only thing you gotta do is use pre-planned keywords/acronyms.
I went to several (music) festivals, big ones between 2002 till 2004 with a few smaller gigs later until 2009 or so. Back then we just used SMS or phone call. I didn't even always have a plan during the mentioned years. Especially outside the country (and NL is small) it was always a surprise to get the next phone bill (one time I paid something like 30 EUR per megabyte, in Serbia). Within the EU, these work with your normal plan nowadays.
I don't know how it is nowadays, but back then on large festivals providers would put up extra (mobile) GSM antennas at the location. I assume they still do that. I can imagine there's a lot of smartphones up in the air to record the magical moment (and ruin it for the people behind you). That alone is a reason why I wouldn't wanna go.
A dumbphone seems still clever if you go outside the country. A rugged one goes for say 30-50 EUR or so. It won't contain or give access to your whole life if it gets confiscated, no social media means you can focus on your stay, and you can still contact authorities or friends if required. Just make sure you add the personal information of those you need to contact (should be on your SIM, though possibly that's too much info as well). Oh, and the screen won't break or get damaged (if it does /care), and who cares if your dumbphone gets stolen. I suppose people generally take the risk, but I got burned once (got a digital camera as birthday present worth ~300 EUR in 2004 and it got stolen after I had it for less than a week). You can always give it away or sell it afterwards (like a real burner) or reuse it for the next journey.
Now, back when I went to music festivals, you'd sortof stay together cause you could find each other but it was a bit annoying. If you could automate it, like you can give your position with WhatsApp, then that'd be great. However, with WhatsApp you decide who can access your location, while with this solution its available to all. That might not be what you want.
Other sports like hiking, skiing I can imagine to use this technology. Even people who live "In The Wild" could meet up with other total strangers, if that's your thing. I mean imagine using this in some huge forest in Canada, or on Greenland where you suddenly notice another life form.
You have to look at the issue from the organizer PoV and not as the event goer. You need to have some kind of reliable communication channels for the staff. The result of 10 years of experience of trying to cause that is for me that analog UHF radios work, wired VoIP phones work and just using whatever smartphones the staff works and combination of these three technologies gives you the SLA level you need. DECT is meaningful solution of the same problem, but the handsets are expensive and even more so if you want some broadcast/PTT capability and ideas like “well, we have bunch of Nokia S60 handsets that should in theory support wifi as LTE/CAE radio layer” is pure nerding-out that does not solve any kind of real issue and instead creates new ones
That’s an awesome project. I was interested in LoRa for the same reason. I’m an iOS dev and paraglider myself so I can help you with the iOS app.
Let’s chat
I guess my only advice is make sure the software keeps to the duty cycle limits of the license free band. And note that different countries may have different regulations on what is allowed on the frequency LoRa uses, if using it is even allowed.
That's the nice thing about 915 in the US, it's basically do-whatever. Not the case with 315/433, though!
I'm a huge fan of 900MHz meshes, and have a basement full of Ricochet hardware. Starmode chat was the coolest thing in the world, but GPS's were expensive back then, so mobile nodes didn't know where they were. Stationary routers were programmed with their lat/lon when they were installed, and the MCDN mesh did geographic (distance-bearing) routing within them.
On the Meshtastic site, it says the TTgo board is recommended "for most users", without saying why. It looks like this is because the GPS is built into the TTgo board but not the Heltec, but this isn't clearly explained. I picked up a few of the Heltec boards recently, because they were much more commonly available. I assume I can tack on a GPS to some random UART pins and tweak some pin assignments in a header file somewhere?
If I have stable power and a high point somewhere, I'd be interested in running a repeater node that helps _everyone_'s traffic, not just my own friends who have the same encryption key loaded or whatever. Is there a way to do that, or can that be added as a feature request?
Is there support for arbitrary data transport over the Lora layer; could I ssh from my phone, across the meshtstic lora, to my desktop at home sitting near another node?
>Is there support for arbitrary data transport over the Lora layer
Seconding this, I am thinking about making ultra-remote seismometers that send back (highly compressed and carefully selected) readings via something like LoRa. I could use this as the transport layer and only have to worry about the sampling and processing.
(Yes - I know about the raspberry shake. It has a lot of flaws with the design which is why I'm going for the redesign)
Also which of the ISM bands are valid in which country. (We sold off the bottom half the 915 band here to telcos, so only the upper half of it is available in .au)
(2) The 900 MHz ISM band within Australia is 915–928 MHz. 900 MHz ISM devices working outside of this range cannot be operated in Australia (that is, ISM devices that use the frequencies 902–915 MHz are not authorised for use within Australia).
(3) Using the frequency range 902–915 MHz would interfere with Australian mobile telephone networks. Severe criminal penalties, including fines of up to $255,000, exist under the Radiocommunications Act 1992 for interfering with radiocommunications services.
I think it would be very helpful to other hobbyists if once you have worked out all the limitations in each country, to make a guide or infographic about all the rules and limitations.
And in EU the whole 915MHz ISM band simply does not exist and is “the original GSM band” with the added caveat that there are some safety critical services inside the GSM's uplink/downlink guard band.
Thanks! alas, I think that is a bit to big for what we have to work with in our ESP32s. We started our sw design based on what off the shelf hardware we could find and worked from that.
How is it offering 'private' communications on the 33cm band? Does this band even offer good performance in hilly or mountainous terrain? These would be short range line of sight only type devices, correct? I'm still fairly new to amateur radio so I could be off. I don't see the advantage of this over something like APRS on 2M, with the exception that you don't need a license.
encryption is allowed for low duty cycle digital usage on that band.
I'm also a ham and really into APRS. But not requiring a license is a big plus, also the way these chirping radios achieve their long range with a super high noise floor so the battery life is amazing. i.e. a TTGO TBEAM will run for about eight days on (including the GPS/radio and CPU). And $30 for that board.
I was going to suggest that you look into some of the patents that were the basis for the old Ricochet Networks stuff as its the basis for most of the smartgrid meter tech, but apparently many of them are more recent than I expected and still under the 20 year mark... also might want to post it to /r/amateurradio for feedback... 73 om!
Not an expert by any means, but I'd suggest looking at the Dash7 protocol/ firmware as a reference for the mesh, security and positioning. It's been around a while and seems robust.
Open source, royalty free, low power, high range (several km even in urban areas), medium bandwidth, runs on several lora boards.
ooh. That is great advice! We used the RadioHead mesh solution but it is super non optimal for us and we plan to switch. I'll definitely do some reading on DASH7.
Not sure if this is "good" advice, but this would make for a very appealing kickstarter: cool gadget with very useful functionality for popular activities (music festivals, hiking, skiing) that could even help in an emergency. It hits a lot of the right notes.
Possible that when you're further along you can have a kickstarter for a commercial version that's officially created by the open-source project. The more (mutually compatible) devices out there, the better the mesh, right?
The ESP32 draws quite a lot of current when running BLE (without Wifi), unless that's been fixed recently. IIRC, the TTGO boards have poor low-power design that will kill the 18650 battery in a few days, no matter what you do, that could perhaps be fixed with a small modification though.
I have a hardware design that might be an interesting starting point. It's based around nrf52 (Cortex M4F with BLE and nice SDK), 400mah battery, microphone, speaker, 3*4 RGB LED matrix, gyro/accelerometer, NFC. Very small device, 35mm across. Can extend the top of the PCB, add a small OLED screen and a LORA radio. Hitting $30 price point shouldn't be a problem. Email in profile :-)
Gotta love ESP32s, huh? It's great to see more affordable "commodity-style" boards with some extra radios built in.
This looks like a very cool project - I might pick up a few of those 'T-beam' boards and see if some people want to try taking a hike with them. Thanks for sharing!
I've never liked Gotenna's requirement to be paired with a cellphone for tracking, so I've been watching Lynq's development for a while. But, I'd much rather have an open-source solution than one that depends on the fortunes and whims of a single compnay. Particularly if there was easy-to-use commercial hardware available with the open source software.
The other downside of Lynq is that it doesn't use mesh networking, e.g., every Lynq unit can only communicate with other units it can connect to directly. That means if you have a group of 3 people all in a line, separated by 3-miles, only the person in the middle will be able to find the location of the entire group, and the people at the ends of the line would be invisible to each other.
Anyway - all that to say - I'm super-excited for your project and wish you all the best.
yes, that's what we thought also. Also, the phone is optional for our case (though you need it for sending texts - if you don't have one the display still shows rxed texts and headings/distance to members of the channel)
In my case, only the Heltec boards were easily available, and they lack the GPS that's in the TTgo boards. So I hope there's a way for the phone's GPS to participate!
(Or, since the esp32 has bluetooth, recognize a bluetooth GPS puck? That's extra work and they're quite rare, so maybe nah.)
Otherwise I'm totally fine soldering another GPS onto some random GPIO pins, I have a whole bag of those. I'm just not sure what it would take to get it recognized.
yes. If your radio doesn't have GPS the phone will provide GPS updates to the radio. Everything is treated identially (though there will be a bit higher battery consumption on both the phone and the radio)
also, adding support to dynamically probe for a GPS attached to GPIOs would be very straightforward (almost identical to the tbeam case). If you're interested in this ping us on the devchat and someone will help talk you through it.
Note that there are limits to how large a mesh network can scale, it's likely to start running into problems with several hundred users. You can scale larger by limiting data to short text messages, but you'll probably never be able to handle more than 10,000 users, unless you can find a way to create high bandwidth backbone links between clusters of users. There has been a lot of research on this in the wireless sensor network research community and in the WiFi mesh network research community also. A concert going crowd could easily cause a mesh network to become un-useably slow if everyone was trying to use it at the same time.
Why? Even 200 in a small area, say a ski resort, mountain bike race, or similar seems perfectly reasonable. Sure not 200 people typing as fast as they can, but plenty for the normal chatter I hear over sms. Especially if you keep the messages short and have a latency of a few minutes be acceptable.
Using the family radios (often $30 ish) on hiking trails, parks, amusement parks, etc. I usually hear minimal chatter, just things like "Anyone seen Bob?", "meet at lift #4", "Lunch in 30m?", "Linda stopped to retie her shoes", etc.
Check out js8call if you want to see how to handle 100s of people with very little bandwidth. Sure it's designed for ham radio frequencies and covers 1000s of miles instead of 1000s of feet, but still man portable
A phone, bluetooth sound card, a HF transceiver, and an antenna is all you need. Generally hams are proud when they get better than 1000 miles per watt.
a channel in this case is a set of friends who are on one common preshared key (and a hopping set of frequencies). So each mesh only cares about (or even sees) packets on that mesh.
Lora is quite a slow bitrate protocol (but it has _great_ range and super low power needs). So we are focusing on our smaller use-case at first (in the interest of speed of development and stability for users)
That's true in practice with current radios, but it was a beautiful discovery in 2006 that it's not true in theory! In a world where radios are perfect and nodes cooperate to do decentralized beamforming, the capacity-per-node of a random mesh network scales as the number of nodes increases. See Ozgur, Leveque, and Tse, "Hierarchical Cooperation Achieves Optimal Capacity Scaling in Ad Hoc Networks," IEEE Trans. Info. Theory (2007) (https://arxiv.org/abs/cs/0611070).
Interesting. I wonder how well it would work in practice though. They assume uniform randomly distributed nodes, whereas people don't tend to distribute themselves randomly. They don't address practical concerns either, like how narrow the MIMO beamwidths need to be and how easy that is to achieve. Still a nice theoretical result.
This seems like it requires point-to-point communication; and with accurate MIMO configuration my intuition for the endpoints is that it's like they are communicating with laser-like narrow beams but in RF. But AFAIK multihop communication is still stuck at sqrt(n) scaling, i.e. not viable.
This is all pretty theoretical though, for a small number of nodes like up to 100 it should work pretty well like in the OP application.
I have looked into this in some detail doing deployment studies for wireless HART instruments (industrial processing plant gear) which can talk to a base station or store and forward for a friend.
So depending whether you want broadcast or point to point, or in between, performance is dominated by "pinch points" which is such an obvious term that I wont describe it.
This means that a groups situation in this context could be dramatically improved by a unit or two in a balloon or drone above the group or similar.
I suspect in practice when deployed and medium sized groups use these that a "signals master" or two will have primary responsibiliy to maintain such nodes to keep effective comms up and might use kites, balloons, drones, terrain, whatever and a particular set of skills and equipment would develop.
Also, if any given unit can impose a "cost" relative to business, amount of battery used etc then self levelling and incentive to be terser with messaging can occur. Lets face it, when you are down to 3 bits a second the use of emoticons will drop off pretty quickly.
XBee it's already at an $30 and $15 price point, I think to 'disrupt' you would need to be profitable at a -10x price point. This is my opinion. I'm usually wrong. But you asked.
Haha not sad. It's hard to have an informed opinion, better to acknowledge it.
I am impressed with the XBee series 3 modules that I've bought. Digi is 100% behind the product. The documentation is great. The engineering is of the 'we're go to the Moon' era not 'move fast and break things' crap the perforates startups. I'm very impressed so they're a tough entrenched to beat.
Thank you. This is a full circuitboard with GPS+battery+lora+CPU+oled screen for $30. So I'm not trying to compete with a $15 radio devboard that someone has to solder into their project, but more something that 'just works'. And open source, for fun, so not selling it at all ;-)
I worked on a similar project for Motorola and it had limited commercial success.
Very dense topologies need to aggressively handle broadcast storms such as ARP storms. Very fragmented topologies need to handle delay tolerant networking.
In any event, search for "Mobile Ad-hoc Networks" will show work that has been done previously.
thanks! yes, we are very delay tolerant and a typical text message (or flooded location update) takes a few seconds to get across our likely max # of hops (which is only three, due to our uhttps://github.com/meshtastic/Meshtastic-esp32/blob/master/d...)
15 year old High School sophomore noob here. We (crazily) are attempting to put up a CubeSat (shameless plug www.seakingspace.com). Using the Lora SX1268 433Mhz we tested the Semtech transceiver across the Catalina channel. 25+ Miles SF factors 7,9,11 at 125 BW. Worked great. We did a link budget and should work over 500KM line of sight no prob. The SX126X is the new improved version of the Lora chip. Im sure a verion with it will come out shortly.
LoRaWAN® distance world record broken. 766 km (476 miles) using 25mW transmission power. After almost 2 years, the world record of 702 km (436 miles) has been broken.Aug 14, 2019
We're working with those guys and might share the same protocol stack. Discussions underway.
The difference is: disaster.radio is targeted as a "just in case emergency radio build on custom hardware, that joins a mesh with other folks who bought the same emergency radio."
This is a $30 radio (with built in GPS+radio+CPU+battery+OLED screen) already available from a chinese mfg. Then you put our app on it and have a group navigator you can use with your friends while skiing or hiking, instead of buying a $100 closed source kickstarter (and it will run eight days on a charge)"
Howdy,
as the founder of the Serval Mesh adhoc networking protocols and hardware, what I would look for in a new radio is:
1. True packet radio mode, that doesn't hide the radioness of the link etc, but lets the programmer use it's strengths.
2. UART link, ideally using 3DR/RFD900 compatible connector (then we can include it directly in our existing systems, and so can others).
3. Field-flashable, but with robust protections on the boot loader, as it is not uncommon for a radio to be on the boot serial interface, on hardware that has only one serial port.
4. Support 434, 868 and 905-935MHz ISM bands.
5. Use advanced interference tolerant wave-forms, like Chirped Spread Spectrum or even something better.
6. Fully open chipset/firmware design, so that it can be truted.
Anyway, poke me at paul@servalproject.org if you would like to talk further about it.
Paul.
Thanks for the feedback. I think this project is a little bit different, we are focusing for now on making a nice end-user friendly consumer product using hardware that is already shipping from various aliexpress vendors. our tag line is "An opensource hiking, pilot, skiing, Signal-App-extending GPS mesh communicator for $30" We are currently using RadioHead mesh library, but we might shift to a common implementation with the disaster radio geeks.
btw: Back when I was writing Andropilot I also wrote a fair portion of the code that is in those RFD900 radios (or at least was, I haven't checked in a while). I'm super glad you are using them!
Keep the hacking ability. Your large target demographic may not use or need it, but tinkerers will hype your product for free, at least in theory. See the RTL_SDR as an example, although it is a low cost DVB tuner.
oh yes - definitely want people to hack and add features (or use it as auto configuring pipes for other projects etc...). I'm just trying to say "at least for 1.0" we are trying to stay focused on this one primary thing. ;-)
Unofficially, CEO of one of the biggest vendors of dvb-t receivers in my country said that he isn't that technical, but he knows very well that he is still biggest vendor because his devices can be hacked.
Good advice. I also recommend to make sure the toolchain is usable and documentation is readily available.
I worked on a project that had an Silicon Labs EFR32, and while the hardware may have been great, their proprietary, closed-source "Radio Abstraction Interface Layer" was hard to use and badly documented.
The Eclipse based IDE that you HAD to use to configure the radio front-end (the EFR32 is a system-on-chip with an RF front-end and an ARM Cortex M4F core) is a GUI, and porting or comparing radio configs between different chip generations, and even different versions of the IDE, is a nightmare.
The Java IDE crashes regularly, debugging does not really work etc., so it really is worth taking some time to evaluate the whole package around an RF IC.
Upvoted for the deep knowledge shared here- but as a consumer, I don't know enough to care anything about any of that. I think a mesh radio that keeps us all together on a hike, festival, or emergency situation sounds pretty cool, and being open and extensible makes it even better.
Yes, we know we need to fix the website and app store. This is the pain of depending on grants to get work done :/ Getting the app back up on Play Store is our current priority.
The idea of these radio mesh network things is great. The reality is terrible because radio waves need line of sight unless you've got a repeater. This is completely impractical when hiking, or in a city filled with buildings. They end up with crazy short range between devices and you need an implausibly long string of them to get from a person off the grid to a mesh point on the grid. The only exception to this being someone high on a hill with no bumpy bits of other hills between them and whoever has the other mesh point that happens to be on-grid.
Gotenna couldn't make this work with all their $$ because of the simple physics of radio waves. Yes they sell devices that technically do what they claim, they just fall flat on their faces when they encounter hills, or buildings... or anything that isn't flat.
I think if you want to make something that actually works, you should drop the "consumer" and make having a ham radio license a requirement. Then use the GPS to find the closest public repeater. Their locations are pretty well mapped at this point.
Use the most appropriate of the many ham radio digital packet systems for whatever wavelength you're broadcasting on and choose the appropriate part of the spectrum that is designated for digital packet use.
Also be a good radio citizen and try other frequencies if the current one is in use.
I understand that the ham license is pretty much a deal breaker for adoption BUT it's what's required to use the decent frequencies and access to repeaters. As this seems to be an open source kind of project and not a "hey lets sell bajillions" kinda thing, that seems like a plausible option.
Dunno, I think one of the biggest weakness of various ham related technologies (and yes I have my general) is the assumption that everyone is online all the time. Trying to communicate with a few dozen people is very inefficient with amateur radio in general. It's usually voice, usually assumes everyone is doing nothing but listening, is listening continuously and has perfect reception. God forbid someone is driving, hiking aggressive terrain, or a group of 10 people is online only 60% of the time each.
Most of the cheap ham stuff assumes a perfect repeater already to do the heavy lifting, which is nice when you have it, but very frustrating when you don't.
I do wish that ham or consumer devices supported digital modes, peer to peer, store and forward, push, pull, query, etc. Js8call supports this, so you can do things like ask when someone was last seen, leave messages on 3rd parties, ask 3rd parties to forward, etc. So even if each radio is online part of the time, and parties that want to talk can not directly hear each other things work just fine. It's amazing to even think about, communicating several magnitudes below the noise floor, power levels so low that hams are proud when they get less than 1 watt per 1000 miles!
Imagine standing on the west cost of the USA, shining a 5 watt flashlight at the sky, having it bounce off the sky, to land, and again into the sky, and again to the last to someone 1000s of miles away... and they can decode your signal. Amazing stuff.
I do wonder what the smallest package you could fit a 1 watt bluetooth connected HF radio in to enable any phone to talk js8call.
we are careful to keep the esp clock-gated almost all the time (esp calls this light-sleep), in that mode the power draw of the ESP is on 1.5mA. When the radio (or button press) receives a packet it wakes the main CPU, which then services everything (turning on bluetooth as needed) and then goes back to sleep. If you are curious for more details we have a power consumptions spreadsheet in our docs.
175 comments
[ 548 ms ] story [ 2316 ms ] threadWe got about 30 users (and some devs from this hackaday article) but we'd love more users and devs to join this happy-happy project:
https://hackaday.com/2020/02/26/lora-mesh-network-with-off-t...
I'm happy to respond to any questions or comments...
You say a few miles per node - I am having trouble seeing how that's possible without elevating all the nodes
But they're still cool and I still want some for non-hiking applications. With the very low power idle and low cost they could be set up with solar panels in the tops of trees or in similar high height above terrain positions.
At very low bit rates you need very little SNR.
There is probably very low noise out in hiking environments.
Yes, attenuation due to terrain is going to be a killer, but my experience with non line of sight 900 MHz links blasting through trees leads me to believe it would be workable for low bit rate data between a series of hikers along the same trail.
It is sending only location and text messages so intermittent link status or re-tries due to temporarily terrain/foliage obstructions will not cause degradation in service that you would experience trying to watch netflix over this mesh.
902-928 has almost no advantage over 2.4 GHz when it comes to line of sight issues with terrain. In fact, it's more problematic due to the increased size of the fresnel zone. Sure, it does better through trees but a slight rise of ground is just as much of a problem for 915 and 2400. The freq here isn't helping much. It's the chirp and LORA modulation helping the link budget. But no line of sight is no line of sight.
I would expect to be able to send a few bytes between two stations maybe 400m apart through non-line of sight forest with 900 MHz and both stations at the same elevation. Certainly the grandparent quoting miles would be for mountain top to mountain top.
(Also, the hardware they're using is fairly generic, and pretty much all the vendors selling them offer them in 915/920MHz and also 868MHz and 433MHz variants. I've seen claims of over 10km range with 433MHz LoRa gear without special antennas or clear line-of-sight...)
If someone else's ISM radio is using a specific frequency (perhaps with CDMA or TDMA), a "chirp" that's spears over about a hundred kHz and -20db or so down in the noise is unlikely to bother them, but is quite useable/reliable for the LORA gear to detect.
https://electronics.stackexchange.com/questions/278192/under...
I find it entirely believable that a lower data-rate modulation could get better range than that, even on less power and worse antennas.
And you can do a LOT with antennas on 900MHz.
OP is also talking about using off the shelf LoRa boards and their project is more about the software, so they are stuck with the bands available on the commercial LoRa transceivers those boards use.
Edit: The issue was making a jump from a local cluster to another cluster far away as local messaging was easy but the further out, the harder it became to maintain connectivity since the amount of devices entering and leaving a mesh became a factor. We actually thought of using amateur radio (to basically allow you to extend the range using them for transfer)
So if Bob at a ski resort in Colorado want to message someone in Germany his message would propagate around the mesh until a gateway noticed it was for a client that hasn't ever been seen by that gateway. The gateway/router would do a DHT lookup, and would find a router in Germany had seen that user recently and forward the message there. Next time that router heard (directly or indirectly) that the recipient was online it would forward it (directly or through store and forward) to the user. Sure this process might take minutes, but generally it would still be useful.
Imagine an island like Haiti or Puerto Rico is hit by a storm and only one in 5000 people has a cell signal or sat uplink. Add a mesh and just a few uplinks for the whole island and important communications could get through. Maybe even putting a sat uplink on a car that could drive around and allow messages in/out even just once a day could be quite valuable. This of course needs to be combined with store/forward messages and the other various delay tolerant network features.
Seems much more useful than using HF radios to scan the planet for open Ham <-> email gateways. I was rather amused to hear that to communicate across Puerto Rico they often ended up sending messages through an email gateway they could reach in Italy... just to get messages across the island.
https://developer.synapse-wireless.com/modules/index.html
However, I'll take the cynical route and say mesh radios, for the general public, are still not very popular. Gotenna and Beartooth, among others appear to be common and popular, and highly reviewed, but in my hikes and ski trips, I haven't seen or heard from a single one. I've seen FAR more basic FRS radios, and SPOT satellite messengers.
Gotenna is stupid expensive. And spot is pretty evil (or at least the instances I've encountered it).
I think what most of the public expects from a radio device is PTT audio. Which isn't going to work with these low bitrate lora devices. I think if they got conditioned to some of this form factor, it would catch on a lot better.
I don't have any relevant skills for radio or SDR stuff, but I'd love to mess around with it for a couple of hours a week.
Keep notes as you do, and that can feed directly into improving the documentation to be more noob-friendly.
You'll find more ways to get involved from there, including just using and sharing the project with friends.
Thanks for the encouragement, by the way. I really appreciate that.
https://github.com/servalproject/foss-comms-tower
Reminds me of the movie Hackers where they used buzzers. And why not? The only thing you gotta do is use pre-planned keywords/acronyms.
I went to several (music) festivals, big ones between 2002 till 2004 with a few smaller gigs later until 2009 or so. Back then we just used SMS or phone call. I didn't even always have a plan during the mentioned years. Especially outside the country (and NL is small) it was always a surprise to get the next phone bill (one time I paid something like 30 EUR per megabyte, in Serbia). Within the EU, these work with your normal plan nowadays.
I don't know how it is nowadays, but back then on large festivals providers would put up extra (mobile) GSM antennas at the location. I assume they still do that. I can imagine there's a lot of smartphones up in the air to record the magical moment (and ruin it for the people behind you). That alone is a reason why I wouldn't wanna go.
A dumbphone seems still clever if you go outside the country. A rugged one goes for say 30-50 EUR or so. It won't contain or give access to your whole life if it gets confiscated, no social media means you can focus on your stay, and you can still contact authorities or friends if required. Just make sure you add the personal information of those you need to contact (should be on your SIM, though possibly that's too much info as well). Oh, and the screen won't break or get damaged (if it does /care), and who cares if your dumbphone gets stolen. I suppose people generally take the risk, but I got burned once (got a digital camera as birthday present worth ~300 EUR in 2004 and it got stolen after I had it for less than a week). You can always give it away or sell it afterwards (like a real burner) or reuse it for the next journey.
Now, back when I went to music festivals, you'd sortof stay together cause you could find each other but it was a bit annoying. If you could automate it, like you can give your position with WhatsApp, then that'd be great. However, with WhatsApp you decide who can access your location, while with this solution its available to all. That might not be what you want.
Other sports like hiking, skiing I can imagine to use this technology. Even people who live "In The Wild" could meet up with other total strangers, if that's your thing. I mean imagine using this in some huge forest in Canada, or on Greenland where you suddenly notice another life form.
I'm a huge fan of 900MHz meshes, and have a basement full of Ricochet hardware. Starmode chat was the coolest thing in the world, but GPS's were expensive back then, so mobile nodes didn't know where they were. Stationary routers were programmed with their lat/lon when they were installed, and the MCDN mesh did geographic (distance-bearing) routing within them.
On the Meshtastic site, it says the TTgo board is recommended "for most users", without saying why. It looks like this is because the GPS is built into the TTgo board but not the Heltec, but this isn't clearly explained. I picked up a few of the Heltec boards recently, because they were much more commonly available. I assume I can tack on a GPS to some random UART pins and tweak some pin assignments in a header file somewhere?
If I have stable power and a high point somewhere, I'd be interested in running a repeater node that helps _everyone_'s traffic, not just my own friends who have the same encryption key loaded or whatever. Is there a way to do that, or can that be added as a feature request?
Is there support for arbitrary data transport over the Lora layer; could I ssh from my phone, across the meshtstic lora, to my desktop at home sitting near another node?
Seconding this, I am thinking about making ultra-remote seismometers that send back (highly compressed and carefully selected) readings via something like LoRa. I could use this as the transport layer and only have to worry about the sampling and processing.
(Yes - I know about the raspberry shake. It has a lot of flaws with the design which is why I'm going for the redesign)
https://github.com/meshtastic/Meshtastic-esp32/blob/master/s...
https://www.acma.gov.au/step-2-show-your-product-complies
Says:
(2) The 900 MHz ISM band within Australia is 915–928 MHz. 900 MHz ISM devices working outside of this range cannot be operated in Australia (that is, ISM devices that use the frequencies 902–915 MHz are not authorised for use within Australia).
(3) Using the frequency range 902–915 MHz would interfere with Australian mobile telephone networks. Severe criminal penalties, including fines of up to $255,000, exist under the Radiocommunications Act 1992 for interfering with radiocommunications services.
You might uncover some really cool stuff in the Erlang/Elixir ecosystem for doing mesh communications.
I'm also a ham and really into APRS. But not requiring a license is a big plus, also the way these chirping radios achieve their long range with a super high noise floor so the battery life is amazing. i.e. a TTGO TBEAM will run for about eight days on (including the GPS/radio and CPU). And $30 for that board.
Open source, royalty free, low power, high range (several km even in urban areas), medium bandwidth, runs on several lora boards.
https://dash7-alliance.org/
Possible that when you're further along you can have a kickstarter for a commercial version that's officially created by the open-source project. The more (mutually compatible) devices out there, the better the mesh, right?
We are using a GPL license, but if someone wants to eventually sell devices (as long as they obey the GPL) with our code we think that's great.
I have a hardware design that might be an interesting starting point. It's based around nrf52 (Cortex M4F with BLE and nice SDK), 400mah battery, microphone, speaker, 3*4 RGB LED matrix, gyro/accelerometer, NFC. Very small device, 35mm across. Can extend the top of the PCB, add a small OLED screen and a LORA radio. Hitting $30 price point shouldn't be a problem. Email in profile :-)
https://photos.app.goo.gl/qUyrRYDrtu2SHsHR9
This looks like a very cool project - I might pick up a few of those 'T-beam' boards and see if some people want to try taking a hike with them. Thanks for sharing!
Seems like an open-source mashup of something like Lynq https://lynqme.com/ - and Gotenna https://gotennamesh.com/
I've never liked Gotenna's requirement to be paired with a cellphone for tracking, so I've been watching Lynq's development for a while. But, I'd much rather have an open-source solution than one that depends on the fortunes and whims of a single compnay. Particularly if there was easy-to-use commercial hardware available with the open source software.
The other downside of Lynq is that it doesn't use mesh networking, e.g., every Lynq unit can only communicate with other units it can connect to directly. That means if you have a group of 3 people all in a line, separated by 3-miles, only the person in the middle will be able to find the location of the entire group, and the people at the ends of the line would be invisible to each other.
Anyway - all that to say - I'm super-excited for your project and wish you all the best.
(Or, since the esp32 has bluetooth, recognize a bluetooth GPS puck? That's extra work and they're quite rare, so maybe nah.)
Otherwise I'm totally fine soldering another GPS onto some random GPIO pins, I have a whole bag of those. I'm just not sure what it would take to get it recognized.
Using the family radios (often $30 ish) on hiking trails, parks, amusement parks, etc. I usually hear minimal chatter, just things like "Anyone seen Bob?", "meet at lift #4", "Lunch in 30m?", "Linda stopped to retie her shoes", etc.
Check out js8call if you want to see how to handle 100s of people with very little bandwidth. Sure it's designed for ham radio frequencies and covers 1000s of miles instead of 1000s of feet, but still man portable
A phone, bluetooth sound card, a HF transceiver, and an antenna is all you need. Generally hams are proud when they get better than 1000 miles per watt.
Lora is quite a slow bitrate protocol (but it has _great_ range and super low power needs). So we are focusing on our smaller use-case at first (in the interest of speed of development and stability for users)
(Also worth reading: Tim Shepard's Ph.D. dissertation from 1995 (http://groups.csail.mit.edu/ana/Publications/PubPDFs/Timothy...), which predates a lot of the "information theory" interest in this subject.)
This is all pretty theoretical though, for a small number of nodes like up to 100 it should work pretty well like in the OP application.
So depending whether you want broadcast or point to point, or in between, performance is dominated by "pinch points" which is such an obvious term that I wont describe it.
This means that a groups situation in this context could be dramatically improved by a unit or two in a balloon or drone above the group or similar.
I suspect in practice when deployed and medium sized groups use these that a "signals master" or two will have primary responsibiliy to maintain such nodes to keep effective comms up and might use kites, balloons, drones, terrain, whatever and a particular set of skills and equipment would develop.
Also, if any given unit can impose a "cost" relative to business, amount of battery used etc then self levelling and incentive to be terser with messaging can occur. Lets face it, when you are down to 3 bits a second the use of emoticons will drop off pretty quickly.
That's either insightful, or sad... and I can relate.
I am impressed with the XBee series 3 modules that I've bought. Digi is 100% behind the product. The documentation is great. The engineering is of the 'we're go to the Moon' era not 'move fast and break things' crap the perforates startups. I'm very impressed so they're a tough entrenched to beat.
Looks like maybe they do already for $40 if you combine a base and LORA unit -
https://m5stack.com/collections/m5-core
https://m5stack.com/collections/m5-module
Very dense topologies need to aggressively handle broadcast storms such as ARP storms. Very fragmented topologies need to handle delay tolerant networking.
In any event, search for "Mobile Ad-hoc Networks" will show work that has been done previously.
We initially used the RadioHead mesh router (which seems to be a variant of DSR), but we are switching to something else soon. Misc notes here: https://github.com/meshtastic/Meshtastic-esp32/blob/master/d...
25mW, imagine what you could do with 1/2 a watt.
How does this differ from disaster.radio? More portable?
I ask because I really think these are important projects and I'm not sure which to contribute my time towards.
The difference is: disaster.radio is targeted as a "just in case emergency radio build on custom hardware, that joins a mesh with other folks who bought the same emergency radio."
This is a $30 radio (with built in GPS+radio+CPU+battery+OLED screen) already available from a chinese mfg. Then you put our app on it and have a group navigator you can use with your friends while skiing or hiking, instead of buying a $100 closed source kickstarter (and it will run eight days on a charge)"
btw: Back when I was writing Andropilot I also wrote a fair portion of the code that is in those RFD900 radios (or at least was, I haven't checked in a while). I'm super glad you are using them!
Unofficially, CEO of one of the biggest vendors of dvb-t receivers in my country said that he isn't that technical, but he knows very well that he is still biggest vendor because his devices can be hacked.
I worked on a project that had an Silicon Labs EFR32, and while the hardware may have been great, their proprietary, closed-source "Radio Abstraction Interface Layer" was hard to use and badly documented.
The Eclipse based IDE that you HAD to use to configure the radio front-end (the EFR32 is a system-on-chip with an RF front-end and an ARM Cortex M4F core) is a GUI, and porting or comparing radio configs between different chip generations, and even different versions of the IDE, is a nightmare.
The Java IDE crashes regularly, debugging does not really work etc., so it really is worth taking some time to evaluate the whole package around an RF IC.
The idea of a secondary low bandwidth Internet being robust to interference from goverment and disasters? That stuff is true cyberpunk to me.
* No http -> https redirect
* Broken layout when forced to https
* Play store link 404's
* Icon on the download button is broken
It is just a standard github pages page. I think you might want to check your web browser config.
Would love to know what you consider better than chirped spread spectrum.
Gotenna couldn't make this work with all their $$ because of the simple physics of radio waves. Yes they sell devices that technically do what they claim, they just fall flat on their faces when they encounter hills, or buildings... or anything that isn't flat.
I think if you want to make something that actually works, you should drop the "consumer" and make having a ham radio license a requirement. Then use the GPS to find the closest public repeater. Their locations are pretty well mapped at this point.
Use the most appropriate of the many ham radio digital packet systems for whatever wavelength you're broadcasting on and choose the appropriate part of the spectrum that is designated for digital packet use.
Also be a good radio citizen and try other frequencies if the current one is in use.
I understand that the ham license is pretty much a deal breaker for adoption BUT it's what's required to use the decent frequencies and access to repeaters. As this seems to be an open source kind of project and not a "hey lets sell bajillions" kinda thing, that seems like a plausible option.
Most of the cheap ham stuff assumes a perfect repeater already to do the heavy lifting, which is nice when you have it, but very frustrating when you don't.
I do wish that ham or consumer devices supported digital modes, peer to peer, store and forward, push, pull, query, etc. Js8call supports this, so you can do things like ask when someone was last seen, leave messages on 3rd parties, ask 3rd parties to forward, etc. So even if each radio is online part of the time, and parties that want to talk can not directly hear each other things work just fine. It's amazing to even think about, communicating several magnitudes below the noise floor, power levels so low that hams are proud when they get less than 1 watt per 1000 miles!
Imagine standing on the west cost of the USA, shining a 5 watt flashlight at the sky, having it bounce off the sky, to land, and again into the sky, and again to the last to someone 1000s of miles away... and they can decode your signal. Amazing stuff.
I do wonder what the smallest package you could fit a 1 watt bluetooth connected HF radio in to enable any phone to talk js8call.
https://www.electronthemes.com/what-is-the-best-cms-between-...
For devices in the field I'd use one of the many available low power ARM controllers.