Novena main board with a prototype Myriad-RF module bottom-right

We were honoured and absolutely thrilled when Bunnie and Xobs saw our Novena RF module design and decided to add it as a stretch goal for the crowdfunding campaign.

We have to admit that, for a little while, we were unsure if the target of 200 pledges at the top 3 levels would be met, thereby enabling us to do a production run of our board. However, the goal was achieved 2 days before the campaign ended and, amazingly and much to our delight, at the final count there were no less than 365 qualifying backers!

After the campaign had drawn to a close we quickly moved on to next steps and worked with Bunnie to confirm that our board would properly fit the Novena enclosure, and he kindly arranged for a main board to be sent out to us for use in testing.

Azio designed the RF module and, not being ones to hang about, scheduled production of prototypes the moment we all agreed that everything looked in order. These arrived earlier this week, testing is already underway and at this point all the signs are positive.

We’re sending a module out to Bunnie to confirm the mechanical fit and for his own testing. Our focus will next turn to developing robust production test capabilities so that we can deliver in time for the rewards going out and while ensuring that all the modules shipped work first time.

With prototypes in-hand and a clear roadmap we’ve now put the Novena-RF into incubation, and will be reviewing the project status as the final boards ship.

It has been asked whether those who missed out on the campaign will be able to purchase an RF module for use with their Novena, and the intention is certainly to put the Novena-RF into general availability if it looks as though there will be sufficient demand.

We’d like to thank Bunnie and Xobs for giving us the opportunity to work together and to contribute to the development of the Novena ecosystem. I have to say, it’s pretty amazing what can be achieved in such a short timeframe, when open hardware takes the friction out of collaboration and everyone is working towards the same goal.

Finally, we’d like to thank everyone who backed the campaign and we’ll be keeping out an eye out on the Novena forums for any questions relating to the module.

Andrew

The RASDR project reached a new milestone! At the Society of Amateur Radio Astronomers (SARA) 2014 Annual Conference held at the end of June, the team presented several aspects of the project and gained tremendous support from attendees. Many new collaborators joined the project and prototype units were distributed. We now have RASDR units in the U.K., France, and the U.S.!

Spectrum collected by 20m telescope

With special thanks to Sue Ann Heatherly and Frank Ghigo at the U.S. National Radio Astronomy Observatory (NRAO) in Green Bank, WV, we hooked up RASDR to the 20m telescope that is part of the Skynet Observation Network. We observed a hydrogen absorption line near the M24 galaxy that has an observable ‘notch’ in the hydrogen spectrum. To the left is what the 20m telescope saw (link), and below what we were able to see with RASDR on a tapped-feed.

RASDR2 (DigiRED+MyriadRF) observing M24 Maser Absorption along with the 20m telescope at NRAO

We’ll be writing up this experiment in the next issue of the SARA journal.

The project is gearing up to do a production run of 100+ units. Our manufacturing plan to distribute RASDR as a kit relies on SARA volunteers and a kickstarter-inspired funding approach: SARA is accepting pledges to purchase the kits. When 100+ pledges are collected, they’ll turn into purchase orders and SARA will collect the funds and start the first production cycle. The kits would be sent out in 60-90 days from the start of the production. The kits will have everything you need to assemble RASDR and check correct operation with your systems. There will even be a radio astronomy experiment guide to help you get started in the exciting world of amateur radio astronomy!

For more details, visit the RASDR project webpage or contact the SARA Treasurer to pledge your interest in obtaining a RASDR kit.

We are pleased to report that Radio Astronomy Software Defined Receiver (RASDR) has graduated from incubation to become a fully fledged Myriad-RF project. It is just a little over 6 months since the project joined Myriad-RF, but it should be noted that it had been in development for some time prior to this and was then at a fairly advanced stage.

The decision to graduate RASDR was made following review with the project team of outputs, progress to date and the project roadmap. At present this is a reasonably informal process, but there are plans to develop a simple set of common criteria, that will help to maintain standards and minimise risk, without introducing needless bureaucracy.

To find out more about RASDR see the introductory blog post and recent update (includes details of how those interested can obtain their own kit).

Parallella SDR Transceiver Daughter Card

Created by Azio - design files on GitHub.

The Parallella-RF module is based on the original Myriad-RF 1 design and has been adapted for use with the Parallella many-core computing platform.

Hardware has not been manufactured as yet and above can be seen a plot of the board.

Interest in a manufacturing run is being gauged via an online poll.

Summary

Transceiver                             LMS6002D

RF Bandwidth (BW)              300 MHz to 3800 MHz

Baseband BW                         Programmable (16 selections); 0.75 – 14 MHz, Bypass mode

Clock                                        TCXO

RF Connectors                        SMA

Communication

The LMS6002D register are controlled via SPI interface and samples are transferred via the Zynq FPGA.

Configuration

The module is pre-configured to work on UMTS band-1, the most common band used by 3G communications equipment. However, it can be configured to run on any mobile frequency band or standard by setting up the LMS6002D registers to the required frequency, gain or BB bandwidth.

A new design enters incubation for a daughter card that adds 300MHz-3.8GHz wideband SDR TX/RX capability to the Parallella many-core computing platform.

Azio recently completed the design for a new board which is based on the Myriad-RF 1 module and that turns the Parallella computer into a compact, powerful SDR platform.

Gen1.1 Parallella board with Zynq 7020 SoC and 16-core Epiphany III 

With its credit card-sized form factor, energy-efficient 16-core floating-point accelerator, plenty of high-speed I/O and a SoC that integrates a dual-core ARM host and FPGA, the Parallella platform is well suited to SDR applications.

As with the Novena-RF, this new RF module design also demonstrates how the Myriad-RF 1 Reference Hardware can be adapted for custom applications with relative ease, in addition to being used as-is and with interface boards for prototyping.

Interest in a manufacturing run of the RF daughter card is being gauged via an online poll and if you’d like to be notified when the board goes into manufacture don’t forget to enter your e-mail address. Further details and a link to the GitHub repository can be found on the project page. Feedback is invited and can be left here and via the issue tracker.

We’re delighted to announce that the Zipper board — an interface adapter which enables the Myriad-RF 1 module to be used with an FPGA development system with either an FMC or HSMC interface — is now available for purchase.

At present Zipper can be bought from DigiKey and direct from Azio, and additional distribution is being put in place.

Project update

The firmware sources for Zipper were recently published to the myriadrf-boards GitHub repository, alongside the hardware design files.

Work is currently under way to add support for using Myriad-RF 1 + Zipper with ZedBoard, and further details will be published in due course.

— Andrew

The post Zipper now on sale and firmware sources published appeared first on Myriad.

Those who have visited the Myriad-RF website over the last couple of weeks will have noticed that there have been some major changes, whereas those who haven’t until just now may have spotted that we’ve been reasonably quiet over the last few months. However, after much hard work, lots of testing and a few tweaks, we’re now pleased to be able to finally make a proper announcement!

Main site

The main website had been completely overhauled and is now a responsive design that should provide a much better experience across a wide range of devices. The way projects are presented has also been greatly improved, with commits being pulled in from GitHub and better structuring of resources. Projects can also now be navigated via status, type and application.

Wiki

Previously the wiki was provided via a WordPress plug-in, which was far from optimal and was always intended to be an interim solution. The old wiki has now been replaced with MediaWiki running on its own subdomain, which provides many additional and improved features.

Forums

The forums were also previously provided via a WordPress plug-in, but now they are being hosted using the excellent Discourse software, once again running on its own subdomain. All the existing posts have been migrated across, along with user accounts. However, if you have an existing account you will need to reset your password.

Finally, all of our web assets are now HTTPS by default for increased security.

The Future

With the new infrastructure now in place we’ll next be turning our attention to project documentation and developing a governance framework. In the meantime you’ll have to bear with us as documentation is added to the wiki, and if you would like to get involved with the governance effort please introduce yourself via the forum.

Lastly, a huge thanks to the guys at Losource for all their hard work!

Andrew

The post New website and community resources! appeared first on Myriad.

The original Myriad-RF 1 module uses a compact, high-performance 80-pin Hirose connector that is designed to meet the IEEE802.3ap backplane link for 10G Ethernet compliant signal channels. The mating connector is then used on the two interface boards that are also part of the Reference Development Kit (RDK), along with the Zipper board that is part of the RASDR project.

This interface is termed the Radio Frequency Digital Input Output connector (RFDIO).

Since all our designs are made available as open source hardware it’s possible to study these if you wish to create a new interface card or host for use with the Myriad-RF 1, or perhaps a new RF module for use with an existing carrier board. However, this process has now been made even easier as we’ve published the mechanical and electrical specification for the RFDIO connector.

The RFDIO Connector Specification can be found in the RDK GitHub repository. Suitable footprints for the KiCad EDA software are provided via the Components Libraries project.

New designs that adhere to the RFDIO Connector Specification should be compatible with the RDK. However, note that while the Novena-RF uses the same Hirose connector, this is not electrically compatible with RFDIO and in turn RDK or Zipper interfaces.

Feedback and implementation questions should be directed to the RDK forum.

It goes without saying that we’d love to hear from anyone who makes a compatible board!

— Andrew

The post RFDIO Connector Specification Published appeared first on Myriad.

The LMS7002M is a dual transceiver containing just about everything you would want in a radio. Programmable clocking and synthesizers, built-in ADCs and DACs, highly configurable signal processing chains with interpolation and decimation. Capturing this into a higher-level user driver means taking on an intimate understand of this extremely flexible, and highly complex part. So how does one get started?

Fortunately, the LMS7002M is organized into separate sections with well defined boundaries. And the diagrams for each section clearly point out which registers are responsible for control for the components within the section at hand. The driver development basically mirrors these sections. So, starting with one section at a time, I began working with the external data IO interfaces, clock generation, and gradually pushing my way into the direction of the RF sections. Now, the new C driver may not initially cover all of the LMS7002M capabilities, but because the driver is organized into well-defined sections, there is a very structured way for anyone to come along and to add new functionality to the driver.

There are 1000s of registers spread across a 16 bit address field, many of which are actually shadow registers, duplicated for the dual channels A and B. To avoid careless mistakes involving bit shifts and masks, this part of the code is completely generated. So, I went through the painful task of manually transcribing the register map into a JSON format which I used to generate a data structure for all registers, and utility functions to pack and unpack these registers into the 16 bit formatting used inside the LMS7002M. This makes the code a great deal cleaner and easier to spot errors. I only wished that lime had provided some sort of register spreadsheet (or PDF that could be copied with table order intact) to simplify this transcribing step.

I have had my share of adventures discovering typos in the data sheets and magic registers, and I am sure there are more to come. However, this one really threw me off and I initially thought it was a typo. So, for the most part, receive and RX mean antenna to baseband, and transmit and TX mean baseband to antenna. So it really caught me off-guard when the data sheet used the same terms in reverse for the external data interface. The output data interface for the LMS7002M is called TX because its transmitting “receive” data from the RFIC to the BBIC (and vice-versa). Its typical to run into these sort of naming-perspective problems when dealing with flows of data. I think using a naming convention like RF2BB and BB2RF could help clear things up.

So at this point in time, I have the EVB7 evaluation board for the LMS7002M hooked up to a MicroZed through a FMC carrier card. I have interfaced the Zynq FPGA to the LMS7002M TX and RX data interfaces. There is a SoapySDR wrapper in the works that demonstrates how to configure the LMS7002M using the new C driver. Teaser screenshot attached of the LMS7002M streaming RX data from its internal test signal generator.

More great progress to come!

For further details see the LMS7002M Control Driver project page.

The post Introducing the LMS7002M Control Driver appeared first on Myriad.

We were honoured and extremely privileged to have received the first Novena Laptop off the production line! In this post we take a look at the final assembly which needs to be done upon receipt of the laptop, including fitting the Novena-RF module and bulkhead mount RF connectors.

Please note that this is not meant to be a comprehensive assembly guide and you are strongly advised to consult the official guide on the Novena wiki before attempting assembly!

Contents

The Novena Laptop came supplied in a fairly unassuming cardboard box.

However, upon opening the box, removing the contents and discovering a printed set of schematics, it quickly becomes apparent that this is no ordinary laptop!

A smaller box could be found inside which contained a mains charger, fixings, thread lock, loudspeakers, an SD card “fuzz” adapter, various other hardware and, of course, the RF module.

One nice touch was the inclusion of hand tools, with another being that a blank “port farm” panel is provided for use with custom projects.

The laptop itself came supplied mostly assembled, complete with battery pack and SSD etc. in place and cabled up. The wiki guide takes you through the process of fitting the LCD — and attempting this is strongly discouraged until you have read the caution on handling the rather fragile panel.

The LCD can be seen above in its protective packaging, along with a second display bezel that is green instead of blue and with an extra cut-out for expansion cards that require this for I/O ports.

Fitting the RF module

Before the Novena-RF module could be fitted the General Purpose Breakout Board (GPBB) had to be removed from the main board expansion port.

This involved lifting the Kapton tape which had been used to secure the WLAN antenna coax to the GPBB, before removing the three screws securing the board and then the board itself.

We decided that we wanted to cable the RF module up to bulkhead mount SMA connectors, and to locate these on the front of the laptop enclosure where there is a removable panel, with the module situated just behind this. Calipers were used to mark out the panel reverse with the drill centres.

The SMA connectors were then fitted, the panel replaced and the U.FL connectors attached to the RF module.

Fitting the screen

Care is required in fitting the screen to ensure that it is not damaged. Completing this step didn’t take very long at all, nor was it difficult, but it should not be rushed.

With the LCD fitted it became apparent that its metal backing would be quite close to the top of the 0.1” pitch header pins on the RF module when the laptop is closed. So with this in mind Kapton tape was used to cover the pins to prevent shorting. It may be that this was not strictly necessary, but at this point we’d recommend taking similar measures just to be on the safe side.

First boot!

As soon as the Novena was powered on it booted straight into setup for Debian GNU/Linux. A few basic questions concerning locale etc. out of the way, we were up and running with a graphical desktop. The first job then being to run update to get the latest versions of installed software.

SDR support

Josh Blum is in the process of developing:

• FPGA support for the Novena-RF module and an accompanying kernel driver
• SoapySDR host wrapper and GNU Radio support via gr-osmosdr
• OpenBTS/OsmoTRX support

The FPGA design and kernel driver, along with host wrapper and GNU Radio support, have now largely been completed. However, there may still be a few bugs and opportunities for minor improvements. Those who would like to try this out now can find further details in the Novena-RF GitHub repo, and there will be another post on this here in due course.

The post Assembling the Novena Laptop appeared first on Myriad.

The Novena-RF daughtercard has a new driver to bring it into the ecosystem of SDR devices and applications.

The hardware

The Novena-RF daughtercard incorporates an LMS6002D from Lime Microsystems, which gives users receive and transmit capabilities between 300 MHz and 3.8 GHz. The Novena motherboard contains a quad-core ARM processor from Freescale (iMX6) and a Spartan6 FPGA from Xilinx (XC6SLX45). The FPGA bridges the daughtercard to the extended memory bus of the iMX6, and provides DSP operations and advanced streaming control.

Software support

The Novena RF uses Soapy SDR to provide an easy to use API and access to a variety of existing applications. Soapy SDR provides C, C++, and Python interfaces to configure, control, and stream to and from a SDR device. In addition, gr-osmosdr and UHD applications are also available to the user through the Soapy SDR compatibility interfaces.

Direct buffer access

The Novena-RF driver was just the use-case that I needed to create a direct buffer access API for Soapy SDR. Direct buffer access avoids copying or converting stream buffers by providing the user with a pointer to the internal stream buffer. In the case of the Novena-RF driver, the user can directly access memory mapped stream buffers on the FPGA — which hopefully saves some extra arm cycles for the application. See the Soapy SDR doxygen for more about the new buffer API.

Kernel module

The novena_rf kernel module is responsible for configuring the iMX6’s extended memory bus (EIM), FPGA register access, and providing the driver with memory mapped stream buffers. After appropriate permissions are set for the device nodes, the driver can be used with normal non-root privilege mode.

FPGA design

Timed streaming and burst controls

The framer block is used for advanced control of the receive stream with controls for burst size and precise timestamping. The de-framer block is used for transmit, and it supports precisely timed transmit bursts and asynchronous error reporting. Both blocks support variable sample widths, and make use of the AXI4 stream standard to be used with other compliant AXI4 IP such as FIFOs and DSP blocks. In addition, an accompanying C header provides packet formatting and unpacking for the host driver.

Up/down conversion DSP chains

The LMS6002D transceiver provides an ADC/DAC rate of 15.36 Msps to the FPGA. The down conversion chain provides configurable decimation down to 480 ksps, in addition it has DC removal and a CORDIC for frequency correction and LO tuning offsets. The up conversion chain also sports a CORDIC, and provides configurable interpolation from 480 ksps up to DAC rate.

Streaming with DMA controllers

Everything ties into the iMX6 though the EIM bus. Hanging off the EIM bus, we have a register interface and several DMA controllers which interfaces between stream and memory domains. The register interfaces controls everything in the FPGA, including DSP chains, DMA controllers, time tracking and interrupts. The framer block uses a pair of DMA controllers for stream control (input) and stream data (output). The de-framer block uses another pair of controllers for stream data (input) and asynchronous notifications (output).

Getting involved

Anyone interested in getting involved with the Novena-RF driver should take a look at the Novena RF issue tracker on github. The FPGA DSP chains could be improved for additional corrections, configurable rates, scaling, and configurable sample formats for the direct buffer access feature. And its worth experimenting and investigating the EIM configuration parameters, and DMA buffer caching to improve stream throughput.

Top image: development setup (with added hamster for scale!)

The post New driver for Novena-RF SDR appeared first on Myriad.

We are thrilled to announce that the STREAM board is the latest project to join the Myriad-RF family. A feature-packed FPGA development platform built around an Altera Cyclone IV device, this includes RFDIO and FMC connectors, enabling use with the Myriad-RF 1 transceiver, future modules and other FMC cards.

Stream with the LMS7002M EVB attached to the FPGA Mezzanine Connector (FMC)

A version of LMS Suite is provided for use with the LMS7002M UNITE board, which enables control of the transceiver and spectrum analysis via an FFT viewer, along with example waveforms which can be loaded into the FPGA.

Olof Kindgren has developed an OpenRISC SoC for the STREAM that is capable of running Linux, complete with a peripheral controller for interfacing RFDIO cards such as the Myriad-RF 1. This allows for a mixed development model whereby programming and control can be via the RISC processor, with baseband and digital processing taking place directly in the FPGA fabric.

STREAM OpenRISC SoC and Myriad-RF 1 dataflow.

Key specifications and features include:

• Cyclone IV EP4CE40F23C7N device in 484-pin FBGA
• 2x64MB (16bit) SDRAM
• Micro SD storage
• Micrel KSZ9021GN GbE controller
• Dual USB 2.0 host
• Cypress FX3 USB 3.0
• DVI transmitter with HDMI jack
• FPGA Mezzanine Card (FMC) LPC connector
• RFDIO (FX80P) high-speed connector
• GPIO header
• FPGA and FX3 JTAG

Dr Ebrahim Bushehri, Myriad-RF founder and CEO of Lime Microsystems commented:

“This is another step forwards in the development of both Myriad-RF and OpenRISC, and the implementation by Olof is a strong indicator of the innovation that is to come from open source communities working together. I foresee significant progress towards the Democratization of Wireless Innovation as the Open Source community gains access to this and similar platforms in the future.”

Stefan Wallentowitz of the OpenRISC project added:

“The OpenRISC community recently worked on a better processor core implementation and getting our software and toolchains straight, like the Linux port. We are really excited to see that this work is useful to a wider community. Myriad-RF is a very interesting project and we are really looking forward to deepen the collaboration of both communities.”

The board KiCad design and Gerbers, aluminium enclosure design, OpenRISC SoC and software sources have all been published to GitHub.

The STREAM board will be available for purchase via distribution.

The post Announcing the STREAM board appeared first on Myriad.

In this post we will walk through installing the SDR module driver on the Novena platform, along with GNU Radio, before finally testing this by running up a simple FFT plotter.

Before we start, please note that the canonical driver installation instructions can be found on GitHub and if you run into any issues consult these in case something has recently changed.

Packaged software

Much of the software that we need is available in the form of packages that can be installed from the Debian Jessie repositories via the magic of apt-get.

$ sudo apt-get install gnuradio gnuradio-dev uhd-host libuhd-dev cmake g++ libpython-dev python-numpy swig libboost-all-dev

At the time of writing this will give us GNU Radio 3.7.5 and UHD 3.7.3, with the development files for both, plus their dependencies and those of software we will later build from source.

Note that we do not install the Debian gr-osmosdr package, as we’ll be building a more recent version of the GrOsmoSDR software that includes support for the Novena-RF hardware.

Setting up the driver

The Novena-RF driver is built on the vendor and platform neutral SDR support library, SoapySDR. For info on this and the driver architecture, see the previous blog post from Josh Blum.

First grab the SoapySDR sources:

$ git clone https://github.com/pothosware/SoapySDR.git
$ cd SoapySDR
$ git submodule init
$ git submodule update

To build and install:

$ mkdir build
$ cd build
$ cmake ..
$ make -j4
$ sudo make install
$ sudo ldconfig

With SoapySDR installed we can now get the sources for the host driver, build and install this:

$ git clone https://github.com/myriadrf/Novena-RF.git
$ cd Novena-RF/driver/host
$ mkdir build
$ cd build
$ cmake ../
$ make
$ sudo make install
$ sudo ldconfig

Next we need to load the FPGA and kernel module, and set device permissions. Note that at the time of writing the pre-built novena_rf.ko module is for the 3.17.0-rc5-00238-gfb115dd kernel. A module for 3.17.0-rc5-00217-gfd79638 is also provided and to use this it must be renamed to novena_rf.ko. If you are running another kernel you will need to build it from source.

Assuming that we are running the gfb115dd kernel we just need to:

$ cd Novena-RF/driver/binary
$ sudo ./prepare_novena_rf.sh

At the present time this script must be run after each reboot. However, this could be improved upon via the creation of udev rules and contributions are welcomed!

If upon running the script you get an error with “could not insert module novena_rf.ko: Invalid module format”, this means you need to rename the gfd79638 module or build a new one from source. If you have recently installed or upgraded your system it will almost certainly be the latter.

At this point we should have a functioning driver and can confirm this with:

$ SoapySDRUtil –make="driver=novena"

If everything has gone according to plan you should get an output similar to that shown below.

We can now run up the ASCII art FFT plotter example that is provided with GNU Radio:

$ /usr/lib/uhd/examples/rx_ascii_art_dft --rate=1e6 --freq=1.8e9 --gain=30 –ref-lvl=-60

This should provide an output similar to the one shown at the top of this post.

At the time of writing we are seeing a spike at the centre frequency, which we suspect is due to some tweaking that needs to be done to the LMS6002D transceiver programming or calibration. However, we are looking into this and hope to have a fix relatively soon.

GrOsmoSDR

SoapySDR provides a module that adds support to the UHD driver that was developed for the USRP devices from Ettus Research. This means that it should be possible to run many applications that were developed against its API with little or no modification, such as the ASCII art FFT plotter.

However, SoapySDR provides its own API also and GrOsmoSDR adds support for this from within GNU Radio.

To install GrOsmoSDR:

$ git clone git://git.osmocom.org/gr-osmosdr
$ cd gr-osmosdr/
$ mkdir build
$ cd build/
$ cmake ../
$ make
$ sudo make install
$ sudo ldconfig

Since the blocks get installed to /usr/local and GNU Radio has been installed via packages to /usr, you will need to tell GNU Radio Companion where to look for them before starting it:

$ export GRC_BLOCKS_PATH=$GRC_BLOCKS_PATH:/usr/local/share/gnuradio/grc

Note that in testing we found that GUI apps built with WX can easily consume a lot of CPU cycles and as a result their controls become frozen. The same is true if we use a software signal source and sink connected together, which rules out the SDR hardware and associated I/O. It could be that the GNU Radio and friends packages available via the repositories are not fully optimized, or the cause could be something else altogether. Further investigation is required.

Final notes

We’d encourage people to test the driver and use with GNU Radio applications and others that use the UHD and/or SoapySDR APIs. A number of proposed enhancements have already been posted to the issue tracker and contributions are very much welcomed. As are reports of any issues encountered, along with successes running up your SDR application of choice.

Finally, I’d just like to take this opportunity to thank Josh Blum for all the amazing work he’s done!

The post Installing the Novena-RF driver and GNU Radio appeared first on Myriad.

Lets talks about drivers! Drivers exist to create a high-level interface for low-level hardware. Drivers are the intermediaries between hardware and applications. When they work well, you probably don’t notice them very much. And when they don’t, it can be a challenge to to figure out what went wrong.

Recently, we have seen the addition of the LMS7002M dual transceiver to the Lime Microsystems product family, and an accompanying addition to the open-source lms-suite software package. In this post, I will discuss the current state of the lms-suite drivers and  purposed improvements to the suite. And then we will open this discussion to the community forum to encourage feedback and the sharing of ideas.

Current LMS-Suite

The lms-suite is an open-source C++ driver and GUI application for the LMS6002D and LMS7002M RFIC transceivers. The driver provides an abstraction for the registers and higher level calls like calibration and tuning the frontend. In addition, there is a control panel GUI which provides detailed and well organized access to the various capabilities of the RFIC. The suite was flexible enough to be adapted into a stand-alone driver for the Novena RF board. That said, I have some criticisms of the software suite that I would like to bring-up to encourage a productive discussion, and possible restructuring of the driver to improve its utility for other developers.

• The code for the lms-suite is not organized into a stand-alone library. Instead, its more or less a part of larger GUI control panel. However, it was easy enough to separate out the relevant sources and compile them into the Novena RF driver.
• There is an abstraction for supporting arbitrary hardware. However, there is a bit of code that selects between several board-specific implementations. I felt that extending this to new hardware was either invasive and more challenging that it should be.
• The abstraction for hardware relies on a packet-like protocol and some specific state machines in an adjoining FPGA connected to the RFIC. I think this makes an assumption about the board design and how the RFIC is connected to the host.

Driver design goals

I have worked on drivers for hardware in the SDR realm for many years now. And from that perspective, here are some basic requirements that I would look for in a RFIC or similar support library:

• Low level language: A reusable driver library should always be written in a low level language like C or C++. The runtime-overhead, the size of the binaries, and the additional dependencies are all minimal. This gives the maximum flexibility to embed this into a hardware driver or end-use application.
• Minimal dependencies: Much like the above requirement, additional library dependencies (like a thread library) can be a burden. Those dependencies carry all the way over the end-use application and can make it potentially difficult to deploy on some systems.
• Hardware independent: The RFICs are configured with SPI and GPIO, but how the host can access to SPI and GPIO is potentially limitless. One device might use spidev on embedded linux machine, on another — a memory mapped FPGA core. The library doesn’t know how my hardware works, so I need a way to customize how the communication takes place.
• Open source code: Users will need to compile, embed, debug, modify, and hopefully upstream changes to the driver. And open driver is a necessity for development — and a requirement for some open-source licensing models.
• Good API abstraction: The vast majority of uses should be wrapped up in simple and straightforward API calls. We will always need low level access to registers for more complicated situations. But the idea is that most developers should be able to immediately access and test the functionality of the hardware without diving deep into the intricacies of register maps and multi-step configuration.

Suite restructuring

Given those design goals, and taking into account the issues I experienced with the current lms-suite, I would like to propose some changes to the suite. Hopefully, these changes are not drastic, but more of a guided-restructuring to streamline a developer’s experience to make the most out of code-reuse.

