Used SoapySDR to simultaneously control 5 SDR Devices, but -
righthal...@gmail.com
Josh Blum
I used SoapySDR to simultaneously control a HackRF One at 20 MSPS, a sdrplay RSP2 at 10 MSPS, a Lime-mini at 40 MSPS, a RTL stick at 2 MSPS and a NetSDR at 2 MSPS. The core routines in SoapySDR appear to be very stable, but some of the individual drivers seem to have problems.
1). HackRF One, did not see any problems
2). RTL-stick , did not see any problems
3). Lime-mini, had to be plugged and unplugged to between uses - (a patch is posted on Myriad-RF Discourse)
4). Sdrplay, would not run a rsp1 and rsp2 at the same time. When a SoapySDRDevice_enumerate command is issued, the sdrplay errors a few times and then starts outputting zeros. SoapySDRDevice_enumerate command has no ill effect on any of the other devices.
This is a known problem with the mirics driver "mirsdrapi-rsp.h",
it just cant support multiple open devices. It uses a global
device handle rather than returning a handle and passing it into
each call. The suggested work around is to spawn a SoapySDRServer
for each SDRPlay and to go through the server. Effectively
isolating the SDRPlay to one per process.
5). NetSDR, the discover routine does not worked ( I wrote a replacement and posted it ), SoapySDRDevice_readStream always returns 256 samples even when less samples are requested, this causes buffer flows. I padded my buffers for this, but the sample rate is then wrong and the sound eventually gets far enough out of sync that it dies.
The netsdr support is basically just gr-osmosdr's netsdr wrapped up: https://github.com/osmocom/gr-osmosdr/blob/master/lib/rfspace/rfspace_source_c.cc
Any fix should be up-streamed to gr-osmosdr, but in the meantime, if you have a fix I can also pull it into SoapyOsmo which is really just a copy which I keep sync'ed up with gr-osmosdr anyway. But I can do that pretty readily if you send a pull request: https://github.com/pothosware/SoapyOsmo
I'm not sure about the sample issue, its either in gr-osmosdr, or possibly in the SoapyOsmo code calling into that. I will double check the logic in SoapyOsmo, but I think it should just pass the number of elements right into the work function in gr-osmosdr anyway: https://github.com/pothosware/SoapyOsmo/blob/master/GrOsmoSDRInterface.hpp#L54
Work function here:
https://github.com/osmocom/gr-osmosdr/blob/master/lib/rfspace/rfspace_source_c.cc#L817
There is never enough time, but I think a native SoapyNetSDR
would be awesome. Its one of the few things left in SoapyOsmo that
didnt eventually get its own replacement project. And it could be
done without boost too :-P
https://github.com/pothosware/SoapySDR/issues/32
I ran all five for an hour with just NetSDR loosing its sound. Resetting the NetSDR to get the sound back, killed the sdrplay - so that it need to be reset also.
Thats great! Is there an official page for sdrglut? I have been collecting links on SoapySDR's wiki for various applications out there.
-josh
--
You received this message because you are subscribed to the Google Groups "Pothos Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pothos-users...@googlegroups.com.
To post to this group, send email to pothos...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pothos-users/75aaedae-f80b-48b0-9a7c-d50019f5ea9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
righthal...@gmail.com
Josh Blum
Hi Josh,
Thanks for the fast reply.
I have attached my version of rfspace_source_c.cc with my new NetSDR search routines. The old version stopped working on MacOS on some version before MacOS sierra. The CuteSDR version of the search was replaced some time ago. I converted his QT version back to straight UPD and TCP/IP and I replaced the boost routines calls with straight c++. That version only worked on the Macintosh. In testing, I found a different set of search parameters that also work on Ubuntu linux. So, it does two passes, one for the macintosh and one for the PC. My search routine even works on my old Macintosh Power PC.
I have written routines to directly access the NetSDR and could likely plug them into the Soapy format, but I do not know much about the rfspace USB devices and how to access them.
Hey Dale,
Well, I dont know much about the USB devices, but looking at the
code, it also looks like its just standard system open/close calls
for a tty serial device. -- and it seems like the usb support
almost should have been a separate wrapper altogether. Its just a
bunch if/else statements complicating the network implementation.
If I started a skeleton of a project on github for NetSDR, you
would be willing to fill it in with a regular C sockets
implementation of the NetSDR protocol?
I dont have a netsdr myself, but I have a fair bit of experience
getting sockets to work across platforms for SoapyRemote.
I tried to get SoapySDR working on msys2, but it failed because of two missing routines. One was the "glob" routine their libraries do not have it. I looked for it, but seems the be deeply embedded in the c++ libraries. The other missing routine was one of the fancy memory printing routine it may have been vasprintf. I just noticed that you have replacements for those routines hidden under _MSC_VER ifdefs - would those work under msys2 ?
The glob.h seems to be on linux/unix stuff and not on windows, hence there is an alternative implementation in that Modules.cpp source for windows. I think that a lot of the ifdef MSVC stuff may actually apply to msys. I think they provide a few more of these linux C libs, and are still lacking in some of the others.
My guess is that if you try to change some of the _MSC_VER to
_WIN32 for both the vasprintf and the glob.h case, you will get it
compiling -- that is if msys can build against windows.h calls
instead.
If thats what it takes, I would be happy to have that patch!
-josh
Dale.
On Sunday, March 17, 2019 at 2:02:23 PM UTC-7, righthal...@gmail.com wrote:
I used SoapySDR to simultaneously control a HackRF One at 20 MSPS, a sdrplay RSP2 at 10 MSPS, a Lime-mini at 40 MSPS, a RTL stick at 2 MSPS and a NetSDR at 2 MSPS. The core routines in SoapySDR appear to be very stable, but some of the individual drivers seem to have problems.
1). HackRF One, did not see any problems
2). RTL-stick , did not see any problems
3). Lime-mini, had to be plugged and unplugged to between uses - (a patch is posted on Myriad-RF Discourse)
4). Sdrplay, would not run a rsp1 and rsp2 at the same time. When a SoapySDRDevice_enumerate command is issued, the sdrplay errors a few times and then starts outputting zeros. SoapySDRDevice_enumerate command has no ill effect on any of the other devices.
5). NetSDR, the discover routine does not worked ( I wrote a replacement and posted it ), SoapySDRDevice_readStream always returns 256 samples even when less samples are requested, this causes buffer flows. I padded my buffers for this, but the sample rate is then wrong and the sound eventually gets far enough out of sync that it dies.
I ran all five for an hour with just NetSDR loosing its sound. Resetting the NetSDR to get the sound back, killed the sdrplay - so that it need to be reset also.
--
You received this message because you are subscribed to the Google Groups "Pothos Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pothos-users...@googlegroups.com.
To post to this group, send email to pothos...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pothos-users/0dd46cfb-f33f-49a5-8fb2-f2c527453229%40googlegroups.com.
righthal...@gmail.com
righthal...@gmail.com
Josh Blum
Hey Dale,
I started a github project for this: https://github.com/pothosware/SoapyNetSDR
I started filling in the skeleton, but I only got so far.
I actually copied in a wrapper I made around sockets for SoapyRemote. It takes care of all of the cross platform stuff. URL parsing, ipv6 and 4, header includes, common sock opts, resolving names, string to error messages, etc... So I hope that has some utility.
Its just basically these two APIs:
*
https://github.com/pothosware/SoapyNetSDR/blob/master/SoapyRemoteLibs/SoapyRPCSocket.hpp
*
https://github.com/pothosware/SoapyNetSDR/blob/master/SoapyRemoteLibs/SoapyURLUtils.hpp
Do you have a github account so that I can give you access?
Best,
-josh
--
You received this message because you are subscribed to the Google Groups "Pothos Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pothos-users...@googlegroups.com.
To post to this group, send email to pothos...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pothos-users/b2f14674-9ba3-4819-aef2-7689f2866bfe%40googlegroups.com.
righthal...@gmail.com
righthal...@gmail.com
On Thursday, March 21, 2019 at 6:22:16 PM UTC-7, Josh Blum wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to pothos...@googlegroups.com.
Josh Blum
Hi Josh,
I have a first working version, but I could not push it back.
I sent you an invite to join team "soapydev" on github. Once you
click accept you should get write access to the repo.
It works on MacOS and uBuntu, but the project errors in some system time template on windows 7 - that is not called directly and it does not to give any traceback - possibly a missing include file, but there is no way to tell.
Cool. I can definitely have a go with the windows stuff.
Best,
-josh
To unsubscribe from this group and stop receiving emails from it, send an email to pothos-users...@googlegroups.com.
To post to this group, send email to pothos...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pothos-users/890cbedd-ddfa-48c7-80b6-3c7a71346491%40googlegroups.com.
Josh Blum
Hi Dale,
I gave the project the works: https://github.com/pothosware/SoapyNetSDR/wiki
* wiki page updates
* msvc build working
* support selecting by serial
* added homebrew/windows build
I changed the discovery routine slightly to use the same socket for receiving all broadcast messages. I thought it was better to have all of the interfaces broadcasted on, and then just one single receive loop with a timeout. That way the discovery time doesnt grow for every interface on the system and end up blocking for seconds in some cases. I hope thats ok, I don't have the hardware to test, I wonder if you can make sure that has not horribly broken anything.
Also, can you check in some kind of license for the code so I can package and release it.
Best,
-Josh
To unsubscribe from this group and stop receiving emails from it, send an email to pothos-users...@googlegroups.com.
To post to this group, send email to pothos...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pothos-users/890cbedd-ddfa-48c7-80b6-3c7a71346491%40googlegroups.com.