Sunday, December 29, 2013

Wrapping up 2013 GNSS facts

Well, it has indeed been quite a long time since I wrote here the last time.
My personal situation has changed in such a way that it is hard to find the time to share my views and to comment your feedback on current advances in the GNSS R&D domain.
However I feel like dropping here an "end of the year" summary which serves more as a memorandum to me that anything else.
I might be challenging this article
http://gpsworld.com/2013-a-positive-year-for-location-industry/
but 2013 has not been a very good year for GNSS.
At least someone generally agrees:
http://qz.com/161443/2013-was-a-lost-year-for-tech/#!

Mass market receivers for low cost RTK
Lately there was one more item on the acquisitions list:
The above shows how aggressive this market is and leaves just a few players on the field.
Some of them, such as Intel, Qualcomm and Broadcom don't really sell to private and just target device manufacturers. Others have shelves as well and those are the most interesting for people thinkering with GNSS of course.
In no particular order:

Mediatek
Early in 2013 Mediatek announced MTK3333. This powerful true dual constellation receiver can be found in many modules (for example by Locosys and GlobalTop. Although impressive, it does not seem to offer pseudoranges or carrier phase at the moment.

uBlox
IMHO, uBlox has a confusing roadmap with 6th generation modules overlapping with 7th generation and now apparently 8th generation. I design with uBlox modules and it is a little awkward to tell my customers that modules already advertised for are due for release in 6 months. The Company has done an aggressive marketing of a "PPP" technology that has nothing to do with Precise Point Positioning, but rather with carrier phase smoothing. uBlox still manages to sell navigation modules which are not true dual constellation but either one or the other constellation. Their "P" and "T" modules have well established pseudorange, carrier phase and more measurements for GPS.

ST-Microelectronics
STM has released in 2013 the TeseoII true dual constellation IC. The STA8088FG is 7x7 mm and is very capable. Pseudoranges can be obtained with some firmware, but never carrier phase. Carrier phase is rumored to be available in Teseo3, which is to be released next year. STM is more open to Galileo than any other Company, but it is weird to find their GNSS products under "Automotive Infotainment and Telematics" category.. not that STM website is an easy one to navigate anyway.

NVS
NVS continued to innovate in 2013 by releasing new FW for their NV08C-CSM and -MCM modules. However, after the press release of compatibility with the popular precision navigation software RTKLIB, they went quiet. By the way, I wrote the support driver for their receiver into RTKLIB but never received a mention.. you are welcome. Next year NVS will release a new hardware revision of their modules, but nothing is told about changes to expect against the current. I have high expectations :)

Geostar Navigation
This Company was pretty new to me and came as a surprise in 2013. It offers a true dual GPS+Glonass receiver module. In my opinion has still to improve in terms of reliability but the preconditions are all good (website is updated often so at least the Company seems well up and running). Rumors want Geostar-Navigation to release a pseudorange and carrier phase capable firmware (for GPS at least) very soon.

Furuno
Furuno came back in 2013 with a true dual constellation chipset called eRideOPUS 7 and module called GN-87F. The Company has expressed interest in releasing Galileo compliant firmware soon and the chip seems to be able to output pseudoranges, but not carrier phase.

CSR
CSR has finally delivered a new standalone receiver IC, the SiRFstarV 5e. I bought the Telit Jupiter SE868 V2 (quite a mouthful) evaluation kit from Rutronik. I still did not have a chance of testing it out in real environment but it does track simultaneously GPS, SBAS and Glonass. The chip seems to be very swift and surely has best in class power consumption, but SiRF already departed from raw measurements path with their 3rd generation so I would not expect them to be back on that track now.

Skytraq
Last but not least, Skytraq was among the first ones to release a true dual constellation chip and module with the intention of supporting raw measurements. I bought some S4554GNS-LP back in 2011 already. Since then the Company has made a great progress in integration and quality of modules. The latest generation, the Venus8, has GPS 50Hz measurements, or GPS+Glonass at 20Hz. As all new modules comply with the uBlox NEO format, I already had a chance of integrating some S1216F8, S1216F8-GL and S1216F8-BD. Whilst not tested in the field but "only" with an Agilent GNSS simulator, these modules represent for me the greatest promise for 2014.
All GNSS enthusiastics should check out the NavSpark:
http://igg.me/p/603168/x/5902022
Although I am not a crowdfunding enthusiastic (see later as well) the news is that it is possible to get at least an evaluation kit (with libraries) for this powerful baseband processor for USD 199. There is a lot of room to play for sure, and 50Hz GPS raw measurements for less than USD 20 a module will buzz for sure.

  GNSS Software Defined Radios

Looking out for interesting devices to use for GNSS SDR, this year has been a promising one. But not all promises are kept, as I will explain below.

Memoto Camera

One year ago already, following the hype of the Cell-guide snapshot GPS technology, I decided for the first time to back a kickstarters project: the Memoto camera. This "lifelogging device" has an Aclys chip inside which will only turn on for a few milliseconds every so often and record a GPS signal snapshot, in order to achieve the lowest possible battery life. After more than 1 year not only I did not received the camera but my contact has been lost in the transition from Memoto to Narrative. Being my support request unanswered, it is hard to know wheter I have lost my pledge or not... fingers crossed.

Jawbreaker -> HackRF One

Michael Ossmann, creator of the Ubertooth, started developing other interesting devices for low cost SDR. I missed by very little the Jawbreaker giveaway back in June, so I decided to support its Kickstarters campaign for HackRF One, which is essentially the same object but not free and with 8 months more on its shoulders. Whether this time has actually served to real innovation or just made Michael more popular (at least well deserved in his case) and rich.
My plans of using HackRF One for GNSS record and playback are a little pushed back by the fact that it is a half-duplex design, although I see some potential by properly hopping between TX and RX.If and when I receive the thing.

Nuand BladeRF

BladeRF was probably the greatest disappointment so far. It mounts
  • the Lime Microsystems LMS6002D, a fully programmable RF transceiver capable of full-duplex communication between 300MHz and 3.8GHz
  • an Altera Cyclone 4 with options at 40KLE or 115KLE
  • a Cypress FX3 microcontroller
Sounds like the perfect board to have a GNSS receiver on FPGA, and a real-time continuous-time record and playback device. I received the boards back in Summer and was never really able to have them working reliably. I installed the Ubuntu several times, until now 13.10 seems to have native support at least for the libusb version they link to. Things might change tomorrow, but it has been six months of bleeding so far. Essentially the software is not stable. BladeRF might even work as a 450 USD spectrum analyzer once you install a leviathan like Gnuradio. But it won't work for me if it misses packets once in a while, if it randomly switches the I and Q channel, if it cannot tune to 1.5GHz in TX mode, if it works only with Renesas and NEC USB 3.0 hosts.

SwiftNav Piksi

Two bright guys, Fergus Noble and Colin Beighley founded Swiftnav and started developing Piksi, an "open source" GPS receiver for RTK implemented as a combination of a Spartan6 9KLE FPGA and STM32F4 168 MHz Cortex-M4 MCU. Swiftnav "kickstarted" Piksi back in the Summer, when I already had a sample of it. Unfortunately once the campaign was funded (and I was one of the backers of course) there has been little development on the software side. Sure, more boards were manufactured to address sales but Swiftnav customers are not yet able to see how the RTK engine will look like, nor they have visibility of the FPGA correlators code.
Actually those two are two valuable pieces of software so I cannot hide my sceptictism in believing the promised Open Source nature of the venture.
Before I publish here anything about Piksi, I need to be provided a simple way of
  1. recording data with the board connected to a perfect antenna. 
  2. converting the recorded stream into Rinex OBS
IMHO, those two are the fundamentals when a Company plans to sell a RTK capable receiver. It does not have to be small, to be low power, to have an embedded antenna if carrier phase isn't rock solid to begin with.
Very recently Swiftnav published a video (filmed in August, so why now?) where they show differential accuracy on the rooftop of their office building.. but that seems a very poor reward for three months of Github silence (1) (2).
I sent Fergus and Colin two pieces of the most recent Rap10LogWi release


asking them to try their RTK engine (I used their same MCU) on a bullet-proof low cost GPS receiver as the uBlox NEO6T.
I have not received any feedback so far.. I know they are busy investing their reward, but I think their customers (and I) need a bit of delivery of credibility at this point.

Ettus USRP B2x0

Probably the savior of my 2013 SDR hopes, the B2x0 boards from Ettus tick many boxes. They are a little expensive maybe, but they are supported by the UHD driver which has a huge community behind. How did Ettus manage to pull off a deal with Analog Devices and integrate first the super powerful AD9361 I don't know. The TI AFE7070 came close sometime this year in terms of chip integration, and the above mentioned LMS6002D (with its awkward footprint) even closer, but that ADI chip seems unbeatable right now. The Spartan 6 75KLE seems also large enough to run several channels of a GNSS receiver already. I will have access to a couple of these boards very soon and I cannot wait.

...TBC








11 comments:

jks said...

Thank you Michele. A much appreciated update.

I found this rather ordinary SiRFstar IV-based 14x10 mm module from Maestro Wireless. Sure, not the latest capabilities (I was only interested in an inexpensive source of PPS). But the best part? Only US $11.70 in quantity 100 from US distributor Mouser ($13.60 quantity 1). I found it rather amazing that the $10 price point is getting closer.

I don't know much about software-defined GPS, but I'm trying to learn and in 2013 was able to port Andrew Holme's excellent open source Homemade GPS Receiver. My breadboard version uses an SE4150 front-end chip, BeagleBone Black SBC and XuLA2 FPGA dev board. I had a lot of fun putting this together and learned much of the basics principles of GPS signal processing.

Michele said...

Hello Jks,

GPS receivers are becoming more and more cheap. I found TIM-4 (which can be easily hacked to provide 10Hz raw measurements) on ebay for 4.99 EUR last year.

I have followed your achievments on your blog earlier this year, congratulations and thanks for commenting on the blog.

With regards with the path you guys took, what puts me off is the soft CPU. I don't understand it very well so I admit I might be missing something there.
But I found the Piksi guys approach quite neat, not needing an application processor and still having 12 channels in a 9KLE FPGA.

Also Andrew approach is great, but really a GPS front-end costs less than 5 USD and saves you most of the RF trouble.

What do you think?

Cheers,
Michele

jks said...

I think Andrew's design was motivated by a couple of factors. He had built a series of FPGA-based fractional-N PLL boards, the latest of which could reach the required L1 LO frequency and had enough spare logic blocks for GPS. He also mentioned an interest in the 1992 work of Matjaž Vidmar, S53MV, using a 1-bit A/D (hard limiter). So being an RF guy couldn't resist trying it himself rather than using an existing front-end chip like I did.

His web page mentions he used an embedded processor in the FPGA because he ran out of gates in the XC3S400 implementing a 12-channel receiver. And the 1 KHz parallel parts of the tracking logic are easily done sequentially with code. But not so easily on the Raspberry Pi running Linux because of the real-time response issues unless you're able to do some serious device driver work (which is no fun). I found his embedded processor design very simple and easy to understand compared to the various open source versions available. This is an area I've long had an interest in and so it was very educational for me.

I looked at the Piksi design briefly. I don't understand how they can possibly fit a 12-channel receiver in an LX9, especially since it seems to do acquisition as well. I thought you pretty much had to do acquisition with FFTs for acceptable speed. There was no evidence of an FFT library linked in to the firmware or library code. Plus that would have to be running on the 168 MHz STM32F4 which seems very unlikely to work. So I agree that it is truly unfortunate that the FPGA firmware is not currently open source.

Unknown said...

Michele,

Nice that you are Bloging again.

I would like to know if Ducat10 (with S1216F8-GL) is working off-the-shelf with RTKLIB 2.4.2

Leandro

Michele said...

@jks
I don't know the details of the SwiftNav implementation, but the way I would attack the problem would be to implement in FPGA logic similar to the one used in the GP2021:
http://cesop.zarlink.com/zarlink/gp2021-datasheet-aug2005.pdf
or the ADSST-200:
http://www.analog.com/static/imported-files/data_sheets/adsst-200.pdf

Back in 2008, I bumped into an interesting paper written by Stewart Cobb:
http://www.ion.org/publications/abstract.cfm?articleID=8133

At the end of the day, the controller unit needs to be responsive enough to collect the baseband registers before they are overwritten. At current SPI speeds (STM32F4 is capable of 37.5Mbps and more) probably one has enough bandwith to control the correlator engine tightly enough. On embedded microcontrollers, the interrupt serving latency sounds easier to bound compared to an application processor where a high-level OS (e.g. Linux) is on the way.

I am pretty sure they do have FFT onboard. With 16x decimation (BB downconversion and a moving average should be light enough in LE consumption) and properly designed algorithms (say, Block Zero Padding) one could limit the FFT engine to a single size (e.g. 64 taps) for both direct and inverse transforms, again saving LEs.

I never explored FPGAs, but if I would have the SwiftNAP code the first thing I would do is fill the cost gap with multi-frequency GPS/GNSS receivers. IMHO, L1 carrier-phase comes too cheap in mass market receivers to be beaten by programmable-logic designs.

@leandro
No ...not yet
;)

Unknown said...

Hello Michele,

Thanks for all you work ! it is fantastic. I have purchased a SDRNAV00 and I do not manage to use it... Is is possible to help me? I am sure that driver is ok, grab data seems also to be ok but when I make the psd of the output (I signal) I do not have data...as if my active antenna is not connected :(... I think I will buy an active antenna in Sparkfun as specified but I am ensure that problem coming from the confiugration of Max2769 or maybe that my module is in failure? I hope you will be able to help me... Sincerely Pascal.

Michele said...

Hello Pascal,

What antenna do you use now?
What do you mean by "the PSD of the output.. I do not have data"? What is the histogram like?

The configuration file for the MAX2769 which you use with the option -m has a bit "ANTEN" which is used to activate the antenna voltage bias. Is that set to "1"?

Cheers,
Mic

Unknown said...

grante Michele!, great post, I enjoyed it a lot. btw, could you please point me to those carrier-phase receiver you mentioned.

cheers
Fabrizio

Joaquin Salas said...

Michele,
we are trying to implement the rtklib. Would it be possible for you to advise us what kind of receivers we should buy?

Thanks. I appreciate your support.

Joaquin

Joaquin Salas said...

Michele,
we are trying to implement the rtklib. Would it be possible for you to advise us what kind of receivers we should buy?

Thanks. I appreciate your support.

Joaquin

Unknown said...

Hey,
Is there any way that a piksi can be used with R-Pi? Currently, I'm using the arm2.6 Autopilot for my drone and aeroquad code on the board. I don't want to disturb the setup. R-Pi is anyways in the system, so I'm looking for ways if I can get increased accuracy using this, but no extra hardware. I'm no pro in the, a simple solution will be of great support.
Thanks.