384kHz/768kHz problem
Jan Simons PA0SIM
we use a RX888MKII and radiod for our websdr:
http://sdr.websdrmaasbree.nl:8901/
radiod (August 2024) runs now for about half a year without any problems. Tks!
Radiod, websdr and wsprdaemon run on separate NUC computers.
Last week I was testing another RX888 on my setup at home.
We want a backup for all hardware, so also one or two RX888 receivers with improved cooling.
I also checked an update of your software in case we have to update in the future.
The new version of a few days ago however didn’t work. The same config file is used.
For the websdr we use 192kHz, 384kHz and 768kHz sample rates.
192kHz was ok, but no data could be received for the 384kHz and 768kHz sample rates.
I checked with PCMCAT (August 2024) and GNUradio (needed for our noise blanker).
Both, PCMCAT and GNUradio, run on a second computer.
However when I change the sample rate to for instance 385kHz or 765kHz, it is received ok.
In GNUradio we use the block from Franco:
https://github.com/fventuri/gr-rtp
At 384/768kHz GNUradio signals: recvmsg: Resource temporarily unavailable
Switching back to the August version, everything is ok again.
Without 384kHz and 768kHz we can’t run the websdr anymore.
73 Jan PA0SIM
Phil Karn
Hi Jan,
I'm deprecating 'pcmcat' and 'pcmspawn'. Use the 'pcmrecord' command with the '--stdout' option:
pcmrecord --stdout --ssrc 555 multicast-group.local
If the channel uses one of the PCM encodings (float, integer) the output will be in .wav format. Add the --raw option to suppress the header.
If the channel is using the opus encoding, the output stream will be Ogg Opus (no --raw option).
Here's the reason for this change. In the beginning I used statically defined values of the 7-bit RTP Payload Type field to define certain combinations of the sample rate and format. This was unworkable because the number of combinations was growing very rapidly. So I had radiod "beacon" a status packet for each channel on the data stream every 500 ms and modified pcmrecord to use this status message instead of the hardwired table. (The 'monitor' program also uses this information). To avoid adding the same functionality to pcmcat and pcmspawn, which would have been a lot of work, I simply added the --stdout and --exec options to pcmrecord.
I am going to remove both pcmcat and pcmrecord soon.
Phil
--
You received this message because you are subscribed to the Google Groups "ka9q-radio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ka9q-radio+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/dc766970-cfea-48d0-830c-2c3ca878b41en%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Franco Venturi
Phil Karn
On 2/10/25 20:19, 'Franco Venturi' via ka9q-radio wrote:
> Couple of quick comments:
> - the original idea (and therefore the name of the GNU Radio OOT
> module I wrote) was to allow GNU Radio to use any RTP stream as input;
> I wrote it because of ka9q-radio and radiod but my intent was to try
> to make it general purposefor any RTP stream. Perhaps we need a more
> specific GNU Radio OOT module called say 'gr-ka9q' that knows about
> radiod and its protocol and uses that to 'decode' the data stream from
> radiod
> - I also agree with Phil that it might be better to just run
> 'pcmrecord' with the '--stdout' setting. In GNU Radio you should then
> be able to use a 'File Descriptor Source'
> (https://wiki.gnuradio.org/index.php/File_Descriptor_Source), set the
> file descriptor to 0 (stdin), and then pipe the output from
> 'pcmrecord' to the Python script generated by GNU Radio Companion.
>
> Phil,
> when you wrote "I am going to remove both pcmcat and pcmrecord soon.",
> I assume you meant ""I am going to remove both pcmcat and pcmspawn soon."
>
Jan Simons PA0SIM
Jan Simons PA0SIM
Franco Venturi
Phil Karn
Those sample rates should be exact, and they should work fine; I can't imagine any reason they shouldn't . The output sample rate must be a multiple of both the block rate (50 Hz) and the FFT bin size (40 Hz), i.e, it must be a multiple of 200 Hz. There's also a performance consideration; the size of the inverse FFT should have no large prime factors. FFTW3 runs well with any number of factors of 2, 3, 5, and 7, plus one factor of either 11 or 13. When you give ka9q-radio a sample rate, it computes the necessary block size and logs a message if it has large prime factors that may slow it down. It also suggests the next larger size with small factors. But it will still work if you have enough CPU.
I primarily use 12 kHz for general HF operation and 24 kHz for NBFM. I am also using various large ad-hoc sample rates to receive and decode the aeronautical HFDL segments, and it all works very well. (I did have to adjust some of them to get optimal IFFT block sizes). Others are also using your sample rates successfully to feed websdr, so I don't know what your problem might be.
My HFDL sample rates are 12, 40, 50, 80, 100, 160, 192 220, 277.2 kHz. All work well.
Phil
--
You received this message because you are subscribed to the Google Groups "ka9q-radio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ka9q-radio+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/59381323-4051-4aa1-8f2a-3564e29a0a58n%40googlegroups.com.
Jan Simons PA0SIM
Jan Simons PA0SIM
about a year ago I reported the problem with some specific output sample rates like 384kHz, 768kHz and 1536kHz.
That is why we run an older version of KA9Q for our websdr and for wsprdaemon.
We are now trying to update wsprdaemon and building a websdr for the 70cm band using a SDRplay receiver.
Of course we would like to use the latest versions of wsprdaemon and of KA9Q.
For the update of wsprdaemon we have to update KA9Q.
After installing the latest KA9Q version on out test setup, we noticed that the sample rate problem is still present.
I did some more tests and it seems that all even multiples of 192kHz don’t stream.
For example 576kHz, 960kHz, 1535kHz or 1537kHz do stream.
The test setup runs Debian 13.
Also the GNUradio multicast block of Franco now only starts receiving the stream when I run monitor for that same stream at the same time.
I seems that something has changed between our older version and the new versions.
So when we would update, our websdr will not run anymore because of:
1) the 384, 768 and 1536 kHz sample rates
2) the GNUradio multicast block from Franco
We don't know what to do next and hope you can help us?
73 Jan PA0SIM
Rob Robinett
To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/460461cd-7cb2-4b2a-89c7-fade9e56a827n%40googlegroups.com.
Jan Simons PA0SIM
Phil Karn
Are you using the latest version of pcmrecord with the --stdout option? The old pcmcat command is obsolete; I folded its functionality into pcmrecord because they shared so much common code.
I just set up my 2m receiver (using an Airspy R2) to emit 384 kHz IQ with s16be encoding, and it worked fine with both monitor and pcmrecord.
The relevant change I made a while back was to beacon the channel status message on the output multicast group every 500 ms. This message contains, among many other things, the RTP Payload Type, output sample rate, channel count and encoding for the channel. The current versions of pcmrecord and monitor both *require* this message to understand the RTP payload type means in the data steam; they will not produce any output until that message arrives (which can take up to 500 ms).
This was necessary because my previous hack of hard-coding specific RTP payload types to mean various common combinations of sample rate, channel count and encoding was becoming unworkable. There were just too many possible combinations, and the RTP Payload Type field is only 7 bits. They're supposed to be dynamically allocated, though there are a few grandfathered values. You were probably using one of my hardwired combinations with an old version of pcmcat.
So if you set up a channel with SSRC 1234 in IQ mode emitting s16be encoding (with 2 channels implied) at 384,000 Hz onto the multicast group output.local, then you can receive this raw data with
pcmrecord --stdout --ssrc 1234 output.local | whatever
and pipe it into whatever program consumes it. By default this will emit a .wav header at the start of the stream. If that's a problem you can suppress it with the --raw option:
pcmrecord --stdout --ssrc 1234 --raw output.local | whatever
There is also the -v option which will tell you the format on stderr (so you'll still see it even if you redirect stdout). eg,
$ pcmrecord -v --stdout --ssrc 1234 gen.local > /dev/null
receiving 2m discone @ KA9Q ssrc 1234 samprate 384000 channels 2
encoding s16le freq 146,000,000.000 preset iq
The --ssrc option is optional but strongly recommended. Otherwise it will latch onto whatever SSRC it first sees on the specified multicast group.
Hope this helps.
Phil
To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/6646abd9-f1b5-4137-8c5f-f3820f716e86n%40googlegroups.com.
Jan Simons PA0SIM
Just checked again. With 384kHz monitor and pcmrecord both are not responding.
Using 383kHz monitor does show the info of the stream:
KA9Q Multicast Audio Monitor: 239.217.197.137
dB pan ssrc freq mode snr Tot Cur level Queue type ms ch bw pt rate pkt rst sockets
+0 0 14500 14,500,000 iq 18 17 -66.5 86 s16be 0 2191 77 12256 19646 2 127.0.0.1(localhost):50437 -> 239.217.
And when using 383kHz I also see the info with pcmrecord:
pcmrecord -v --stdout 239.217.197.137 > /dev/null
receiving rsp1a ssrc 14500 samprate 383000 channels 2 encoding s16le freq 14,500,000.000 preset iq
This is in my config file:
################
[global]
hardware = sdrplay
status = uhf.local
samprate = 10000000
mode = iq
ttl = 0
fft-threads = 4
overlap = 5
verbose = 1
iface = lo
[sdrplay]
device = "sdrplay" # required so it will not be seen as a demod section
description = "rsp1a"
serial = 220500ED98
samprate = 10000000
lna-state = 1
if-gr = 32
if-agc = 0
frequency = 14000000
[band1]
disable = no
demod = linear
data = band1-pcm.local
samprate = 384000
low = -50000
high = 50000
freq = "14500k"
agc = no
gain = 0 dB
encoding = s16be
#channels = 2 # makes no difference
Jan Simons PA0SIM
Phil Karn
I doubt it. I avoid the Linux audio subsystem like the plague, I touch it only when I actually want to send something to the speaker. pcmrecord doesn't touch it at all. monitor first converts the sample rate of everything it is playing to 48 kHz before sending to the sound system.
384 kHz works just fine here with both monitor and pcmrecord. I was using an Airspy front end for this particular test, but that shouldn't matter; any output sample rate that is a multiple of 200 Hz should work. Although I do support the SDRplay I strongly dislike it because of their closed source driver policy.
Can you look at the status stream, eg, with 'control' or 'metadump' when running at 384 kHz output? Is the channel thread running at all?
Are you only using a bandwidth of 100 kHz with a 384 kHz sample rate? That seems like a waste of bits.
Phil
Phil,is it possible that this sample rate problem is related to pulseaudio?
Op dinsdag 17 februari 2026 om 07:16:10 UTC+1 schreef Jan Simons PA0SIM:
To view this discussion visit https://groups.google.com/d/msgid/ka9q-radio/b73350c2-e478-4f6d-8a5c-ff7c4160495an%40googlegroups.com.
Loek Veeger
Hi all,
Let me share my measurements:
Test set: - i7 12 core laptop, debian13
- one sdrplay connected, V3.15.2 api
- one instance of radiod (latest version from github)
websdr cfg file always set to sample rate 1536000, otherwise it doesn't work
test 1:
radiod config file set to sr 1535000. At launch (sudo taskset -c 0 radiod rad...@sdrplay-test.conf) radiod gives the warning:
create_filter_output: N=38375 is not an efficient blocksize for FFTW3. Next good choice is N = 38400 (L=30720, M=7681); set samprate = 30720 * blockrate
But it starts streaming data to the channel, and pcmrecord it pushing it to the websdr ( taskset -c 2 pcmrecord -v --stdout --ssrc 430500 --raw band1-pcm.local > /home/loek/UHF/sdr-test/fifo70laag1 &
The websdr is working on this channel. But it humbles, cracks, sometimes slow startup, so it is not working 'pleasantly to hear, certainly not in CW mode.
In this case control is showing a channel, but SNR is -36,8dB.
Monitor is streaming packets. Of course, otherwise the websdr should be blank,....hi.
test 2:
According to the suggestion of the warning I change the blocksize to 38400 -->> sr 1536000. Relaunch radiod.
The cpu use is dropped by 50% (20 -> 10% on one core).
control is showing the channel
monitor is NOT showing data/stream.
I tried the --rate option, but that was denied by radiod at launch. No valid option anymore.
In the previous mail, Phil suggested to pick a sample rate of 384000. Well I changed the radiod config to 384000.
What are your bets,.......it does not work.
I changed to 385000, just give it a try,..........bets ????? It works!!!, but with the cracks, etc.
These experiments also done by Jan, PA0SIM, and he came to the same output (only he picked 383000).
My very cautious conclusion would be, that if you are exactly on the 'standard' sr's of 384000, 1536000 (more not tested)
some mechanism is blocking the stream. Probably the pcmrecord (no data, and no monitor). Are they missing the
500ms message ?
Hope it helps, tnx for all the support by the way !
Loek, PE0MJX