Wednesday, January 13, 2016

NT1065 review

So I finally came about testing the NT1065… apologies for the lack of detail but I have done this in my very little spare time. Also, I would like to clarify that I am in no way affiliated to NTLab.

Chip overview

A picture speaks more than a thousand words.
Figure 1: NT1065 architecture
Things worth noting above are:
  • Four independent input channels with variable RF gain, so up to 4 distinct antennas can be connected;
  • Two LOs controlled by integer synthesizers, one per pair of channels, tuned respectively for the high and low RNSS band, but one can choose to route the upper LO to the lower pair and have 4 phase coherent channels
  • ADC sample rate derived from either LO through integer division
  • 4 independent image-reject mixers, IF filters and variable gain (with AGC) paths
  • Four independent outputs, either as a CMOS two bit ADC or analogue differential so one could
    • connect his/her own ADC or
    • phase-combine the IF outputs in a CRPA fashion prior to digitisation
  • standard SPI port control
Another important point for a hardware designer (I used to be a little bit of that) is this:
Figure 2: NT1065 application schematic
The pin allocation shows a 1 cm2 QFN88 (with 0.4mm pin step) with plenty of room between the pins and an optimal design for easy routing of the RF and IF channels. Packages like that aren’t easy to find nowadays for such complex RF ICs (everything is a BGA or WLCSP) but I love QFNs because they are easy to solder with a bit of SMD practice and can be “debugged” if the PCB layout is not perfect first time.

Evaluation kit overview

The evaluation kit presents itself like this:
Figure 3: NT1065 evaluation kit
One can see the RF inputs at the top, the external reference clock input on the left, the control interface on the right and the IF/digital part on the bottom. The large baluns (for differential to single ended conversion) were left unpopulated for me as I don’t use redpitaya (yet?). The control board is the same used for the NT1036.
In configured the evaluation kit to be powered by the control board (it was an error, see later) and connected the ADC outputs and clock to the Spartan6 on the SdrNav40, used here simply as USBHS DAQ. In total, there is one clock like and 8 data lines (4 pairs of SIGN/MAGN, one per channel).
The IF filters act on the Lower Side Band (LSB) or the Upper Side Band (USB) for respectively high and low injection mixing and can be configured for a cutoff frequency between 10 and 35 MHz. Thus, bandwidths of up to 30 MHz per signal can be accommodated and the minimum ADC sampling rate should be around 20 Msps. 20 MByte/sec are not easy to handle for a USBHS controller, so I will look into other more suitable  (but still cost effective) DAQ options to evaluate the front-end. In the meantime, I could do a lot with 32MByte/sec of the FX2LP by testing either 2 channels only with 2 bit or all the 4 channels with 1 bit and compressing nibbles into bytes (halving the requested rate).
The evaluation software is a single window, very simple and intuitive to use but very effective.
Figure 4: Evaluation software
The software comes with several sample configuration files that can be very useful to quickly start evaluating the chip.

Tests

All my tests used a good 10MHz CMOS reference.

GPS L1

The first test was GPS L1 in high injection mode setting the first LO to 1590 MHz (R1=1, N1=159), leading to an IF of -14.58 MHz, a filter bandwidth of about 28 MHz and a sampling frequency of 53 Msps (K1/2=15). I streamed one minute to the disk and verified correct operation.
Figure 5:GPS L1 PSD (left) and histogram+time series (right)
Figure 6: G30 correlation of L1 code detail (left) and all satellites (right).

GPS L1/L5

When performing this test I bumped into a hardware problem. If the control board powers the NT1065 evaluation kit with its internal 3.3V reference, the power line is gated by a small resistor thus the voltage depends on the current drawn by the chip (undesirable!). Enabling the second channel in the GUI made the chip draw more current so the voltage on the evaluation kit decreased away from the SdrNav40 one which was steady at 3.3V. Level mismatch created unreliability in reading the digital levels and failure to transfer meaningful data. So I powered the evaluation kit with the SdrNav40 3.3V voltage reference and everything was happy again.
In this configuration L1 is again at -14.58 MHz (1590 MHz high side injection) and L5 is on the third channel (low RNSS) at -13.55 MHz (R2=1, N2=119 for 1190 MHz high side injection). To be noted the relative large spike in the spectrum at 1166 MHz, not an obvious harmonic so it could be some unwanted emission from neighbour equipment.
Figure 7: L5 PSD (left) and histogram+time series (right)
Figure 8: G30 correlation of L5 code detail (left) and all satellites (right).
Interestingly, the Matlab satellite search algorithm returns respectively for L1 and L5:
Searching GPS30 -> found: Doppler +4500.0 CodeShift:  35226 xcorr: 12502.4
Searching GPS30 -> found: Doppler +3000.0 CodeShift:  35226
The above outputs show coarse but correctly scaled Doppler [Hz] and a perfect match in code delay [samples] (just by chance spot on).

4x GPS L1

