Re: [DisasterRadio] hello

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(a)kinetic-compute.com DMR: 3102272 425-395-4554 Allstar: 531920 On 9/22/21 4:48 PM, Greg Troxel wrote: