Will CubicSDR for OSX move past V0.2.2 in my lifetime?
Will CubicSDR for OSX move past V0.2.2 in my lifetime?
Will CubicSDR for OSX move past V0.2.2 in my lifetime?
Reason: No reason
Re: Will CubicSDR for OSX move past V0.2.2 in my lifetime?
Hi,
CubicSDR is actively being updated regularly by the authors. You can check out their github repository here...
https://github.com/cjcliffe/CubicSDR
(the last update was less than a day ago at the time of this posting)
It is unfortunate (and maybe a feature of the way development happens on github) that the revision number of the software doesn't increment when there are updates to the code. As far as I know the revision number is incremented when the author makes official binary builds available and essentially creates a snapshot of the design.
I hope that helps,
Best regards,
SDRplay Support
CubicSDR is actively being updated regularly by the authors. You can check out their github repository here...
https://github.com/cjcliffe/CubicSDR
(the last update was less than a day ago at the time of this posting)
It is unfortunate (and maybe a feature of the way development happens on github) that the revision number of the software doesn't increment when there are updates to the code. As far as I know the revision number is incremented when the author makes official binary builds available and essentially creates a snapshot of the design.
I hope that helps,
Best regards,
SDRplay Support
Reason: No reason
Re: Will CubicSDR for OSX move past V0.2.2 in my lifetime?
For what it's worth I've cloned the git repository and built CubicSDR and SoapySDR with SoapySDRPLAY on my mac pro running high sierra.
git clone https://github.com/cjcliffe/CubicSDR
git clone https://github.com/pothosware/SoapySDR
git clone https://github.com/pothosware/SoapySDRPLAY
I'm using `homebrew` to fight my way through installing all the needed dependancies. Sadly I didn't take notes but using `cmake` (and gui version`ccmake`) make this possible (and reading the directions on the github pages for these repos)
It's a well structured program which uses OpenGL to do the screen drawing. One thing I've encountered is the appears not to fathom non-zero IF modes very well. I think this may be due to limitations of the current SoapSDRPLAY lib. SoapySDR is a code layer that allows codes like CubicSDR to deal with a vendor neutral API.
The problem with non-zero IF modes is the change in streaming data format due to decimation? It's reasonable that this could be fixed by adding a mir_sdr_DownConvert() call to SoapSDRPLAY. Currently the git repository version makes no reference to this API call.
The non-zero IF modes may or may not be useful to me, hard to tell if you can't take a look at it.
The real goal for me is adding some measurement cursors and level readouts. CubicSDR constantly updates the spectrum displays. The dB markings are confusing unlabeled and a moving target.
git clone https://github.com/cjcliffe/CubicSDR
git clone https://github.com/pothosware/SoapySDR
git clone https://github.com/pothosware/SoapySDRPLAY
I'm using `homebrew` to fight my way through installing all the needed dependancies. Sadly I didn't take notes but using `cmake` (and gui version`ccmake`) make this possible (and reading the directions on the github pages for these repos)
It's a well structured program which uses OpenGL to do the screen drawing. One thing I've encountered is the appears not to fathom non-zero IF modes very well. I think this may be due to limitations of the current SoapSDRPLAY lib. SoapySDR is a code layer that allows codes like CubicSDR to deal with a vendor neutral API.
The problem with non-zero IF modes is the change in streaming data format due to decimation? It's reasonable that this could be fixed by adding a mir_sdr_DownConvert() call to SoapSDRPLAY. Currently the git repository version makes no reference to this API call.
The non-zero IF modes may or may not be useful to me, hard to tell if you can't take a look at it.
The real goal for me is adding some measurement cursors and level readouts. CubicSDR constantly updates the spectrum displays. The dB markings are confusing unlabeled and a moving target.
Last edited by Paul314 on Thu Jan 01, 1970 12:00 am, edited 0 times in total.
Reason: No reason
Reason: No reason