In this case I enabled all 4 channels and shared the LO amongst them all. Unfortunately I cannot show the 6dB increase in gain when steering a beam to a satellite as all RF inputs were connected to the same antenna and -being the noise the same- steering the phase is useless. However, it is possible to verify how the phase amongst the channels is perfectly coherent (requirement for an easy CRPA).
The signals were conveniently brought to baseband, filtered and decimated by 5, resulting into a 10.6 MHz sampling rate. As one can see below the power was well matched and the inter-channel carrier phase is extremely steady and constant over the 60 seconds capture time. In the very case of zero-baseline, one can easily check that such phase difference is also the same across different satellites (as it does not depend on geometry but just on different path lengths beyond the splitter).
Figure 9:PSD of the IF obtained from the 4 channels and relative carrier phase

GPS L1 + Glonass G1 + GPS L5 + Glonass G3

I wanted to verify here reception of Glonass G1 on the second channel (upper side band). At this point it had become merely a formality. Glonass CH0 is at +12 MHz so the acquisition returned correctly as shown below.  Of course 53 Msps for a BPSK(0.5) is a bit of an overkill :)
Figure 10: Glonass acquisition all satellites (left) and CH-5 detail (right).

GPS L1 + Beidou B1 + GPS L5 + Galileo E5b

The case for GPS and Beidou was a bit more challenging as the distance between L1 and B1 is only 14.322 MHz, thus the IFs must be around 7 MHz. I decided to set the LO to 1570 MHz (R1=1, N1=157). So GPS went upper side band on channel 1 at +5.42 MHz IF. Beidou consequently went on lower side band on channel 2 at -8.902 MHz. Channel 3 and 4 were enabled with LO2 set at 1190 MHz: in the middle between E5a and E5b in order to verify AltBOC reception.
As 1570 MHz is a nasty frequency to generate a round sampling frequency value I decide to derive the clock from LO2 using K2/2 = 10 and therefore stream at 59.5 Msps. As one can see below the L1 peak has moved very close to baseband now and the sampling frequency is quite exceeding the Nyquist limit.
Figure 11: GPS acquisition with close-in IF
Figure 12: Beidou B1 sprectrum (MSS on the right) and acquisition (incidentally also showing IGSO generation 3 satellites C31 and C32).
Figure 13: E5a acquisition of E30
Figure 14: E5b acquisition of E30, showing a perfect match in code delay with E5a as one would expect.

Conclusions and work to do

I am very suprised of how little time took me from unboxing the kit to sucessfully using it to acquire all the GNSS signals I could think and test all configurations. Of course I had the former experience with the NT1036 but this time I had the perception of a solid, feature-rich, plug-and-play IC.
In my todo list there is the extension of this post with a home-made measurement of channel isolation.. and the way I plan to do it should be interesting to the readers :)

Friday, January 1, 2016

Happy begin of 2016

2015 just passed. I don't write much here anymore as time has become a very precious resource and my job imposes tight limitations on what one can or cannot write on the web.
The yearly update will quickly cover constellation the status, some info on low cost RTK developments and some more SDR thoughts (although the most significant article in that respect will come soon in another post).

Constellation updates


As retrieved from Tomoji Takasu's popular diary, 2015 has seen the following launches:

Date/Time (UTC)     Satellite             Orbit   Launcher        Launch Site               Notes
2015/03/25 18:36    GPS Block IIF-9       MEO     Delta-IV        Cape Canaveral, US        G26
2015/03/27 21:46    Galileo FOC-3, 4      MEO     Soyuz ST-B      Kourou, French Guiana     E26, E22
2015/03/28 11:49    IRNSS-1D              IGSO    PSLV            Satish Dhawan SC, India   111.75E
2015/03/31 13:52    BeiDou-3 I1           IGSO    Long March 3C   Xichang, China            C15
2015/07/15 15:36    GPS Block IIF-10      MEO     Atlas-V         Cape Canaveral, US        G08
2015/07/25 12:28    BeiDou-3 M1-S, M2-S   MEO     Long March 3B   Xichang, China            ?
2015/09/10 02:08    Galileo FOC-5, 6      MEO     Soyuz ST-B      Kourou, French Guiana     E24, E30
2015/09/29 23:23    BeiDou-3 I2-S         IGSO    Long March 3B   Xichang, China            ?
2015/10/30 16:13    GPS Block IIF-11      MEO     Atlas-V         Cape Canaveral, US        G10
2015/11/10 21:34    GSAT-15 (GAGAN)       GEO     Ariane 5        Kourou, French Guiana     93.5E
2015/12/17 11:51    Galileo FOC-8, 9      MEO     Soyuz ST-B      Kourou, French Guiana     E??, E??


GPS 

GPS replaced three IIA birds with brand new IIF, as one can see Figure 1. The number of GPS satellites transmittiing L5 raised now to 11 (as one can also verify with UNAVCO). The number of GPS with L2C is instead 18 (quite close to a nominal constellation!). The question is now how GPS will proceed in 2016 and beyond, having seen the delays that afffect OCX and in general the bad comments (see e.g. 1 and 2) on the progress of modernisation of GPS.
Figure 1: One year of GPS observations, obtained using a bespoke tool from the freely available data courtesy of the IGS network.
Glonass

Stable situation here, as seen in Figure 2, with the only exception of PRN 17 going offline in mid-October (perhaps soon to be replaced according to the table of upcoming launches)
Figure 2: One year of Glonass observations
Galileo

