MyriadRF on Desktop

Apologies for not having spotted this sooner.

There's actually quite a bit of work been done on FPGA and software support for the Novena-RF module, but at the time of writing there remain a few wrinkles to iron out.

There is a driver plus SoapySDR host wrapper (which will also give you UHD compatibility via a module for this if you have it installed), and integration with GNU Radio is available via support folded into gr-osmosdr. Work has also been done on adding support to OsmoTRX (transceiver for the Osmocom GSM stack). Current status:

* Terminal GNU Radio applications work, but if you run an ASCII FFT plotter a spike can be seen at center frequency.
* wxPython GNU Radio applications suffer performance issues, but we've ruled out the device/driver as the same holds true if you plot a software noise source.
* There is a bottleneck in feeding samples to the GSM transceiver. More work needs to be done to work out where this is and it may even be related to something as simple as compiler optimisation of dependencies.

I'd encourage folks to have a go at building the driver and testing out GNU Radio applications.

  https://github.com/myriadrf/Novena-RF/t … ter/driver

And of course would be interested to hear of any thoughts on outstanding issues.

Regards,

Andrew
Myriad-RF Community Manager

Hahaha, a day after I worked my way through setting up NovenaRF, and suddenly there's a walkthrough. Typical

Couple of my notes: WX GUI elements are being deprecated because as you've noticed, they're pretty bad performance-wise. Use the QT equivalents instead (remember to change to QT GUI in the options box in the top left of a graph, or they won't work properly.)

Connecting a software source and sink together causes issues for other reasons; it's not connected to the WX performance. Basically there's nothing to tell gnuradio how fast to source/sink data, so it goes at 100% cpu and starves everything else. You need to add a Misc->Throttle block somewhere in the data path which only lets data through it at the configured samplerate. Hardware sources/sinks inherently provide/consume data at a fixed rate, so you don't need to add the throttle block.

Ah ok, then it's just the standard WX slowdown then, which is because those modules are written in Python rather than being natively compiled like the QT widgets are.

Turning the update rate right down in the options of a WX widget lets them work, but then you have 5fps or something equally horrible.

What do you get when you run:

$ SoapySDRUtil –make="driver=novena"

?

Strange. And you tried the ASCII FFT plotter command line exactly as in the post?

Suggest trying using something which makes use of the GrOsmoSDR blocks. Although this may still default to using the UHD API unless you temporarily move the SoapySDR module out of /usr/local/lib/uhd/modules, in which case you should definitely be using the Soapy API then.

Right, so that will be the Wordpress editor that converted the dashes, which is not the first time I've been caught out like that...

If you get stuck I'd appreciate it if you could post details to the Novena-RF forum.

I have the same results as pelrun using the uhd cli utilities.

osmocom_fft works but osmocom_siggen gives me this error which I would like to resolve:

built-in sink types: uhd soapy 
[TRACE] Register loopback test
[TRACE] Memory loopback test
GPIO122: set to 1
GPIO122: set to 1
spi mode: 0x0
bits per word: 8
max speed: 4000000 Hz (4000 KHz)
[INFO] Connected to Board on Novena | Firmware: ?  Device: Novena  Protocol: ?

[INFO] LMS6002: ver=0x2, rev=0x0
[TRACE] Actual sample rate 0.480000 MHz, enables=0x1f, 0x1f
meta-range is not monotonic

I was having the same issue -- somehow I'd missed the need to also do:
https://github.com/pothosware/SoapyUHD/wiki

(Looks like it isn't on the "Installing" page...)

The quickest and easiest way to fix the UHD path issue is just to set a symlink:

sudo mkdir -p /usr/share/uhd
sudo ln -s /usr/lib/uhd/modules /usr/share/uhd/

uhd_usrp_probe then works nicely, without needing to ensure environment variables are set properly.

Throttling wasn't present on the 3.17 kernel, it just makes the core issue more obvious. The WX GUI components are really slow and don't tolerate being starved of CPU very well, so it's best not to use them.

I just had the same problem because SoapyDevice.cpp never got built. You need to run ./configure with --with-soapy as an argument. You may also want --with-neon for better performance.
Of course you need to have SoapySDR installed beforehand.

It builds for me now. I didn't try it yet.