In the recent project activity, I see what seems to be support for SoapySDR and SDRplay.
I cannot find anything in the dream -h help or on the discussion topics.
Is this true? How can it be used?
I managed to compile r1373 on my Raspberry Pi 4 Debian Buster system, but it crashes when decoding starts.
See the discussion "Dream crashes when decoding starts" the problem was solved by a branch that uses the libfdk-aac codec.
In addition, with the current hamlib release, I was not able to successfully compile Dream until I patched the source files as specified in the discussion: https://sourceforge.net/p/drm/discussion/compiling/thread/e2393d26d0/
I'm able to use an Airspy HF+ Discovery using Gqrx as the receiver software and configuring the audio output to VB-Cable. Then I tell Dream to use VB-Cable as the audio input, with the output going to the standard output.
To tune, you set the mode to USB with the bandwidth to a little over 10KHz, detuning by a little more than -5kHz so the entire signal fits inside.
Not sure if this exactly helps your R-Pi configuration. Gqrx can be built for Linux. Just not sure what you'd use for piping the audio in lieu of VB-Cable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do use gqrx with a virtual audio cable and I tune it like you describe.
My main point is that SoapySDR software changes in reference to Dream implies that it can use an SDR as its input, eliminating the separate receiver and virtual audio cable. I am curious as to why they are talking about SDR interfaces in reference to an application that doesn't support them. I think that would be a nice feature.
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd have to see the reference of course, but perhaps they're talking about using the hamlib interface to tune it, and that the driver has made the SDR's output compatible with portaudio (or whatever that new thing is they're using now)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your interest in my branch. I am indeed in the process of adding native SoapySDR support to Dream, but it's work in progress and certain things are hard-coded for the particular setup I have (Raspberry Pi OS, RSP1A) , and there's a horrible kludge in the way Soapy is selected as a SoundIn device. I hope to improve this whole area soon but I have a few other things to do first.
I'm pleased that this work appears to be of interest to others and will endeavour to keep you posted on my progress. Similarly your feedback will be helpful in getting the code to work more widely.
Let's keep using this thread for discussion.
73, Ollie.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I finally found how to download your branch. I am new to the sourceforge system.
this is from an email that I sent to you. It is an honor to hear from you.
I have a Raspberry Pi 4 running 64 bit DietPi Debian Buster.
I have a SDRplay RSP1A and HackRF running with SoapySDR, etc.
I tried to compile it and it failed:
/usr/local/include/hamlib/riglist.h:646:18: error: conflicting declaration ‘typedef uint32_t rig_model_t’
646 | typedef uint32_t rig_model_t;
After that the compile process went much further, but it failed:
src/creceivedata.cpp: In member function ‘void CReceiveData::Enumerate(std::vector<std::__cxx11::basic_string<char> >&, std::vector<std::__cxx11::basic_string<char> >&, std::string&)’:
src/creceivedata.cpp:109:38: error: invalid new-expression of abstract class type ‘CSoundIn’
109 | if(pSound==nullptr) pSound = new CSoundIn;
| ^~~~~~~~
In file included from src/sound/sound.h:38,
from src/creceivedata.cpp:37:
src/sound/../linux/alsain.h:45:7: note: because the following virtual functions are pure within ‘CSoundIn’:
45 | class CSoundIn : public CSoundInInterface
| ^~~~~~~~</std::__cxx11::basic_string<char></std::__cxx11::basic_string<char>
....and more messages.
Can you tell me what I need to get this to work?
Thanks, Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi I looked at this and I can see what the problem is.
Currently the SoapySDR input only works if you use PulseAudio, whilst your build appears to be using ALSA. In fact if it's configured for PulseAudio, it uses Soapy as the input instead of the PulseAudio input: that's the "horrible kludge" that I referred to!
I'd like to fix this all properly, but if you could use PulseAudio instead of ALSA that would make things easier in the meantime.
Julian knows a lot more about the build system than I do, but I'm guessing you have alsa defined somewhere - possibly in your qmake build step under Build Settings if you're using QT Creator. If you can install PulseAudio, qmake should pick this up automatically. That will stop it from attempting to compile the problematic code so should avoid the compile error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
qmake (or the dream.pro) tries to detect what packages are installed and use them so if you apt-get install pulseaudio-dev (or the right thing if I've remembered that wrongly) it will probably pick pulse.
Generallising out of the hack needs a little thought. Ollie and I will try and make time to at least come up with a direction of travel..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FYI: Fedora is moving to something completely new (PipeWire's audio server) as a replacement to PulseAudio, which should make life interesting for everyone. I reverted back to Pulse for now, because PipeWire broke a lot of things in my Fedora VM, but I'm sure this is an eventual total switchover in the architecture.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to get this branch to compile and run by not specifying ALSA. It did default to pulseaudio
I do have pulseaudio installed.
When I initially ran Dream by typing "dream", it failed because it couldn't find oss, so I used "dream -I pulse -O pulse".
My two SoapySDR devices appear in Settings / Sound Card / Signal Input / device.
When I select either SDR, or an audio file to play, Dream will crash, displaying on the terminal:
Closing device
Segmentation fault
--or--
Closing device
Bus error
SoapySDRUtil --probe="driver=sdrplay" does show that the device is working.
Oddly, the Settings / Sound Card / Audio Output / device lists only ALSA devices although I specified pulse on the command line.
alsa_output.platform-bcm2835_audio.digital-stereo [Built-in Audio Digital Stereo]
alsa_output.platform-bcm2835_audio.analog-stereo [Built-in Audio Analog Stereo]
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I played with the settings and got it to work, but there's a story...
I started Dream with "dream -O pulse"
It opened for a few seconds, then crashed and displayed this:
CSoapySDRIn::SetFrequency(7229000)
can't unsubscribe - no rig set! 0 [INFO] Opening HackRF One #0 17c467dc315234c3...
front end mapping:
setting rfgain_selto0
setting iqcorr_ctrltotrue
setting agc_setpointto-60
setting biasT_ctrltofalse
setting rfnotch_ctrltofalse
setting dabnotch_ctrltofalse
strSDRConfig = bias_tx=false
Activating stream succeeded
Ofront end mapping:
setting bias_txtofalse
strSDRConfig = bias_tx=false
terminate called after throwing an instance of 'std::runtime_error'
what(): RX stream already opened
Aborted
It's like it tried to open both SDRs.
I unplugged the HackRF and tried it again. Now it works!
When a station is received, there is nothing in Shifted PSD.
Waterfall display shows a weak signal that looks like a DRM signal. It displays a value in SNR and the DC frequency.
The other input waveforms do have signal.
Did not get a strong enough signal to decode.
The level indicator shows no signal unless it is an extremely strong local signal.
Is there a provision to specify the SDR gains?
It still crashes when I open an audio file.
Edit:
Upon further investigation, I see that if only the HackRF is connected, it crashes. If only the SDRPlay is connected, it works. The first time, I thought it tried to open both, but it is not doing that now.
It would be nice in the future to see the AM dialogue work with the SDR so I can test the audio, etc. As of now, it only tunes the original audio frequencies. It does seem to be using the SDR now.
----Steve
Last edit: Steven Sostrom 2021-11-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it is working for me. I was able to decode a signal for about 1 second.
It seems that the dream-mjf branch that I normally use with gqrx is more sensitive with the gain set in gqrx. The gain in the SDRplay RSP1 is low with the dream-ollie branch.
It looks like the HackRF crashes Dream.
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the updates Steve and pleased to hear you've had partial success at least!
The gain settings are something I've been playing with. The SDRPlay implementation for SoapySDR doesn't quite conform to the API contract, in particular in that the "gains" it reports are actually gain reductions so operate in the opposite sense. There's discussion here, and you can see that I've been trying out one of the options in Franco's branch. I guess you're using the master branch of SoapySDRPlay.
Either way, if you look in your Dream.ini file you should see a line like this: sdr-config=rfgain_sel=0,iqcorr_ctrl=true,agc_setpoint=-20,biasT_ctrl=false,rfnotch_ctrl=false,dabnotch_ctrl=false
You can simply change rfgain_selto whatever you like. I think "0" should give the maximum gain.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your help.
In my Dream.ini, rfgain_sel was already set to 0.
My agc_setpoint was set to -60. Changing that to -20 as in your example helped.
Will there be a setting for the IFGR or IF gain? Apparently, it is now set to automatic gain.
It seems that there is still a lot to talk about with the gains. If the others had used an attenuation number instead of the gain number, then that would be the norm.
If you need help testing HackRF with your branch, I will help where I can.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@olliehaffenden
I have been experimenting with the r1394 branch of dream-ollie
I have gotten it to work with DRM broadcasts, but I am trying AM, SSB, etc.
When I change the Settings to AM and I tune in a station, I do not get audio.
However, every few minutes, I do hear about 2 seconds of audio. It seems to be correct for those 2 seconds.
Is there a setting I need to change? Could audio configuration cause this?
There isn't a good enough DRM signal to try DRM tonight for a comparison.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't put any attention into AM; in fact I thought it crashed instantly in AM mode, so it's apparently not as bad as I thought! We'd definitely want to get AM working before doing a new release, but I'm afraid I have several other things I need to do first.
Happy new year!
Ollie.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all, as Ollie says, we're really happy for your interest on this work. Just so you know, Ollie has been a major player in DRM from the very start and his team in BBC R&D were responsible for some of the earliest working content servers and receivers. No-one understands the signal processing in DRM the way Ollie does. We're privileged to have him working on a new Dream based DRM monitoring solution and we are doing it in a way which gives the maximum benefit to the whole professional and amateur community.
It seemed to me that SoapySDR is 'the hamlib for SDRs' so we are trying to make a native integration that just works. If anyone wants to generalise Ollie's work for more different SDR variants please post your ideas here. If you can code, we'll make you a branch and give you access.
Julian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't know Ollie's background. That's quite an impressive resume!
Having been mostly out of radio after many years, SDRs are still kind of new to me. My history in DRM monitoring up until this past year has been with a clunky JRC NRD-535D. Have mostly been using an RTL-SDR (original v3) and Airspy HF+ Discovery, both of which have reignited the radio bug. The Airspy is an excellent radio for this kind of work and was looking to eventually adapt nrsc5 (the Ibiquity standard for digital FM in the US) for it as well.
Have mostly looked at gnuradio and not played much in SoapySDR, so I'm quite ignorant of the differences. That, other than gnuradio being a model-driven environment that's difficult for me to get my head around. Calling SoapySDR the hamlib of SDRs gives me the impression that it's a simple uniform control interface, which is fine by me.
I already have a branch and access. Given time I'd like to take a look at Ollie's code and see if I can help in any way. Retirement is another word for lots of time to do lots of things, but still trying to find the time to do it all...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your work are really amazing, I remember when I first heard DRM using
more than a decade ago with some crazy grc scripts to get the 455 kHz IF
from a stock HF radio connected to my USRP to feed the signal to
Dream... fast-forward to today - we can buy very affordable mirics-based
(SDRPlay, AirSpy and others) dongles with very good sensibility and
listen to DRM with Dream! Yay!
Cheers,
Rafael
On 11/22/21 1:47 PM, Julian Cable wrote:
Hi all, as Ollie says, we're really happy for your interest on this
work. Just so you know, Ollie has been a major player in DRM from the
very start and his team in BBC R&D were responsible for some of the
earliest working content servers and receivers. No-one understands the
signal processing in DRM the way Ollie does. We're privileged to have
him working on a new Dream based DRM monitoring solution and we are
doing it in a way which gives the maximum benefit to the whole
professional and amateur community.
It seemed to me that SoapySDR is 'the hamlib for SDRs' so we are trying
to make a native integration that just works. If anyone wants to
generalise Ollie's work for more different SDR variants please post your
ideas here. If you can code, we'll make you a branch and give you access.
In the recent project activity, I see what seems to be support for SoapySDR and SDRplay.
I cannot find anything in the dream -h help or on the discussion topics.
Is this true? How can it be used?
I managed to compile r1373 on my Raspberry Pi 4 Debian Buster system, but it crashes when decoding starts.
See the discussion "Dream crashes when decoding starts" the problem was solved by a branch that uses the libfdk-aac codec.
In addition, with the current hamlib release, I was not able to successfully compile Dream until I patched the source files as specified in the discussion:
https://sourceforge.net/p/drm/discussion/compiling/thread/e2393d26d0/
The changes are detailed here:
https://sourceforge.net/p/drm/discussion/compiling/thread/e2393d26d0/6204/attachment/changes.txt
I'm able to use an Airspy HF+ Discovery using Gqrx as the receiver software and configuring the audio output to VB-Cable. Then I tell Dream to use VB-Cable as the audio input, with the output going to the standard output.
To tune, you set the mode to USB with the bandwidth to a little over 10KHz, detuning by a little more than -5kHz so the entire signal fits inside.
Not sure if this exactly helps your R-Pi configuration. Gqrx can be built for Linux. Just not sure what you'd use for piping the audio in lieu of VB-Cable.
I do use gqrx with a virtual audio cable and I tune it like you describe.
My main point is that SoapySDR software changes in reference to Dream implies that it can use an SDR as its input, eliminating the separate receiver and virtual audio cable. I am curious as to why they are talking about SDR interfaces in reference to an application that doesn't support them. I think that would be a nice feature.
----Steve
I'd have to see the reference of course, but perhaps they're talking about using the hamlib interface to tune it, and that the driver has made the SDR's output compatible with portaudio (or whatever that new thing is they're using now)?
If you select the summary tab on the Dream page, the comments are there under Project Activity. You may have to select See All Activity.
Oliver HaffendenOliver Haffenden committed [r1373]
Load and save settings for SoapySDR
Oliver HaffendenOliver Haffenden committed [r1372]
Temporary fix for SDRPlay gain (should be put back if SDRPlay wrapper for SoapySDR are fixed)
Ham!ib is independent of SoapySDR and the SDR itself. For example, it interfaces with gqrx, which controls the SDR.
There must be something good going on here.
----Steve
Related
Commit: [r1372]
Commit: [r1373]
Very possible that Oliver was working on a candidate capability within his branch. You might want to ask him directly.
Hi all!
Thanks for your interest in my branch. I am indeed in the process of adding native SoapySDR support to Dream, but it's work in progress and certain things are hard-coded for the particular setup I have (Raspberry Pi OS, RSP1A) , and there's a horrible kludge in the way Soapy is selected as a SoundIn device. I hope to improve this whole area soon but I have a few other things to do first.
I'm pleased that this work appears to be of interest to others and will endeavour to keep you posted on my progress. Similarly your feedback will be helpful in getting the code to work more widely.
Let's keep using this thread for discussion.
73, Ollie.
I finally found how to download your branch. I am new to the sourceforge system.
this is from an email that I sent to you. It is an honor to hear from you.
I have a Raspberry Pi 4 running 64 bit DietPi Debian Buster.
I have a SDRplay RSP1A and HackRF running with SoapySDR, etc.
I tried to compile it and it failed:
/usr/local/include/hamlib/riglist.h:646:18: error: conflicting declaration ‘typedef uint32_t rig_model_t’
646 | typedef uint32_t rig_model_t;
I also tried using the patches for hamlib source files as specified in the discussion:
https://sourceforge.net/p/drm/discussion/compiling/thread/e2393d26d0/
Hamlib has apparently changed things in its newer releases.
The changes are detailed here:
https://sourceforge.net/p/drm/discussion/compiling/thread/e2393d26d0/6204/attachment/changes.txt
After that the compile process went much further, but it failed:
src/creceivedata.cpp: In member function ‘void CReceiveData::Enumerate(std::vector<std::__cxx11::basic_string<char> >&, std::vector<std::__cxx11::basic_string<char> >&, std::string&)’:
src/creceivedata.cpp:109:38: error: invalid new-expression of abstract class type ‘CSoundIn’
109 | if(pSound==nullptr) pSound = new CSoundIn;
| ^~~~~~~~
In file included from src/sound/sound.h:38,
from src/creceivedata.cpp:37:
src/sound/../linux/alsain.h:45:7: note: because the following virtual functions are pure within ‘CSoundIn’:
45 | class CSoundIn : public CSoundInInterface
| ^~~~~~~~</std::__cxx11::basic_string<char></std::__cxx11::basic_string<char>
....and more messages.
Can you tell me what I need to get this to work?
Thanks, Steve
Hi I looked at this and I can see what the problem is.
Currently the SoapySDR input only works if you use PulseAudio, whilst your build appears to be using ALSA. In fact if it's configured for PulseAudio, it uses Soapy as the input instead of the PulseAudio input: that's the "horrible kludge" that I referred to!
I'd like to fix this all properly, but if you could use PulseAudio instead of ALSA that would make things easier in the meantime.
Julian knows a lot more about the build system than I do, but I'm guessing you have alsa defined somewhere - possibly in your qmake build step under Build Settings if you're using QT Creator. If you can install PulseAudio, qmake should pick this up automatically. That will stop it from attempting to compile the problematic code so should avoid the compile error.
qmake (or the dream.pro) tries to detect what packages are installed and use them so if you apt-get install pulseaudio-dev (or the right thing if I've remembered that wrongly) it will probably pick pulse.
Generallising out of the hack needs a little thought. Ollie and I will try and make time to at least come up with a direction of travel..
FYI: Fedora is moving to something completely new (PipeWire's audio server) as a replacement to PulseAudio, which should make life interesting for everyone. I reverted back to Pulse for now, because PipeWire broke a lot of things in my Fedora VM, but I'm sure this is an eventual total switchover in the architecture.
I was able to get this branch to compile and run by not specifying ALSA. It did default to pulseaudio
I do have pulseaudio installed.
When I initially ran Dream by typing "dream", it failed because it couldn't find oss, so I used "dream -I pulse -O pulse".
My two SoapySDR devices appear in Settings / Sound Card / Signal Input / device.
When I select either SDR, or an audio file to play, Dream will crash, displaying on the terminal:
Closing device
Segmentation fault
--or--
Closing device
Bus error
SoapySDRUtil --probe="driver=sdrplay" does show that the device is working.
Oddly, the Settings / Sound Card / Audio Output / device lists only ALSA devices although I specified pulse on the command line.
alsa_output.platform-bcm2835_audio.digital-stereo [Built-in Audio Digital Stereo]
alsa_output.platform-bcm2835_audio.analog-stereo [Built-in Audio Analog Stereo]
----Steve
I played with the settings and got it to work, but there's a story...
I started Dream with "dream -O pulse"
It opened for a few seconds, then crashed and displayed this:
CSoapySDRIn::SetFrequency(7229000)
can't unsubscribe - no rig set! 0
[INFO] Opening HackRF One #0 17c467dc315234c3...
front end mapping:
setting rfgain_selto0
setting iqcorr_ctrltotrue
setting agc_setpointto-60
setting biasT_ctrltofalse
setting rfnotch_ctrltofalse
setting dabnotch_ctrltofalse
strSDRConfig = bias_tx=false
Activating stream succeeded
Ofront end mapping:
setting bias_txtofalse
strSDRConfig = bias_tx=false
terminate called after throwing an instance of 'std::runtime_error'
what(): RX stream already opened
Aborted
It's like it tried to open both SDRs.
I unplugged the HackRF and tried it again. Now it works!
When a station is received, there is nothing in Shifted PSD.
Waterfall display shows a weak signal that looks like a DRM signal. It displays a value in SNR and the DC frequency.
The other input waveforms do have signal.
Did not get a strong enough signal to decode.
The level indicator shows no signal unless it is an extremely strong local signal.
Is there a provision to specify the SDR gains?
It still crashes when I open an audio file.
Edit:
Upon further investigation, I see that if only the HackRF is connected, it crashes. If only the SDRPlay is connected, it works. The first time, I thought it tried to open both, but it is not doing that now.
It would be nice in the future to see the AM dialogue work with the SDR so I can test the audio, etc. As of now, it only tunes the original audio frequencies. It does seem to be using the SDR now.
----Steve
Last edit: Steven Sostrom 2021-11-22
I think it is working for me. I was able to decode a signal for about 1 second.
It seems that the dream-mjf branch that I normally use with gqrx is more sensitive with the gain set in gqrx. The gain in the SDRplay RSP1 is low with the dream-ollie branch.
It looks like the HackRF crashes Dream.
----Steve
Thanks for the updates Steve and pleased to hear you've had partial success at least!
The gain settings are something I've been playing with. The SDRPlay implementation for SoapySDR doesn't quite conform to the API contract, in particular in that the "gains" it reports are actually gain reductions so operate in the opposite sense. There's discussion here, and you can see that I've been trying out one of the options in Franco's branch. I guess you're using the master branch of SoapySDRPlay.
Either way, if you look in your Dream.ini file you should see a line like this:
sdr-config=rfgain_sel=0,iqcorr_ctrl=true,agc_setpoint=-20,biasT_ctrl=false,rfnotch_ctrl=false,dabnotch_ctrl=falseYou can simply change
rfgain_selto whatever you like. I think "0" should give the maximum gain.Thanks for your help.
In my Dream.ini, rfgain_sel was already set to 0.
My agc_setpoint was set to -60. Changing that to -20 as in your example helped.
Will there be a setting for the IFGR or IF gain? Apparently, it is now set to automatic gain.
It seems that there is still a lot to talk about with the gains. If the others had used an attenuation number instead of the gain number, then that would be the norm.
If you need help testing HackRF with your branch, I will help where I can.
@olliehaffenden
I have been experimenting with the r1394 branch of dream-ollie
I have gotten it to work with DRM broadcasts, but I am trying AM, SSB, etc.
When I change the Settings to AM and I tune in a station, I do not get audio.
However, every few minutes, I do hear about 2 seconds of audio. It seems to be correct for those 2 seconds.
Is there a setting I need to change? Could audio configuration cause this?
There isn't a good enough DRM signal to try DRM tonight for a comparison.
Steve,
I haven't put any attention into AM; in fact I thought it crashed instantly in AM mode, so it's apparently not as bad as I thought! We'd definitely want to get AM working before doing a new release, but I'm afraid I have several other things I need to do first.
Happy new year!
Ollie.
Thanks. I see that you are working on your branch.
I'll check back later.
In Dream.ini, I changed samplerateaud=8000 to samplerateaud=48000
I selected an alsa device.
Now, audio for the analog modes works!
Is there a document that describes the Dream.ini parameters?
Last edit: Steven Sostrom 2023-01-08
Hi all, as Ollie says, we're really happy for your interest on this work. Just so you know, Ollie has been a major player in DRM from the very start and his team in BBC R&D were responsible for some of the earliest working content servers and receivers. No-one understands the signal processing in DRM the way Ollie does. We're privileged to have him working on a new Dream based DRM monitoring solution and we are doing it in a way which gives the maximum benefit to the whole professional and amateur community.
It seemed to me that SoapySDR is 'the hamlib for SDRs' so we are trying to make a native integration that just works. If anyone wants to generalise Ollie's work for more different SDR variants please post your ideas here. If you can code, we'll make you a branch and give you access.
Julian
I didn't know Ollie's background. That's quite an impressive resume!
Having been mostly out of radio after many years, SDRs are still kind of new to me. My history in DRM monitoring up until this past year has been with a clunky JRC NRD-535D. Have mostly been using an RTL-SDR (original v3) and Airspy HF+ Discovery, both of which have reignited the radio bug. The Airspy is an excellent radio for this kind of work and was looking to eventually adapt nrsc5 (the Ibiquity standard for digital FM in the US) for it as well.
Have mostly looked at gnuradio and not played much in SoapySDR, so I'm quite ignorant of the differences. That, other than gnuradio being a model-driven environment that's difficult for me to get my head around. Calling SoapySDR the hamlib of SDRs gives me the impression that it's a simple uniform control interface, which is fine by me.
I already have a branch and access. Given time I'd like to take a look at Ollie's code and see if I can help in any way. Retirement is another word for lots of time to do lots of things, but still trying to find the time to do it all...
Hi Julian and Ollie,
Your work are really amazing, I remember when I first heard DRM using
more than a decade ago with some crazy grc scripts to get the 455 kHz IF
from a stock HF radio connected to my USRP to feed the signal to
Dream... fast-forward to today - we can buy very affordable mirics-based
(SDRPlay, AirSpy and others) dongles with very good sensibility and
listen to DRM with Dream! Yay!
Cheers,
Rafael
On 11/22/21 1:47 PM, Julian Cable wrote: