During the preliminary testing of the MC149.01 receiver, I was curious about checking our receiver against some other NT1065-based device. As far as I know, the most widespread one is the Piksi Multi by Swift Navigation. This is a remarkable ZynQ-based receiver with the best user-software I’ve seen. One of the advantages that we share is the software-defined processing: both the MC149.01 and the Piksi can be further upgraded to process more signals and improve receiver quality.
A lot has been said and done about modern (post-2011) C++. Most of the times it makes your code more expressive, which often leads to better optimizations from the compiler. As you may know, I’m currently working on a triple-band GNSS receiver, which is built upon the BBP2 SoC. This SoC has two NeuroMatrix DSPs and one ARM1176JZF-S core. NeuroMatrix has a very old toolchain, even pre-standardization era (~1995). ARM compiler toolkit is built upon some GCC version with C++11 core language support, but no library support.
During the development process of the MC149.01 GNSS receiver, we’ve got a delegation from the company making a reference station network. Their job is to make a Hydrogen Master clock-based station with three receivers inside. For one of their receivers they chose some of the Javad lineups, other two are vacant. Therefore, they came to us to test our device and, if all is good, include it in their master-device.
Every GNSS engineer has heard of the RTKLib. It’s an open source toolkit for real-time and post-processing of the raw GNSS data. The availability of such a toolkit is somewhat of a revolution: it allowed small companies to step into the high-precision navigation market without the need for spending a lot of time and money on R&D tasks. There are, however, some limitations and drawbacks:
One of the main reasons to choose C++ over any other programming language is performance. Eventually, this is what we’re being paid for. There are several cases when we have to write multi-platform: