UDP Streaming Output Rate

333 views
Skip to first unread message

Jason Mao

unread,
Feb 13, 2018, 5:13:20 PM2/13/18
to Gqrx SDR
I have gqrx installed on ubuntu and am using a Funcube Dongle Pro V1.1. I am trying to stream the audio over udp to Direwolf for further processing.
Is there a way to increase the sample rate past the default 48000? gqrx says the FCD has a sample rate of 96000.

Alexandru Csete

unread,
Feb 13, 2018, 5:24:32 PM2/13/18
to gq...@googlegroups.com
The 96 kHz is the RF bandwidth of the receiver, but the demodulated
audio sample rate in gqrx is 48 kHz (24 kHz analog bandwidth).

Alex

Jason Mao

unread,
Feb 13, 2018, 5:30:12 PM2/13/18
to Gqrx SDR
Could the 48 kHz output be increased if the receiver's bandwidth was increased? I believe the FCD Pro+ has a sample rate of 192 kHz.

Alexandru Csete

unread,
Feb 13, 2018, 5:57:55 PM2/13/18
to gq...@googlegroups.com
On Tue, Feb 13, 2018 at 11:30 PM, Jason Mao <jaja...@gmail.com> wrote:
> Could the 48 kHz output be increased if the receiver's bandwidth was
> increased? I believe the FCD Pro+ has a sample rate of 192 kHz.

There is no user selectable option for it, but the source code is
generic enough to allow using other output rates. Note that your sound
card has to support the sample rate otherwise it will not work.

The audio sample rate in gqrx was chosen to 48 kHz because all sound
cards support it and it covers the vast majority of the use cases. 48
kHz gives you almost 24 kHz of analog bandwidth. Speech requires
around 3 kHz of analog bandwidth. AM radio stations 5 kHz, maybe a
little more. Even broadcast FM with "hifi music" will do just fine
with ~20 kHz audio.

Alex

Jason Mao

unread,
Feb 13, 2018, 6:37:22 PM2/13/18
to Gqrx SDR
Alright, I think I will test that. Would the d_audio_rate(48000) part of the receiver constructor be the correct place to start?

Thanks for all the help!

Alexandru Csete

unread,
Feb 13, 2018, 6:50:37 PM2/13/18
to gq...@googlegroups.com
Yes, but you also need to check the individual receivers, as some of
them will have an internal "preferred sample rate" which is also 48k.

Alex
> --
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gqrx/81d509eb-54d9-4cc0-ac99-9b3b120e392e%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

David Ranch

unread,
Feb 13, 2018, 8:49:55 PM2/13/18
to Gqrx SDR

Hello Jason,

Can you tell us what you're trying to do with Direwolf?  Ultimately, Direwolf is only expecting *one* AFSK/FSK signal to come in via the passband be it via a sound card or say audio over UDP..  Gqrx supports this use case this today and does it well.  Yes, you can configure Direwolf multiple off-frequency decoders to support better decodes within that passband but that's really intended for HF operations. 

Ultimately, what I think you're looking for is multiple SDR demoulation "slices" decoding their respective different RF signals and sending that decoded audio to one or more copies of Direwolf to decode things.   If so, that's not something that Gqrx does today.  Check out RTL-SDR-Airband's Dev branch at https://github.com/szpajder/RTLSDR-Airband which is a console based multi-slice SDR program which now supports the SoapySDR API layer.  With Soapy, it  now  supports multiple SDR devices which I believe includes the the FCD..

--David
KI6ZHD

Jason Mao

unread,
Feb 14, 2018, 5:06:57 PM2/14/18
to Gqrx SDR
Hi David,

I am trying to use Direwolf and gqrx with a FunCube Dongle Pro to communicate with a satellite radio. At the moment, the communication works fine for the most part, packets sent from the satellite are picked up by the radio, demodulated in gqrx and streamed over UDP to Direwolf. Direwolf then sends its output via KISS connection to another program. 

The problem I am having is that some packets, those containing any values between 0xF0 and 0xFC, are not being demodulated. I an not 100% sure what the error is, but Direwolf gives a warning that the baudrate to sample rate is low, so I was looking for a way to increase the output sample rate of gqrx to see if that helped at all.

I'm somewhat of a novice to radio and digital signal processing, so I'm not entirely sure what you mean my demodulation slices.

David Ranch

unread,
Feb 16, 2018, 11:49:55 AM2/16/18
to Gqrx SDR
Hello Jason,



I am trying to use Direwolf and gqrx with a FunCube Dongle Pro to communicate with a satellite radio. At the moment, the communication works fine for the most part, packets sent from the satellite are picked up by the radio, demodulated in gqrx and streamed over UDP to Direwolf. Direwolf then sends its output via KISS connection to another program. 

Ok.. got and it sounds like you're 99% of the way there.  What is the modulation of this satellite packet station?  AFSK1200?  FSK9600?  PSK2400?  PSK4800?  Something else?


 
The problem I am having is that some packets, those containing any values between 0xF0 and 0xFC, are not being demodulated. I an not 100% sure what the error is, but Direwolf gives a warning that the baudrate to sample rate is low, so I was looking for a way to increase the output sample rate of gqrx to see if that helped at all.

