FAQ: NavSpark GPS / GNSS

FAQ for NavSpark
=========================
Arduino Compatible with GPS GNSS Receiver
Packing 32bit Features and GPS GNSS into 8bit Size and Price
http://www.indiegogo.com/projects/navspark-arduino-compatible-with-gps-gnss-receiver/x/6094574
=========================

NavSpark FAQ:
based on www.indiegogo.com/projects/navspark-arduino-compatible-with-gps-gnss-receiver/x/6094574?c=comments
This FAQ page is not official, and may not be accurate. Summarized by J.Beale  21 May 2014
There is an official FAQ at http://www.skytraq.com.tw/Commonly%20Asked%20Questions.pdf
There is a user forum at http://www.navspark.com.tw/
User guide / user manual and downloads at http://navspark.mybigcommerce.com/resources/

Sections:
=========================
Hardware Specs
Software Specs
Electrical Specs
I/O Signals
GPS, GLONASS, Beidou
RAW output version
GPS Antenna
GPS Performance
Time from one satellite
Updates & Changes

Hardware Specs
=========================
·  100MHz 32bit LEON3 Sparc-V8 + IEEE-754 Compliant FPU
·  1024KB Flash Memory + 212KB RAM
·  ~80uA/MHz @ 3.3V
·  Powered and programmed by micro-USB connector
·  1 full duplex asynchronous UART
·  1 asynchronous UART transmit
·  2 SPI with master/slave mode configurable
·  1 I2C
·  1 24bit PWM
·  17 digital I/O pins (shared with above functional pins)
·  Atomic clock synchronized 1PPS time reference with +/-10nsec accuracy

Software Specs
=========================
We expect to have two kinds of library for Arduino: one with GPS/GNSS, and one without. The new Venus822 datasheet will have a detailed description of the hardware peripherals, enabling interested users to fully access the hardware to build things from the ground up using the library without GPS/GNSS. The other library will have an easy to use API provided. Description of the LEON3 Sparc-v8 used in Venus822 can be found at: http://www.gaisler.com/index.php/products/processors/leon3?task=view&id=13

The provided GPS/GNSS library will be integrated into the customized Arduino IDE, automatically linked during compilation phase. The GPS/GNSS library will not be open sourced; NavSpark board level hardware design and customized Arduino IDE will.

The currently remaining Flash/RAM space for user applications on NavSpark, NavSpark-GL, NavSpark-BD is roughly 490/45, 420/20, 440/10 Kbytes. NavSpark-RAW is not programmable. NavSpark (GPS-only) is generally a good choice with a larger programmable space (490KByte Flash, 45KByte RAM).  Both NS-BD and NS-GL versions can be used in GPS only mode to have same CPU MIPS/memory resource left as GPS-only mode, but current consumption will not differ very much. The user space will be larger if we later have time to optimize.

GPS uses a 1 msec interrupt. A 10 Hz navigation routine runs in the background, computing a PVT solution every 100 msec. Venus 8 RISC/FPU has the potential to do a maximum of 50 Hz update rate running at top speed, thus we expect to have at least 50% throughput for the user application when doing 10 Hz if running at top speed.

With the NavSpark Arduino IDE or SDK, user code resides in a function that the main() function will call. There is no RTOS, just the GPS/GNSS interrupt service routine and the background main() loop. The application code should be written in the form of "Do some action if some event is detected" so as not to block the background main() function from looping continuously. Since the GPS/GNSS kernel code is partitioned into an interrupt service routine and a background function called by the main() function, this is transparent to the user. So long as the user application doesn’t block the main() function looping, it will appear that you have user code and GPS/GNSS running concurrently.   -from http://www.skytraq.com.tw/A001.pdf

Q: Will NavSpark have a command set similar to TinyGPS?

A: Below is the document for our standard $199 GPS SDK, which is the core GPS library going into the ported Arduino system. User can call it directly or through a wrapper API that makes it friendlier. All will be explained clearly in the document release. As GPS related information is native, there is no need for a NMEA parser. Anyone can easily add a wrapper to have an API similar to some other GPS parser library they are using.  http://t.cn/8Fb1H3d

Q: How open is the Venus 8 chip on these boards going to be to tinkering? Will I be able to use GRMON (debug/flash tool?) on these chips? Would a hardware programmer of some kind be required?

A: Other than GPS/GNSS, register description won’t be opened. The LEON3 description is already there; we need to make available function and register description of other on-chip peripheral (UART, SPI, I2C, GPIO, watchdog, …) and mapping address for memory and peripherals. GRMON needs a USB key costing $ thousands and there is no pin-out to support it with Venus822. If user programming hangs the system, you can simply put a jumper to boot up in ROM mode to load flash code, so there is no additional programmer to purchase.

Q: Will Mac OSX be supported?

A: While we tried to port to Mac OS, we found there is some fundamental issue with the compiler being unable to work under Mac OS. Thus unfortunately Mac OS Arduino IDE cannot be supported. The LEON3 Bare-C Cross-Compiler (BCC) from Gaisler Research is only configured for Window and Linux. We weren’t able to get it compile correctly under Mac OS, as some part is not available in source. [It may be possible after some community effort to develop using gcc leon-sparc, the feasibility of this is not yet known.]

Electrical Specs
=========================
NavSpark is a 3.3V +/-10% type. It has 2 Schottky diodes in parallel, taking input from USB 5V interface and battery input, with outputs going into a 3.3V output LDO regulator to power the circuitry. The I/O is also 3.3V type, and does not work with 5V.

Current consumption for initial full power signal acquisition / fully tracked navigation for NavSpark, NavSpark-GL, NavSpark-BD is roughly 38/30, 45/40, 45/40 mA at 3.3V using on-chip DC/DC switching regulator.

Both BD and GL version can be used in GPS only mode, to have the same CPU MIPS/memory resource left as GPS-only version, but the current consumption will not differ very much.

The separately-available adapter board does not have a separate regulator. It only has a micro SD card holder, battery connection, and battery charger for a user-supplied external Li battery. The charger voltage supply comes from NavSpark’s 5V pin-out. The NavSpark board size is 38mm x 18mm and the adaptor board is slightly longer to accomodate the uSD card socket.

I/O Signals
=========================
Venus822 has 2 sets of UART, TXD1/RXD1 and TXD2/RXD2. TXD1/RXD1 is connected to UART-to-USB bridge chip to allow USB interfacing. The TXD1 output is also brought out to a pin. RXD1 is not brought out to a pin, because the application UART driving RXD1 would conflict with the USB-to-UART bridge chip also driving RXD1. For a NS-RAW application needing TTL serial output, you can use TXD1.

The Venus822 device is LEON3 Sparc-V8 + FPU + memory + peripherals. All LEON3 Sparc-V8 & FPU details can be found in section 69 of GRIP document. What we need to add to the existing Venus822 datasheet are the memory map and peripheral register control descriptions.  http://t.cn/8FbovJT  http://t.cn/8Fboh6t

The GPS/GNSS chip datasheet from other vendors are all like this: just enough information for making a GPS receiver. :-) http://t.cn/8FboAEX

We will modify the [initial] hardware design to support time stamping on external trigger. The NavSpark time accuracy is ~60nsec due to the 16.368MHz clock. For -GL, -BD, time accuracy is ~40nsec due to 24.552MHz clock. NavSpark’s time stamp will be correct in an absolute time reference frame, with an error within 60nsec or 40nsec.

GPS, GLONASS, Beidou
=========================
Q: Why would I choose a GLONASS or Beidou-capable system instead of GPS-only?

A: In an urban canyon or a heavy signal attenuation environment, a dual-satellite navigation receiver may give better accuracy with more satellite measurements available. Outside Asia, one will see more GLONASS signal than Beidou signals, since the latter is not yet fully deployed yet. So NS-GL may perform better than NS-BD under adverse condition in North America. Under open sky with good satellite visibility and enough satellites over all time, GPS/GLONASS or GPS/Beidou will not offer more accurate 1PPS timing than GPS alone.

NS-GL will see more satellites, due to 24 globally orbiting MEO GLONASS satellites. Beidou is not fully deployed yet, with only 5 globally orbiting MEO satellite, 6 geostationary and 5 inclined geostationary satellites over Asia.

Venus8 baseband hardware is designed to handle GPS/Galileo, GLONASS, and Beidou signals from 3 IF signal paths concurrently, yet there’s only GPS + GLONASS or GPS + Beidou 2 IF paths RFIC available, thus we’re unable to have solution processing all 3 signals concurrently yet.

We will have poor GLONASS performance if we make GL and BD reception software configurable due to the RF front end, and there isn’t an alternative cost-effective single RFIC design that supports configurable dual reception of GPS/GLONASS and GPS/Beidou. Reluctantly we had to have different hardware for GPS/GLONASS and GPS/Beidou for optimal signal reception performance. Thus, due to different hardware, NavSpark-GL and NavSpark-BD cannot be configured into one and the other.

The RFIC we use does not support Galileo. All GPS/GNSS modules on the market claiming "Galileo-capable" likely will be superseded by their next-gen solution when there are enough Galileo satellites, and it is unlikely there will be resources to develop code for an older chip. Some may have experience with xxxxx-5 Galileo capable solution, which is already phased out by latest Galileo capable xxxxx-8 solution, yet no consumer ever saw Galileo reception on any of them. Such a marketing claim is to be taken with a grain of salt.

SkyTraq has been shipping GLONASS/GPS modules to Russia since early 2011, much earlier than ublox, MediaTek, or SiRF/CSR.

