Automatic version for Vmail forwarding
Hello everyone, I, like perhaps many others, have a very full Vmail inbox. Which is a good thing, as it is clear that VarAC has become quite popular and well used.
I also retrieve a lot of Vmails because I can often only reply to some OMs in the USA / South America via relay.
This works very well. But there could be improvements here.
If you are waiting for a Vmail, an automatic attempt could be made to deliver the mail to the recipient instead of having to collect it manually from all over the world :-) For me personally, this is already turning into “work”,hi.
A concept could look like this:
You write a new Vmail, either deliver it directly manually or wait for the beacon from the other station. When it has been heard with sufficient signal (i.e. no delivery at -15db or so), a connection will be established.
Both stations must have Auto QSY set to on.
If the delivery of the Vmail is not successful, try again in 2 or 3 hours, provided the beacon has been heard. The interval should definitely not be too short (1 hour or less).
If the remote station cannot be reached directly, i.e. “never”, you could enter the relay directly in an option field for the recipient.
Example: I often have contact with KL7QR in Arizona, sometimes it works directly but often not. We now know that we can use KA3NAM and VO1CBL as very reliable relays.
At this point you could enter the relay station as an option in the Vmail.
Proceed as above. If KA3NAM is heard, then deliver the Vmail via KA3NAM. KA3NAM logically checks again whether it hears the beacon from KL7QR and then the procedure as above.
I think this would be a great idea and would greatly reduce the manual effort, especially with Vmail. It would also certainly be an important and useful thing for EMCOM! In this situation, you´ll wont´t check every some minutes if a Vmail is waiting. Just deliver them as described above.
73 Andre / DL4QB
This is a WONDERFUL idea! Please do implement this, even in stages. 1. You could build a table of relays that are well connected to different regions, and a table with the distance in hops to each station. Let's call them "Supernodes" or hubs in the mesh. Especially useful if they can reach multiple continents, or if they are in between you and other continents. You could have two levels of hubs: A. Regional hubs - good connectivity to many stations in a region B. Inter-regional hubs - good connectivity to many stations across multiple regions.
For example, I could connect QRP to any station regional hub that is fast and available to me. Then it will relay to an inter-regional hub to get it closer to the destination station. Etc. 2. I am currently doing this manually, using PSK reporter. Check which regions each station reaches well (how many stations they reach there and the SNR). 3. Then each station shall relay the parked vmail to a station that has connectivity to the target region.
Automatic relay shall work for at least two hops, three would be even better, to be effective.
You could make a setting for Max Automatic Relay Hops.
Ideally, path history and loop detection. It should NOT for example be sent repeatedly back and forth bouncing between the same two or three stations! In that case, it shall be held for manual intervention, and the operator alerted to handle it.
Manual relay shall always be allowed, regardless of loop detection, max hops, etc.
I have been thinking about it from day one of rela-notifications. but there is one flaw in this concept - if both sides are not there, how the QSY frequency will be determined to make sure no QRM is being made to other stations on other slots ?
Good ideas Andre,
73 de Demetre SV1UY