pothosware / PothosSDR

Pothos SDR windows development environment
https://github.com/pothosware/PothosSDR/wiki
308 stars 48 forks source link

ADALM-PLUTO support #57

Closed i4cy closed 5 years ago

i4cy commented 5 years ago

I am trying to get ADALM-PLUTO working with Pothos Flow (PothosSDR-2018.07.04-vc14-x64). When adding a PlutoSDR Soapy SDR Source to Pothos Flow, the following error is continually announced...

[14:01:52.638000] ::1: ERROR: Unable to find host: No such host is known. [14:02:03.930000] ::1: ERROR: Unable to find host: No such host is known.

My Pluto device config.txt is configured such that the ipaddr and ipaddr_host is not set to the default 192.168.2.1 and 192.168.2.10 respectively. Do I have to specify the correct ipaddr in the "Device Args*" section of the Source? I'm guessing that currently only default config settings are supported by Pothos Flow, is this correct?

Also I have noticed that after exiting Pothos Flow the PothosFlow.exe and PothosUtil.exe (x2) processes remain. These processes have to be manually ended before a new instance of Pothos Flow can be executed. Perhaps the following error is related...

[13:49:06.086975] PothosFlow.EvalEngine: Detected evaluation thread lock-up. The evaluator will not function: EvalEngineImpl.cpp:182 void __cdecl EvalEngineImpl::evaluate(void)

The Pluto device seems to be working fine with the included CubicSDR application. I am new to PothosSDR and so I may be missing something obvious.

Great work BTW, thanks.

guruofquality commented 5 years ago

I already have an issue for this: https://github.com/pothosware/PothosSDR/issues/56

Any help testing potential patches https://github.com/jocover/SoapyPlutoSDR/issues/3 would be great

My Pluto device config.txt is configured such that the ipaddr and ipaddr_host is not set to the default 192.168.2.1 and 192.168.2.10 respectively. Do I have to specify the correct ipaddr in the "Device Args*" section of the Source? I'm guessing that currently only default config settings are supported by Pothos Flow, is this correct?

It looks like the SoapyPlutoSDR is implemented here, it should usually take the address somewhere in the device arguments if its a network device, just like any other device would. The hard coding is one issue.

Can you clarify this for me, I dont have a pluto, and i dont know how to test this, is the pluto a network or usb device, is it both, do they have different models, etc? It seems like if one or the other we can cleanup how the SoapyPlutoSDR wrapper works.

Also I have noticed that after exiting Pothos Flow the PothosFlow.exe and PothosUtil.exe (x2) processes remain. These processes have to be manually ended before a new instance of Pothos Flow can be executed. Perhaps the following error is related...

It tries to monitor devices in the background, this gigantic timeout for pluto is pretty catastrophic though. So the code isnt handling that well it looks like.

The Pluto device seems to be working fine with the included CubicSDR application.

Its stalling cubic's discovery fwiw, but its not getting anything stuck

i4cy commented 5 years ago

@guruofquality thanks for your reply. I quite understand it will not be easy testing PlutoSDR support especially if you don't have one.

I already have an issue for this: #56

Noted

Any help testing potential patches jocover/SoapyPlutoSDR#3 would be great

I certainly would be happy to conduct PlutoSDR patch testing on windows. Including the patch as described in https://github.com/pothosware/PothosSDR/blob/master/patches/soapy_plutosdr_network.diff

It looks like the SoapyPlutoSDR is implemented here, it should usually take the address somewhere in the device arguments if its a network device, just like any other device would. The hard coding is one issue.

I took a look at https://github.com/jocover/SoapyPlutoSDR/blob/master/PlutoSDR_Registation.cpp find_PlutoSDR() C++ method. As you say IPaddr and hostname are hard-coded. So I tried resetting the PlutoSDR to the default IP-address, and then tried adding a Soapy SDR Source in Pothos Flow. Now it does not result in "find host" errors. As you know there will be many cases where the PlutoSDR IP-address will not be set to default, so this will need to be patched.

Can you clarify this for me, I dont have a pluto, and i dont know how to test this, is the pluto a network or usb device, is it both, do they have different models, etc?

Both I believe, but it certainly implements RNDIS which provides a virtual Ethernet link over USB.

It seems like if one or the other we can cleanup how the SoapyPlutoSDR wrapper works.

I will also ask the SoapyPlutoSDR developer to add support for non default IP-addresses.

Many thanks.