Topic: MyriadRF on Desktop

While waiting on my desktop model to be delivered, I was curious if there's any feedback / further info about the SDR board?  Anyone used it for something yet?

Re: MyriadRF on Desktop

mikem wrote:

While waiting on my desktop model to be delivered, I was curious if there's any feedback / further info about the SDR board?  Anyone used it for something yet?

I was wondering the same. So last weekend I tried to find some more info. I did find a few things, but less than I hoped for.
I think it boils down to studying the miradRF (non novena version) documentaton and analysing the differences in interfacing. Also, there is software on github for the novena version (see elsewhere on this forum).
As not many people actually have the hardware yet, few people actually tried it and wrote about it.

Also there are more projects that use the same 'rf' tuning chip, so they can be used as examples too. e.g I found this (having devices using the LMS6002D chip. But once the hardware actually is on my desk (and other desks), maybe we see more.

Roelof

Re: 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

Re: MyriadRF on Desktop

Blog post detailing how to install the Novena-RF driver and GNU Radio:

  https://myriadrf.org/blog/installing-th … gnu-radio/

Cheers,

Andrew

5 (edited by pelrun 2015-04-15 22:46:10)

Re: MyriadRF on Desktop

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

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.

Re: MyriadRF on Desktop

Apologies, I should have noted that a throttle was also in the path. With the software signal source everything seemed to work fine until I turned up the frequency and then the UI got progressively less responsive and jerky, before finally freezing.

IIRC I used this GRC graph:

  http://files.ettus.com/tutorials/labs/Lab_2.grc

Regards,

Andrew

Re: MyriadRF on Desktop

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.

Re: MyriadRF on Desktop

Hmm. Can't seem to run the commandline uhd utilities, I get this:

LookupError: KeyError: No devices found for ----->
Empty Device Address

Re: MyriadRF on Desktop

What do you get when you run:

$ SoapySDRUtil –make="driver=novena"

?

Re: MyriadRF on Desktop

That command works fine, returning the same output as on your page.

Re: MyriadRF on Desktop

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.

Re: MyriadRF on Desktop

Yeah, it was a direct copy-paste. (incidentally the SoapySDRUtil line you posted isn't valid - there's a single em dash before 'make=' instead of two dashes.)

Gnuradio seems to work with the gr-osmosdr source blocks, although I haven't got the settings right to actually see anything more than noise just yet.

Re: MyriadRF on Desktop

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.

Re: MyriadRF on Desktop

I've done a bit more poking around and it looks like it's just not picking up the uhd support module. osmocom_fft (using the gr_osmocom block) does seem to work, even though it gives a "cannot set initial frequency" error; I finally found a couple of spikes around 1.5GHz. So at least the SDR is picking up *something*. I can live with this, at least for the moment.

Re: MyriadRF on Desktop

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

Re: MyriadRF on Desktop

pelrun wrote:

Hmm. Can't seem to run the commandline uhd utilities, I get this:

LookupError: KeyError: No devices found for ----->
Empty Device Address

I had this problem as well. It's because the default .deb install of UHD is not set up to look for the SoapySDR module where it gets installed. You need to set the environment variable UHD_MODULE_PATH. On my box, after following the driver install instructions in the blog post on myriadrf.org, the correct path is:

/usr/lib/uhd/modules

Then you should be able to use uhd utilities with your Novena-RF.

Re: MyriadRF on Desktop

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...)

Re: MyriadRF on Desktop

wkumari - you don't need to do that step separately, SoapyUHD is built as a submodule of SoapySDR (though libsoapySupport.so doesn't get put where libuhd expects to find it).

arguably it's actually libuhd that's doing it wrong, since architecture-specific files shouldn't live under /usr/share...

Re: MyriadRF on Desktop

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.

Re: MyriadRF on Desktop

9600 wrote:

Apologies, I should have noted that a throttle was also in the path. With the software signal source everything seemed to work fine until I turned up the frequency and then the UI got progressively less responsive and jerky, before finally freezing.

I noticed this when hitting the thermal CPU throttling - everything would run fine with lower load, but once the frequency goes above some threshold or I use a larger FFT or the display window gets too big (boo unaccelerated video) the temp goes above 85ºC, the CPU gets throttled, and everything pretty much falls in a heap until things cool down again.

Now I keep a shell running with "watch grep . /sys/devices/virtual/thermal/thermal_zone0/{temp,trip*}" so I can start fanning the CPU when it's about to trip.

Re: MyriadRF on Desktop

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.

22 (edited by hash79 2015-06-28 23:58:09)

Re: MyriadRF on Desktop

I get the following error when trying to compile the Novena specific osmo-trx, anyone seen this? The non-Novena specific version of osmo-trx compiles fine for me and recognizes the Novena-RF but doesn't know what to do with it.

make[3]: Entering directory '/home/hash/SDR/osmo-trx/Transceiver52M'
  CXXLD    osmo-trx
osmo-trx.o: In function `main':
/home/hash/SDR/osmo-trx/Transceiver52M/osmo-trx.cpp:377: undefined reference to `RadioDevice::make(unsigned int, unsigned int, bool, double)'
collect2: error: ld returned 1 exit status

-Hash

Re: MyriadRF on Desktop

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.

Re: MyriadRF on Desktop

russm wrote:

wkumari - you don't need to do that step separately, SoapyUHD is built as a submodule of SoapySDR

This is no longer the case (since August 2015) when SoapyUHD and SoapyOsmo were removed as git submodules from SoapySDR. Now you need to clone and build those yourself after building SoapySDR.