RAW output version
=========================
The NS-RAW module is GPS-only, it cannot be configured to be receive GPS/GLONASS or GPS/Beidou.  The NS-RAW module is not user-programmable.

NS-RAW output measurement data would go to RTKLIB which receives correction data from the reference station and takes measured data from NS-RAW to compute position to cm-level. SBAS output for raw measurement is in the pipeline.  The NS-RAW version is not (user-) programmable. NS-RAW can switch between binary mode that output carrier phase raw measurement data, and NMEA mode. In NMEA mode, PVT solution is computed and 1PPS signal will be generated. In binary mode, PVT solution is not computed and no 1PPS signal will be generated.

The RTKLIB website, especially the RTKLIB document, has sufficient information on how to properly setup and run using a low cost GPS receiver. NS-RAW is compatible to S1315F-RAW mentioned in the RTKLIB document. There is also a forum with much discussion on RTKLIB below for reference:  http://www.rtklib.com/   http://t.cn/8FG6RMr

RTKLIB has a utility that converts our [SkyTraq] binary to RINEX. We also have a program that converts to RINEX that we could provide.

S1315F-RAW uses Venus 6 chipset. At the first posting of NS-RAW, we were still having some issue with Venus8 port working with RTKLIB, so Venus 6 version was planned as backup. Last Friday [Jan.17 2014] we had Venus8 port working correctly with RTKLIB, so we expect to ship NS-RAW using the Venus 8 solution.

Q: Is there any reason why you can’t configure the Navspark/Narspark-GL/Navspark-BD to output the same data as the Navspark-RAW?

A: It’s mainly market segmentation issue, similar to software companies having different price bundles for a product, although they could have offered all-encompassing features for the lowest price model as there is no difference in production/distribution cost. Take Microsoft Office for example. :-)

GPS Antenna
=========================
The supplied internal active antenna will be 1”x1” type, 10cm lead length, ~28dB gain, current drain < 10mA. We are still deciding on the antenna supplier, it will be something that looks like this: http://t.cn/8Fbz7t4

Due to construction of the female connector on the antenna, it has rating of less than 50 plug/unplug cycles, although we see far higher durability in our production S2532DR dead-reckoning GPS module which uses female UFL on test-fixture. UFL male receptacle on the PCB has a typical rating of 500 plug/unplug cycles. So if the supplied embedded active antenna is left in place without much plug/unplug, it will last for a long time. In case it wears out, a 2nd antenna comes in handy.

Despite being more compact, the problem with an antenna on board is that it then becomes the bottleneck on receiver performance. Usually the bigger the antenna, the better the signal reception performance. Having the RF connector allows the user to choose a different antenna according to their needs.

GPS Performance
=========================
GPS accuracy highly depends on signal condition. Accuracy under open sky is 2.5m CEP for position, 0.1m/sec for speed, 10nsec for time pulse.  An example application using the previous generation Venus 6 chipset has been added to the NavSpark page; it might serve as a reference on quality of the GPS. NavSpark uses the latest Venus 8 chipset, which has the good performance characteristics of the previous generation.

NavSpark TTFF (Time to First Fix) is 30 sec average under open sky. The 34 tracking channels are not fully used. Some GPS vendors claim 48 tracking channels while showing no more than 16 signals; what difference is there between 16, 34, 48, or 100 tracking channels to an end user? :-)

Time from one satellite
=========================
The signal traveling from a GPS satellite to earth takes about 70msec. With just one GPS signal with sufficient signal strength to decode the data bits, the GPS receiver can determine time with an error of less than the distance variations between zenith and horizon position, if accounting for the signal travel time difference, or if not then within 100msec error. For an outdoor clock that only shows hours, minutes, and seconds, this 100 msec accuracy without ever needing to adjust the time is pretty good.

NavSpark doesn’t have precision timing mode receiver features such as TRAIM, self-survey mode and single-sat precision 1PPS timing generation. The SDK for standard navigation and tracking application is integrated into the Arduino IDE; it has same feature as those $40 ~ $60 GPS receivers selling on hobby electronics sites, but with the unprecedented major feature of SkyTraq’s $199 SDK put into the form of an Arduino IDE.

Updates and Changes since campaign started
=========================
1) New RAW-output version (for use with RTKLIB)
2) Change mini-USB connector to micro-USB (USB Forum has declared mini obsolete)
3) New feature: 60/40 nsec resolution timestamp on external input
4) New adaptor board option with microSD socket, battery charger & connector
5) Will be unable to support MAC-OS (SDK remains Windows / Linux only)

The original ship date was pushed back due to problems with 3rd party antenna performance, but all of the Indigogo NavSpark perks shipped out during the week of May 11 2014, according to the May 18 update at
https://www.indiegogo.com/projects/navspark-arduino-compatible-with-gps-gnss-receiver#activity