SATNOGS_LO_OFFSET greater than 0.25 x sample rate

9h1y · November 2, 2020, 7:07pm

Hi, I am interfacing the Satnogs client with a home-made phased array which will accept commands via hamlib to electronically steer the antenna. The way the system works is that I control phase and amplitude via a set of 4 channel DDSs. The question I have here is, I am mixing the incoming signal in the 435-438MHz with an LO of 10MHz, however the SATNOGS_LO_OFFSET maximum can only be the sample rate/4 which with an RTL SDR is 2.4e6.

Can anyone suggest how I can pass on the LO offset to the Satnogs client?

Thanks
73 de 9H1Y

vk5qi · November 2, 2020, 9:27pm

I think LO offset was meant to shift the signal of interest away from any DC spike that might be present in some SDRs.

That parameter appears to be used in 2 spots in the flowgraphs, one to just set an offset in the SDRs tuning frequency, but its also used again in the doppler compensation block to compensate for that offset again, hence why that particular parameter cant be set to anything too high.

It sounds like there needs to be another parameter for a mixing offset (commonly used by LNBs for microwave bands too). I thought we used to have this, but i cant find any reference to it in satnogs-setup.

Paging @Acinonyx and @surligas !

9h1y · November 2, 2020, 10:38pm

Understood, the RTL-SDR i am using does exhibit a spike so makes sense. Ideally there is no restriction in terms of frequency on the mixing offset to cater for any possible IF outputs depending on choice of mixer. Let’s wait for what the guys say. Thanks!

kerel · November 3, 2020, 9:22pm

Hi 8H1Y,

there is a corresponding issue on this topic at gr-satnogs#129.