• Stand-alone library: I would take all of the core driver code, without the hardware specific parts, and without the GUI control panel, and stick it into its own clearly separable stand-alone library (lms-driver). Because this library will be the bare minimum, it will be easier to version control, create pre-built packages for it like debs, rpms, exes. Developers will be able to choose to use it as a library, or to simply embed the code wholesale into their application.
• Communication abstraction: This purposed communication abstraction is the place for all hardware-specific knowledge. It will be based around register and GPIO access, and possibly cover other misc niche cases. A developer will create an overloaded communication class for their specific hardware, and hand this object to the lms driver instance. All the driver instance understands is this interface to registers and GPIO. Several pre-existing overloads of this board communication class will stand as examples — like for the evaluation hardware.
• Very high level API calls: Without precluding advanced uses, I would like to see overly simplified high level access controls added to the driver API. Examples: initialization with automatic calibration, setting gains, filter bandwidths, clock rates, tuning the frontend. Even if the settings are sub-optimal, the goal is to give the developer the confidence that the hardware is working properly before getting deeper into the configuration.
• GUI control panel library: The graphical control panel application used with the eval boards is a really useful general purpose testing tool. We would like to make sure that anyone designing new hardware based on Lime RFICs would be able to make use of this GUI to test and validate their creation. I purpose that most of the GUI code gets moved into another hardware-independent library.
• Glueing it all together: The developer links together the lms-driver, a custom communication interface, and the GUI library into an executable graphical application. This means that the software for Lime-based evaluation board like EVB7 and a custom design can reuse 99% of the code without modification and only differs in the hardware-specific glue logic.

Embedded kernel/firmware

Another interesting use case that’s not covered here is embedding the driver into firmware or a linux kernel for example. Certainly, this poses an issue for the larger lms-suite which is C++, requires on an OS with a MMU, and uses floating point math. This firmware/kenel use case is basically asking for another driver based on C and fixed point math. Fortunately, I’m also working on a C-based driver for the LMS7002M. After additional host-based testing, parts of it will be re-written in fixed point for use within the linux kernel. I’m not sure how to work this in with the rest of the lms-suite, but I’m sure it will be a valuable asset for hardware developers that are looking to very tightly integrate the hardware.

Poll and further discussion

We’ve created a poll and would really appreciate it if you could take the time to complete this:

https://www.surveymonkey.com/s/lmssuite

Should you be interested in contributing to the discussion further please post to the LMS Driver category on Discourse:

https://discourse.myriadrf.org/c/projects/lms-driver

The post LMS Suite driver discussion appeared first on Myriad.

We’re pleased to announce that ClockTamer is the latest project to join the Myriad-RF family. Developed by Fairwaves — who are also behind the industrial-grade dual-channel transceiver, UmTRX — ClockTamer is very much a mature project, with the version 1.0 hardware design having being published over 5 years ago, back in February 2010.

But what does it do? Well, it’s essentially a compact, low-cost configurable clock generator with optional GPS sync. Suited to use with GSM, TETRA, DAB, DVB, LTE and many more systems. Outputs include CMOS and LVDS, with the v1.2 hardware supporting output frequencies from 3.75MHz all the way up to 1137MHz.

For further information, schematics, PCB layout and firmware sources etc. see:

• Project page
• Main wiki page
• GitHub repository

The post Welcome to ClockTamer! appeared first on Myriad.

When I was contacted last year about making an OpenRISC-based SoC for an SDR platform I didn’t have to think twice. I have been curious about SDR and being able to combine that with my knowledge of Open Source FPGA work seemed like a great opportunity. After having talked to Ebrahim Bushehri, CEO of Lime Microsystems, I was even more eager as it turned out that this was a company that understood open source and used it as a vital part of their business strategy. By releasing all the support infrastructure such as development boards, drivers, specifications and software as open source, as well as actively collaborating with high-profile open source projects such as Parallella, Novena and OpenRISC, they are able to focus on their core business of providing world class highly configurable RF ASICs.

In June 2014 I went to visit Lime Microsystems in Guildford, where I got to meet the team and was shown early schematics of what would become the STREAM board. The vision that Ebrahim had for the the board was to enable the myriad of software engineers to be able to do interesting RF-enabled applications with the LMS ASICs, without having to deal so much with the intricate details of the hardware. In a way, this is just what the LMS ASICs themselves do for me as an FPGA designer, as I can enjoy a simple digital interface without having to dive into the vastly more intricate details of analog hardware. Working for Qamcom, a company specialized in the field of high performance RF systems, I had also a vast supply of instruments and experienced colleagues to help me with the testing and theories of radio communication, which was very helpful whenever I found myself lost in sampling theorems and modulation techniques.

After throwing some ideas back and forth it seemed like we shared a common idea of what the board should be able to do. I went back home to Sweden, we agreed on a time plan and I got to work with implementing the FPGA logic on a prototype board, while the engineers at Lime were finishing up the last details of the final STREAM boards. By February 2015 we had something running on the STREAM boards that was close to the original vision. The FPGA was now able to boot Linux, transmit samples between the onboard memories and the RF ASIC, and could be controlled from either a computer connected through USB or software running directly on the OpenRISC CPU in the FPGA. A few of the peripherals were unfortunately not connected due to lack of time.

So let’s dive into the architecture.

The SoC running on the FPGA is a fairly standard setup for an OpenRISC-based system. It has a UART for standard input/output, an Ethernet MAC, memory controllers and a debug interface available through JTAG. The parts specifically tailored for the LMS ASIC is an SPI interface for accessing the LMS registers and tx/rx interfaces for transmitting I/Q data to and from the LMS. The tx/rx interfaces are connected to one of the DDR2 memories through DMA controllers. By using one of the DDR2 memories exclusively for transmitting I/Q samples, we can ensure that no samples are lost even when the main operating system is under heavy load. The received I/Q data stream can also be transmitted through the FX3 USB controller to a PC. There is also a DVI controller for presenting a frame buffer through the HDMI connector. This feature is currently under testing and is not yet available in the provided sources.

