[DisasterRadio] decoupling protocol, software, working hardware, outside-ok hardware

[Kriss]

Just wanted to thank the participants for such detailed and well thought
out discussion on this topic.

Just blown away by the complexity of all the knowledge you all have and at
the same time explaining it so Non-Tech savvy people can make sense of it.

Appreciate learning from all the Expertise expressed here.

I've been in the Emergency Medical Services for over 35 years and in All
Major disasters I've studied and been a part of in our Western regions in
the US, both Great and Small, the final debrief of how to have "made them
run more seamlessly" has been Communications ... especially between
agencies them selves and between communities in the mess.

I was on Duty with the US Coast Guard on 911 and was involved with many
planning groups in all that played out after the event... Promises were
made to bring out major changes in our Inter-agency Communications and here
we are 20 years later with many gaps unmanaged.

Thank you for pushing for solutions and brainstorming all of this.

Keep Aiming to be Semper Paratus.


Kriss

On Fri, Sep 24, 2021, 17:33 Mitra Ardron <mitra at mitra.biz> wrote:

> Greg
>
> As I look at our requirements for this, - semi rural Australia - I'm
> seeing some differences, but more similarities with what you say.
>
> As an example of how we do this in practice ...... our area gets flooded a
> couple of times a year, so we get to practice regularly, we are also prone
> to bushfires, nearby areas have been hit though not us, but it means we go
> into hyper-alert when the risk is up.   We use a WhatsApp group which is
> ONLY used during disasters. That is important, as it means 85 of the
> roughly 120 people in the neighbourhood are on the group. Its used for
> messages such as "At the third creek crossing, water is currently 60cm
> deep, just saw a Honda CRV get through, dont try it anything smaller, and
> remember to keep to the right as you go around the bend" or "We smell smoke
> - seems to be coming from NE - maybe the nature reserve - anyone got info"
>
> My answers below are based on other projects, if there is anyone with
> experience with the Disaster Radios please correct me.
>
> When I talk to people in rural areas using LoRa the range they are seeing
> is I believe around 1kM - low bandwidth but higher distance. The max range
> of LoRa which I think is 10km is (I'm told) never seen in practice.  BUT
> the people I'm talking to are using LoRa IoT->base not peer to peer.
> Distances are going to be shorter peer to peer, BUT its also possible to
> roof mount the node.
>
> For us, its going to have to be WiFi from phone (iPhone or Android) to a
> node, just because of range - BLE won't cut it without a unit on every
> house. We would want people un-prepared to connect to the houses that are
> either pre-prepared, OR easy to setup in an emergency (climb on roof or up
> tree and zip-tie a node).
>
> I don't see battery power as the issue for the nodes, LoRa is low power -
> so I'm betting a small solar panel or a larger Lithium battery is going to
> be fine.
>
> I think for scalability - even to the 10's or small 100s of nodes it would
> be nice to get pre-made boxes, but at a minimum its got to be off the shelf
> hardware (like the ESP/LoRa boards) with minimal soldering (add battery,
> screw into box, flash board). If there is enough demand, maybe someone can
> create a side-gig supplying them.
>
> In terms of Dev, I think the most important thing is to have something
> that sort-of works, good enough to be useful, at that point its going to be
> easier to get people interested enough to improve any incremental part of
> it. At the moment the curve to get involved seems pretty high, without
> immediately usable results.
>
> You mentioned small data packets and no images - which makes sense BUT I
> think (Greg T) you've missed one possibility. That is to hold a simple app
> at each node. Then a captive WiFi portal can deliver that to an un-prepped
> phone (Android or iPhone). An ESP32 should be able to do that easily. If
> this is built as a single-page app (everything locally done in Javascript,
> not by page loads), and if the comms between the node and the phone, and
> between nodes are just data (no more images or HTML) then it wouldn't
> overload even a small ESP32. I haven't dug into the code to see how the
> existing app is built, I'd probably have designed it using simple JSON
> queries for ease of development. I read somewhere that SSB is being used,
> but I'm not sure whether there are JS libraries that would make that easy
> to integrate to a HTML/JS web app.
>
> I dont' know how well developed the node to node comms are, SSB would seem
> like a good idea for that (strong handling of intermittent connections
> especially) though the pool of people who understand it is relatively
> small, so I'd hope its far enough along that it could just be tweaked as
> needed - does anyone know ?
>
> Voice would be nice - but I can't see it happening over LoRa - and I
> haven't seen any other solution that does voice well, is affordable, and
> doesn't require Ham licenses. I think for our neighbourhood we'll use
> walkie talkies among pre-prepped people but text is hugely valuable.
>
> Above all, we need solutions that do not require geeks for deployment,
> many of the ideas I've heard - making home made antennas, soldering up
> boards, putting together repeaters, etc, just aren't going to be available
> to most people.
>
> All just opinions - welcome correction !
>
> - Mitra
> On 24/9/21 10:58 pm, Greg Troxel wrote:
>
>
> As a lurker, it seems many are interested but we don't really have
> critical mass.  I see multiple parts as being necessary to eventual
> success at the "world domination" level, and my inclination from
> previous software/project experience is to see if they can be separated,
> to let progress happen somewhat separately.
>
> For background, I've worked on several ad hoc radio projects (not open
> source), done a bit of Amateur Radio packet, and done protocol design
> and prototype implementation for networking research projects.  Often
> I've organized these projects into phases to allow incremental funding,
> with more mature hardware and larger scale at the end.
>
> # big picture
>
> It seems obvious to me that this entire project is text and small
> amounts of data only, and no images and no powerpoint files.  And, it's
> not about providing IP service.
>
> I'm unclear on if there is any aspect of connecting to internet or not.
> It might be good to have a description of which problem is being solved,
> separately from the description of approach.   I mostly get it, but
> there's a more detailed view of concept of operations about who does
> what prep and who wants to talk to who and why.
>
> One issue in my area is how to provide 911 service (call to
> police/fire/ambulance) during an extended power failure.  Very few
> people have copper pair landlines, almost all have a cellphone, most of
> them smartphones, and most people have either VZ FiOS (fiber to the
> home) or Comcast (cable).  Comcast fails after a few hours due to
> battery-powered equipment on poles, and FiOS works if you can power your
> ONT (and router, and wifi).  So it would still depend on individuals
> prepping but a bunch of nodes and people with cell phone battery banks
> and solar chargers would be at least plausible.  This would lead to
> wanting some sort of 911 relay with an authorized chat destination.
>
> The 911 replacement concept could also benefit from some nodes being
> internet connected when that works and routing to a computer at the PSAP
> (911 call taking location) when that is doable, and staying on lora when
> it is not.  But is very likely be way too much to bit off right now.
>
> I am unclear on if chat is 1:1 or group, and how addressing and naming
> works.  It would seem there are nodes, and then there are users, with
> perhaps different namespaces.  I'm also unclear on encryption.
>
> # protocol
>
> It looks like this is defined separately from the code.  Unusual but
> yay!  There have been recent suggestions about allowing some authorized
> organizer to control things, and that probably requires configuring
> public keys.  Baking control into software (vs protocol) feels like the
> wrong approach architecturally.
>
> Scaling is obviously a problem, and it's not clear to me what the story
> is.  One idea is to keep the number of nodes manageable (100?) via some
> network id, and another is to have some limited hop count for messages.
> I will try to read the protocol spec rather than super-skimming.
>
> Maybe 15 years ago "Disruption Tolerant Networks" were popular, which is
> store and forward at the network layer.  Of course it doesn't really
> matter if this is network or application since that's just a bounday of
> convenience for thinking.  It's not clear to me how things are and what
> the long-term view is.
>
> Perhaps there should be time sync, perhaps not.  Perhaps only very
> rough.
>
> # prototype hardware instructions
>
> Maybe I'm off, but if one gives up power resilience and weather sealing,
> a protoboard with an ESP32 and a lora module should be enough.  I guess
> that's the TTGO thing, but ESP32 and lora are easy to get many places.
>
> Also, for people in the ham radio world that already have backup power,
> putting one of these things high in the house  and hooking up to 12V
> solar-charged batteries is not an unreasonable thing to do.
>
> # code
>
> More people could hack on code with the above prototype hardware than
> probably do now.  But maybe I'm confused.
>
> I'm unclear on whether the android app for BLE is only useful if one
> decides to run BLE and not WiFi, or if it's also an alternative backend
> on wifi.   Perhaps it's just the webapp pre-staged rather than served.
> Or maybe the webapp comes over BLE?
>
> Regarding the android app: f-droid has
>   Version 1.7 (17) suggested Added on 2020-03-08
> and if that's old, would be good to figure out how to update.  If it's
> not old, it might be good to release a micro every 6 months to signal
> liveness.
>
> I know iphones don't allow Free Software, so I wonder if the only path
> is wifi/web.  And if so, how viable (in the US) the concept of no wifi
> and using BLE is.  Around me, something that only works on android is
> just not going to fly outside of the extreme cypherpunk nerd crowd.  (I
> realize other countries have different prevalances.)
>
> Network routing visualization seems maybe missing and would help a lot
> in understanding an actual network.
>
> # geoprivacy
>
> I realize there is a map notion, which is fine, but I think it's
> important to keep the main path of the network not needing to publish
> coordinates.  I find not wanting to publish location to be correlated
> with a willingness to spend time prepping.  Maybe that's ok now.
>
> # emulator
>
> It would be nice if it were possible to run the code with an emulated
> radio that has a link that acts like lora but is tunneled over the
> internet to somebody else.   Then the people working on disaster.radio
> could talk to each other.   I am not sure how hard this would be and if
> it's worth it though.
>
> # power, range and scaling data
>
> It's really unclear to me how much power gets used doing what, and if
> nodes can somehow do fair-share of routing vs high nodes using all their
> batteries.  But maybe high nodes should just have more power/battery and
> then it's all good.  It would be nice to have some measurements.
>
> It would be nice to have some published anecdata about range.  In the US
> we're talking 915 I think, for Part 15 compliance, but it would be nice
> to understand how being able to close a 5W UHF FM link relates to lora
> links.  (Yes, I know I should just buy a few and try some things; it's
> on my todo list.)
>
> It would be nice to have reports of network sizes and how they work.  In
> various research projects, it was often a big deal to get the network
> size up, and I've done demos with 20 wireless nodes, 50 wireless nodes,
> and 100 wired nodes.  Has anyone built a diaster.radio network more than
> 10?  25? 50? 100?
>
> # deployable hardware design
>
> Next is nerd-replicable deployable hardware, and the more it can be buy
> commodity parts (even if it's plastic food containers that can be hung
> in a tree with rope), the better.  The key point is a set of recipes.
>
> Later comes purchasable hardware.  I suspect that an open hardware
> design and mature software will lead someone to build and sell nodes, so
> to me this is the last thing to worry about.
>
>
>
>
> I hope at least some of this ranting is helpful.
>
> Greg
>
>
> _______________________________________________
> DisasterRadio mailing listDisasterRadio at lists.sudoroom.orghttps://sudoroom.org/lists/listinfo/disasterradio
>
> --
> Mitra Ardron - mitra at mitra.biz www.mitra.biz
> +61-491-082-515 mobile; +1-510-423-1767 whatsapp
>
> _______________________________________________
> DisasterRadio mailing list
> DisasterRadio at lists.sudoroom.org
> https://sudoroom.org/lists/listinfo/disasterradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sudoroom.org/pipermail/disasterradio/attachments/20210925/58970916/attachment-0001.html>