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:
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.
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.
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.
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.
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!
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.
(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.)
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.
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.
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?
https://github.com/meshtastic/Meshtastic-esp32/blob/master/s...
Looks like maybe they do already for $40 if you combine a base and LORA unit -
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.
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 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’ve been trying to write an open-source Apple driver for goTenna units, and have been unable to get them to help me out by providing their BLE spec.
That’s a shame, because I write really nice SDKs. Even if my driver was open and free, it would provide significant brand reinforcement. Win-win.
I believe that this tech is important, as it can provide service in disasters. I’m also big on open-source.
But I cut my teeth on RF stuff, and know that it’s a real black art. Software can get complicated, but is child’s play, compared to RF tech.
You have your work cut out for you.
If you'd like to play with this project we'd love your help (and we have a documented ble api).
Here's an issue where various iOS types are ideating on possibly making an iOS app: https://github.com/meshtastic/Meshtastic-esp32/issues/14
I'm actually in the middle of creating a Web-based instruction series on writing Core Bluetooth SDKs for Apple platforms (not just iOS).
Once I get that done, I may look at adapting this project:
https://github.com/RiftValleySoftware/RVS_GTDriver
For it. It started as a goTenna project, but they never got around to helping me out, so I gave up on them, and made it an OBD driver.
The infrastructure is still there for all kinds of stuff, so I could probably do something.
BTW: If that works out, it would be an SDK that would afford ALL Apple platforms; including Watch and TV.
In the meantime, I have my work cut out for me.
Knowledge of something being patented changes potential damages to punitive damages, making potential lawsuit costs 3x.
Hence, nearly all tech industries prevent discussion of patent specifics outside forums designed for patent discussion. Otherwise anyone who reads this page is increasing their liability 3x, which isn't what HN wants to inflict on its users.
How about outlining the specific patent claims you feel are being violated here, along with links to the patents in question? That approach would feel a lot more helpful and a lot less like a shakedown.
If you've somehow managed to get a patent on sending GPS coords over LoRa I think a lot of people in this space are going to be interested in that. Nearly every LoRa application in the field is going to find themselves in violation.
I understand that hackers are strictly opposed to any sort of patents or copyright. But it is not avoidable topic once you are into business of settling or growing your own company (or a startup). And this is a startup place, isn't it ?
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.
25mW, imagine what you could do with 1/2 a watt.
Open source, royalty free, low power, high range (several km even in urban areas), medium bandwidth, runs on several lora boards.
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 :-)
Offline GPS tracker with very long run time for hiking. I'd like up to one month run time. On the other hand I only need low time resolution, one waypoint each minute. It also does not need to send the location anywhere, storing it local is fine.
Offline/Online GPS tracker for paragliding. Battery for one day, but also high resolution tracking, about one waypoint per second.
Long range communication extender for my mobile phone that does not require infrastructure like base stations. (For the prepper in me)
https://forums.garmin.com/outdoor-recreation/inreach/f/gpsma...
I'm also a (retired, but formerly very active) paraglider and that was a big motivator for me.
1. You mention "location and distance" between member nodes. I assume this is based on the LORA RSSI? How precise is the reading?
2. Do you support the "TTGO LORA32"? Your Github Readme mentions it, but Pages does not.
3. Will the TTGO LORA32 and Heltec LoRa 32 measure distance without being connected to a phone?
Not that it's really relevant here, but I'm wondering if the LORA RSSI can be used to determine distance inside 9m.
You could check for any lessons learned there. I think you can discount any flight users, because they would like to be seen too by other airplanes.
The wikipedia suggests they use standard hardware components?
You might uncover some really cool stuff in the Erlang/Elixir ecosystem for doing mesh communications.
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...
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!
For devices in the field I'd use one of the many available low power ARM controllers.
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.
And if anybody is interested, I'm actively trying to cook up a neat solution with DMR radios - it just works better than the LoRa ones so far :).
Into amateur radio, Digital voice, DMR, SAR, Location tracking and really looking up to https://www.sartrack.co.nz/.
There is a general fear in the backcountry Skiing community that any RF devices might impede or negatively impact the use of search and recovery beacons to locate buried partners in the event of an avalanche. Any documentation/speculation on any potential interference?
My take on this: these devices should be safe to carry provided the hardware is verified to not produce spurious harmonics (via FCC certification or other means). The 900Mhz band used (in the US) by these radios will not interfere with 457KHz signals used by beacons.
I wouldn't carry it in the same pocket as my beacon, but I would use this device--definitely excited to watch the project's progress.
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)"
Problem #1: if users need a custom antenna, it's already a barrier. /me dreams about the IEEE people designing standards that would enable smartphones to use mesh networking... I guess a tiny antenna that can be attached to a smartphone could also make it viable. If the antenna is not bigger than the phone, it would certainly be marketed.
In my view, mesh radio could possibly compete with traditional ISPs, for certain uses, so this kind of tech might not be funded for obvious reasons.
Some form of Repeater/Server or similar feature would be great. A small webserver that the phone can use as a backbone would be really useful. I might even try to help with developing one.
In mass adoption, you want to keep the price right - so have a bulk pricing upfront. Also, keep one access protocol you can access from a phone / PC / most popular devices.
You're doing everything right. Try to get one great customer who can benefit from this today.