That's very strange.  Direwolf on a Raspberry Pi works WELL with the /3 option (see Section 9.2.2 in the Direwolf User-Guide) for AFSK1200 which divides down the sampling rate to 16khz!  As such, trying to change how Gqrx to send *more* audio bandwidth or it's sampling rate most likely with gain you nothing.  What version of Direwolf are you running?  I recommend the current 1.5-Beta.  Next, are you using any FIXBITS settings in Direwolf?  

If you can save some of these problem packets as demodulated from GQRX into WAV files, I can give them a look to see why you might be thinking that your seeing issues with digital patterns between 0xF0 and 0xFC.

 
I'm somewhat of a novice to radio and digital signal processing, so I'm not entirely sure what you mean my demodulation slices.

Your specific SDR hardware will present GQRX with a stream of I/Q data.  In the FCD's case, I think that's 192Khz worth of bandwidth, in a RTL dongle, it's usually 2.5Mhz, and in a AirSpy R2.. 10Mhz of signals.  At that point, you select a seen signal in GQRX's RF waterfall, select a demodulation type like LSB, USB, FM, AM, etc... and then you should start seeing the signal in the lower right *AUDIO* FFT and should hear those signals.  It's this demodulate signal that is sent to Direwolf via GQRX's UDP streaming feature.  With some other SDR software out there, you can actually select different signals in the RF waterfall, assign them to an independent demodulator and listen to each of them independently.  Some programs even allow to send the demodulated audio to different UDP streams to different instances of Direwolf to decode them all at the same time.  Very power stuff if you have a need for it.. 

--David
KI6ZHD

Jason Mao

unread,
Feb 17, 2018, 8:11:57 PM2/17/18
to Gqrx SDR
The satellite outputs at 19200 baud, but I will check with some co-workers on the exact type of modulation.

The Direwolf manual said not to use the /n option with 9600 baud, and since I'm using something higher, I left that off. I am also using the latest stable version of Direwolf 1.4. There were some seg fault issues with v1.5, but I can try to work through those if 1.5 is a significant upgrade. I also left the FIXBITS settings at default, 1. 

It doesn't seem like I should need demodulation slices, since all the packets are fine bar the few curious ones. Also, after double checking, the bad packets actually contained bytes between F8 and FB, not F0 and FC.

I have attached a few wav files via Google drive. The smaller is the signal from one bad packet. The other is a series of packets, the first being a good packet while the rest are bad.

Thanks,
Jason

David Ranch

unread,
Feb 17, 2018, 10:06:41 PM2/17/18
to Gqrx SDR
Hello Jason,

That's probably a 19.2k FSK signal and you're right, you don't want to lower the sampling rate but I don't think you need anything more than 48Khz from Gqrx either.  If you can tell us the specific satellite, this should be very easy to look up.  Looking at the WAV files, the signals are definitely there though the SNR is pretty low.  I don't suppose you can bring that up any higher?

Which version of Direwolf 1.5 were you using?  Was it the Alpha?  Was it this beta?  If you're seeing issues, there, please report them at direwol...@yahoogroups.com and we'll get those fixed!  Btw, could you post your direwolf config as well?

--David
KI6ZHD

David Ranch

unread,
Feb 17, 2018, 11:10:38 PM2/17/18
to Gqrx SDR
Hello Jason,

Ok.. so I gave it a try with one of your files..  The mode is 19200 G3RUH FSK.  Per the sampling table in https://github.com/wb2osz/direwolf/blob/dev/doc/Going-beyond-9600-baud.pdf , it seems like there could be some real benefit to having Gqrx offering a higher audio sampling rate output than just 48Khz for these higher speed modes.


hampacket2:/tmp$ atest -B 19200 gqrx_20180217_004607_438992800.wav

Data rate set to 19200 bits / second.
Using scrambled baseband signal rather than AFSK.
48000 samples per second.  16 bits per sample.  2 audio channels.
5616232 audio bytes in file.  Duration = 29.3 seconds.
Fix Bits level = 0
Channel 0: 19200 baud, K9NG/G3RUH,  , 48000 sample rate x 2.
The ratio of audio samples per sec (48000) to data rate in baud (19200) is 2.5 <------------------
There is little hope of success with such a low ratio.  Use a higher sample rate.  <------------------

Channel 1: 19200 baud, K9NG/G3RUH,  , 48000 sample rate x 2.
The ratio of audio samples per sec (48000) to data rate in baud (19200) is 2.5
There is little hope of success with such a low ratio.  Use a higher sample rate.

DECODED[1] 0:03.0752 NX1U audio level = 85(+126/-128)
[0] NX1U>W6YRA:�5<0x00>��^
'nul' character found in Information part.  This should never happen.
It seems that NX1U is transmitting with defective software.

