No streaming channels in PothosFlow

[cjheath]

Forgive me, I'm getting started with Pothos.

I built all using HomeBrew, it all went nicely.
SoapySDRUtil --probe="driver=hackrf"
shows my device, so I added a SoapySDR Source in PothosFlow and set the driver to hackrf, and other parameters like receive frequency.

Obviously it won't start because there is nothing to do. So I added a BlackHole, but the SoapySDR block has no channel connection points to connect to anything, and I'm stuck.

There's almost certainly no bug in the code, but there is a big gap in the tutorial or documentation. Can someone please enlighten me, and perhaps also leave this issue as a request for more documentation?

[guruofquality]

Hackrf aside. When you add the block to the graph editor, a nub on the right side should appear, and it should have selected the "NULL" device. Are you saying that does not happen for you?

[cjheath]

That's right, the null device is selected, but no nub appears.

[guruofquality]

Thank goodness i added that traceback :-). It says that it locked up trying to query some information about the block. Its probably some misbehaving driver. At this point I would look at the modules listed in SoapySDRUtil --info, and removing one at a time until it starts behaving. And I guess go from there.

[cjheath]

Ahhh, I assumed it could not start processing the block because it had no output connected.
I have this:

os> SoapySDRUtil --info
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.7.0-release
API Version: v0.7.0
ABI Version: v0.7
Install root: /usr/local
Search path:  /usr/local/lib/SoapySDR/modules0.7
Module found: /usr/local/lib/SoapySDR/modules0.7/libHackRFSupport.so (0.3.3)
Module found: /usr/local/lib/SoapySDR/modules0.7/libaudioSupport.so  (0.1.0)
Module found: /usr/local/lib/SoapySDR/modules0.7/libremoteSupport.so (0.5.0)
Module found: /usr/local/lib/SoapySDR/modules0.7/librtlsdrSupport.so (0.3.0)
Available factories... audio, hackrf, remote, rtlsdr
Available converters...
 -  CF32 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS16 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS32 -> [CS32]
 -   CS8 -> [CF32, CS16, CS8, CU16, CU8]
 -  CU16 -> [CF32, CS16, CS8]
 -   CU8 -> [CF32, CS16, CS8]
 -   F32 -> [F32, S16, S8, U16, U8]
 -   S16 -> [F32, S16, S8, U16, U8]
 -   S32 -> [S32]
 -    S8 -> [F32, S16, S8, U16, U8]
 -   U16 -> [F32, S16, S8]
 -    U8 -> [F32, S16, S8]

[cjheath]

What needs turning off and how do I do it? It is necessary to hide or remove the libraries?

[guruofquality]

you could rm /usr/local/lib/SoapySDR/modules0.7/libaudioSupport.so, or brew remove the package that provided that file. I'm personally suspicious of audio, but I guess we will find out.

[cjheath]

I renamed /usr/local/lib/SoapySDR/modules0.7/libremoteSupport.so and the error does not occur.
libaudio and librtlsdr seem to be ok to remain. Now I can select the HackRF, yaay team :)

I need to read further to configure blocks for a receiver, e.g. FM broadcast band. Is there a library of standard or common dataflow graphs anywhere?

BTW, total respect for building such a major bit of software and making it FOSS. I've also MIT open-sourced projects that involve multiple years (full-time) work, so I know what a big thing it is. Let me know how I can help. I'm competent in C++ (but not Boost or DSP) and have significant skills in RF design, and an advanced amateur radio license. I'd like to see a platform like this that uses a web API (rather than Qt) for constructing and running a dataflow pipeline.

[cjheath]

Never mind. I'm playing with https://github.com/pothosware/PothosDemos/wiki/Simple-FM-Demod
Not getting demodulated audio yet (just noise), but everything else seems to be working.

[cjheath]

Switching the exact same flow graph to use RTL-SDR works perfectly. So there seems to be a problem in the SoapySDR->HackRF support. And before you ask, the HackRF one works fine under Gqrx - but it can't get audio at the zero IF (centre) frequency, so perhaps that's the problem.

[guruofquality]

I'm seeing the SoapyRemote lock up on some apple mdns api call on this HighSeria vm. So maybe thats what you are seeing. Which is odd because this is the exact VM I developed it on. Maybe something updated... looking into it.

• MDNS lockup on OSX - DNSServiceProcessResult SoapyRemote#61

I need to read further to configure blocks for a receiver, e.g. FM broadcast band. Is there a library of standard or common dataflow graphs anywhere?

Basically just the demos. Theres random stuff out there on internet forums. We need more demos :-) pothosware/PothosDemos#2

BTW, total respect for building such a major bit of software and making it FOSS. I've also MIT open-sourced projects that involve multiple years (full-time) work, so I know what a big thing it is. Let me know how I can help. I'm competent in C++ (but not Boost or DSP) and have significant skills in RF design, and an advanced amateur radio license

I generally avoid boost because its a big dependency and C++ has come a long way (thanks to boost FWIW). Ironically, the PothosComms could probably use the most work. Although I do support DSP operations through gr-pothos and pothosliquiddsp as well.

If you are interested in testing things, developing blocks, packaging things that arent packaged. Theres tons of stuff. And I spend a lot of my free time maintaining the bitrot, the obscure platform issues, packaging debs, for windows, and fixing stuff after pull requests dont quite get all the details rights... :-P Sure I will take help where ever I can get it.

I'd like to see a platform like this that uses a web API (rather than Qt) for constructing and running a dataflow pipeline.

That would be great. Personally I think the gui design needs a lot more options. It does real-time evaluation of the blocks and topology, but ultimately I want to be able to 1) not rely on that, and 2) generate python/C++ code with and without GUI support. A web API is a big time investment too, but it might be really great. And it would still leverage all the existing framework, blocks, hardware tie-ins. So its easily something that could co-exist/compliment a Qt GUI.

Switching the exact same flow graph to use RTL-SDR works perfectly. So there seems to be a problem in the SoapySDR->HackRF support. And before you ask, the HackRF one works fine under Gqrx - but it can't get audio at the zero IF (centre) frequency, so perhaps that's the problem.

Maybe a gain issue? Blown PA? Or just high DC at the center? I think I developed this demo with hackrf in the first place using that big telescoping antenna that came with it -- I can check it out monday

Anyway, I hope that covers everything. I will try to figure out that lockup in the meantime. Please open another issue if you find something wrong, or think of a great idea, etc. - Best!

[cjheath]

It's a pity that the GUI and the evaluation are tightly coupled. I spent a big chunk of my career building software to help people keep presentation and application semantics decoupled, but the anti-pattern persists - and is even revived in web dev now! I envisage a flow API that allows construction of a general-purpose browser-side app. Sounds like that might be too big a job to bite off anytime soon. The benefit is that any web developer can produce new UIs, and any user can produce custom presentations.

Your video shows the simple FM demo using a LimeSDR - perhaps that is what you developed with?

My HackRF receives FM ok with Gqrx despite very weak signals levels from the very small antenna (not telescoping). The receive LNA is good (I just replaced it, see greatscottgadgets/hackrf#541 !) but I haven't tested whether SoapySDR is correctly turning it on. There should be an RF gain constraint in SoapySDR; 0dB or 14dB, not a slider. I don't understand how the SoapySDR's gain slider is working, so perhaps it just hasn't enabled the LNA. However, the DC level is too high and/or wide for FM demodulation to work at present. If I knew how to receive off-centre (use a Frequency-Xlating filter?) I could test whether the zero-IF DC is the culprit, or just the low signal due to no LNA activation. Will let you know what I find.