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.
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.
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. ;-)
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.
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:
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)
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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)
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.
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
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.
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
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!
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...)
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.
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 ;-)
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.
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!
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
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.
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.
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)
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.
(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.
You can try to contact those Russian guys at http://stratonautica.ru/. They were making a project __exactly__ like this, with LoRa (with modifications?) but for location tracking.
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/.
Also, am Russian and https://lizaalert.org volunteer. Would be happy to see you on the bands if you've got a call, come over to TG 250661 GMT+3, daytime. 73s.
This is a great idea, especially for tracking kids. I'd love to leave one of these in my kids backpack and know where they were without depending on a cellular-device/service-plan/charging/etc
It's not a new idea, but it's really a cool project, it just seems difficult to democratize.
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.
This is awesome! It looks like it could do several things for which I wanted to have a device.
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)
current battery life is about 3 days and will soon be eight days. See our power calculations spreadsheet, but with with scheduled broadcast intervals (because we have GPS time) it is fairly feasible to reach 30 days between charging.
I'm also a (retired, but formerly very active) paraglider and that was a big motivator for me.
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.
Right, and accuracy of ~9m makes sense for this application. The smaller supported ESP32's, however, don't have onboard GPS. Does it use RSSI or need to be paired with 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.
This is very similar to FLARM devices (https://en.wikipedia.org/wiki/FLARM) for ultralights, gliders, etc. This is already broadly deployed (at least in Europe).
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.
FLARM is very bad example especialy for DIY community. They have proprietary chips, firmware and are running non opensourced protocol. Also they are actively trying to prevent reverse engineering with cryptography and killing old/diy devices with protocol timebombs...
Make the mesh affordable, keep making the drivers and interfaces clean and reasonably easy to maintain.
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.
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?
I dabble in both backcountry and skiing and wireless devices, but I'm not an expert on either.
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.
Would be great to have LoraWan redundancy, say with the things network, if in range.
From my experience, 8 days battery life with TTGO-beam is unrealistic, unless sleeping for most of the time, or with some hardware modifications.
Great project, I will test it out!
Go have a look at https://www.project-owl.com/ when you have a moment. They’re tackling similar problems but from a different angle. Doesn’t mean there isn’t room for both!
Sounds promising, but as someone who tramps a decent amount, I love as much range as possible without needing a sat phone.
I've got 2 gotenna, and they're not so great, very short range. Maybe 1km in hilly areas.
How will you make sure your customers will be in compliance when operating the device? GoTenna used to have a nice photo gallery of people breaking the law, i.e. using their earlier MURS-band mesh devices abroad.
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)"
I'm just curious why my comment regarding patent was deleted ? Yes we developed a device that implements this same idea of sharing GPS data over mesh (868 ISM) network and patented it in 2014. The patent is still valid and supported. If someone is interested in further development of this idea, please contact me, we would be happy to sell this patent along with schematics and source codes for fair price.
Raising awareness that something is patented on a public forum isn't considered polite.
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.
Your post said nothing about the patent itself, and simply stated that this open source project should be paying you. It's not exactly the best approach on a site like this.
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.
Don't get me wrong, I'm not a patent troll, neither I want to sue anyone - that is against my attutude (I consider myself an old time hacker rooting from late 80s :)). I'm just a co-developer and co-holder of the patent for a device that does, among other things, exactly what topic starter described. We began developing it back in 2011 and proceeded for several years, we had been spending our free time and "pocket" money on it. In case you are interested it took us to route and assemble 22 versions of PCB prototype of the main board and 5 prototypes of a radio. We even exhibited it at one of the electronics show in Moscow. As we failed to find sufficient investment to push it to the market, we decided to freeze the project in 2015. In my initial comment that was silently and shamefully deleted, I proposed to aquire our patent, that's what might have any value today, as schematics and hardware are all outdated. As mentioned above, discussing patent details on public is not any good idea, that is why I simply pointed that I can be contacted on these matters.
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 ?
You sound like a reasonable person and I have every reason to believe you’re acting in good faith. Your website suggests a patent pending in Russia. I am completely unfamiliar with Russian IP law which might be the source of my misunderstanding. Having said that, is there a reason you won’t provide the specific patent(s) in question? I would presume they are a matter of public record when they were issued.
