[DisasterRadio] hello

Gerard Hickey hickey at kinetic-compute.com
Thu Sep 23 14:49:35 PDT 2021


Sorry, I just realized that the message I sent out earlier did not go to 
the list (Sorry Greg for the duplicate on your end). Here it is again to 
the list.

------------------

OK, I will speak up here. I definitely fall into this camp here. I too 
wish there was more activity (and for quite a while after joining the 
list I thought it had become a dead project) and I wish I had more time 
work with and contribute to Disaster Radio. I think it has a good view 
of what it is trying to achieve and could be a really useful project 
that a lot of people could benefit from.

[Now I am going to combine a response to several emails that have been 
going through the list instead of creating response for each one]

I have looked at a couple of other projects--Project Owl and a few I 
don't remember right now--and most are targeting the same basic 
idea/plan. A couple are commercial systems and those get discounted 
immediately because the use case I have is for the local ARES/RACES 
teams which have very little money and are 100% volunteer based. The 
remaining ones, like Project Owl, seem to want to put a lot of hardware 
behind all the nodes to make the system work. To me that is unrealistic 
in a emergency situation/disaster to maintain a number of servers that 
may or may not have power, probably will not have cooling any more and 
oh, by the way are there people around to make sure that the system is 
functioning correctly. A solution like that might be find for a large 
city that funds an emergency management division properly but most do not.

When I looked at Disaster Radio, I like what I saw in the flashy video 
and was slightly disappointed with what I saw in the firmware image of 
the time (full disclosure, I have not loaded any newer firmware so 
things may be vastly improved). Mostly it seemed like Disaster Radio was 
behind on the app development especially compared to the promotional 
video. Yet I understood that the video was the vision vs. what work had 
been done.

I did want to get involved (and still do), but the basic problem is that 
I just have too many projects and can not spread myself any thinner.

There are a few things that I see (from my perspective of doing EMCOMM 
work and living in a city that had a lot of emergency management 
support) that Disaster Radio needed to develop to be a more viable 
solution. The chat app (about the only real app in the firmware I played 
with) was pretty minimal, but it worked reasonably well.

One of the things that I identified pretty quickly from an emergency 
management perspective is an app for community reporting of incidents 
and needs. These are geographically specific so the needs and responses 
would need to be customized for an installation. In other words, the 
types of incidents and the types of resources are different from what I 
need here in the Pacific Northwest vs. say Oklahoma. The idea being is 
that when there is an event, someone in the community could report that 
they need food and water at a location or that there is a tree down that 
needs to be cleared. These reports need to be structured so that they 
can be correlated and processed efficiently at incident command. Free 
form reporting does not work as it takes too much time and energy to 
decode the request and work it through the system.

There also needs to be a message board of sorts where the controlling 
entity can post notices related to the incident. In my use case it would 
be where the city  could post where the open shelters are located or 
maybe where one could find specific items like food, water or emergency 
care. This can not be posted to by everyone because otherwise it becomes 
a lot of noise and the important messages are lost.

Another aspect I see is having some light weight management of the 
nodes. I would like the network to be up all the time but not be 
available to the general public. If the network is available all the 
time then it becomes a medium to be abused and unreliable. I want the 
ability for the controlling entity to be able to enable and disable 
specific nodes (say to allow testing and drills to be performed) and 
then when an event occurs a single command could be sent to enable all 
nodes to make them available to the public at large. Then disabled again 
once the event is over.

On the hardware side there needs to be a little bit of revision to the 
circuit for cold weather climates. Using a lithium based battery is fine 
(and mostly desirable) but this poses a problem for an area that 
occasional and routinely reaches freezing temperatures. Pulling energy 
from the battery in freezing temperatures is fine (other than degraded 
performance) but attempting to charge the battery in freezing 
temperatures renders the battery useless and it will never accept a 
charge afterwards. So there needs to be some control as to when to apply 
the charging current to the battery depending upon the environment 
temperature.

OK, there is a lot here and I am sure that some of this will need to be 
digested. I hope that someday I will have more time to where I can spend 
time working on Disaster Radio and help improve what others have 
produced already.

-- 
Gerard Hickey / WTØF           IRLP:3067/Echolink:529661
hickey at kinetic-compute.com     DMR: 3102272
425-395-4554                   Allstar: 531920

On 9/22/21 4:48 PM, Greg Troxel wrote:
> eM Grzegorz <emgrzegorz at interia.pl> writes:
>
>> Hi,active list?Grzegorz
> Sort of.  When people ask, someone answers.  But not much seems to be
> happening.  I do have the impression that those on the list wish there'd
> be more activity, and that most of them sort of hope to contribute.  I
> of course do not speak for the coalition.
>
> Perhaps you can tell us why you're interested and what you'd like to see
> as highest priority.
>
>
> _______________________________________________
> 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/20210923/e879875c/attachment-0001.html>


More information about the DisasterRadio mailing list