[Discuss-gnuradio] Alternative to gr-osmosdr for HackRF source/sink blocks?
Hi, I'm trying to get my HackRF to do burst transmission. As I understand, this isn't possible in gr 3.7, but is possible in 3.8+. However, I've been using gr-osmosdr blocks for the HackRF source/sink, and that isn't compatible with gr 3.8+ yet. Are there any alternatives out there that are compatible with the HackRF AND gnuradio 3.8? Thanks! -- Eamon Heaney *Fleet Commander* *President, Model UN at Virginia Tech*
problems about Installing multiple versions of gnuradio
I want to install two versions of gnuradio on one machine. I first installed gnuradio 3.7 in default directory /usr/local/（and it works normally）, and then installed the gnuradio 3.9 in the directory /opt/gnuradio. But the gnuradio 3.7 can't run again,as follows: $ gnuradio-companion Traceback (most recent call last): File "/usr/local/bin/gnuradio-companion", line 99, in run_main() File "/usr/local/bin/gnuradio-companion", line 92, in run_main exit(main()) File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/main.py", line 51, in main install_prefix=gr.prefix() File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Platform.py", line 38, in init _Platform.init(self, *args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/core/Platform.py", line 75, in init self.build_block_library() File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/core/Platform.py", line 175, in build_block_library hide_bokeh_gui_options_if_not_installed(self.blocks['options']) File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/core/utils/odict.py", line 35, in getitem return self._data[key] KeyError: 'options' what can i do?? when i run gnuradio 3.9 in the directory /opt/gnuradio/bin as follows, it runs: $export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gnuradio/lib $export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/gnuradio/lib/pkgconfig $export PYTHONPATH=$PYTHONPATH:/opt/gnuradio/lib/python3.6/dist-packages $cd /opt/gnuradio/bin $ ./gnuradio-companion <<< Welcome to GNU Radio Companion 3.9.0.0-git >>> Block paths: /opt/gnuradio/share/gnuradio/grc/blocks
Re: [Discuss-gnuradio] Alternative to gr-osmosdr for HackRF source/sink blocks?
Hi, try gr-soapy ( https://gitlab.com/librespacefoundation/gr-soapy/tree/maint-3.8 ) :) The maint-3.8 branch is gnuradio 3.8-compatible Cheers On Thu, Nov 14, 2019 at 10:00 AM Eamon Heaney wrote: > Hi, > > I'm trying to get my HackRF to do burst transmission. As I understand, > this isn't possible in gr 3.7, but is possible in 3.8+. > > However, I've been using gr-osmosdr blocks for the HackRF source/sink, and > that isn't compatible with gr 3.8+ yet. Are there any alternatives out > there that are compatible with the HackRF AND gnuradio 3.8? > > Thanks! > > -- > Eamon Heaney > *Fleet Commander* > *President, Model UN at Virginia Tech* >
Re: problems about Installing multiple versions of gnuradio
You probably have conflicting configuration about paths in ~/.gnuradio; hard to say, actually. Generally, when installing in separate prefixes, it's no good idea to have both prefixes in LD_LIBRARY_PATH etc at the same time - for any given process, only one should be in there. That's no technical challenge, though, since environment variables are always just inherented from the spawning parent process. Best regards, Marcus On Thu, 2019-11-14 at 17:16 +0800, mangrove_forest wrote: > I want to install two versions of gnuradio on one machine. I first installed > gnuradio 3.7 in default directory /usr/local/（and it works normally）, and > then installed the gnuradio 3.9 in the directory /opt/gnuradio. But the > gnuradio 3.7 can't run again,as follows: > $ gnuradio-companion > Traceback (most recent call last): > File "/usr/local/bin/gnuradio-companion", line 99, in > run_main() > File "/usr/local/bin/gnuradio-companion", line 92, in run_main > exit(main()) > File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/main.py", line 51, > in main > install_prefix=gr.prefix() > File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Platform.py", > line 38, in init > _Platform.init(self, *args, **kwargs) > File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/core/Platform.py", > line 75, in init > self.build_block_library() > File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/core/Platform.py", > line 175, in build_block_library > hide_bokeh_gui_options_if_not_installed(self.blocks['options']) > File > "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/core/utils/odict.py", > line 35, in getitem > return self._data[key] > KeyError: 'options' > what can i do?? > > > when i run gnuradio 3.9 in the directory /opt/gnuradio/bin as follows, it > runs: > $export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gnuradio/lib > $export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/gnuradio/lib/pkgconfig > $export PYTHONPATH=$PYTHONPATH:/opt/gnuradio/lib/python3.6/dist-packages > $cd /opt/gnuradio/bin > $ ./gnuradio-companion > <<< Welcome to GNU Radio Companion 3.9.0.0-git >>> > Block paths: > /opt/gnuradio/share/gnuradio/grc/blocks smime.p7s Description: S/MIME cryptographic signature
Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation
Hi Glen, first of all: This email nearly eluded my attention – you replied to a completely different topic, and that means email clients will sort your mail under the "Simulated Time?" thread. Simply don't reply to emails if you don't mean to actually reply. Then: The SDRPlay block isn't part of GNU Radio itself – it comes from somewhere else, and I must admit I don't know from where. You'll probably have to download the SDRPlay driver package and look inside. Problem with the SDRPlay driver is: It's closed source, and as such, they can't link software against GNU Radio (which is GPL), and then distribute it. If someone could reverse engineer that and write a GPL- compatible driver (and integrate it with soapy or with gr-osmosdr), that'd be very cool. Best regards, Marcus On Wed, 2019-11-13 at 20:19 -0500, Glen Langston wrote: > Hello all, > > This email is a request for documentation on SDRPlay Source block in > Gnuradio companion. > > I have been testing our Radio Astronomy Spectrometer and Event > detection with the SDRPlay RSP1A. It seems to be working pretty > well, using the downloaded OS for Pi from SDRPlay. They seem to have > put a pretty complete version of 3.7.13.4. > > Swig and boost are installed and it was fairly easy to build the C++ code in > git clone http://www.github.com/WVURAIL/gr-radio_astro > > I did update a few items, including VNC and SSH configuration, but > mostly it worked out of the box. I started with a Pi 3B+ but did > have some trouble running out of memory, so switched to a PI 4B (4 GB) > and the complied > code ran well. > > Attached is a screen capture of the design, the inputs to the > SDRSource and the operating design. I seem many lines in the > frequency range 1416.5 to 1423.5 MHz and I'm wondering if I have the > wrong band pass filter selected. But I the SDRPlay source block > inputs don't well match the hardware layout (so far as I can figure > out). (The capture has the wrong frequency label, it should be GHz > not MHz). > > I've goggled everywhere but have had no luck finding any document on > the sdrplay source block in gnuradio companion. Any suggestions? > > Thanks > Glen smime.p7s Description: S/MIME cryptographic signature
Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation
Thanks Marcus, Concerning your points, I thought I’d edited the Subject line to start a new thread. I’ll be more careful in the future. Also thanks for your clarification of the source code origin. I’ve also directly contacted the folks at SDRPlay. I do think the SDRPlay folks do want to be more closely integrated with the Gnuradio folks, as they are partially integrated into the OsmoSdr releases. I’m a little vague on the relationship between OsmoSdr.org and Gnuradio. Maybe the relationship is “parallel play”. Thanks again, Glen > On Nov 14, 2019, at 9:11 AM, Müller, Marcus (CEL) wrote: > > Hi Glen, > > first of all: This email nearly eluded my attention – you replied to a > completely different topic, and that means email clients will sort your > mail under the "Simulated Time?" thread. Simply don't reply to emails > if you don't mean to actually reply. > > Then: The SDRPlay block isn't part of GNU Radio itself – it comes from > somewhere else, and I must admit I don't know from where. You'll > probably have to download the SDRPlay driver package and look inside. > > Problem with the SDRPlay driver is: It's closed source, and as such, > they can't link software against GNU Radio (which is GPL), and then > distribute it. If someone could reverse engineer that and write a GPL- > compatible driver (and integrate it with soapy or with gr-osmosdr), > that'd be very cool. > > Best regards, > Marcus > > On Wed, 2019-11-13 at 20:19 -0500, Glen Langston wrote: >> Hello all, >> >> This email is a request for documentation on SDRPlay Source block in >> Gnuradio companion. >> >> I have been testing our Radio Astronomy Spectrometer and Event >> detection with the SDRPlay RSP1A. It seems to be working pretty >> well, using the downloaded OS for Pi from SDRPlay. They seem to have >> put a pretty complete version of 3.7.13.4. >> >> Swig and boost are installed and it was fairly easy to build the C++ code in >> git clone http://www.github.com/WVURAIL/gr-radio_astro >> >> I did update a few items, including VNC and SSH configuration, but >> mostly it worked out of the box. I started with a Pi 3B+ but did >> have some trouble running out of memory, so switched to a PI 4B (4 GB) >> and the complied >> code ran well. >> >> Attached is a screen capture of the design, the inputs to the >> SDRSource and the operating design. I seem many lines in the >> frequency range 1416.5 to 1423.5 MHz and I'm wondering if I have the >> wrong band pass filter selected. But I the SDRPlay source block >> inputs don't well match the hardware layout (so far as I can figure >> out). (The capture has the wrong frequency label, it should be GHz >> not MHz). >> >> I've goggled everywhere but have had no luck finding any document on >> the sdrplay source block in gnuradio companion. Any suggestions? >> >> Thanks >> Glen
Going from GUI to non-GUI operation.
This email is a question concerning the Gnuradio transition from a GUI interface to purely python execution. We’ve developed a series of gnuradio-companion compatible designs that are "just about" perfected from our point of view. Now we’re going from interactive mode to fully automatic startup and execution from computer reboot. Our designs now immediately start capturing radio astronomy spectra and transient events. Is there a simple mechanism to turn off and on the GUI interface? Maybe just in the control block? Sorry if this is an obvious question. Thanks - Glen
Re: Going from GUI to non-GUI operation.
Hi Glen, In the top right corner of the flow you will see the flow properties box. In there you can disable the GUI. You can then run your python file directly, or even call the created class object from another file (have a look inside the main function to see how the flow is instantiated). You can also get and set variable values in runtime via Python and have the flow update, just like you can with the GUI. On 14 Nov 2019 Thu at 5:28 PM Glen I Langston wrote: > This email is a question concerning the Gnuradio transition from > a GUI interface to purely python execution. > > We’ve developed a series of gnuradio-companion compatible designs > that are "just about" perfected from our point of view. Now we’re going > from interactive mode to fully automatic startup and execution from > computer reboot. > > Our designs now immediately start capturing radio astronomy spectra > and transient events. > > Is there a simple mechanism to turn off and on the GUI interface? Maybe > just in the control block? > > Sorry if this is an obvious question. > > Thanks - Glen > > >
Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation
Hi Glen, On Thu, 2019-11-14 at 09:22 -0500, Glen I Langston wrote: > Thanks Marcus, > > Concerning your points, I thought I’d edited the Subject line to > start a new thread. I’ll be more careful in the future. > no worries – just the danger of hiding your own threads! > Also thanks for your clarification of the source code origin. I’ve also > directly contacted the folks at SDRPlay. > > I do think the SDRPlay folks do want to be more closely integrated > with the Gnuradio folks, as they are partially integrated into > the OsmoSdr releases. We'd love to, but the licensing is pretty clear on that: can't distribute compiled code that links against GNU Radio if you're closed source. > I’m a little vague on the relationship > between OsmoSdr.org and Gnuradio. You mean the osmocom project; they are cool folks that do way more than just gr-osmosdr; from experimentation hardware over software implementations of fully standards-compliant base stations to cellular backbone infrastructure. BBS / modem servers and much more! Check out their projects! https://osmocom.org/projects/ I think you specifically might enjoy their work on Thuraja http://media.ccc.de/browse/congress/2011/28c3-4688-en-introducing_osmo_gmr.html I'd say, osmocom is in the business of making as much as possible of the modern communication stack free to use and inspect. > Maybe the relationship is > “parallel play”. There's a personal overlap between GNU Radio contributors and osmocom contributors! Also, I respect hell out of them and enjoy hanging around with 'em, so there's that. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: Going from GUI to non-GUI operation.
Hi Amr, Thanks for your suggestion. However when I select no-gui, then all the QT blocks go RED in my designs in gnuradio-companion. I was hoping that they would instead just go quiet and use the default values. I can, of course, just delete all the QT blocks, but then when going back to debugging/improving I’d have to put them back in. My hope is not yet implemented, it appears. Best regards, Glen > On Nov 14, 2019, at 9:53 AM, Amr Bekhit wrote: > > Hi Glen, > > In the top right corner of the flow you will see the flow properties box. In > there you can disable the GUI. You can then run your python file directly, or > even call the created class object from another file (have a look inside the > main function to see how the flow is instantiated). You can also get and set > variable values in runtime via Python and have the flow update, just like you > can with the GUI. > > On 14 Nov 2019 Thu at 5:28 PM Glen I Langston > wrote: > This email is a question concerning the Gnuradio transition from > a GUI interface to purely python execution. > > We’ve developed a series of gnuradio-companion compatible designs > that are "just about" perfected from our point of view. Now we’re going > from interactive mode to fully automatic startup and execution from > computer reboot. > > Our designs now immediately start capturing radio astronomy spectra > and transient events. > > Is there a simple mechanism to turn off and on the GUI interface? Maybe > just in the control block? > > Sorry if this is an obvious question. > > Thanks - Glen > >
Re: Going from GUI to non-GUI operation.
Hi Glen, On Thu, 2019-11-14 at 11:52 -0500, Glen I Langston wrote: > Hi Amr, > > Thanks for your suggestion. > > However when I select no-gui, then all the QT blocks go RED in my designs in > gnuradio-companion. > > I was hoping that they would instead just go quiet and use the default values. That would be relatively hard to do in the general case, since QT blocks also include sliders, variable entry boxes etc. > > I can, of course, just delete all the QT blocks, but then when going back > to debugging/improving I’d have to put them back in. You'll be delighted to find the "disable" function: rightclick -> disable, or just selecting a block and pressing "D". Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: Going from GUI to non-GUI operation.
It's a bit wasteful from a CPU cycles standpoint, but you can run your flowgraph unchanged from the command line using xvfb, and no graphical output will be displayed. Nick On Thu, Nov 14, 2019, 8:53 AM Glen I Langston wrote: > Hi Amr, > > Thanks for your suggestion. > > However when I select no-gui, then all the QT blocks go RED in my designs > in gnuradio-companion. > > I was hoping that they would instead just go quiet and use the default > values. > > I can, of course, just delete all the QT blocks, but then when going back > to debugging/improving I’d have to put them back in. > > My hope is not yet implemented, it appears. > > Best regards, > > Glen > > > > > On Nov 14, 2019, at 9:53 AM, Amr Bekhit wrote: > > > > Hi Glen, > > > > In the top right corner of the flow you will see the flow properties > box. In there you can disable the GUI. You can then run your python file > directly, or even call the created class object from another file (have a > look inside the main function to see how the flow is instantiated). You can > also get and set variable values in runtime via Python and have the flow > update, just like you can with the GUI. > > > > On 14 Nov 2019 Thu at 5:28 PM Glen I Langston > wrote: > > This email is a question concerning the Gnuradio transition from > > a GUI interface to purely python execution. > > > > We’ve developed a series of gnuradio-companion compatible designs > > that are "just about" perfected from our point of view. Now we’re going > > from interactive mode to fully automatic startup and execution from > > computer reboot. > > > > Our designs now immediately start capturing radio astronomy spectra > > and transient events. > > > > Is there a simple mechanism to turn off and on the GUI interface? Maybe > > just in the control block? > > > > Sorry if this is an obvious question. > > > > Thanks - Glen > > > > > > >
Re: Going from GUI to non-GUI operation.
On 11/14/2019 11:52 AM, Glen I Langston wrote: Hi Amr, Thanks for your suggestion. However when I select no-gui, then all the QT blocks go RED in my designs in gnuradio-companion. I was hoping that they would instead just go quiet and use the default values. I can, of course, just delete all the QT blocks, but then when going back to debugging/improving I’d have to put them back in. My hope is not yet implemented, it appears. Best regards, Glen There is a "disable" function in GRC -- so the scaffolding for the block is there, but not actually enabled in code generation. Unfortunately, there's no GRC-way to do this at runtime. On Nov 14, 2019, at 9:53 AM, Amr Bekhit wrote: Hi Glen, In the top right corner of the flow you will see the flow properties box. In there you can disable the GUI. You can then run your python file directly, or even call the created class object from another file (have a look inside the main function to see how the flow is instantiated). You can also get and set variable values in runtime via Python and have the flow update, just like you can with the GUI. On 14 Nov 2019 Thu at 5:28 PM Glen I Langston wrote: This email is a question concerning the Gnuradio transition from a GUI interface to purely python execution. We’ve developed a series of gnuradio-companion compatible designs that are "just about" perfected from our point of view. Now we’re going from interactive mode to fully automatic startup and execution from computer reboot. Our designs now immediately start capturing radio astronomy spectra and transient events. Is there a simple mechanism to turn off and on the GUI interface? Maybe just in the control block? Sorry if this is an obvious question. Thanks - Glen
Re: Going from GUI to non-GUI operation.
Hi Glen, One other possible approach could be to separate your processing flowgraph from the display/GUI flowgraph. This could be done with a combo of ZMQ blocks, the Parameter block and XMLRPC blocks. Depending on your data rates, this might not work so great and is a bit wasteful of CPU cycles. On Thu, Nov 14, 2019 at 10:35 AM Marcus D. Leech wrote: > On 11/14/2019 11:52 AM, Glen I Langston wrote: > > Hi Amr, > > > > Thanks for your suggestion. > > > > However when I select no-gui, then all the QT blocks go RED in my > designs in gnuradio-companion. > > > > I was hoping that they would instead just go quiet and use the default > values. > > > > I can, of course, just delete all the QT blocks, but then when going back > > to debugging/improving I’d have to put them back in. > > > > My hope is not yet implemented, it appears. > > > > Best regards, > > > > Glen > > > There is a "disable" function in GRC -- so the scaffolding for the block > is there, but not actually enabled in code generation. > > Unfortunately, there's no GRC-way to do this at runtime. > > > > >> On Nov 14, 2019, at 9:53 AM, Amr Bekhit wrote: > >> > >> Hi Glen, > >> > >> In the top right corner of the flow you will see the flow properties > box. In there you can disable the GUI. You can then run your python file > directly, or even call the created class object from another file (have a > look inside the main function to see how the flow is instantiated). You can > also get and set variable values in runtime via Python and have the flow > update, just like you can with the GUI. > >> > >> On 14 Nov 2019 Thu at 5:28 PM Glen I Langston < > glen.i.langs...@gmail.com> wrote: > >> This email is a question concerning the Gnuradio transition from > >> a GUI interface to purely python execution. > >> > >> We’ve developed a series of gnuradio-companion compatible designs > >> that are "just about" perfected from our point of view. Now we’re > going > >> from interactive mode to fully automatic startup and execution from > >> computer reboot. > >> > >> Our designs now immediately start capturing radio astronomy spectra > >> and transient events. > >> > >> Is there a simple mechanism to turn off and on the GUI interface? Maybe > >> just in the control block? > >> > >> Sorry if this is an obvious question. > >> > >> Thanks - Glen > >> > >> > > > > > process.grc Description: Binary data display.grc Description: Binary data
Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation
On Thu, 14 Nov 2019 14:11:22 + Müller, Marcus (CEL) wrote: > Hi Glen, > > first of all: This email nearly eluded my attention – you replied to a > completely different topic, and that means email clients will sort your > mail under the "Simulated Time?" thread. Simply don't reply to emails > if you don't mean to actually reply. > > Then: The SDRPlay block isn't part of GNU Radio itself – it comes from > somewhere else, and I must admit I don't know from where. You'll > probably have to download the SDRPlay driver package and look inside. > > Problem with the SDRPlay driver is: It's closed source, and as such, > they can't link software against GNU Radio (which is GPL), and then > distribute it. If someone could reverse engineer that and write a GPL- > compatible driver (and integrate it with soapy or with gr-osmosdr), > that'd be very cool. The original poster can get some information from installing soapy and doing 'SoapySDRUtil --probe'. But I wonder what gnuradio block the original poster is using with the proprietary driver? I couldn't make it out from the image he posted. I only know of three: (i) gr-osmosdr's built-in support for sdrplay, (ii) gr-osmosdr's built-in support for soapy and so for the soapy-sdrplay plugin, and (iii) gr-soapy's support for soapy and so also for the soapy-sdrplay plugin. If there is a fourth I would be interested to know what it is. The first doesn't work that well for me with the current proprietary driver whereas the last two work fine (for me on x86/64). In any event, with reference to the original poster's comments about selecting the wrong band pass filter, RSP1A only supports certain bandpass filtering widths. These can be examined with the soapy probe above. Generally you want the bandwidth to be somewhat less than the sample rate (soapy's probe will also tell you what sample rates are available).
Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation
On Thu, 14 Nov 2019 19:35:13 + Chris Vine wrote: > The original poster can get some information from installing soapy and > doing 'SoapySDRUtil --probe'. I should probably have appended what the probe tells me about my RSP1A, which may or may not apply to his: -- Device identification driver=SDRplay hardware=RSP1A mir_sdr_api_version=2.13 mir_sdr_hw_version=255 serial=xxx -- Peripheral summary Channels: 1 Rx, 0 Tx Timestamps: NO Other Settings: * RF Gain Select - RF Gain Select [key=rfgain_sel, default=4, type=string, options=(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)] * IF Mode - IF frequency in kHz [key=if_mode, default=Zero-IF, type=string, options=(Zero-IF, 450kHz, 1620kHz, 2048kHz)] * IQ Correction - IQ Correction Control [key=iqcorr_ctrl, default=true, type=bool] * AGC Setpoint - AGC Setpoint (dBfs) [key=agc_setpoint, default=-30, type=int, range=[-60, 0]] * BiasT Enable - BiasT Control [key=biasT_ctrl, default=true, type=bool] * RfNotch Enable - RF Notch Filter Control [key=rfnotch_ctrl, default=true, type=bool] * DabNotch Enable - DAB Notch Filter Control [key=dabnotch_ctrl, default=true, type=bool] -- RX Channel 0 Full-duplex: NO Supports AGC: YES Stream formats: CS16, CF32 Native format: CS16 [full-scale=32767] Antennas: RX Corrections: DC removal Full gain range: [0, 48] dB IFGR gain range: [20, 59] dB RFGR gain range: [0, 9] dB Full freq range: [0.01, 2000] MHz RF freq range: [0.01, 2000] MHz CORR freq range: MHz Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz
creating a 57 KHz signal from 19 KHz reference
Hi all,
I'm again experimenting with GNUradio, now with a flowgraph I found
("rds_rx") to demodulate FM/RDS.
One facts about FM/RDS:
After demodulation a FM broadcasting signal, the signal contains
multiple sub-signals, (among others) a 19 KHz 'stereo pilot' and a PSK
(RDS) signal at 57 KHz.
57 KHz is three times 19 KHz.
Question:
I am trying to find a way to use the 19 KHz stereo-pilot signal to
create a 57 KHz carrier (to down-convert the FM/RDS carrier at 57 KHz).
How do I do this?
I tried using a PLL carrier-tracking block to extract the 19 KHz carrier
(which seams to work) and direct that carrier to a 3 input multiplier
block, but that does not seams to work.
Even after filtering out DC and the carrier at -19 KHz (negative
frequency), the output of the multiplier is always zero. (*)
Or is there a better way to generate a 57 KHz complex sine-wave from a
19 KHz reference signal?
(*)
When I just connect the output of a signal-source block (that contains a
19 KHz complex-number signal) and connect this to all ports of a 3-input
multiplier, I do get a carrier at 57 KHz.
So I am puzzled why this seams to work, but using the same technique to
multiply the output of a PLL carrier-tracking block does not result in
anything useful.
Cheerio! Kr, Bonne,