To summarize my last comment there:
To add an offset (due to a previous mixer stage with a LO of 10MHz) add OFFSET=10000000 to SATNOGS_TUNE_ARGS via `satnogs-setup (Advaced Options>Radio).

I didn’t test this yet, please let us know if this works!

Best wishes,
Fabian

9h1y · November 4, 2020, 6:53am

Hi Fabian

Thanks for the quick response. I have setup this parameter in the config however I am getting a runtime error as follows:

Nov 04 07:38:58 raspberrypi satnogs-client[927]: Found Rafael Micro R820T tuner
Nov 04 07:38:58 raspberrypi satnogs-client[927]: [INFO] Opening Generic RTL2832U OEM :: 00000001…
Nov 04 07:38:58 raspberrypi satnogs-client[927]: Found Rafael Micro R820T tuner
Nov 04 07:38:58 raspberrypi satnogs-client[927]: [R82XX] PLL not locked!
Nov 04 07:38:58 raspberrypi satnogs-client[927]: [INFO] Using format CF32.
Nov 04 07:38:58 raspberrypi satnogs-client[927]: Traceback (most recent call last):
Nov 04 07:38:58 raspberrypi satnogs-client[927]: File “/usr/bin/satnogs_fsk.py”, line 514, in
Nov 04 07:38:58 raspberrypi satnogs-client[927]: main()
Nov 04 07:38:58 raspberrypi satnogs-client[927]: File “/usr/bin/satnogs_fsk.py”, line 499, in main
Nov 04 07:38:58 raspberrypi satnogs-client[927]: tb = top_block_cls(antenna=options.antenna, baudrate=options.baudrate, bb_freq=options.bb_freq, bw=options.bw, dc_removal=options.dc_removal, decoded_data_file_path=options.decoded_data_file_path, dev_args=options.dev_args, doppler_correction_per_sec=options.doppler_correction_per_sec, enable_iq_dump=options.enable_iq_dump, file_path=options.file_path, framing=options.framing, gain=options.gain, gain_mode=options.gain_mode, iq_file_path=options.iq_file_path, lo_offset=options.lo_offset, other_settings=options.other_settings, ppm=options.ppm, rigctl_port=options.rigctl_port, rx_freq=options.rx_freq, samp_rate_rx=options.samp_rate_rx, soapy_rx_device=options.soapy_rx_device, stream_args=options.stream_args, tune_args=options.tune_args, udp_IP=options.udp_IP, udp_port=options.udp_port, waterfall_file_path=options.waterfall_file_path)
Nov 04 07:38:58 raspberrypi satnogs-client[927]: File “/usr/bin/satnogs_fsk.py”, line 95, in init
Nov 04 07:38:58 raspberrypi satnogs-client[927]: tune_args, settings, samp_rate_rx, “fc32”)
Nov 04 07:38:58 raspberrypi satnogs-client[927]: File “/usr/lib/python3/dist-packages/soapy/soapy_swig.py”, line 166, in make
Nov 04 07:38:58 raspberrypi satnogs-client[927]: return _soapy_swig.source_make(nchan, device, dev_args, stream_args, tune_args, other_settings, sampling_rate, type)
Nov 04 07:38:58 raspberrypi satnogs-client[927]: RuntimeError: soapy::source: Unsupported tune argument OFFSET for channel 0

Any thoughts?

Regards
Charles

kerel · November 4, 2020, 9:08am

Hi Charles,
thanks for testing! Sorry to hear that it doesn’t work.

This is a bug in soapyrtlsdr. When asked for it’s capabilities (via getFrequencyArgsInfo) soapyRTLSDR-driver returns an empty set (see Settings.cpp#L440-L447). We should open an issue there (if it doesn’t exist yet, i’ll check later).
So for now the current SatNOGS client doesn’t support LO offset when using RTL-SDRs (other drivers might implement this already, I didn’t check it). But in principle it should be an easy fix in soapyrtlsdr.

Best wishes,
Fabian

9h1y · November 5, 2020, 7:06pm

Thanks Fabian. Is this something I can easily do by adding some code on my machine and rebuilding Soapy RTL-SDR locally to try it out? (as per yourwiki) In which case any suggested code saving me figuring it out?

Charles

kerel · November 6, 2020, 11:39am

Hi Charles,

we had a discussion in #satnogs-dev (it is open to anyone and you are invited to join, you need to sign up to matrix.org / element.io to be able to read the history though) on this.

While there is this bug in soapyrtlsdr and it might be easily fixed,

it remains to be checked if other soapy drivers exhibit the same bug and
maybe this (it is a simple hardware-independent subtraction) should be solved at a higher level, specifically gr-soapy or gr-satnogs or satnogs-flowgraphs.

The best place to decide this might be the aforementioned gr-satnogs#129.

To answer your last question:
The reference soapy Frequency API / SoapySDR::Device::setFrequency at SoapySDR:lib/Device.cpp#L357-L398 respects the OFFSET keyword, and apparently this function is not overwritten by the SoapyRTLSDR driver. So it might be enough

to add the code from SoapySDR:/lib/Device.cpp#L470-L511 to SoapyRTLSDR::getFrequencyArgsInfo or
remove getFrequencyArgsInfo from SoapyRTLSDR, so that it will not overwrite the behavior of the reference implementation (this is a wild guess).

Best wishes,
Fabian

9h1y · December 8, 2020, 5:04pm

Hi Fabian

I did manage to make the change and compile. However, I am still getting the same error. Sorry for the Q, but how can I be sure that the satnogs client is indeed using my compiled version now instead of the pre-installed one?

Thanks
Charles

9h1y · December 13, 2020, 8:15am

@kerel I am working using the Satnogs image which by default does not seem to have the uncompiled files installed, which I am installing manually.

kerel · December 13, 2020, 4:27pm

Hi Charles,

I just learned that you can check which version of the soapy modules is used by checking this command SoapySDRUtil --info. On my SatNOGS station it creates the following output:

######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.7.2-1
API Version: v0.7.1
ABI Version: v0.7
Install root: /usr
Search path:  /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7
Search path:  /usr/local/lib/arm-linux-gnueabihf/SoapySDR/modules0.7                (missing)
Search path:  /usr/local/lib/SoapySDR/modules0.7                                    (missing)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libHackRFSupport.so  (0.3.3)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libLMS7Support.so    (20.01.0)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libRedPitaya.so      (0.1.1)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libairspySupport.so  (0.1.2)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libaudioSupport.so   (0.1.1)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libbladeRFSupport.so (0.4.1)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libosmosdrSupport.so (0.2.5)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libremoteSupport.so  (0.5.2)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/librtlsdrSupport.so  (0.3.1)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libuhdSupport.so     (0.3.6)
Available factories... airspy, audio, bladerf, hackrf, lime, osmosdr, redpitaya, remote, rtlsdr, uhd
Available converters...
 -  CF32 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS16 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS32 -> [CS32]
 -   CS8 -> [CF32, CS16, CS8, CU16, CU8]
 -  CU16 -> [CF32, CS16, CS8]
 -   CU8 -> [CF32, CS16, CS8]
 -   F32 -> [F32, S16, S8, U16, U8]
 -   S16 -> [F32, S16, S8, U16, U8]
 -   S32 -> [S32]
 -    S8 -> [F32, S16, S8, U16, U8]
 -   U16 -> [F32, S16, S8]
 -    U8 -> [F32, S16, S8]

The line listing librtlsdrSupport.so should look differently for you.

Best wishes, Fabian

pierros · March 29, 2021, 5:07pm

@surligas can you please copy the right developer of gr-soapy that might be able to shed a light on this issue to unblock the experiment of @9h1y ?

Thanks!

surligas · March 29, 2021, 8:24pm

As mentioned by @vk5qi, the LO_OFFSET is not meant for mixing an IF etc. It is just to avoid the DC spikes of the receiver. Possibly the bb_freq argument can be used to achieve the desired 10MHz mixing.

9h1y · March 30, 2021, 5:16pm

Hi @surligas, according to documentation this is marked FIXEDME. Who do i speak to in order to get this fixed? Thanks!