384kHz/768kHz problem

[Jan Simons PA0SIM]

Dr Phil,
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]

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."

Franco

[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."
>

Right. Not enough sleep.

[Jan Simons PA0SIM]

Hello Phil, Franco,

I spent a few hours trying to use pcmrecord and file descriptor sources for our 11 bands, but I couldn't get it to work.

It will need more time to get it to work and to test. For instance on latency.

The GNUradio gr-rtp block is receiving data for all sample rates, but not at exactly 384kHz, 768kHz and 1536kHz.

For instance at 383kHz, 385kHz, 769kHz or 1537kHz it is ok.

May be it is another change in KA9Q software that causes it?

Phil, is it an option to keep the August 2024 version available on GitHub?

That would save us a lot of time.

73 Jan PA0SIM

Op dinsdag 11 februari 2025 om 06:14:37 UTC+1 schreef Phil Karn:

[Jan Simons PA0SIM]

Forgot to tell that 192kHz is also ok with the GNUradio gr-rtp block.

Op dinsdag 11 februari 2025 om 10:07:41 UTC+1 schreef Jan Simons PA0SIM:

[Franco Venturi]

Jan,

the good news is that with git you can checkout the exact ka9q-radio code that was there on August 2024.

First of all, run 'git log' and find which commit you want your ka9q-radio source files to be at - for instance commit 4b96113c0e3e14a5b1f0cb7c4b6361b0bbcae4a7 sets your source code at what it was on August 29 2024 (the last commit for that month).

Once you have decided which commit, you run 'git checkout <commit>' and your ka9q-radio source code will be exactly what Phil had at that time - in the example above you would run 'git checkout 4b96113c0e3e14a5b1f0cb7c4b6361b0bbcae4a7' and your copy of ka9q-radio will be the source code that was there on August 29 2024.

73,

Franco K4VZ

[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]

Thanks Franco for the info about git checkout!

I found that I can see it all with "git log --branches" and using the "w" and "z" to go backward and forward in time.

With this we can keep the websdr in the air.

Phil: I don't know why those specific sample rates are not streaming data using the same config file.

Tried this morning again and it is persistent.

73 Jan PA0SIM

Op dinsdag 11 februari 2025 om 20:29:16 UTC+1 schreef Phil Karn: