Closed ast closed 6 years ago
I've written a module for FUNcube Dongle Pro Plus: https://github.com/ast/SoapyFCDPP/ Primarily for remote operation via a Raspberry Pi 3.
Hey thats great. That liberates FCD from a lot of dependencies. Let me know if you want to host it here and make it official.
Also, I see you wrapped libalsa? Have you considered opening/wrapping SoapyAudio for the streaming support. That might simplify things, or make porting easier on other systems. Depending upon how portable the libhid stuff is.
I'm facing a problem where I experience lag in the sample stream whenever I change center frequency or some other hardware property of the FCDpp. The FCDpp is controlled via HID messages using libhidapi and is not super quick. I get the feeling the setFrequency etc is called from the same thread as the sample streaming thread, or there is some locking involved.
At least with SoapyRemote, the settings will end up being in a different thread than the readStream. I dont know if thats an issue for FCD (probably not since its separate libhidapi for settings and libalsa for streaming). Does your application use separate threads as well?
Several of the SDR wrappers actually flush the rx samples when the setting is applied just to make the plotting more responsive. Which seems ok to me since the samples are basically undefined during centre frequency changes.
Hey thats great. That liberates FCD from a lot of dependencies. Let me know if you want to host it here and make it official.
Thanks! I'm definitely up for hosting it somewhere more official! Might need some more polishing though. I will look into SoapyAudio. Original goal was to have as few dependencies as possible. libhidapi is fairly portable, I think, at least I've used it on macOS and Linux.
At least with SoapyRemote, the settings will end up being in a different thread than the readStream. I > dont know if thats an issue for FCD (probably not since its separate libhidapi for settings and libalsa > for streaming). Does your application use separate threads as well?
Ok that's great. I've only used GQRX for testing (soapy=0,remote=hostname.local:1234
). GQRX seems to do threading right. At least I've never had a problem when using my FCDpp locally... I'm not using any threading in my Device subclass.
If I comment out the call that actually sends the HID message I don't get any lag so I'm starting to suspect there might be some congestion on the USB bus, which is a bit depressing...
Will look more into it and report!
Ok so I had some more time to look into this and I've tracked it down to what I think was a GUI bug i GQRX (GUI hang while waiting for getFrequency). After I pulled the latest GQRX it's much less noticeable. I guess they fixed something but I haven't tracked down the exact change. Sorry for trying to blame SoapySDR :-)
It's working very well now streaming 192kHz from a RBpi 3b.
Thanks! I'm definitely up for hosting it somewhere more official! Might need some more polishing though. I will look into SoapyAudio. Original goal was to have as few dependencies as possible. libhidapi is fairly portable, I think, at least I've used it on macOS and Linux.
When you feel like it, transfer the repo to my user guruofquality, and then I can move it to the oranization github.com/pothosware/. Dont feel-like anything needs to be 100% complete :-) I gave you repo access so you can read/write like a normal repo.
Otherwise thanks for investigating, closing the issue!
Ok I will do that!
On a side note, we are building a new open source Raspberry Pi "hat" SDR (larger than a normal hat). It's an FPGA based digital/analog hybrid approach TRX with 24bit ADC/DAC, 96kHz bandwidth. Aiming for SoapySDR to be it's "native" platform. More to come :-)
AST Sorry for hijacking your thread. I’m interested in your Pi hat TRX project, either as contributor, tester, or user. Do you have a project page or mote info?
Thanks! Jake
On Sep 25, 2018, at 6:32 AM, Albin Stigo notifications@github.com<mailto:notifications@github.com> wrote:
Ok I will do that!
On a side note, we are building a new open source Raspberry Pi "hat" SDR (larger than a normal hat). It's an FPGA based digital/analog hybrid approach TRX with 24bit ADC/DAC, 96kHz bandwidth. Aiming for SoapySDR to be it's "native" platform. More to come :-)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/pothosware/SoapyRemote/issues/51#issuecomment-424324154, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATqahdJ7MWxWdpzzsvX3tVHyUQ3SPBSjks5ueiJHgaJpZM4W1uz7.
No website yet but we will put one up very soon. Will also create a mailing list. This is a project I'm developing together with Daniel, SM6VFZ.
Some initial notes on his first version: https://sm6vfz.wordpress.com/dspsdr-with-fpga/
Was also covered in Elektor magazine in a 3 part series: https://www.elektormagazine.com/magazine/elektor-201707/40506
Here's a render of the new board, work in progress. Board size is "Eurocard". The board will also power the Pi (or Pi zero). We are aiming for very high dynamic range both in ADC and RF chain. The board also has an audio codec so you can connect a speaker directly to it.
@guruofquality I made some small tweaks and it's working very well now. Have only tested via a Raspberry Pi 3 over SoapyRemote. There are still some TODOs in the code but nothing serious. What I haven't resolved however is discovery of multiple devices. Maybe someone else can have a go at this.
I have transferred the repo to you and I hope others will benefit from it!
I've written a module for FUNcube Dongle Pro Plus: https://github.com/ast/SoapyFCDPP/ Primarily for remote operation via a Raspberry Pi 3.
I'm facing a problem where I experience lag in the sample stream whenever I change center frequency or some other hardware property of the FCDpp. The FCDpp is controlled via HID messages using libhidapi and is not super quick. I get the feeling the setFrequency etc is called from the same thread as the sample streaming thread, or there is some locking involved.
Another possible, more depressing, cause is that both samples, network and control is over the Raspberry Pi's USB bus...
I'm posting this issue and will also try to investigate the cause.