Some Problems and some Success with SoapyICR8600

[righthalfplane]

I am using the latest version the PothosSDR stuff so the Support library is put into -

C:\Program Files\PothosSDR\lib\SoapySDR\modules0.8

On Windows 7 -

CubicSDR worked fairly well with the SoapyICR8600 from 12/2/2020

CubicSDR no longer works with the SoapyICR8600 from 12/29/2020

SdrGlut works with both versions but crashes with a corrupt stack in icr8600Support when shutting down.

HDSDR runs OK.

SdrGlut and CubicSDR both have problems with the NBFM Weather channel 162.4 MHZ unless both the frequency and the center frequency are set to 162.4 MHZ. If the center frequency is off, it generates lots of noise and the width of the peak widens.

There are several other minor problems, but I see you are already working on some of them.

On Windows 10,

The "IC-R8600 I/Q Port (Wind WinUSB)" shows up correctly, but HDSDR says "Communication failed Cannot access Receiver". HDSDR shows the IC-R8600 information in the "device window" and it sets the frequency of the IC-R8600, but gets that error when trying to receive the data.

SdrGlut and CubicSDR both run on Windows 10 with some glitches. The antenna selection now works with the latest version. They both hang now if you set the sample rate higher than 960,000 SPS - that is strange since on Windows 7 CubicSDR ran at the full 5,120,000 SPS with no problem.

[robojay]

I am using the latest version the PothosSDR stuff so the Support library is put into -

Just to verify - the latest PothosSDR binary for Windows was released on December 28th, 2020: PothosSDR-2020.12.28-vc14-x64.exe Is this what you're running?

C:\Program Files\PothosSDR\lib\SoapySDR\modules0.8

I suspect you're building from source, but also to verify... Are you building SoapyICR8600 from source, or using the dll from the release directory on GitHub? The dll in the release directory is still for v0.7 of SoapySDR and doesn't contain the latest fixes.

I'll try to help out once you confirm these items. Unfortunately, I don't have a PC running Windows 7.

Your note under Windows 10 is concerning:

The "IC-R8600 I/Q Port (Wind WinUSB)" shows up correctly, but HDSDR says "Communication failed Cannot access Receiver". HDSDR shows the IC-R8600 information in the "device window" and it sets the frequency of the IC-R8600, but gets that error when trying to receive the data.

HDSDR uses the ExtIO drivers from Icom and has nothing to do with SoapySDR. If this configuration isn't working, I'm fairly certain the SoapySDR drivers/applications won't either.

One thing I have noticed is I occasionally need to manually power cycle my R8600 after using it under I/Q mode (even with HDSDR). Try that to make sure the radio isn't hung.

Do you have Icom's RS-R8600 software by any chance? When my radio hangs, the RS-R8600 software can't control it either.

Something else that will be helpful for CubicSDR... set the SoapySDR log level and run CubicSDR from the command line, saving log and error messages to a file:

set SOAPY_SDR_LOG_LEVEL=DEBUG CubicSDR.exe > log.txt 2>&1

--Jay

[robojay]

I just modified the getAntenna() and setAntenna() calls to operate based on frequency (see the latest pull request).

When I tried to run CubicSDR in my system, the getAntenna() call was failing (because I was outside the HF band) and CubicSDR didn't handle the empty string return value gracefully.

The latest modifications should help that.

[robojay]

There are a couple other issues with CubicSDR.

