search

argilo / gr-tenna

goTenna Mesh receiver and transmitter for GNU Radio
GNU General Public License v3.0
31 stars 4 forks source link

Exception in set_time_unknown_pps() with LimeSDR #3

Open sybip opened 3 years ago

sybip commented 3 years ago

I'm getting an exception when running the Python scripts on a LimeSDR radio:

Traceback (most recent call last):
  File "./gotenna_rx_hackrf.py", line 144, in <module>
    main()
  File "./gotenna_rx_hackrf.py", line 122, in main
    tb = top_block_cls()
  File "./gotenna_rx_hackrf.py", line 51, in __init__
    self.osmosdr_source_0.set_time_unknown_pps(osmosdr.time_spec_t())
  File "/usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py", line 2311, in set_time_unknown_pps
    return _osmosdr_swig.source_sptr_set_time_unknown_pps(self, time_spec)
RuntimeError: SoapyLMS7::setHardwareTime(UNKNOWN_PPS) unknown argument

I can work around this problem easily in gotenna_(rx|tx)_hackrf.py by wrapping the set_time_unknown_pps line in a try block. As the command is optional (AFAIK is no-op unless an external clock source is present), the script runs without further problems. However, I am unsure how / if this solution can be properly implemented in the corresponding grc file.

Platform details
OS Fedora 31 Cloud Edition
Arch x86_64
GnuRadio 3.7.13
gr-OsmoSDR 0.1.4
SoapySDR 0.7.1
LimeSuite 20.10.0
Radio LimeSDR-Mini USB
sybip commented 3 years ago

I think the cause (or should I say the trigger) of this issue is the sync parameter of the osmocom Source block.

Setting "Sync" to "unknown PPS" in the gnuradio companion, or sync: sync in the grc file will cause this issue on LimeSDR. This is the default setting currently.

Setting "Sync" to "don't sync" results in correct operation.

So, not a gr-tenna issue per se, but perhaps worth a mention in the README so other LimeSDR users can avoid the initial bad experience and subsequent troubleshooting.