Hello everybody,
I’m doing some test on node 311 with an HackrfOne.
Everything seems to work, except that the SDR seems to be more “noisy” than the previous RTL V3 dongle. An LNA is needed on this issue, which I should be able to do soon.
There’s another issue about PPM correction; if I put any PPM values into Radio → Advanced → SATNOGS_PPM_ERROR the observation fails.
Looking at the problem with journalctl -f -u satnogs-client.service I obtain this output:
Sep 21 14:03:08 raspberrypi systemd[1]: Started SatNOGS client.
Sep 21 14:12:08 raspberrypi satnogs-client[8215]: rot_init called
Sep 21 14:12:08 raspberrypi satnogs-client[8215]: dummy: _init called
Sep 21 14:12:08 raspberrypi satnogs-client[8215]: rot_register (1)
Sep 21 14:12:08 raspberrypi satnogs-client[8215]: rot_register (2)
Sep 21 14:12:08 raspberrypi satnogs-client[8215]: dummy_rot_init called
Sep 21 14:12:08 raspberrypi satnogs-client[8215]: rot_open called
Sep 21 14:12:08 raspberrypi satnogs-client[8215]: dummy_rot_open called
Sep 21 14:12:08 raspberrypi satnogs-client[8215]: rot_get_position called
Sep 21 14:12:08 raspberrypi satnogs-client[8215]: dummy_rot_get_position called
Sep 21 14:12:08 raspberrypi satnogs-client[8215]: rot_set_position called
Sep 21 14:12:10 raspberrypi satnogs-client[8215]: [INFO] Opening HackRF One #0 238866dc345489e3…
Sep 21 14:12:10 raspberrypi satnogs-client[8215]: Traceback (most recent call last):
Sep 21 14:12:10 raspberrypi satnogs-client[8215]: File “/usr/bin/satnogs_cw_decoder.py”, line 489, in
Sep 21 14:12:10 raspberrypi satnogs-client[8215]: main()
Sep 21 14:12:10 raspberrypi satnogs-client[8215]: File “/usr/bin/satnogs_cw_decoder.py”, line 472, in main
Sep 21 14:12:10 raspberrypi satnogs-client[8215]: tb = top_block_cls(antenna=options.antenna, bb_freq=options.bb_freq, bfo_freq=options.bfo_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, 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_dump_host=options.udp_dump_host, udp_dump_port=options.udp_dump_port, udp_port=options.udp_port, waterfall_file_path=options.waterfall_file_path, wpm=options.wpm)
Sep 21 14:12:10 raspberrypi satnogs-client[8215]: File “/usr/bin/satnogs_cw_decoder.py”, line 116, in init
Sep 21 14:12:10 raspberrypi satnogs-client[8215]: self.soapy_source_0_0.set_frequency_correction(0,ppm)
Sep 21 14:12:10 raspberrypi satnogs-client[8215]: File “/usr/lib/python3/dist-packages/soapy/soapy_swig.py”, line 457, in set_frequency_correction
Sep 21 14:12:10 raspberrypi satnogs-client[8215]: return _soapy_swig.source_sptr_set_frequency_correction(self, channel, freq_correction)
Sep 21 14:12:10 raspberrypi satnogs-client[8215]: RuntimeError: soapy::source: Channel 0 does not support frequency correction setting
Sep 21 14:12:14 raspberrypi satnogs-client[8215]: satnogsclient.observer.observer - ERROR - No waterfall data file found
It seems that the problem is in the bolded line…
This SDR swap it’s undeway cause I’m planning to “expand” the frequency range to L / S band, where the PPM error becomes more evident.
Any suggestion???
Tnx, de Victor I3VFJ
So this looks to be an issue with SoapyHackRF… which doesn’t support frequency correction settings (PPM offset). Nothing about frequency correction in here: https://github.com/pothosware/SoapyHackRF/blob/master/HackRF_Settings.cpp
The only ways of fixing this are:
- Submit an issue (or even better, a pull request) on SoapyHackRF and hope that the package maintainers agree that adding this in is a good idea. I have raised an issue: https://github.com/pothosware/SoapyHackRF/issues/32
- Try and convince people here that doing PPM correction somewhere within gr-soapy is appropriate (Which is probably something that needs to be considered if the source module maintainers won’t implement the correction)
- Get a different SDR.
Tnx Mark,
clearly the issue it’s related to the Soapy layer.
At the moment the tests I’m doing with HackrfONE don’t satisfy me too much: it seems rather “noisy” and with the same antennas the RTL V3 dongle is anyway better, both without LNA. Next days I’m going to reinstall a LNA with also a new linear PSU, to get rid of the switching PSU.
A transitional solution could be to provide a better reference (GPSDO / TCXO)… I will see what to do.
If only I could get Pluto… to work! 
Anyway tnx, experiments are underway 
73’s de Victor, I3VFJ
Hi Victor,
Please let me know if you tried to solve ppm error with external reference (something like NooElec Tiny TCXO: 0.5PPM TCXO Module for HackRF) and if you improved the SN ?
Regards,
Cristian Moldovanu - YO4DFT
Good evening Christian,
unfortunately, I am no longer active as a SATNOGS station at this time. I can confirm you that still the SoapyHackrf module does not support the ‘ppm’ correction. I installed a TCXO in the Hackrf and so, all in all, the frequency is quite correct, although at 2.4 GHz the difference is still noticeable… yes, I know, I am a perfectionist XP
In another project I am working on with GNURADIO, I provide the ppm correction directly in the ‘RF Options’ → ‘Center frequency’ field, but I don’t know how much this is possible in the SATNOGS ecosystem
Have fun 
Victor, I3VFJ