Decode call sign from PI

[ghost]

According to the NRSC-4 standard for the U.S., the PI for a station is based on its call sign, according to a formula in the standard : http://www.nrscstandards.org/SG/nrsc-4-B.pdf (see section 7.12). Most stations here in the U.S. (commercial ones, in any case) use PS either for a slogan (as suggested by the NRSC document) or as a 'poor man's RadioText+'. This leads to interesting results when a radio manufacturer doesn't account for this (the radios in BMWs have had this issue before).

It would be nice, perhaps when the -u switch is used, to have the PI decoded into a string like 'WFOO' or 'KBAZ'. This is makes things more consistent when trying to use redsea output to identify stations.

[windytan]

Thanks, great idea!

[windytan]

There's now preliminary support for this. A JSON field callsign will appear in the data when the -u option is used. I've tested it to work with the examples provided in that PDF - hope it works with real signals as well!

And by the way, I don't have any real data from the US. I'd be grateful for a minute's worth of hex output of some stations with the -x switch, if you have time :)

[ghost]

Wow, that was fast! Testing shows me that it works in nearly all cases. One case, where the proper call sign is WYYY, shows up as "KCMQ". It is very possible that the station is simply transmitting incorrect information: this happens more often than you might think (the AF for WCNY is transmitted as 89.7 but is actually 89.5, and they don't put their third alternate in there at all). I have attached some recordings as you requested, including from WYYY. All the others show up correctly. Nice work, and thank you.

By the way, if you are interested, WYYY transmits TMC data, as do most Clear Channel Communications-owned radio stations in the U.S. The data is encrypted, but may be of interest to you since I know redsea does handle TMC data.

Another possible interesting US-specific bit is emergency alerts. https://en.wikipedia.org/wiki/Emergency_Alert_System These can be delivered by RDS, I believe. Whether they are or not, I don't know.

WAER-FM.txt WCNY-FM.txt WNTQ-FM.txt WTKW-FM.txt WYYY-FM.txt WZUN-FM.txt

[windytan]

WYYY has PI code 1690 which indeed decodes to KCMQ, as if they didn't follow the call sign encoding practice.

Thanks a lot for the data, very useful!

[windytan]

I just noticed this is actually covered by that document . Stations may use a 1 as the first nibble for better compatibility with a wider range of TMC receivers. They don't offer any easy fix for detecting this; instead, ClearChannel just recommends using RadioText as a source for the displayed call sign instead of back-calculating from the PI. Perhaps the field name could be changed to callsign_uncertain or something when the PI starts with 1 and there is a TMC app present.

[ghost]

It is likely that when TMC is present, so is RT+. In most radio markets of the U.S., TMC is carried by Clear Channel because (as their name suggests) they tend to own a class C license (up to 100 kW) or a grandfathered B license carrying as much power if not more. As a result it is easy for GPS receivers without good FM antennas to pick up.

They own another station in my area, WWHT, but there is oddly no RDS data on that channel. Despite it being a digital-hybrid station and presumably having relatively new equipment. It's a 50 kW class B and it comes in strong at my location, so I am inclined to believe that the data isn't present, rather than it being a reception problem on my end. It would be nice to have a second test-case to see if TMC is indeed the reason for this, but I haven't found one.

CC tends to be a leading adopter of radio technology, they are big on the IBOC digital radio standard too. So, it's a safe bet that RT+ is present on most stations with TMC, but even if it is not, I think that is something for users of the redsea output to be concerned about. Something like 'callsign_uncertain' would work well.

[windytan]

You may be able to see whether the subcarrier is present in a post-demodulation spectrogram.

callsign_uncertain is there now :)