I recommend disabling Automatic Gain Control for now - not sure if the gain strategy in the driver matches well with what CubicSDR is trying to do (may need to revisit the driver's gain strategy).

Changing parameters while running CubicSDR seems brittle, and stopping/restarting the device generated some errors. I'll look into that further.

[robojay]

Probably should create a new issue... recording here for now...

The driver doesn't play well if function calls are made from different threads, which is what I suspect is happening a lot in CubicSDR, and maybe less so in other applications. I need to look at other SoapySDR drivers to see how they deal with this.

With debug mode at the TRACE level, I can see function call overlap which causes issues (i.e. the responses back from the R8600 are going to the wrong function).

[righthalfplane]

I wrote SoapyNetSDR for pothosware. I worked partly from SoapyHackRF. You write the code to be thread save and you lock the operations where there may be a conflict.

I was using PothosSDR-2020.01.26-vc14-x64 on Windows 7 and Windows 10. SdrGlut worked with the version of icr8600Support that I built on both Systems. CubicSDR only worked with the version of icr8600Support that I built on Windows 10. Neither worked with the version of icr8600Support that was included with SoapyICR8600.

I upgraded to PothosSDR-2020.12.28-vc14-x64 on both systems and icr8600Support crashes on both system with CubicSDR and SdrGlut. However, all of my other devices, HackRF One, RTL-Stick, LimeSDR Mini, RSP1, RSP1a, RSP2 , RSPDuo all work fine with PothosSDR-2020.12.28-vc14-x64 on both Windows systems (and many others) with CubicSDR and SdrGlut.

[robojay]

Thanks - I have some work to do... none of the driver is thread safe. Not surprised that its crashing on you.

[robojay]

I suspect the older version was working for you because most of the "set" functions didn't do anything yet - no access conflicts.

[robojay]

I have a pull request that is a rough stab at using mutexes similar to what was done in the HackRF driver.

This seems to fix my CubicSDR crashing issues.

@righthalfplane if you get a chance to build this version, let me know how it works for you.

Demodulated signals are still not completely correct and need more investigation.

[righthalfplane]

I grabbed a new version this morning. On Windows 10, It now partly works with SdrGlut and CubicSDR. I have to build my on version of icr8600Support, yours does not work. With SdrGlut, it crashes if you try to close icr8600Support down. With CubicSDR, it crashes if you try to swap devices from the IC_R8600 to a RTL-stick for input. With SdrGlut, it crashes if you try to use a sample rate of greater than 960000 SPS.

[robojay]

Yes - you still need to build icr8600Support from source, and place it in the appropriate locations. There is no pre-built release DLL in the latest updates.

It may be a couple weeks before I get back to this. The whole streaming side of the driver needs work. I am fairly confident the way it is done now doesn't work correctly (i.e. synchronous/blocking WinUsb_ReadPipe calls). I'm also fairly certain we're dropping data all over the place. What amazes me is how well FM demodulation still works when this happens.

If I send an constant CW carrier with one radio, and monitor it with CubicSDR, the carrier frequency warbles. The same setup works fine using the Icom ExtIO driver and HDSDR.

@righthalfplane Thanks for checking... I'll add your findings to my list of things to check.

[righthalfplane]

I took a shot at controlling the R6800 with libusb - It worked on Window, I changed the mode status and received the ACK. However after making the changes that seemed necessary for linux - it times out and does not do the Bulk transfers. Here is the windows version with the linux stuff commented out. -

include

include

include

include <libusb-1.0/libusb.h>

// cc -o usb usb.c -lusb-1.0

int sub();

int main() { libusb_device_handle *handle;

//sub();

int r = libusb_init(NULL);
if (r < 0)return 0;

handle=libusb_open_device_with_vid_pid(NULL,(uint16_t )0x0c26,(uint16_t )0x0023);
//handle=libusb_open_device_with_vid_pid(NULL,(uint16_t )0x0c26,(uint16_t )0x0022);
if(handle == NULL){printf("libusb_open_device_with_vid_pid failed\n");return 1;}

int e=libusb_claim_interface(handle,0);
if(e != 0){printf("libusb_claim_interface error %d\n",e);return 1;}

//e=libusb_set_interface_alt_setting(handle,0,1);
//if(e != 0){printf("libusb_set_interface_alt_setting error %d\n",e);return 1;}

{
    unsigned char cmd[] = { 0xFE, 0xFE, 0x96, 0xE0,  0x1A, 0x13, 0x00, 0x01,  0xFD, 0xFF };

    int transferred;
    transferred=0;
    e=libusb_bulk_transfer(handle, 0X02,cmd,(int)sizeof(cmd), &transferred,1000);
    if(e != 0)printf("libusb_bulk_transfer1 %d\n",e);
    printf(" transferred %d\n",transferred);
    transferred=0;
    e=libusb_bulk_transfer(handle, 0X88,cmd,(int)sizeof(cmd), &transferred,1000);
    if(e != 0)printf("libusb_bulk_transfer2 %d\n",e);
    printf(" transferred %d\n",transferred);

}

if(handle)libusb_close(handle);

printf("Done\n");
return 0;

}