Problems with SDR API 3.11 and DSDPlus

[venom6733]

Ive been using DSDPlus with Fastlane for quite a while now with my RSP1 & 1A. I had API version 3.07 but I had to upgrade it to the newest one which is 3.11. My RSP!A works fine but now my RSP1 serial number has changed and when I put it in the fmpp config file, it wont open and gives me the error of "cant open SDRPlay device 1 SDR device with serial number 0000B0001 is not present or already in use" I use to use the default 0000000001 and its worked fine until I had to update the API. The actual Serial number now is B0001P0002_0068F2F8 and thats exactly how i have it in the config file but the error message is saying a different serial than I have in the config file. I looked in the device manager under software defined radio and it has my rsp1 listed but doesnt show me the serial number in the properties. The RSP1 is working fine with sdr console and HDSDR so I know its functional

 

[morfis]

Does Dastlane say it supports the 3.07API?
I don't use Fastlane with my SDRplay devices but remember when the developer added support it was for a specific API at that time.

 

[PDXh0b0]

Have you tried using 0000B0001 instead?

 

[venom6733]

Does Dastlane say it supports the 3.07API?
I don't use Fastlane with my SDRplay devices but remember when the developer added support it was for a specific API at that time.

fastlane shows support for 3.07 but SDplay has released a few new versions of their API since then and now they are up to 3.11. The 3.07 stopped working on my SDRConsole and HDSDR and I had to upgrade to the newer API. I dont know if the maker of DSD is going to update their program to support it or not but I sent a email to the guys at DSD explaining what happened

 

[venom6733]

Have you tried using 0000B0001 instead?

yep....Ive tried about every way of putting the serial number in that I can think of. Im sure its because I updated the API. My RTL still works but I get better farther away results with my RSP's

 

[venom6733]

Its weird because when I put the RSP1 on the other computer I updated with the same API, it shows a different serial number for my RSP1 than the one I posted about above. So between the 2 computers, its showing 2 different serial numbers for the same RSP. My RSP1A shows the same serial number on both computers

 

[dave3825]

Can you post your FMPP-CC.bat and FMPP.cfg

 

[venom6733]

looks like the second part of the serial number changed again...the part after the '_'




Everything was working perfect until I upgraded the API from 3.07 to 3.11

As you can see in the error box, the serial number in the error box doesnt match the one in the config file but the serial number in the black box matches the one in the config file. Its not reading it right or something

 

[dave3825]

In FMP24 you can specify dongles and set the bat file to use the first available.

FMP24 -h
...
Options:
-i0 Use first available RTL SDR device [-i0]



I don't have a Rsp nor do I have FMPP on my system (so I can't run the help file) so I do not know if this would work in FMPP but you could try to change the -i1 in your FMPP.cc to i0 and see if that does anything.

 

[venom6733]

In FMP24 you can specify dongles and set the bat file to use the first available.

FMP24 -h
...
Options:
-i0 Use first available RTL SDR device [-i0]



I don't have a Rsp nor do I have FMPP on my system (so I can't run the help file) so I do not know if this would work in FMPP but you could try to change the -i1 in your FMPP.cc to i0 and see if that does anything.

well i tried it and got the error of "invalid command line parameter -'i0'

I guess ill have to go back to using rtl's...which arent bad but I got way better signals using my rsp1

Im not sure why i still have the -b12.5 still in there, it never worked for either rsp's or my rtl's...as soon as some talkes, it drops the bandwidth back to 9.5 regardless, even when i use the 'b' button to put it back to 12.5

 

[dave3825]

Can you plug both rsp dongles in and post that start up screen showing the sdr device count?

 

[venom6733]

ill try doing that later, I have to leave for a bit but SDRPlay just wrote me back and it sounds like there isnt much I can do about it because since API 3.08, they made it so the RSP1 generates a random serial number every time. If thats the case, theres not much I can do.

heres the email


"The RSP1 has no embedded serial number. The only record of the actual S/N is the label printed on the underside of the unit

The problem that this created is that if the user has two RSP1s, then there is no way to distinguish between the two devices.

A change was implemented in v3.08 of the API to generate a 'random' S/N for each RSP1 in software to allow the two devices to be distinguished.

Clearly this has implications for other software that we were unaware of and in fact, you are the first person to flag this as an issue."

 

[dave3825]

Clearly this has implications for other software that we were unaware of and in fact, you are the first person to flag this as an issue."

Clearly since FMPP is looking for a serial number in the config.

That sucks. But you say all worked well before updating the API? Can you roll back to the prior API?

