-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rx_fm tuning problem with SDRplay RSP2 #75
Comments
I have the same problem and hear only complete silence using an RTL-SDR attached to my Raspberry Pi. No one has yet commented on my November post on this problem, but I see recent checkins so there is hope. rx_fm would be so useful for my WSPR receive projects. If I get it working I would like to contribute a feature to rx_fm which will generate a series of 2 minute long wav files synchronized to start at each even 2 minute. That feature is available in the kiwirecorder utility I use for LF/MF/HF WSPR recording with the KiwiSDR, and rx_fm will allow me to support many more SDRs. |
Sorry my search missed your earlier post, rrobinett. I have since looked for alternative applications, but without luck. At this point I would consider trading the nice RSP2 for less capable hardware if I could identify a product that worked correctly for this simple use case. Is there an RTL or other model that known to work correctly with the current rx_fm? Briefly: I need a way for a microcomputer to control the receiver frequency for commercial North American FM broadcasts, sending demodulated output to an audio amplifier. This is an aid of a paraplegic patient who cannot use any conventional controls. Something like Silicon Labs Si47xx radio chips would do the job nicely, but I discovered this hardware is not so easy to work with. SDR seemed like a natural fit. |
The excellent $20 RTl_SDR should work perfectly for your application using the rtl-tools: https://github.com/n1gp/librtlsdr |
rx_tools definitely needs some community help. It was basically a hack job of rtl sdr tools ported for soapysdr, but the code was never very good quality to begin with :-/ I'm not the maintainer, but I have been trying to fix warnings, report errors better, improve use of the API, and keep up with pull requests. I suppose something has been wrong with the FM demod for most of the life of this program at least for certain devices? Or perhaps new and exciting bugs have crept in. If anyone wants a fun weekend project, or is familiar with rtl_fm, its just an FM demod, and a lot of people seem to want to use it. Perhaps we could get a pull request? I would be happy to merge it. I bet its just some stupid casting thing, or a number is off by a factor of two. |
Thanks for looking at this, rtl_fm -d 0 -M wbfm -f 88.5M | sox -r 32k -t raw -e s -b 16 -c 1 - -d This line runs and seems to think it is playing, but I hear (and see) only silence: Here is the complete output of the rx_fm session which shows no error messages I can discern until I press ^C to terminate the session: pi@PiB83:~/wsprdaemon $ rx_fm -d 0 -M wbfm -f 88.5M | sox -r 32k -t raw -e s -b 16 -c 1 - -d -: (raw) Encoding: Signed PCM In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 Found Rafael Micro R820T tuner User cancel, exiting... |
I dont see the difference between these commands, why does one work and one is silent? If this is an issue with the audio player, can you test with a audio wave capture that works? |
I am trying to run on a Raspberry Pi 3b with vanilla Raspbian Stretch OS: pi@PiB83: The difference is the first command runs 'rtl_fm' and feeds its raw output to sox which plays it fine on my speakers. I have tried writing the output of rx_fm to wav file and playing that wav file with sox and other utilities. All of them report that rx_fm created a valid wav file at the rate and format I specified, but all of them report only silent audio in that file. |
Ahh, I missed the rx vs rtl, I was thinking different arguments. So one thing that bothers me about rx_fm is this line:
https://github.com/keenerd/rtl-sdr/blob/master/src/rtl_fm.c#L984
The rtl one is just converting from its 8-bit format to signed 16 bit, but the RX tools one should not need to do this, and it appears to be throwing out a lot of precision with the big divide. Thats a divide by 255, so if the rtl samples were 8 bit, and were not scaled up to msb, this would entirely throw them out. Can you try and change this line to just copy the samples without scale into |
thanks so much! |
Thanks GoQ for looking into this. And thanks rrobinett for the hardware suggestion-I should receive one this week. Unlike rrobinett, I get plenty of audio output, its just seems to be the wrong frequency--or mangled in some fashion suggesting this. I'm also on RPi-3 and using the SDRPlay image (0.5) as the base system. RPi native sound is not that great, so i'm using a USB audio dongle. My attempts to coax rx_fm onto the right frequency have been inadequate. I experimented with the scaling patch mentioned above--this actually helped noticeably! That GoQ is able to make this work fairly well on Debian (x86?) with Sox/play is trying to tell us something. I will see if I can duplicate that configuration. BTW, if having another code reviewer would help at some point, I have decades of C language experience. (Unfortunately, my modulation theory is decades rusty.) |
Thanks GoQ. ++++++++++++++ pi@Wsprdaemon-Pi:~/rx_tools/src $ diff rtl_fm.c save/
|
rrobinett's code reviewer wrote a multi-page PDF outlining the GNU Radio approach: |
|
I'm having difficulty tuning in (any) strong local broadcast FM station using rx_fm (rx_tools f562c5d) and an SDRplay RSP2. The audio is somewhat copyable, but sounds like its just off freq. with a bit of a background whistle. Have tried fiddling with various parameters with little success. The station comes in very clear in CubicSDR using this same hardware. Possibly I'm missing some critical parameter? The trace below indicates it is tuning to 91.371M when the command line argument specifies 91.1M, which is perplexing. ("Tuned to 91371000 Hz."). Suggestions?
The text was updated successfully, but these errors were encountered: