Re: Test sdrangel port for Mac OSX Mojave #osx

Fabio IZ0IBA 2220156

Hi Z, to briefly recap the whole :

There are some question about compilation process 
* Information about how to compile on OSX was definitely too short (Release build configuration with QT Creator ... that's it
* It is not clear if the sdrangel Application provide on its code all hardware libraries need for every devices or is dependent on other packages to be present and where they has to be found 
* Since many library are dynamic it is clear that you have to install other code before program run but this information is not so evident to people that normally do only (config, make and make install)
* The compiled binary rely on a specific library version and it is necessary to edit 
the .pro files and set all paths in the right way. 
* it should be nice to develop an abstraction layer that overcomes the need to recompile if some library has to be upgraded, probably exposing a common interface

Some question about the code itself
* Using Xcode as compiler many warning errors pops up, a huge amount of "implicit conversion change signedness", "use old cast style" "zero used as null pointer" 
"cast from ... drop cast qualifier"  "loss of precision in floating point operations"  "using == or != for floating point comparison is unsafe" and others....  so it not clear to understand if some behaviour are dependent on this warning or not.   Code is not commented, so to understand what happen in an event driven threaded application is not easy. 

To be more specific i am building a release for the LimeSDRmini.  Weird things happen ... first the device sometime is recognised as 2.0 device sometime as 3.0 ... this probably does not depend on sdrangel but may be libusb or some other hardware factor.  Device listing find as well the LimeSdrMini but also a normal LimeSDR, so the interface expose all controls for the huge parent of LimeSDRmini.  my guess is  that the LimeSDR is found by limesdr while the LimeSDRmini is found by soapysdr. Here the exposed gui is right.  However only the very first time is possible to start reception.  it you try to stop reception it is not possible to rearm it. This fact has been observed by few people. Also if you try to modify sample rate while receiving the system hang-up.

Now i have a test bed where to investigate for the problem but looking to the code is not so easy, especially about following the start and stop of threads.  My guess is that when fresh started the application is able to open device and reception start. When stopping some process does not release memory descriptor or some thread don't close, or is the library code that has some problem.  
An other problem i shown is that moving the gain slider all controls move by themselves (i upload a video about it) 

I would like to contribute fixing the LimeSDRmini device but i need some help to activate some debug trace and understand where is the point of the code where the troubles happen.  i am fixing many warning , maybe this is useful or not .. but surely don't do any damage to the code.  Using 0 as null pointer can lead to problem if some method is overloaded with different argument types.. in this case 0 can be interpreted as a number while nullptr is clearly a pointer.

At the end of the story ... rtlsdr works nice ... LimeSDRmini works (but only on fresh start) PlutoSDR works  HackRF does not so far.  other device are untested. 
73, Fabio IZ0IBA



Join to automatically receive all group messages.