SDplay has released a few new versions of their API since then and now they are up to 3.11. The 3.07 stopped working on my SDRConsole and HDSDR and I had to upgrade to the newer API.

What actually triggered that? Did you upgrade the sdr console and hdsdr to newer versions and those did not support the previous API??

 

[venom6733]

What actually triggered that? Did you upgrade the sdr console and hdsdr to newer versions and those did not support the previous API??

Well Im going to buy a RSPdx and the older API only supported RSP 1,1A and 2. I had to upgrade to API 3.11 so SDRConsole and HDSDR would see the new DX.

My 1A and my RTL's still work with DSD but Im a little bummed about not being able to use the RSP1 anymore with DSD...itll be ok since I know theres not much I can do about it since its getting random serial numbers assigned to the 1 now. I replied to SRPlay asking if there was a way I could put my own serial number in the rsp1 and they said 'all their rsp's have a EEPROM except the rsp1

 

[N9MKR]

Well Im going to buy a RSPdx and the older API only supported RSP 1,1A and 2. I had to upgrade to API 3.11 so SDRConsole and HDSDR would see the new DX.

My 1A and my RTL's still work with DSD but Im a little bummed about not being able to use the RSP1 anymore with DSD...itll be ok since I know theres not much I can do about it since its getting random serial numbers assigned to the 1 now. I replied to SRPlay asking if there was a way I could put my own serial number in the rsp1 and they said 'all their rsp's have a EEPROM except the rsp1

I kept away from 3.11 and only upgraded to 3.09... Is that an option for you? -N9MKR

 

[venom6733]

I kept away from 3.11 and only upgraded to 3.09... Is that an option for you? -N9MKR

The email I got from SDRPlay said they started assigning and random serial number to the RSP1 starting with API 3.09 so I still would have had the problem using the RSP1 with dsd with API 3.09. My RSP1A and my rtl's are still working with dsd and im fine with that. My RSP1 works on everything else like SDRConsole and HDSDR, it just doesnt work with DSDPlus because I cant put the serial number in the config file for the RSP1 because the newer API's (3.09 and 3.11) generates a random number every time.

The API 3.11 is working great so far for all my other programs that use my RSP's...I havent had any crashes or lockups or anything.

 

[dave3825]

The email I got from SDRPlay said they started assigning and random serial number to the RSP1 starting with API 3.09 so I still would have had the problem using the RSP1 with dsd

Anyway you could filter out your personal details and post that email here? Or forward a copy to the DSDPlus team? Maybe they could do something in a future release where that model could get treated like an rtl sdr dongle that does not require a serial number in its config.

 

[R0am3r]

I wonder if the SDRplay team could provide a code snippet that programmatically retrieves the RSP1 serial number (that they generated) for use in other software (e.g., DSDPlus Fastlane)?

I own the RSP1 and will soon be the owner of the RSP1A. It looks like I too will be stuck on the 3.07 API unless something changes.

 

[venom6733]

I wonder if the SDRplay team could provide a code snippet that programmatically retrieves the RSP1 serial number (that they generated) for use in other software (e.g., DSDPlus Fastlane)?

Well sdrconsole shows me the serial numbers of both the rsp1 and rsp1a and it’s listed in the device manager also but with Api 3.08 or newer, the api generates a new serial number every time the rsp1 is connected, that’s why I can’t use it with DSDPlus with the rsp1 because any API newer than 3.07 generates a different serial number each time. The rsp1a has a serial number already so it’ll work with dsd plus

 

[venom6733]

Anyway you could filter out your personal details and post that email here? Or forward a copy to the DSDPlus team? Maybe they could do something in a future release where that model could get treated like an rtl sdr dongle that does not require a serial number in its config.

Here’s the email


“The RSP1 has no embedded serial number. The only record of the actual S/N is the label printed on the underside of the unit

The problem that this created is that if the user has two RSP1s, then there is no way to distinguish between the two devices.

A change was implemented in v3.08 of the API to generate a 'random' S/N for each RSP1 in software to allow the two devices to be distinguished.

Clearly this has implications for other software that we were unaware of and in fact, you are the first person to flag this as an issue.

I am afraid that I have no idea why you are having a problem entering the new S/N into the configuration file for DSD+ Fastlane as this is not software that we use ourselves. I can only suggest that you revert back to v3.07 of the API, or contact the author of Fastlane to see if they can help you on using the alternative S/N that is created by later versions of the API. In the meantime, I will ask the S/W team the review this feature to determine how useful it actually is and whether we may be better to revert to the old approach in the next version of the API.”

Regards

Tech_Support