DECODED[2] 0:18.4598 NX1U audio level = 78(+104/-96)
[0] NX1U>W6YRA:<0x17><0x0f>0<0x00><0x00><0x01><0x01><0x02><0x18>3<0x00><0x00>)<0x00>/<0x00>/<0x00><0x01><0x02>�<0x02><0xff><0x01>*<0x00>�<0x00>�<0x00><0x00><0x00><0x00><0xff>�<0x19> e�<0x00><0x13><0x7f>{<0xff>�<0x19>�e <0xff>�<0x7f>a<0x03>�<0x01><0x01><0x18>�<0x01><0x01><0x01><0x01>ccc<0x00><0x01><0x01><0x02><0x10><0x11><0x01><0x00>,<0x00>/<0x00>/<0x00><0x01><0x02>l<0x02>�<0x01><0x1a><0x00>�<0x00>�<0x00><0x11><0x00><0x10>�<0x7f><0x19>`W �<0x1d>w��*<0x19>�Z��<0x1c><0x10>O<0x03>�<0x01><0x01><0x01><0x01><0x17>� <0xff>]]<0x0d><0x00><0x01><0x01><0x02><0x18>F<0xff>�<0x00>_<0x00><0x1f><0x01><0x01><0x01><0x01><0x01><0x01><0x01><0x01><0x00><0x01><0x01><0x02><0x19><0x15><0xff>�<0x00>a<0x00> <0x01><0x01><0x01><0x01><0x01><0x01><0x01><0x01><0x19><0x00>�<0x03>H<0x00>!�.�8<0x00><0x02>v�<0x04><0x00><0x00><0x00><0xff><0xff><0x00>F<0x1e><0x16><0x00><0x00>��<0x00>�<0x00><0x01><0x02><0x18>3<0x09><0x01><0x02><0x18>3<0x02><0x01><0x02><0x18>3<0x02><0x01><0x00>PY<0x02>
'nul' character found in Information part.  This should never happen.
It seems that NX1U is transmitting with defective software.

DECODED[3] 0:25.3746 NX1U audio level = 87(+133/-124)
[0] NX1U>W6YRA:�5<0x00>��^
'nul' character found in Information part.  This should never happen.
It seems that NX1U is transmitting with defective software.


3 packets decoded in 0.431 seconds.  67.9 x realtime

David Ranch

unread,
Feb 17, 2018, 11:25:37 PM2/17/18
to Gqrx SDR
I wonder if there is enough of a use case here to see if we could ask Alex for a configuration item in Gqrx to save demodulated audio in higher rate WAV files?  More and more satellites are using higher speed bit tates and this sure would be useful for Direwolf's higher speed modes (it supports up to at least 38400 bps)!

--David
KI6ZHD

Jason Mao

unread,
Feb 18, 2018, 10:17:27 PM2/18/18
to Gqrx SDR
I tried using Direwolf v1.5-beta. I won't by able to upload the config file or try to up the SNR until probably Tuesday, but I'll get those asap. 

I also increased the gqrx output to 9600 in the source code, and it appears to have worked but did not fix the demodulation errors.

David Ranch

unread,
Feb 18, 2018, 10:47:50 PM2/18/18
to Gqrx SDR
Hello Jason,


I also increased the gqrx output to 9600 in the source code, and it appears to have worked but did not fix the demodulation errors.

Just checking here but are you seeing the "demodulation" errors in the actual KISS or AGW data stream you're connecting some application or are you just referring to the warnings/comments you're seeing on the STDOUT of Direwolf?  If the latter, you can safely ignore those items as the code is trying to apply APRS rules to that misunderstood data stream.  Technically speaking the "AX25" heuristics option in the FIX_BITS feature should turn those warnings off but it seems like it's not completely working here.
Btw, for weak satellite work, you might try playing with the PASSALL feature to disable the CRC check options.  Can help a lot but you can get a LOT of noise as well.

  FIX_BITS 1 AX25 PASSALL

--David
KI6ZHD

Jason Mao

unread,
Feb 20, 2018, 4:34:24 PM2/20/18
to Gqrx SDR
I attached the direwolf.conf there are no major edits except changing the input rate from the udp source, changing the modem setting to 19200 baud, and setting the KISS port to 8100.

When receiving a packet, I expect to get some output from the program connected through KISS, however with the bad packets no output is seen. I in general ignored the warnings in the direwolf output.

How would you recommend getting better SNR? Would just increasing gain work?
direwolf.conf

Jason Mao

unread,
Feb 26, 2018, 6:32:13 PM2/26/18
to Gqrx SDR
Here is another recording which should have less noise. When I receive the packet from the SDR, gqrx seems to pick it up judging from the waveform, but Direwolf doesn't show any decoded packet.
Strangely, when I try to replicate the error using a handheld radio to output instead of receiving from the radio, the packet is decoded fine. The handheld radio uses 9600 baud.

PASSALL does not seem to solve the problem either, not does raising the FIX_BITS to 2.


https://drive.google.com/open?id=0BziQ7p1YgPxmYUVMNFJCX1FCbXRrdlgzYzEtazY2SXFxbDdB
Reply all
Reply to author
Forward
0 new messages