The situation has been very "dynamic" for Galileo but is indeed very promising as seen in Figure 3. The latest launch went well and we can hope for several signals in space in 2016: hopefully the year that Galileo will make its appeareance in most consumer devices. Incidentally, there are as of today 8 satellites broadcasting E5a.




Beidou 

Also for Beidou the situation is rapidly evolving as can be seen in Figure 4. My colleague James and I did a detailed study on the new generation satellites and published part of it on GPSWorld. Indeed 3rd generation test birds host a very versatile payload that allows them to broadcast modern navigation signals on three frequencies. Incidentally C34 and C33 (the two MEO space vehicles) also broadcast a QPSK on E5a.
Figure 4: One year of Beidou observations.

Low cost RTK

An awful lot of progress here, with NVS, Skytraq, Geostar Navigation and uBlox releasing multi-constellation single frequency products for RTK.

NVS released two products with onboard GPS+Glonass (upgradeable to Galileo) RTK engine: NV08C-RTK (for standard base-rover configuration) and NV08C-RTK-A (with added dual antenna heading determination for precision AG). Rumors say that they both run an highly reworked version of RTKLIB on a LPC32xx microcontroller (ARM926EJ-S processor with VFP unit). The price is not public, but again rumors suggest it is a few hundreds of EUR a piece (in small quantities) for the single receiver version. I got my hands on a couple of boards and build a simple adapter board to be able to use them with a standard laptop and a wireless module fitting the Xbee socket (including this one).



Skytraq has built on its Navspark initiative and came out with two groundbreaking products S2525F8-RTK
and S2525F8-BD-RTK. The -I shall say- provocative price of 50 and 150 USD respectively sets a new threshold very hard to beat. Skytraq has also done extensive analysis on the performance of GPS only versus GPS+Beidou single frequency RTK, e.g. here and here. In Asia the dual constellation (2x CDMA) single frequency (1540x and 1526x f0)  RTK shows incredibly promising results, mainly due to the impressive number of birds in view. I got my hands on a couple of plug&play evaluation kits and already verified the sub-minute convergence time to fix in zero baseline and good visibility conditions.



Geostar Navigation has also recently released the GeoS-3MR which is practically identical in terms of capability to the GeoS-3 and GeoS-3M, but has a factory setting such that the most recent firmware provides carrier phase for both GPS and Glonass. Although Glonass phase is not calibrated, last month statements from Tomoji suggest that this feature could be incorporated in v2.4.3 anyway.
A few years ago I had designed and produced some carrier boards for GeoS-3M so I could just place an order for a few raw-capable chips (at 25 USD each) and test them out. The software provided by the manufacturer (Demo3 and toRNX) allows to extract Rinex observations from the binary logs. At the time I had also developed some parser code for RTKLIB but I now found out that it has a small issue.. I don't feel like reinstalling C++ Builder just to fix it but anyone please feel free to take that code and push it to v2.4.3.


 
uBlox released the M8T module with raw data support for two simultaneous constellations.. very interesting chip but I have the feeling that some big change is going to happen there since the Company is focussing much more on comms than nav lately.

ComNav offers the K500 OEM board also for less than 300 EUR in small quantities.

In view of all the above, one could expect that initiatives like Reach® and Piksi® will surely have to reconsider their approach. In particular, things based on Edison® are facing the competition of ARM-based modules which are perfectly capable of RTK and are accessible at a much lower price (e.g. see Raspberry Pi Zero and C.H.I.P.  SwiftNav has recently release an update but unless they go multi-frequency rapidly the competition will give them very hard times.

Finally, low cost dual frequency cards such as Precis-L1L2 have started to appear. Apparently based on a Chinese Unicorecomm OEM board it offers multi-constellation multi-frequency RTK at 800 USD.

SDR

Over the holydays I assembled the test-bench for the NT1065, the latest multi-constellation front-end from NTLAB. The setup again is very clean and builds on lessons learnt with the NT1036: I will present the first results soon, in the next post.


Since the chip has the native capability of streaming about 60 MBytes/sec (4 channels ~15 MHz IF output at 2-bit per sample) a USB2.0 transceiver is sub-optimal as limited to about 40 Mbytes/sec.
I started investigating the FT601 USB3.0 trasceiver from FTDI and the KSZ9031RNX GigETH transceiver from Micrel, as seen in the beautiful development from Peter Monta. Also, the availability of the FX3 Explorer Kit is tempting as easy mid-step solution. There are many SDR boards, but I would just need a cheap programmable FPGA+GigETH/USBSS and I cannot find it... Parallella seems the best candidate with its Porcupine to use and some software to develop of course (I am surprised nobody published a GPIO-GigEth streamer software with Parallella yet). Ettus and Avnet are much ahead with powerful SDR platforms (e.g. the B210 and the picoZed SDR SOM) but there is what feels a steep lerning curve to use them. Perhaps it is time again to go design something?
In the meantime, I am watching the pcDuino3 Nano Lite and the Odroid XU4 as cheap NAS solutions to efficiently store long snapshots of IF data.