Noted over a week ago that Perth’s RTR FM was using a default RDS PI code of FFFF.
I thought that wouldn’t last long given the protentional problems with Noongar Radio also using the same default PI code & Noongar Radio would be unlikely to change.
Sure enough the next day RTR FM changed their PI code to an unusual and also problematic (for those tuners not wanting to display RDS with leading zero PI codes), but unique 0006 .
Will they ever learn
@melb_mateyy0 please note the new RDS PI code that has been in place for over a week @ RTR re the logo files for others.
The issue of clashing codes with FFFF Nongar Radio was not a problem for me and my webserver as long as you tagged the icon file with the exact RDS text eg FFFF_RTRFM.pnp and FFFF_nongar.pnp they were happy to coexist.
The change to 0006 just meant a simple rename. That peed off older radios. I have contact details for the RTR FM tech I will ask him how RDS codes are allocated as well enquire about the extremely wide BW issue I am having here with 92.1 and if it can be checked at the transmitter
The issue which I didn’t elaborate on was the frequency switching issue (re the temporarily shared PI code of FFFF) which would have been experienced by motorists with RDS tuners.
Closest thing to recommended PI code allocations we have in Australia is the flawed CRA list. I took a peek this arvo & unsurprisingly they allocated a PI code of 6921 to 6RTR. Given the significance of the 2nd digit of the PI code & RTR’s single transmitter, I’d have been tempted to allocate them a PI code of 6021 or 6022.
But given the low density of RDS stations in the region, a PI code of 6921 is fine for them or perhaps one of my two suggestions above.
If you’re in contact with the tech at RTR FM please inform them that a PI code of 0006 is also unsuitable due to the leading zero of the PI code rendering the RDS decoding of their station void in a significant number of tuners. This is per design & compliance with International RDS standards & not a tuner technical issue that some uninformed tech folk would like to spread misinformation on.
A suitable & compliant PI code for RTR would be 6021 or 6022 or plenty of other choices for PI codes commencing with 60XX. But in this instance, at the moment, 6921 is also free & not currently conflicting with any other known RDS FM station in WA.
3BA is still using the problematic FFFF pi code which I can now confirm doesn’t decode on my vehicle (2017 Mitsubishi Pajero Sport). Also, somewhat unrelated but I noticed that the station logo plugin doesn’t load any logo for 3BA.
Today’s Country 94.1 Gosford has been running without RDS for the last few days. But i also noticed the overmodulation is not as bad as it was before, offset frequencies of 93.9 and 94.3 are now fairly clean.
94.1 signal strength is still about the same, so I’m not sure what’s going on here, have they switched off RDS, is there a fault with the encoder or using a TX that doesn’t support RDS? I didn’t think RDS would make much difference to the modulation.
Thanks for this feedback.
Can I suggest contacting the station & request that the information is passed on to their technician/engineer. The only way faults like this get fixed is with numbers of folk complaining when the tech doesn’t respond to just one complaint.
Finally I have had a spare moment this morning to start constructing a new worksheet within our Google Sheets Aussie/NZ RDS List. The new worksheet #19 now allows folks to enter in vehicle details & provide a tick or cross to indicate whether the vehicle RDS tuner will decode RDS with known troublesome & non RDS International Standard PI codes such as; 0000, FFFF & 0xxx (where x = any number (HEX)).
My sincere apologies to those who earlier sent me details of their/other vehicles & RDS decoding results with the problem PI codes. Unfortunately I’ve been too busy past several weeks to compile these notes & may have lost track of messages & notes. It may perhaps be easier to add these notes yourself anonymously in the new worksheet, which you can now find here:
This would no doubt be due to the logo associated with the former PI code of: 3023 within the webserver logo file. If the 3BA tech can revert the PI code back to what it was two problems would be fixed at the same time.
To be honest I can’t answer most of those questions as I don’t have anything to do with the station & don’t really take much notice of what they have at the transmitter site, though the RDS encoder may be at the studio so I wouldn’t know if it was or wasn’t working anyway.
As for the RDS not making much difference to the modulation, it shouldn’t if they have it set to no more than 5%, but given they don’t seem to run anything to spec, the RDS injection levels could be quite high.
The Stereo Pilot level & RDS injection level all add to the audio sub carriers to make up the modulation, so the total of everything in the baseband should add up to give 100% modulation or 75kHz deviation.
Whatever you add in with the stereo pilot & RDS comes (or should come) out of the audio sub carrier levels, (L-R & Mono).
Total deviation you have to play with is 75kHz, the stereo pilot should be 9% of that (= 6.75kHz) but no more than 10%, the RDS should be 4% but recommended is 5% these days (= 3.75kHz), but no more than 6%, that leaves 64.5kHz for the mono & L-R Stereo audio sub carriers.
This must be a bit embarrassing for Wave FM. There are people who have cars with FM Radio containing the RDS feature and they rely on that for song information and to know what station they’re tuned to. Wait til newcomers and visitors to the Illawarra tune their radios to 96.5 FM and see this in their cars, they’ll probably just see it as a pirate radio station and complain to the ACMA. Oh dear. I wonder if they’re scrambling to fix the issue ASAP? Or do they simply just not care?
DESTRUCTIVE DAMAGE to our Aust/NZ RDS LIST THIS MORNING!
At the hours of 4.30am & again at 7.30am AEST today February 15th, 2025 a Media Spy user had a brain snap & decided to go on a destructive sojourn throughout the RDS List.
It “appears” the “embarrassing” Wave FM RDS issue has too much for them to handle so they felt the need to go on a destructive bender.
To the person concerned I hope you are satisfied with your actions.
Is there a reason why you felt the need to destroy so much of peoples hard work?
Firstly this image posted immediately below (also see two posts above) & a sample of the 71 destructive changes including wiping out most of the Victorian RDS data & widespread damage to the majority of the worksheets.
That’s unfortunate to hear. At least you have the option to restore to a previous version and not all is lost.
All my FM-DX Webservers were also set to 96.55 when I checked this morning (as per your last screenshot). Even the QLD tuners were set to 96.55 when I checked.
The bandwidth switch on my servers was also set to 56 kHz so that RDS doesn’t decode properly. I’ve now disabled the bandwidth switch on my FM-DX Webservers due to abuse (previously, it had also been set to 311 kHz during trolling episodes which also causes issues).
The IP address was 45.87.214.90, which is just a VPN.
Yes that was done ASAP after observing the changes.
Thanks for the heads up on this & the VPN IP address.
Why crazy people waste their time with such pursuits I’ll never comprehend.
All I’ll say is that there are people about who are in need of further mental health care & should actively seek it.
I’ll do more regular backups in future. I’ll be making contact with the MS Admins soon.
Thanks for your kind concerns folks. I would however for the interim request that folks not bother to like posts or reply or react to the person responsible posts. It only fuels their interest in the group & our pursuits. Just ignore them.
Just try googling recovering older version of excel files you might be surprised you can revert the file to a previous saved version before the changes were made. I can not guaranteed it and does depend on how the document is stored and shared. It might also give you extra information on who edited the file. Good luck
