APRS 'Voice Alert'
APRS 'Voice Alert'
BTW, When I read this I had to test if I could reproduce the error which I could when I changed to German.
But then I noticed that the CTCSS settings are greyed out when you activate APRS.
Can APRS be combined with CTCSS ?, there is some "obscure" APRS function called "Voice Alert" that I have read about.
http://www.aprs.org/VoiceAlert3.html
PS, On my old 20230818 versions I could enter RX CTCSS 136.5 on the APRS designated channel, but on the new version 20230904 CTCSS is N/A
You can of course have another channel with the APRS frequency and the Voice Alert CTCSS in your scan to receive "Voice Alerts".
But I think the Idea is that you also send your APRS packets with the "Voice Alert" CTCSS to signal that you respond to Voice Alerts.
But then I noticed that the CTCSS settings are greyed out when you activate APRS.
Can APRS be combined with CTCSS ?, there is some "obscure" APRS function called "Voice Alert" that I have read about.
http://www.aprs.org/VoiceAlert3.html
PS, On my old 20230818 versions I could enter RX CTCSS 136.5 on the APRS designated channel, but on the new version 20230904 CTCSS is N/A
You can of course have another channel with the APRS frequency and the Voice Alert CTCSS in your scan to receive "Voice Alerts".
But I think the Idea is that you also send your APRS packets with the "Voice Alert" CTCSS to signal that you respond to Voice Alerts.
Last edited by SA0BUX on Tue Sep 05, 2023 6:09 am, edited 1 time in total.
APRS 'Voice Alert'
I don't think this affects the APRS operation of the firmware.SA0BUX wrote: ↑Tue Sep 05, 2023 5:45 amBTW, When I read this I had to test if I could reproduce the error which I could when I changed to German.
But then I noticed that the CTCSS settings are greyed out when you activate APRS.
Can APRS be combined with CTCSS ?, there is some "obscure" APRS function called "Voice Alert" that I have read about.
http://www.aprs.org/VoiceAlert3.html
APRS channels in the firmware only send APRS, you can't send voice on a channel defined with an APRS configuration
APRS data is not sent with CTCSS and if the operator sets a Tx CTCSS on an APRS channel, the firmware ignores the Tx CTCSS and does not transmit CTCSS
If you want to transmit voice onto an APRS channel, you can make another channel and set the appropriate CTCSS
Also, people would need to check whether their local APRS network allows "Voice Alert", e.g. I have been listening to my local APRS frequency for several days when testing APRS Tx and I never heard any voice traffic, so I doubt this usage is normal.
Edit.
Actually. This is about APRS Rx which we don't support, but at the moment if the radio receives a signal when the channel has an APRS configuation the audio can still be heard
So possibly the Tx CTCSS setting should be disabled in the CPS but not the Rx CTCSS setting, except that setting the value to "None" should probably not allow Rx audio, and only if the Rx CTCSS is set, should the speaker be allow to be enabled if there is a signal and the tone is correct.
I'll change the CPS so it only disabled Tx CTCSS because AFIK APRS is not transmitted with CTCSS
Also. FYI. We allow the channel bandwidth to be set for an APRS channel, because there does not seem to be universal agreement about the bandwidth for an APRS channel.
e.g Yaesu seem to use 25kHz for APRS but some other radios use 12.5kHz bandwidth
APRS 'Voice Alert'
Maybe one of the APRS gurus that replied earlier about some other APRS function knows more about this.
Some Kenwood and Yaesu radios seems to have dedicated Voice Alert support and it seems that you send APRS with CTCSS to ping the "Voice Alert radar"
Some Kenwood and Yaesu radios seems to have dedicated Voice Alert support and it seems that you send APRS with CTCSS to ping the "Voice Alert radar"
APRS 'Voice Alert'
OK.
I think at the moment it is safer not to transmit any CTCSS with the APRS, becuase this is yet one more complication to APRS which people already find quite complicated
Its possible that the Voice Alert CTCSS tone could be defined as part of the APRS configuatation rather than part of the channel data.
Also. I found another problem with using Rx CTCSS on the APRS channel, because currently the APRS functionality does not handle collision detection, i.e the APRS Tx function transmits even if there there is another transmission on the same frequency.
So first APRS collision detection and handling would need to be added to the manual APRS Tx funtionality, and normally it seems APRS transmissions do not carry CTCSS
So the Rx needs to detect if there is any signal for the collision detection, but possibly only enable the speaker if the Rx CTCSS value is set and matches the received CTCSS
i.e just setting CTCSS to None, should probably not allow the Rx audio, becuase normally this needs to be muted if there is automatic collision detection
I think at the moment it is safer not to transmit any CTCSS with the APRS, becuase this is yet one more complication to APRS which people already find quite complicated
Its possible that the Voice Alert CTCSS tone could be defined as part of the APRS configuatation rather than part of the channel data.
Also. I found another problem with using Rx CTCSS on the APRS channel, because currently the APRS functionality does not handle collision detection, i.e the APRS Tx function transmits even if there there is another transmission on the same frequency.
So first APRS collision detection and handling would need to be added to the manual APRS Tx funtionality, and normally it seems APRS transmissions do not carry CTCSS
So the Rx needs to detect if there is any signal for the collision detection, but possibly only enable the speaker if the Rx CTCSS value is set and matches the received CTCSS
i.e just setting CTCSS to None, should probably not allow the Rx audio, becuase normally this needs to be muted if there is automatic collision detection
Re: CPS R2023.09.04.01 Error
Yea, it's probably complicated , just noticed the difference regarding APRS&CTCSS as I have several radios with OpenGD77 with different versions.
I'm up to three RT3S (two with GPS) and one each of RT-84 , DM-1701, MD-9600 (GPS) now.
So it's a hard task to keep them updated , But I like to test all the new features.
I'm up to three RT3S (two with GPS) and one each of RT-84 , DM-1701, MD-9600 (GPS) now.
So it's a hard task to keep them updated , But I like to test all the new features.
Re: CPS R2023.09.04.01 Error
I have every radio type, except DM1801A, RT-84 and 2 of the MD9600 variantsSA0BUX wrote: ↑Tue Sep 05, 2023 6:42 amYea, it's probably complicated , just noticed the difference regarding APRS&CTCSS as I have several radios with OpenGD77 with different versions.
I'm up to three RT3S (two with GPS) and one each of RT-84 , DM-1701, MD-9600 (GPS) now.
So it's a hard task to keep them updated , But I like to test all the new features.
i.e
I have multiple GD77 (5 I think), GD77S, RD5R, DM1801, DM1701, RT3S, MD-9600 V2 and 2 x MD-9600 V4
Its basically impossible for me to test all functionality on all radios all of the time. I rely on various Beta testers, but everyone also has their normal life to lead.
Also DJ0HF tests anything related to the blind users, this includes CPS and firmware. He has multiple radios
All functions in the CPS and the firmware must be accessible to blind users, so adding even a small feature can cause a huge amount of work
The firmware is translated into 19 languages, and the CPS into 13 languages - excluding English
So any change has also to be made in all these files
PS. Currenly the distance display is not accesible to blind users and this need to be fixed.
PPS.
I know it takes a while for the correct translations to be updated into the relevant files, but its a massive amount of work to handle all of this and takes many hours every week by me and Daniel and also many hours of testing by other people
Re: APRS 'Voice Alert'
APRS Voice Alert is fairly simple in "ussage", certainly can not speak for the coding part of it. But when I'm in the vehicle I have VA set up on my Kenwood D710G. If someone else has it set up, and they're within simplex range I'll hear their APRS packets. I could then look at their packet and see if their packet contains a frequency and could call them on that frequency. You can also key up voice on the APR frequency and quickly call the other user and tell them you're listening on another frequency. A quick voice call is fine, obviously one should not try to have a conversation on the APRS frequency. Different areas may have different rules; in the US the APRS frequency is not defined by our FCC; it's only a convention.
Re: APRS 'Voice Alert'
"APRS Voice Alert" basically deals with the "APRS mute" aspect of the mode. Many people who use APRS set our radios to audibly mute packets being sent and received (because it might be too noisy hearing packets all day). APRS pacekts are sent and received without any tone. But some radios support a feature whereby the radio will open audio from the APRS channel if tone 100 Hz is heard.
As KT4LH mentioned, it lets users call each other on voice if determined to be within simplex range (and then switch to another simplex frequency to continue the QSO).
From F4FXL:
https://www.f4fxl.org/what-is-aprs-voice-alert/
As KT4LH mentioned, it lets users call each other on voice if determined to be within simplex range (and then switch to another simplex frequency to continue the QSO).
From F4FXL:
https://www.f4fxl.org/what-is-aprs-voice-alert/
Once an APRS frame with a matching tone is received you’ll hear the sound of the APRS data in your speaker. Now you have several options :
Look at your display and maybe the station you just heard is sending out frequency information, you could just try to QSY to that frequency and give a shout.
Switch to you APRS radio/VFO and make a short voice call on the APRS frequency using the same tone as for voice alert. Since the other station is also using the same tones the operator will hear your voice through his APRS radio. Keep the call short an immediately propose a QSY !
Re: APRS 'Voice Alert'
Thanks
We currently can't mute the Rx because it would require collision detection to prevent Tx if there is already a transmission in progress , rather than relying on operators to listen before transmitting
We currently can't mute the Rx because it would require collision detection to prevent Tx if there is already a transmission in progress , rather than relying on operators to listen before transmitting