By using as many existing and well-proven components as possible, the maintenance burden is shifted out from the project and improvements to each components can be pulled in as they seem fit. The only parts in the FPGA specific to the STREAM board are a thin I/O layer towards the digital I/Q interfaces. A streaming DMA component was also developed as part of the project, and that one has already seen use in other places during which a Linux driver was also developed. This is a great indication of the benefits of open source.

When we want to transmit data over the air, we do that by providing the LMS ASIC with a stream of I/Q samples. By default tx data is provided by a test pattern generator that sends four pairs of I/Q data that implements a continuous 30.72/4/2MHz sine wave in the frequency plane. This is mainly intended to provide the user with a known signal to see that the transmit chain is working. If the multiplexer named tx_src is switched over to its other input TX data is instead sourced from a streaming DMA. The stream DMA is reads a memory area out of RAM and transfers it as a stream of I/Q samples to the I/O interface. The CPU takes care of setting up the address and the length of the memory buffer, sends an activation signal and can then proceed to do other work until it gets an interrupt that all data has been sent.

On the receive side samples are streamed directly from the RF ASIC to the USB interface if no configuration is made. The samples are transmitted through USB in a format that is directly readable by the FFT Viewer in the LMS Suite. This allows users to view the received data on a computer without having to do any configuration of the FPGA registers. If instead rx_sink is switched to its other output the samples are sent to a RX stream DMA unit. The RX stream DMA reads samples from a stream and writes them to RAM through the Wishbone interface. The CPU sets up the address and size of the memory buffer to use, activates the DMA controller and can then do other things until the buffer is filled.

It has to be stated that a soft CPU running in an FPGA has nowhere near the capacity needed for any advanced signal processing, but what it can do is to make sure the OS runs and control the data flow through the signal processing chain.

All in all, STREAM is a fantastic little board that can be used as a general-purpose SDR platform straight away, and can be easily specialized for specific workloads by adding software or hardware accelerators in the data paths. And because both the board design files and the RTL code for the FPGA is open source, you can build, manufacture, sell and give away your own customized board based on the STREAM board design.

Olof Kindgren is working as a Digital Design Engineer at Qamcom Research & Technology in Göteborg, Sweden. Qamcom Research & Technology is a product development and specialist service provider in the areas of signal processing and communication systems, automotive systems and functional safety.

The post Introducing the STREAM OpenRISC implementation appeared first on Myriad.

Has the time for open source processors and SoCs finally arrived?

Open source designs for logic synthesis targeting FPGAs and ASICs are by no means new, with numerous industry and community initiatives that stretch back as far as the late 1990s. However, in recent years — and in particular over the last year or so — efforts appear to have redoubled, with developments that suggest that more widespread industry adoption may be on the horizon.

Before considering more recent developments, let’s first take a look at some earlier efforts.

A tale of two SPARCs

LEON2 architecture diagram. Source: esa.int.

LEON is a family of 32-bit processors based on the SPARC-V8 architecture, that was originally developed by the European Space Agency (ESA), before going on to be developed by Gaisler Research (subsequently becoming Aeroflex Gaisler and then more recently, Cobham). Described in VHDL, LEON can be implemented in programmable logic or manufactured into an ASIC.

Given its origins it shouldn’t be surprising to learn that LEON is designed for operation in the harsh space environment, with radiation hardened fault-tolerant versions of the processors.

LEON is dual-licensed; available under GPL/LGPL and also a proprietary license. Meaning that companies can buy out of any obligation to publish their modifications to a processor core.

The project was started by ESA back in late 1997. LEON 2 has been used in the Atmel AT697 and various SoCs. The latest generation of the processor core, LEON 4, was released in January 2010.

T2 processor floorplan. Source: wikipedia.org, CC BY-SA 3.0.

The OpenSPARC project was started by Sun Microsystems in 2005 and in 2006 they open sourced the complete design for their UltraSPARC T1 processor. This was followed in 2007 by the open sourcing of the T2 processor, which featured no less than 8 cores, 16 pipelines and 64 threads!

This was a bold move by Sun, who provided not only the Verilog RTL, but also a verification environment and diagnostic tests, along with tools for synthesis and simulation. In addition to which they supplied development kits to universities and even published a book on internals.

Open to the (IP) core

STREAM OpenRISC SoC block diagram

OpenCores is an open source hardware community developing IP cores such as processors and USB, Ethernet and other interface controllers, with many components supporting a non-proprietary system bus called Wishbone. Its roots can be traced back to around 1999 and by 2010, OpenCores boasted some 800 projects and 95,000 users, hitting the 150,000 user mark in 2012.

The flagship project is OpenRISC, which along with having created an open source RISC ISA with DSP features, has developed tools, libraries, operating system support and applications. Not to mention also system-on-chips and system simulators, with one that even runs in a web browser.

OpenRISC has been used in numerous ASICs, including Samsung digital television SoCs. A fault tolerant version of OpenRISC also flew in TechEdSat, the NASA CubeSat technology demonstrator. And of course there is an OpenRISC SoC for the Myriad-RF STREAM board.

RISC-V and lowRISC

lowRISC system diagram.

RISC-V originated in 2010 at UC Berkeley and was originally designed to support computer architecture research and education. However, it is now hoped that it will go on to become a standard open architecture for industry implementations. ISA specs are provided along with toolchains, a simulator and verification suite. Rocket, a 64-bit processor, is also available for high-speed simulation and full synthesis, with support for affordable FPGA development systems.

The lowRISC project builds on RISC-V and aims to provide fully open hardware systems, from the processor core to development board. The lowRISC SoC will benefit from novel features such as tagged memory for enhanced security, plus programmable I/O courtesy of “minion cores”.

