jamesg466, I have been able to build it on my Mac just fine following the usual
git clone https://github.com/myriadrf/gr-limesdr
cd gr-limesdr
mkdir build
cd build
cmake …
make
sudo make install
still working on using it…I seem to be confused with device number. LineUtil gives me:
MacBook-Pro:build scott$ limeutil --find
* [LimeSDR-USB, media=USB 2.0, module=STREAM, addr=1d50:6108, serial=0009070105C6102B]
FYI:
MacBook-Pro:build scott$ limeutil --info
######################################################
## LimeSuite information summary
######################################################
Version information:
Library version: v17.09.1-release
Build timestamp: 2018-01-13
Interface version: v2017.9.0
Binary interface: 17.09-1
Which number do I use in Device Number? GRC complains when I put in 0009070105C6102B or 9070105C6102B as I expect it expects a base 10 value. When I put in the decimal equivalent number of 2540975763623979 I get the following runtime error:
File "/usr/local/lib/python2.7/site-packages/limesdr/limesdr_swig.py", line 134, in make
return _limesdr_swig.source_make(device_number, device_type, chip_mode, channel, file_switch, filename, rf_freq, samp_rate, oversample, calibration_ch0, calibr_bandw_ch0, calibration_ch1, calibr_bandw_ch1, lna_path_mini, lna_path_ch0, lna_path_ch1, analog_filter_ch0, analog_bandw_ch0, analog_filter_ch1, analog_bandw_ch1, digital_filter_ch0, digital_bandw_ch0, digital_filter_ch1, digital_bandw_ch1, gain_dB_ch0, gain_dB_ch1)
OverflowError: in method 'source_make', argument 1 of type 'int'
I assume I’m just being dumb here and using the wrong value. Any suggestions for the PAC would be appreciated.
Also a few would love to have request for the driver. Would it be possible to expose the values in the drop-down dialogs of programmatic manipulations? I understand why you would want to make thing easier for user with drop downs. Also, it would be of great value to me to have access to the RSSI value from the lnaW. If there are no limitations in the Lime board I would be happy to work on this and contribute back the code to a pull request.
Further, it seems that these values are not dynamic. The ability to programmatically adjust basic values such as frequency without rebooting your GR flow is critical.