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