Established as a non-profit in 2014, by the end of 2015 lowRISC plan to fabricate a dual-core test chip with memory PHY and minion cores in either 28nm or 40nm.

Collaboration and commercialisation

In addition to following in that great open source tradition of standing on the shoulders of giants and building on the work of others, technical advisers to lowRISC include Julius Baxter from the OpenRISC project and veteran hardware hacker, Bunnie Huang. Furthermore, there will be a European lowRISC and RISC-V workshop running as part of ORCONF this year, which has grown from purely an OpenRISC focus to covering wider open source digital design topics.

Collaborations such as these are key and central to the development of open source ecosystems. In this respect and others, great advances are now being made on earlier efforts. Which is not to downplay the significant IP contributions made by Sun or the effectiveness of the LEON project in meeting its objectives, but it does feel as though we have begun a new chapter in open source digital design, together with a palpable growth in interest, activity and commercial viability.

If all goes according to plan we should see the first lowRISC volume run some time within the next two years, with development boards following shortly after. There has also been the emergence of start-ups such as Nerabus that plan to build their own lowRISC-based silicon products.

Given the obvious differences, challenges and associated costs, it is hardly surprising that open source digital design has not progressed anywhere near as fast as the development of open source software. However, it does look as though exciting times are ahead and we look forward to further collaborating with the community!

Top image: RISC V prototype chip at UC Berkeley Par Lab Winter Retreat, January 2013. CC0.

The post The rise of open source digital design appeared first on Myriad.

Documentation is important to any project, but the accessibility of technical documentation is often at the top of engineers’ lists of pet peeves. It’s with this in mind that we’re pleased to announce an initiative which we hope will improve things considerably: a shift to wiki-first documentation for all things Myriad-RF.

The project, which is officially launched today following considerable behind-the-scenes efforts, sees Myriad-RF project and technical documentation taken out of proprietary document formats in favour of being published directly on the official wiki. As well as being more accessible, our hope is that these documents will become more collaborative: we’re releasing everything under a Creative Commons licence, allowing any and all documentation to be remixed and reused as required.

An even bigger positive to the project is that the documents themselves will become more collaborative. The wiki is open to anyone, pending manual approval of new accounts to prevent spam and vandalism, and we’re actively seeking feedback and suggestions for how the documentation could be improved. This is especially true with regards to some of the more innovative aspects of the documentation effort, including the use of TeX formatting to produce mathematical formulae which are both easy to read and portable for re-use elsewhere.

The initiative has so far transferred key documentation for the Myriad-RF project, and we’re looking for feedback. If you have any comments, you can either use MediaWiki’s in-built Talk function on the page in question or head to the Myriad-RF forum for longer-form feedback and discussion. If you have project documentation of your own you’d like to contribute, or have suggested improvements or additions, then please do get in touch.

It’s not just the Myriad-RF project that is benefiting from this shift, either. We’re pleased to announce that Lime Microsystems is joining us, publishing important technical documents central to the Myriad-RF project in the same format and under the same permissive licence. The Lime Microsystems documentation can be found in the dedicated LimeMicro namespace on the Myriad-RF wiki, which will help to keep things organised and group vendor-specific documentation for ease of access.

At Lime we have long recognised the vital importance of providing open and unrestricted access to technical documentation, having previously published the datasheets and many supporting documents for our products to GitHub. We have now taken further steps to deliver on our commitment to the open source community, by publishing the LMS6002D Datasheet, Programming & Calibration Guide and FAQ to the Myriad-RF wiki under a Creative Commons licence, thereby making it even easier to access and reference these documents while also enabling reuse in other documentation by those who use our chipsets in their systems.

We hope that you will find this useful and, as always, feedback is welcomed. In particular, it would help us to know whether you think we should publish additional documentation in this way and more generally, how we might further improve the wiki as a community resource.

Ebrahim Bushehri, chief executive officer, Lime Microsystems

The post Announcing the Myriad-RF Wiki Documentation Initiative appeared first on Myriad.

We are excited to announce that three new designs have been published to GitHub for boards that extend the Reference Development Kit and STREAM projects. These together provide an incredibly compact and low cost solution for prototyping wireless applications that are based on an Altera FPGA and Lime Microsystems FPRF.

The boards are also the first to implement the new uRFDIO interface, which has allowed Azio to create a micro version of the STREAM board, “uSTREAM”, along with micro versions of the transceiver module available in both LMS6002D and LMS7002M variants.

The FPGA board itself measures only 31mm x 108mm in size and along with an Altera Cyclone IV device incorporates a Cypress FX3 USB 3rd generation controller, 512M SDRAM, TCXO and Raspberry Pi 40-pin header.

GUI applications are provided for programming and calibration of the transceiver, along with TCXO configuration and FFT display of received signals. Python examples are also available for use with a Raspberry Pi SBC.

The wiki will be updated with further details over the coming weeks and general availability is expected early in the new year.

The post New micro STREAM board, plus LMS6002 and LMS7002 modules appeared first on Myriad.

Alexandru Csete and Josh Blum have been busy putting together updated Ubuntu packages for GNU Radio plus various drivers, along with their dependencies. To summarise:

• Update to GNU Radio 3.7.9/volk 1.2
• Latest gr-osmosdr with Red Pitaya support
• SoapyRedPitaya added
• UmTRX 1.0.8
• Using UHD PPA

The packages can be obtained via the SDR Drivers PPA and GNU Radio PPA.

If you have any feedback or would like to get involved in contributing to the packaging project — e.g. by packaging other SDR and related software, else packaging for additional distributions — please get in touch via the discussion forum.

The post Updated GNU Radio and SDR driver Ubuntu packages appeared first on Myriad.