Hi Joshua,
have you tried your experiment with a powered USB hub? I've found a number
of times that a powered hub can solve mystery problems with USB devices.
Cheers!
-Justin N2TOH
---------- Forwarded message ----------
From: DC7IA <mailinglists(a)dc7ia.eu>
To: osmocom-sdr(a)lists.osmocom.org
Cc:
Bcc:
Date: Thu, 26 Apr 2018 19:56:01 +0200
Subject: [osmo-fl2k] can't receive anything
Hi there,
I've set up osmo-fl2k yesterday and since then I'm trying to get WBFM or
GSM working, but I cannot receive anything.
Software does not give me any errors, so I don't know where to look for the
problem.
Maybe I should note that I'm only able to use USB 2.0 on my Thinkpad T400,
could that make trouble as it is a USB 3.0 device?
--
*73 Joshua Hoffmann DC7IA | KK4RVI *
stellv. AJW-Referent im Distrikt O
(Süd-Westfalen) AJW-Seite des Distriktes
<http://www.darc.de/distrikte/o/referate/ajw/>
Diese E-Mailadresse ist ausschließlich für Mailinglisten E-Mails. Normale
E-Mails an DC7IA(a)DARC.de senden, da sie andernfalls nicht rechtzeitig
gelesen werden.
--
--Evil people do evil things, how is irrelevant.
Hi there,
I've set up osmo-fl2k yesterday and since then I'm trying to get WBFM or
GSM working, but I cannot receive anything.
Software does not give me any errors, so I don't know where to look for
the problem.
Maybe I should note that I'm only able to use USB 2.0 on my Thinkpad
T400, could that make trouble as it is a USB 3.0 device?
--
*73 Joshua Hoffmann DC7IA | KK4RVI *
stellv. AJW-Referent im Distrikt O
(Süd-Westfalen) AJW-Seite des Distriktes
<http://www.darc.de/distrikte/o/referate/ajw/>
Diese E-Mailadresse ist ausschließlich für Mailinglisten E-Mails.
Normale E-Mails an DC7IA(a)DARC.de senden, da sie andernfalls nicht
rechtzeitig gelesen werden.
can the USB to VGA adapter output quadrature I and Q pairs via the red and
blue channels? with maybe using green as a configurable local oscillator.
-Justin
--
--Evil people do evil things, how is irrelevant.
I am trying to understand the layout of the RGB buffers sent to the fl2k
over USB. From lines 755-820 in libosmo-fl2k.c I can see the RGB buffers
are "serialized" in this order:
g1,r1,b2,g2,b0,g0,r0,b1,b4,g4,r4,b5,r2,b3,g3,r3,r6,b7,g7,r7,g5,r5,b6,g6
(where r0 is the red component of first pixel, b3 is the blue component of
fourth pixel, etc)
What is this layout? Why does the chip expect the pixels to be sent in this
order?
Hi,
At first I reported this bug at Gqrx mailing list:
https://groups.google.com/forum/#!topic/gqrx/pVea3JObMLw , then Csete
mentioned that Gqrx uses gr-osmosdr source, while I'm using gr-uhd
source. Then I tried it again using osmocom source, then that weird
center frequency noise appears again.
I've attached several screenshots and GRC flowchart that I used to
reproduce this bug (it uses gr-fosphor). Maedhros_008.png is the
screenshot of gr-fosphor displaying the correct UHD: USRP source, with
all of FM broadcast radio visible, while Maedhros_011.png is the
gr-fosphor showing the output of osmocom source, with this big ~2MHz
spike at center frequency, and all of those FM broadcast radio are not
visible.
I'm using Arch Linux with gnuradio, gr-fosphor, and gr-osmosdr
compiled from source using makepkg/pkgbuild system, and libuhd
3.10.2.0-3
Hi,
A QT API change in Gnuradio 3.17.12.0 :
https://github.com/gnuradio/gnuradio/pull/1418 breaks modules that
relies on QT windowing system, resulting in Template error on
generated python file, resulting in this error when I try to run the
generated python file:
Executing: /usr/sbin/python2 -u /home/feanor/Development/SDR/top_block.py
File "/home/feanor/Development/SDR/top_block.py", line 69
self.fosphor_qt_sink_c_2 = Template error: #set $win = 'self._%s_win'%$id
^
SyntaxError: invalid syntax
>>> Done (return code 1)
This also affects other modules that relies on QT:
gr-inspector: https://github.com/gnuradio/gr-inspector/issues/2
Following the fix in this pull request for gr-inspector:
https://github.com/gnuradio/gr-inspector/pull/21/commits/9d00bb83c155c84ee8…
by changing a line:
15c15
< $(gui_hint()($win))</make>
---
> $(gui_hint() % $win)</make>
fixes the problem for gr-fosphor and make the flowgraph runnable again
All,
I installed GNU Radio for windows on my machine running Windows 10.when I try to run GRC it comes back with:
<<< Welcome to GNU Radio Companion 3.7.11.1 >>>
Block paths: C:\Program Files\GNURadio-3.7\share\gnuradio\grc\blocks
Loading: "C:\Users\JoseM\Documents\GNU\test w grc.grc">>> Done
Generating: 'C:\\Users\\JoseM\\Documents\\GNU\\top_block.py'
Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u C:\Users\JoseM\Documents\GNU\top_block.py
Win32; Microsoft Visual C++ version 14.0; Boost_106000; UHD_003.010.001.001-0-unknown
gr-osmosdr c653754d (0.1.5git) gnuradio 3.7.11.1built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf airspy redpitaya Using device #0 Generic RTL2832U OEMusb_open error -12
FATAL: Failed to open rtlsdr device.
Trying to fill up 1 missing channel(s) with null source(s).This is being done to prevent the application from crashingdue to gnuradio bug #528.
Anybody have any idea how to fix this ?Thanks,
Jose
Hi Theodric,
no, these values that appear on stdout are already audio samples (PCM
to be specific).
That is the "job" of rtl_fm:
It takes the complex time-domain baseband samples from the hardware,
detects FM (which implies detecting a frequency deviation) and convert
that to audio amplitude values.
The `aplay` command barely takes these samples and hands them over to
the sound card (after resampling to fit possible sampling rates, I
guess, as 120 kHz isn't something that sound systems usually operate
at).
The `rtl_fm` command takes a couple of parameters. In your case, `-M
wbfm` means that it's demodulating FM in a way compatible to broadcast
FM; that implies fixed parameters for deviation, emphasis etc.
What you want is really not `rtl_fm`, which primarily is a demo
program, not meant to be a flexible do-it-all solution.
What you want, showing deviation of a station, does very much sound
like a spectrum visualization. Wouldn't a waterfall or even just an
instantaneous spectrum visualization be what you want?
Best regards,
Marcus
On Wed, 2018-03-14 at 15:57 -0400, Theodric Young wrote:
> Hi,
>
> I'm new to SDR and I have a question about the data values that are
> generated by the rtl_fm program.
>
> I got rtl_fm running on my system (cygwin running on Windows 7). It is
> sending a stream of 16-bit signed integer values to stdout which I can
> redirect to a file or pipe to an audio playback system, such as sox. So
> when I do this:
>
> rtl_fm -f 88.1M -M wbfm -s 240k -r120k -g 30 | play -t raw -r 120k -b
> 16 -c 1 -e s -V1 -
>
> I hear sweet, sweet music! Hurray!
>
> But how do these 16-bit integers relate to the modulation level of the
> carrier? I'm assuming that the values are directly proportional to the
> instantaneous frequency deviation of the transmitted signal. Is that
> right? If so, how do I determine that ratio? I'm hoping to use this to
> build a device that shows total modulation (as a percentage of the
> maximum modulation of +/- 75kHz) for an FM radio station.
>
> Also, I'm assuming that the sample-rate of the output data stream needs
> to be at least 120kHz because the baseband signal includes the stereo
> pilot (19kHz), the stereo subcarrier (38kHz) and an RBDS subcarrier (57
> kHz).
>
> Any insight would be appreciated. Thanks in advance,
>
> Theodric Young