punkgeek

Meshtastic is encrypted.

Encrypted digital transmission over Lora is legal in the US.

No ham license required. Much better range per watt. Slower. More modern protocol.

Hi! I'm one of the devs. If you have questions you might like our (friendly/helpful) forum: meshtastic.discourse.group.

we talked about it in the early but there were some fundamental technological limitations that made it seem like not a good fit. At this point I think meshtastic is more feature complete and has lots of areas not serviced by disaster radio (ie. python API, ports to many different types of lora boards, extremely good battery life).

I think the only feature we miss wrt disaster radio is dual radio support and full DSR.

yep - I'm one of the meshtastic devs and that was our thought as well.

* use off the shelf hardware, so user can just buy a finished device from China * make it cheap * Make something useful for people in general (without disaster) - then they will have it when the disaster happens.

ah! thanks!

sure! either chat on our gitter chat (link at www.meshtastic.org) or send me an email at kevinh@geeksville.com.

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.

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)

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.

The current alpha works pretty well. (I'm sort of retired now, but my old job included writing software for these sorts of radios).

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

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)

yep - what myself248 said. and yes, if you have questions just ask on the gitter channel and we'll all work together to help.

I just want to say: you seem like an awesome person. Keep being awesome!

FRS radios and SPOT are also awesome.

really - on www.meshtastic.org?

It is just a standard github pages page. I think you might want to check your web browser config.

thanks. that was our motivation also.

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. ;-)

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!

SUPER COOL. It sounds like you are using similar SFs to us. Rock on!

you can buy it now if you wanna guy a radio from aliexpress (not from us). see our website for info.

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)"

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 ;-)

cool! please ping us on the devchat when you try it out.

tell me about it. I have a box of 5 I ordered before CNY. Still sitting in china.

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...)

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...

yes, this is targeted at hikers etc... so typical max mesh size of about 20 and I bet it would dying by the time a channel had 100 people.