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.
2 Likes
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
1 Like