Hello, everyone. next case. I would like to reply later to a VMail that I received on 7105 kHz in my absence.
My waiting OM is also absent in the meantime. Its trx and VARAC but standby on 7105.
Because my response/transmission event takes longer due to the file size, I would send its TRX from my VARAC station with a slot up in QSY. He can't accept it manually. After the end of the transmission and disconnect, his Trx should then automatically switch back to the QRG 7105 call.
Does such a function already exist, or would something like this make sense and be feasible.
73 Juergen DK4BU
Released in V7.
Thank you irad for incorporating my suggestion for the required QSY. will test this function that days. vy 73, Juergen DK4BU
I've observed the following situation today. Station A wanted to retrieve a VMail from station B. The VMail was so long that the CF timeout kept kicking in. The VMail was never successfully retrieved, but the whole operation blocked the CF for a good 15 minutes.
How is A ever supposed to get his VMail from B, without some kind of QSY? How is this supposed to be communicated?
Maybe the answer here is a standard Away frequency that if you are away you stay on this frequency. All a remote station will need to do, is listen on the away frequency and retrieve their messages when that station beacons, this will leave the standard call frequency for keyboard CQ calls and then QSY to a vacant slot as per normal operation (Just a thought)
De Paul VK2EX
The obsession with force QSY in VarAC is really a bit much. If in VarAC, why not all the bands, all the modes? Someone is using a frequency, well ... let's push a button and remote force their radio to QSY them to be someone else's problem. Pfft Those wanting to mind other's busy has gotten out of hand. For everyone you want to inconvenience, someone else will want to change your behavior, too. Be careful what you wish for.
We force a TX all the time with pull requests!! In fact we depend on forced TXing for the bast majority of exchanging. If we allow for a temp qsy before the forced pull everything improves.
I´ve seen the same behaviour, and would appreciate the suggested feature quite a lot. I can see the hesitation to implement automated QSY, but I think it can be made work by carefully limiting the allowed QSY frequencies, and automatically checking for any activity on the new frequency before allowing transmission. Even limiting the feature to the 3kHz of total bandwidth around the CF would already be a major benefit, while at the same time being considerate to other spectrum users.
If we connect to a call because we saw a beacon from an away user, and if we have vmail waiting, the vmail fires off on the CF. If we leave a msg for an away operator, then that msg also fires off on the CF. For the same connection, we could have both events: an email and a msg. This really ties up the CF.
The new requested option allows a connector to auto qsy the absent receiver to another slot, then send the vmail and/or the msg. The connector can only switch the away party if the away party has checked an option allowing the behavior.
Wait, so you are saying someone else can change your TX freq to another slot? Sure, why not? the connector is going there, so they are responsible for validating the lack of a qso on the target slot. If they pull another party there, it matters little cause the connector was going there anyway.
And yes, put a time limit on these types of semi automated slot qsys. And after the exchange, auto back to the CF.
This would get all that auto traffic off the CF for the users who grant permission for temporary slot changes.
It sounds good to me and several others...
I did not understand completely the entire cycle you are suggesting, but I have a red line I am STILL not willing to cross: Having one side forcing a QSY on the other side without an approval. Especially for TX. This open a Pandora box where I can drive you out of the frequency or make your station cause QRM to other QSOs while you are absent.