This is necessary because make fails with errors related to hamlib. I have successfully compiled earlier versions (r1373) of the dream-ollie branch.
The problem I am having today are with a missing sound.h file. make terminates with:
usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++ -o obj/DrmReceiver.o src/DrmReceiver.cpp
src/DrmReceiver.cpp:40:10: fatal error: sound/sound.h: No such file or directory
40 | #include "sound/sound.h"
The other files included in DrmReceiver.cpp are present, but there is no dream-ollie/src/sound/sound.h
It does exist in dream-mjf/src/sound
Is this an error in the source, or am I doing something wrong?
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for pointing this out. It's definitely my bad: the idea is that sound.h isn't used any more, but it looks like I haven't fully disentangled it. I'll look at it tomorrow.
Ollie.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just committed rev 1379 which fixes this compile error. In fact it's sufficient to delete the offending #include line which isn't needed any more. You might find this easier than doing an update as you have to do the other changes.
My commit also adds a frequency offset parameter so that the SDR can be tuned e.g. 12kHz below the wanted centre frequency and operated in "I/Q pos" mode to avoid any LO breakthrough issues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for fixing this. I installed the new version.
It is working, but I do not understand how to specify the 12KHz frequency offset parameter.
When I changed tunerfreqoffset=0 to tunerfreqoffset=12, in Dream.ini, it just added 12 KHz to the specified frequency and I had to tune 12 KHz lower. Is this what you were referring to?
In addition, there was an AM signal that moved in the opposite direction from the DRM signal when I change the frequency in stations. It effectively moved closer to or further from the DRM signal. As this seems to be an image signal, I adjusted agc_setpoint lower, but the signal was still there, just weaker. I would like to have full control of RF and IF gain with the option of using AGC. I cannot make the signal as strong in the Level [db] indicator as I can when using audio (in the audio input version). It also seems to give a lower SNR.
Will you be able to implement the hamlib changes so I don't have to edit the source files? I see that some have been done, but it still won't compile for me unless I do all of them.
If both my HackRF and SDRplay are connected, it will open the Hack RF and display a series of "O" and does not work. I have to unplug the HackRF, so it will use the SDRplay SDR.
With both connected, [INFO] Opening HackRF One #0 17c467dc315234c3... appears in the terminal output. Both SDRs appear in the input selection menu.
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The 12kHz offset is just what you say: it adds the offset to the requested frequency before tuning the SDR. So if you use tunerfreqoffset=-12 and then select I/Q Pos for the input, then choosing stations from the Stations dialog should work. I thought this might be better (for some SDRs) than tuning to the centre frequency and using "I/Q pos zero" mode because it avoids problems around DC, but you might find differently for your front-end.
For the RSP1A to work as intended, you need to build a particular branch (new-gain-controls) of the SoapySDRPlay3 module: see my post here, first setting the GAIN_MODE to DB and unsetting GAIN_MODE_DB_POSITIVE. Sorry I forgot to mention that earlier. Once you've done that you can adjust the RF and IF gain directly in the Dream.ini file. This affects both gain settings and level measurement.
I'll try to work out how to deal with the Hamlib and GPS issues this week. Have you seen [Christopher Andrews's thread]https://sourceforge.net/p/drm/discussion/compiling/thread/36b300eba8/?limit=25#3c51)? You're both experimenting with my branch and there's significant overlap in what you're finding. Having multiple devices connected is something I need to look at. I have two RSP1As so I can try to get that working first, but your setup with two different SDRs would make a very useful testbed once it can handle two devices of the same type.
Ollie.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for clearing things up.
I was confused about the many SDRPlay3 modules. I installed SoapySDRPlay3-new-gain-controls branch and it allowed the adjustment of rfgain_sel, but I found the range to be, 0-5 instead of the usual 0-9 for my RSP1A. Any other setting causes the API to fail.
I do like the tunerfreqoffset setting, as I was able to use -6 to place the DRM signal 1 KHz above "0" in the spectrum.
I will be able to try it better later when I can get signal.
In your branch, I only see hamlib as useful when the audio input options are available. I hope you will eventually be able to merge it with the main branch and have everything in the same application.
Adding the audio input at the same time as the SoapySDR inputs is on my list and shouldn't be too difficult now.
For the hamlib changes, my understanding is that those changes break the build if you have a different version of hamlib, as Julian mentions on the thread you linked. So ideally we need something a bit cleverer - I'll try to find out what Julian had in mind for that.
I've done some experiments with two RSP1As connected and trying to switch between them. It looks like a thread safety issue: there's a race condition between closing and initialising the SoapySDR input. I've made a few changes that makes it crash less, but it's still not reliable so I wasn't planning to commit anything yet. Basically I check pointers more often before using them, but there's still a chance of one thread destroying something that another thread is about to use. I'm currently trying to figure out the sequence of events that get fired, as there's more happening than I expect and everything seems to get called twice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It sound like you have a plan. I think that Hamlib upset everything when they made such drastic changes. Other applications had to change also. Are you using GNU Radio? They made some changes in v 3.9 that broke a lot of applications
Last night, I tuned to the BBC on 3.955 MHz. Then I tuned to 3.965 MHz. The BBC signal appeared just 1 KHz lower on the display instead of moving 10 KHz. I had a -6 KHz offset in Dream.ini, which would apply to both frequencies.
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just realised that I haven't mentioned the sampling rate. The RSP1A only goes down to 96kHz so I've added a 2:1 downsampling option to convert to 48kHz. I've attached my Dream.ini file in case there are other settings you need, but the relevant lines are:
sampleratesig=96000
sigdownratio=2
sigupratio=1
I'm guessing you must have worked this out for yourself if you're able to decode DRM signals, but your description of the tuning behaviour made me think of this.
I changed my Dream.ini sample rate settings to be the same as in your post. I don't notice any difference.
The tuning is still strange.
In the attached image, I tuned to a frequency that displayed 2 carriers in the waterfall. I lowered the frequency in Stations by 1 KHz several times. The carriers moved closer together rather than moving together in the same direction. I expect them to move in the same direction.
This does not happen with the same frequencies in gqrx.
Hmm. I can't reproduce what you're seeing. Can you double-check that all the relevant settings in Dream.ini (i.e. not just the ones in the post) are the same as in the file I attached above?
In other news, I committed rev 1382, which should allow switching between different SDR units. I've tested it with two RSP1As and it seems ok.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried rev 1384. I used the Dream.ini file that you provided except that I changed tunerfreqoffset=-6. My previous installations used the Dream.ini that Dream created.
When I run Dream with the HackRF connected, it crashes:
... [INFO] Opening HackRF One #0 17c467dc315234c3...
Setting sample rate to 96000
Setting frequency to 6032000
front end mapping:
setting rfgain_selto0
setting iqcorr_ctrltotrue
setting agc_setpointto-20
setting biasT_ctrltofalse
setting rfnotch_ctrltofalse
setting dabnotch_ctrltofalse
strSDRConfig = bias_tx=true
Activating stream succeeded
OCSoapySDRIn::Init()
double free or corruption (!prev)
Aborted
With only the RSP1A connected, it works. I can see the RSP1A and the audio devices.
The strange tuning phenomenon where signals move in opposite directions when I change the frequency by 1 KHz no longer happens. Everything move in the same direction.
Some frequencies are weaker than others, so I used agc_setpoint=-10. It seems that agc is not keeping things constant.
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the update. I think that's progress. The "double free or corruption" is probably a new problem that I introduced with the Composite Sound Input. It's possibly wrong for all SDRs, but for some reason we get away with it with the RSP1A. I'll have another look. Are you running in the debugger or from the command line? Good news about the tuning phenomenon. I guess that must have been down to a Dream.ini setting. There's no AGC implemented in Dream itself - it relies on the SDR module to provide AGC. So for the RSP1A the RF gain is just set to a fixed value. This would be an interesting area of development but it's likely to be quite front-end-specific. The RSP1A's IF AGC will work on the whole received signal, so it's possible that strong signals in adjacent channels are affecting the gain and the resulting power in the wanted channel.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am running from the command line.
If the tuning problem was caused by settings in the Dream.ini file then the one generated by Dream should be correct. Also we should have some instructions at some point, or put the settings in thr GUI.
The signal that was weaker was on the 60 meter broadcast band with lots of strong signals. Is there an option to disable the hardware AGC and set IF gain manually?
As for the SDR selection menu, does Dream support the HackRF?
If you want to support it. I can test it for you. however I rarely get a strong enough signal to decode in the HackRF is less sensitive than the RSP1A.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You make a fair point that the default configuration generated by Dream ought to work. The problem is that the correct settings depend on the particular SDR but that is abstracted away by SoapySDR. It's analogous to the way hamlib might need specific settings for particular rig model. Dream deals with that by having some settings hard-coded in the CHamlib class and stored in a lookup-table.
The SoapySDR API does include an auto/manual gain mode settings which could be exposed to Dream. So far I've been assuming the default AGC mode is good enough. Definitely something to add to the wishlist though. In the first instance it could be a setting in the ini file, but as you say it would ideally be available via the GUI.
In principle Dream should support any front-end supported by SoapySDR, but as discussed earlier there's some kind of issue with the "double free" thing. I note that with earlier revisions you were seeing "O"s output to the terminal window and I can see an "O" in the output you quoted above. I made one change in rev 1385 which might prevent the double free issue, so would be interested to hear if that makes any difference.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using a Raspberry Pi 4 B with arm64 Debian Bookworm.
In order to compile this branch, I have to apply the patches 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
This is necessary because make fails with errors related to hamlib. I have successfully compiled earlier versions (r1373) of the dream-ollie branch.
The problem I am having today are with a missing sound.h file. make terminates with:
usr/lib/aarch64-linux-gnu/qt5/mkspecs/linux-g++ -o obj/DrmReceiver.o src/DrmReceiver.cpp
src/DrmReceiver.cpp:40:10: fatal error: sound/sound.h: No such file or directory
40 | #include "sound/sound.h"
The other files included in DrmReceiver.cpp are present, but there is no dream-ollie/src/sound/sound.h
It does exist in dream-mjf/src/sound
Is this an error in the source, or am I doing something wrong?
----Steve
Thanks for pointing this out. It's definitely my bad: the idea is that sound.h isn't used any more, but it looks like I haven't fully disentangled it. I'll look at it tomorrow.
Ollie.
I just committed rev 1379 which fixes this compile error. In fact it's sufficient to delete the offending #include line which isn't needed any more. You might find this easier than doing an update as you have to do the other changes.
My commit also adds a frequency offset parameter so that the SDR can be tuned e.g. 12kHz below the wanted centre frequency and operated in "I/Q pos" mode to avoid any LO breakthrough issues.
Thank you for fixing this. I installed the new version.
It is working, but I do not understand how to specify the 12KHz frequency offset parameter.
When I changed tunerfreqoffset=0 to tunerfreqoffset=12, in Dream.ini, it just added 12 KHz to the specified frequency and I had to tune 12 KHz lower. Is this what you were referring to?
In addition, there was an AM signal that moved in the opposite direction from the DRM signal when I change the frequency in stations. It effectively moved closer to or further from the DRM signal. As this seems to be an image signal, I adjusted agc_setpoint lower, but the signal was still there, just weaker. I would like to have full control of RF and IF gain with the option of using AGC. I cannot make the signal as strong in the Level [db] indicator as I can when using audio (in the audio input version). It also seems to give a lower SNR.
Will you be able to implement the hamlib changes so I don't have to edit the source files? I see that some have been done, but it still won't compile for me unless I do all of them.
If both my HackRF and SDRplay are connected, it will open the Hack RF and display a series of "O" and does not work. I have to unplug the HackRF, so it will use the SDRplay SDR.
With both connected, [INFO] Opening HackRF One #0 17c467dc315234c3... appears in the terminal output. Both SDRs appear in the input selection menu.
----Steve
Hi.
Thanks for your comments and observations.
The 12kHz offset is just what you say: it adds the offset to the requested frequency before tuning the SDR. So if you use tunerfreqoffset=-12 and then select I/Q Pos for the input, then choosing stations from the Stations dialog should work. I thought this might be better (for some SDRs) than tuning to the centre frequency and using "I/Q pos zero" mode because it avoids problems around DC, but you might find differently for your front-end.
For the RSP1A to work as intended, you need to build a particular branch (new-gain-controls) of the SoapySDRPlay3 module: see my post here, first setting the GAIN_MODE to DB and unsetting GAIN_MODE_DB_POSITIVE. Sorry I forgot to mention that earlier. Once you've done that you can adjust the RF and IF gain directly in the Dream.ini file. This affects both gain settings and level measurement.
I'll try to work out how to deal with the Hamlib and GPS issues this week. Have you seen [Christopher Andrews's thread]https://sourceforge.net/p/drm/discussion/compiling/thread/36b300eba8/?limit=25#3c51)? You're both experimenting with my branch and there's significant overlap in what you're finding. Having multiple devices connected is something I need to look at. I have two RSP1As so I can try to get that working first, but your setup with two different SDRs would make a very useful testbed once it can handle two devices of the same type.
Ollie.
Thanks for clearing things up.
I was confused about the many SDRPlay3 modules. I installed SoapySDRPlay3-new-gain-controls branch and it allowed the adjustment of rfgain_sel, but I found the range to be, 0-5 instead of the usual 0-9 for my RSP1A. Any other setting causes the API to fail.
I do like the tunerfreqoffset setting, as I was able to use -6 to place the DRM signal 1 KHz above "0" in the spectrum.
I will be able to try it better later when I can get signal.
In your branch, I only see hamlib as useful when the audio input options are available. I hope you will eventually be able to merge it with the main branch and have everything in the same application.
Again, the hamlib changes by Mark J. Fine are detailed here:
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
----Steve
Last edit: Steven Sostrom 2022-01-31
Adding the audio input at the same time as the SoapySDR inputs is on my list and shouldn't be too difficult now.
For the hamlib changes, my understanding is that those changes break the build if you have a different version of hamlib, as Julian mentions on the thread you linked. So ideally we need something a bit cleverer - I'll try to find out what Julian had in mind for that.
I've done some experiments with two RSP1As connected and trying to switch between them. It looks like a thread safety issue: there's a race condition between closing and initialising the SoapySDR input. I've made a few changes that makes it crash less, but it's still not reliable so I wasn't planning to commit anything yet. Basically I check pointers more often before using them, but there's still a chance of one thread destroying something that another thread is about to use. I'm currently trying to figure out the sequence of events that get fired, as there's more happening than I expect and everything seems to get called twice.
It sound like you have a plan. I think that Hamlib upset everything when they made such drastic changes. Other applications had to change also. Are you using GNU Radio? They made some changes in v 3.9 that broke a lot of applications
Last night, I tuned to the BBC on 3.955 MHz. Then I tuned to 3.965 MHz. The BBC signal appeared just 1 KHz lower on the display instead of moving 10 KHz. I had a -6 KHz offset in Dream.ini, which would apply to both frequencies.
----Steve
I just realised that I haven't mentioned the sampling rate. The RSP1A only goes down to 96kHz so I've added a 2:1 downsampling option to convert to 48kHz. I've attached my Dream.ini file in case there are other settings you need, but the relevant lines are:
I'm guessing you must have worked this out for yourself if you're able to decode DRM signals, but your description of the tuning behaviour made me think of this.
I changed my Dream.ini sample rate settings to be the same as in your post. I don't notice any difference.
The tuning is still strange.
In the attached image, I tuned to a frequency that displayed 2 carriers in the waterfall. I lowered the frequency in Stations by 1 KHz several times. The carriers moved closer together rather than moving together in the same direction. I expect them to move in the same direction.
This does not happen with the same frequencies in gqrx.
----Steve
Hmm. I can't reproduce what you're seeing. Can you double-check that all the relevant settings in Dream.ini (i.e. not just the ones in the post) are the same as in the file I attached above?
In other news, I committed rev 1382, which should allow switching between different SDR units. I've tested it with two RSP1As and it seems ok.
You might also like to try rev 1383, which should allow selection between SoapySDR inputs and sound inputs.
I tried rev 1384. I used the Dream.ini file that you provided except that I changed tunerfreqoffset=-6. My previous installations used the Dream.ini that Dream created.
When I run Dream with the HackRF connected, it crashes:
...
[INFO] Opening HackRF One #0 17c467dc315234c3...
Setting sample rate to 96000
Setting frequency to 6032000
front end mapping:
setting rfgain_selto0
setting iqcorr_ctrltotrue
setting agc_setpointto-20
setting biasT_ctrltofalse
setting rfnotch_ctrltofalse
setting dabnotch_ctrltofalse
strSDRConfig = bias_tx=true
Activating stream succeeded
OCSoapySDRIn::Init()
double free or corruption (!prev)
Aborted
With only the RSP1A connected, it works. I can see the RSP1A and the audio devices.
The strange tuning phenomenon where signals move in opposite directions when I change the frequency by 1 KHz no longer happens. Everything move in the same direction.
Some frequencies are weaker than others, so I used agc_setpoint=-10. It seems that agc is not keeping things constant.
----Steve
Thanks for the update. I think that's progress.
The "double free or corruption" is probably a new problem that I introduced with the Composite Sound Input. It's possibly wrong for all SDRs, but for some reason we get away with it with the RSP1A. I'll have another look. Are you running in the debugger or from the command line?
Good news about the tuning phenomenon. I guess that must have been down to a Dream.ini setting.
There's no AGC implemented in Dream itself - it relies on the SDR module to provide AGC. So for the RSP1A the RF gain is just set to a fixed value. This would be an interesting area of development but it's likely to be quite front-end-specific.
The RSP1A's IF AGC will work on the whole received signal, so it's possible that strong signals in adjacent channels are affecting the gain and the resulting power in the wanted channel.
I am running from the command line.
If the tuning problem was caused by settings in the Dream.ini file then the one generated by Dream should be correct. Also we should have some instructions at some point, or put the settings in thr GUI.
The signal that was weaker was on the 60 meter broadcast band with lots of strong signals. Is there an option to disable the hardware AGC and set IF gain manually?
As for the SDR selection menu, does Dream support the HackRF?
If you want to support it. I can test it for you. however I rarely get a strong enough signal to decode in the HackRF is less sensitive than the RSP1A.
You make a fair point that the default configuration generated by Dream ought to work. The problem is that the correct settings depend on the particular SDR but that is abstracted away by SoapySDR. It's analogous to the way hamlib might need specific settings for particular rig model. Dream deals with that by having some settings hard-coded in the CHamlib class and stored in a lookup-table.
The SoapySDR API does include an auto/manual gain mode settings which could be exposed to Dream. So far I've been assuming the default AGC mode is good enough. Definitely something to add to the wishlist though. In the first instance it could be a setting in the ini file, but as you say it would ideally be available via the GUI.
In principle Dream should support any front-end supported by SoapySDR, but as discussed earlier there's some kind of issue with the "double free" thing. I note that with earlier revisions you were seeing "O"s output to the terminal window and I can see an "O" in the output you quoted above. I made one change in rev 1385 which might prevent the double free issue, so would be interested to hear if that makes any difference.