Unable to get PSN to work

[paredlund]

I have an lab instance of JMPXRDS setup, the MPX generator and the control panel is fully working on Ubuntu Studio. The JMPXRDS client is installed and started on an raspberry pi 4 with an HifiBerry DAC+ HAT. The HAT is connected via audio out to mpx in on the transmitter. The audio is working as expected, the rds RT is working, but i am unable to get the PSN thru to the rds reciever (Radio). I have tested to set the text string both via the control panel and rds_tool, but no go. The command rds_tool -g gives: Status: Enabled PI: 0xE083 ECC: 0xE3 LIC: 0x28 PTY: 9 PSN: STATION RT: PTYN: TP: 0x0 TA: 0x0 MS: 0x0 DI: 0x5 To extend the question, does the 192khz stream generated internally in the MPX generator and transmitted to the client?. i.e. do i have to have an 192khz sound card on the MPX generator itself, or is it just on the client connected to the transmitter?.

[mickflemm]

The MPX generator actually works at a much higher frequency internally (see https://github.com/UoC-Radio/JMPXRDS/blob/master/oscilator.h#L39) and it outputs a signal at 192KHz either raw through a UNIX socket (used by the GUI but you can also just redirect it with netcat/sox etc to another device), or FLAC-encoded (to reduce bandwidth) through RTP to another device (using gstreamer and the bundled client). It doesn't matter what's the sampling rate of your soundcard or the sampling rate of the JACK/Pipewire instance that JMPXRDS is connected to, that only mandates the audio input, it will get resampled / filtered internally.

As for the PSN issue, it's very weird that you receive RT but not PSN, your receiver either receives RDS groups, or not, and the 0B group where the PSN is, is supported by all receivers. RT for example is not that common and it takes many more packets to receive the full RT (so receiving it correctly is much harder than PSN). There is a chance there is something wrong with your receiver, some in order to support dynamic PSN do all sorts of stupid things, others do the exact opposite (try to avoid dynamic PSN) and for example they may ignore PSN changes once you store a station in memory, they'll display the PSN at the time you stored them. In any case you need a more reliable test, I suggest you use an SDR (e.g. an rtlsdr) and either the gnuradio receiver included (that also does rds decoding), or the RDS Spy application (https://rdsspy.com/).

Do you at least see the PTY / PTYN being displayed ? is the time set correctly ? If you play with traffic announcement / traffic programme do you see the flags being set on your receiver ?

Note that some DAC shields have a low pass filter in their output, with a cutoff frequency much lower than Nyquist, so they sometimes trim the 50-57Khz range of the MPX where the RDS is, they may even trim the 38KHz L-R part (if they only allow audible frequencies for example). Another test you can try to check the filter of your shield is to play some white noise through the DAC and use a spectrum analyser on its output to see that it doesn't filter out MPX, also note that there are some filter options through alsamixer you can play with (at least with some shields).

Finally make sure your exciter works as expected, there is a chance your exciter does the filtering (e.g. because it's switched to mono, or due to some other setting), and doesn't let RDS go through.

I hope this helps, from our side everything works as expected, we do see PSN in both radio stations that we operate using JMPXRDS. So I can't reproduce your issue unfortunately in our setup.

[paredlund]

The raspberry pi is connected via the RTP server in JMPXRDS. The pi HAT and the pi itself, included the installed os, was recently used in a working 192 khz studio-to-transmitter mpx link between an hardware multiplexer and a transmitter. In that case both the audio and rds was working fine, tested on the same radio receiver as now tested. I will try with an SDR as you suggested to see if PTY/PTYN shows up. I have not fiddled very much with the pilot tone settings, which i have somewhat copied the settings from the old hardware multiplexer. Also, thank you for your promt response!

[mickflemm]

This is what we have:

jmpxrds.service:

[Unit]
Description=JMPXRDS Signal Generator
StopWhenUnneeded=true

[Service]
Type=notify
EnvironmentFile=/etc/local_configuration/mastering/%H/fm-config.env
ExecStart=/usr/bin/jmpxrds
ExecStartPost=/usr/bin/fmmod_tool -a ${AUDIO_GAIN} -m ${MPX_GAIN} -p ${PILOT_GAIN} -r ${RDS_GAIN} -c ${STEREO_CARRIER_GAIN} -s ${STEREO_MODE} -f ${AUDIO_LPF} -e ${FM_PREEMPH_MODE}
ExecStartPost=/usr/bin/rds_tool -e -pi ${RDS_PI} -ps ${RDS_PSN} -rt ${RDS_DEFAULT_RT} -ecc ${RDS_ECC} -pty ${RDS_PTY}
ExecStartPost=/usr/bin/rtp_tool -a ${RTP_CLIENT_IP}
Restart=always

[Install]
WantedBy=radio.target

fm-config.env:

AUDIO_GAIN=38
MPX_GAIN=72
PILOT_GAIN=2
RDS_GAIN=2
STEREO_CARRIER_GAIN=100
STEREO_MODE=2
AUDIO_LPF=1
FM_PREEMPH_MODE=0

RDS_PI=0x1060
RDS_PSN=RSPK96,7
RDS_DEFAULT_RT="Radiofonikos Stathmos Panepistimiou Kritis"
RDS_ECC=0xE1
RDS_LIC=0x70
RDS_PTY=0

RTP_CLIENT_IP=<ip of rpi>

This is tailored to our exciter (which clips easily, we are in the process of switching to a better one). We use an odroid with a HiFi-shield (this is EOL now but it has a DAC that goes up to 384Khz and it's mostly linear in the range we want).

For mastering we use https://github.com/trummerschlunk/master_me, before that we used calf's compressors/limiters etc but master_me is much simpler and (in most cases) neutral.

[mickflemm]

And on our other station, we have this DAC on rpi: http://www.inno-maker.com/product/hifi-dac-hat/, with a different set of settings (again, different exciter there, one from PCS electronics):

AUDIO_GAIN=45
MPX_GAIN=70
PILOT_GAIN=2
RDS_GAIN=4
STEREO_CARRIER_GAIN=50
STEREO_MODE=1
AUDIO_LPF=1
FM_PREEMPH_MODE=0

RDS_PI=0x1060
RDS_PSN=MatzoRe
RDS_DEFAULT_RT="MatzoRe 89,1 Radiofonikos stathmos Panepistimiou Kritis"
RDS_ECC=0xE1
RDS_LIC=0x70
RDS_PTY=0

RTP_CLIENT_IP=<ip address of rpi>
PIPEWIRE_LATENCY=2048/48000

PIPEWIRE_LATENCY is needed when using pipewire since in some cases it tries to change sampling rate after jmpxrds has registeres its ports, in which case we get buffer over/underflows etc. I'll need to add a callback for that but I don't have much time for it, and this is a quick/simple workaround that does the trick.

Note that this DAC has an alsamixer setting for controlling the output filter (or even disabling it). However we didn't have much time to verify its operation with a spectrum analyzer (the station was down and we wanted to bring it back asap).