APRS 'Voice Alert'

[SA0BUX]

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.

[VK3KYY]

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

I don't think this affects the APRS operation of the firmware.

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

[SA0BUX]

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"

Capture.JPG (102.22 KiB) Viewed 2553 times

[VK3KYY]

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

[SA0BUX]

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.

[VK3KYY]

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 have every radio type, except DM1801A, RT-84 and 2 of the MD9600 variants

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

[kt4lh]

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.

[DU2XXR]

"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/

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 !

[VK3KYY]

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