RDS PI loss mute

[AaronJowitt]

Suggest;

RDS Settings > PI loss mute > Off, A123 (etc)

The menu would allow setting to:

• Off (default)
• Store the current PI code the tuner is receiving
• Manually enter a PI code

Stored in EEPROM for persistence.

New behaviour is audio output (STEREO and MPX mode) mutes when;

1. Beyond SQ mute threshold (current behaviour), and;
2. Whenever the currently received PI code does not match the stored PI code. Including if no PI code is being received.

Some pro FM receivers have this. It is useful for;

1. DXing to catch a specific radio station whose PI code is known. The radio ignores other stations received on the tuned frequency, and only unmutes when the target PI code is being received (and above the SQ unmute threshold).
2. Feeding an FM transmitter, ensuring only the target radio station is rebroadcast. Muting temporarily when rare weather conditions allow another radio station to be temporarily received.

Thank you. Brilliant software.

[PE5PVB]

If signal drops, RDS decoder is halted, not reset. So I don't know how to add this.

[AaronJowitt]

If signal drops, then assuming SQ is set to an appropriate value for reliable RDS reception (which is implicit in using this feature) SQ mute threshold is met and the radio mutes anyway, irrespective of what the PI code value in the halted RDS decoder is. That should be ok. To amend what I wrote above, the radio should mute when;

1. Beyond SQ mute threshold (i.e. the current/normal SQ behaviour), OR;
2. Whenever the currently received PI code does not match the stored PI code.

So if either signal drops (SQ) or a new PI code is received that doesn't match stored PI target value, it mutes, which is the behaviour we want. The fact the RDS decoder retains its last received PI value when the signal drops (i.e radio is muted by SQ anyway) shouldn't matter.

[AaronJowitt]

I gather you don't have a means to track if the RDS decoder is halted, or alternatively if new RDS data has not been received for xx seconds - implying reception of an unwanted station without RDS?

It wouldn't be perfect without one of those checks, as the feature wouldn't work if a new unwanted station is suddenly received that doesn't broadcast RDS (and the hatled TEF RDS decoder retains its last PI value). However, the vast majority of stations do use RDS here now, so even with that limitation it would be a useful feature.

[AaronJowitt]

The PI code displayed on the radio currently changes color when the RDS signal is poor or lost - so wouldn't it do same if reception changes to a station without RDS? If so, can't that color/state change trigger be used to assume an invalid PI code (compared to stored PI target code) ? With this feature audio is ever only umuted when signal is (at least) good enough for RDS reception anyway.

[AaronJowitt]

Inovonics name it "RDS Loss (hijacking)".
Pira name it "RDS PI mismatch".

[AaronJowitt]

Does v2.00.12 get us closer, with PI now being stored to MEM presets?

So, an option to mute a MEM preset if the PI code stored in the MEM does not match perhaps? It could dim, flash or show a strike through the displayed received PI code (maybe alternate between the stored & received code?) until the correct PI code for that MEM preset is received and the radio unmutes?

Would need to be persistent through power cycling.

[PE5PVB]

OK. So you want to have a squelch on memory channels which opens when the PI in memory matches the broadcast? Should it go back to mute on RDS loss?

[AaronJowitt]

Yes to both.

Open immediate. Close perhaps on a slight delay (0-60s ?) to avoid it ever muting unintentionally if the PI code is briefly lost & not properly received.

[AaronJowitt]

Clarify. Dynamically;

• MUTES whenever received PI does not match the PI stored in the memory channel, ideally including when no PI is being received.
• UNMUTES whenever received PI matches the PI stored in the memory channel (if above any set SQ threshold).