The need: Emcom Users who employ AREDN Mesh Networks to support served agencies need to communicate with shelters, etc. that are outside the range of the Mesh. What is needed is a server on the mesh that allows VarAC traffic between mesh nodes as well as via conventional RF to stations outside the mesh. Such a server would be able to gain awareness of stations existing only on the mesh (just running VarAC over TCP/IP) and others coming into the mesh via VaraFM so as to route traffic to RF only as needed, similar to APRS servers. This would both reduce VaraFM channel congestion during emergencies and would reduce the VHF/UHF radio equipment and setup time needed during deployments.

In the past there was some discussion about an "EMCOMM Mode" for VaraFM, as well the ability to have VarAC beacon continually for the duration of the emergency (or training event) rather than be limited to 24hrs. Is continuous beaconing while using VaraFM still in the works?

In Western Colorado our EMCOMM group is experimenting heavily with VarAC and VaraFM. Before I request any of these features I'm curious if other EMCOMM users would find them useful: (Perhaps activated by VarAC/VaraFM going into 'EMCOMM Mode'): 1). Persistent beaconing. (Perhaps limited to VaraFM users?) In an emergency lasting more than 24 hours, it's likely that some users will accidentally allow their beacons to lapse. If those users don't beacon, they won't receive notification of waiting Vmails, correct? If our EOC fails to beacon for a few hours, it won't receive notification of potentially a number of important messages. I'm thinking in terms of keeping a VaraFM channel open as much as possible, like when an EOC master packet station polls remote stations for traffic in a round-robin fashion as opposed to those stations sending traffic to the EOC on their own. Perhaps VarAC's traffic handling is already much more robust? 2) Timed broadcasts (like APRS Objects, but without position information). Examples: 'K0DZ-10 Winlink Gateway. VaraFM 145.090' 'W0RRZ VaraFM Digi on Blackridge' 'Please conduct non-emergency VarAC traffic on 145.050' Etc. Useful broadcasts could be sent every hour or so during an emergency without the need for EOC folks having to remember to rebroadcast. Being able to advertise mountaintop Digis would also be nice for new users. Not everyone who sees a beacon like 'K0DZ via W0RRZ' realizes that W0RRZ is a Digi they can utilize because when they ping it from VarAC instead of their VaraFM modem it doesn't respond. 3) Last Heard CQs and Beacons in local time, or, better, elapsed time. I've seen where folks have requested this is the past only to be advised essentially 'UTC is there. Do the math'. This is fine for casual use, but not desirable in an emergency where EOC folks may be working through the night for perhaps several days. Tired humans make mistakes. Also, not everyone is familiar with UTC, especially it seems with primarily VHF/UHF users. Would other find these features useful, or have better suggestions?

I and another ham have been using VarAC V6.3.3 with VaraFM v4.2.7 to chat. Whenever my VarAC beaconed, he noticed that his VaraFM modem indicated that my callsign was K0DZ-9. This happened both directly and via digipeating. I had him beacon to me and my VaraFM showed his callsign with -9 appended. CQs both ways show the callsign without -9. Under the VarAC "My information" tab, neither of us are using a "Special Suffix". K0DZ-9 is my APRS callsign, so naturally I spent a few anxious hours checking my APRS gear before realizing that his beaconed callsign also had -9 appended. The issue seems to be generated in either VarAC or VaraFM.