A blog about digital signal processing and GNSS. My personal thoughts about interesting work stuff.
In this series of articles I’d like to share my experience in GNSS receiver design over the last 10+ years. Writing down the knowledge on various topics is an excellent way to share the information, as well as structuring and preparing this kind of educational material allows one to find the missing pieces in one’s knowledge.
Part 0: Hardware and system design Part 1: Digital frontend Overview Mixer Verification of operations Hardware-friendly optimizations Resampler Hardware-friendly optimizations Signal packer Summary Part 2: Jamming mitigation Part 3: Acquisition Part 4: Correlation and tracking Part 5: Standalone positioning Part 6: Advanced positioning methods Overview In software-defined and software-oriented…
GNSS jamming is something I’m very familiar with and with what I’ve been involved in for most of my career. My specialist’s thesis (6-year degree, Russian alternative to bachelor and master combined) was about real-time narrowband interference mitigation for GNSS receivers with FIR-filters, I wrote several papers about that and, eventually, I became a scientific supervisor of the big antijamming…
Signal acquisition is a process of a rough estimation of partial code delay and pseudo-Doppler frequency to provide a bootstrap for the tracking loops. In the modern software-defined receivers there’s a designated hardware/software block called the Fast Search Engine (FSE) that is used to speed up the initialization of the receiver in the case of a cold start.
It is extremely useful to have a little vacation every once in a while, to distract yourself from your day-to-day basis. You may find yourself thinking about various tasks you were too busy to give some serious time to. One of such tasks I was intrigued about is the guitar cabinet simulation via the impulse responses of the real cabinet-microphone pair.
Every time I work with a C library, I miss the power and capability of the type system C++ provides. That’s why I developed a simple C++17 header-only helper library to pack the multiple type-dependent C-style functions into single overload deduced at compile-time. No external libraries are required. Repo link: https://github.com/MKlimenko/plusifier. Currently, it’s just the header and a…
TL;DR; I’ve made a (yet another) simple repo and a table on its’ wiki to estimate the build penalty when including boost headers.
TL;DR: There’s an excellent new GNSS dataset which would allow you to become a better engineer: link. Beware, it would take some time to download it.
Introduction Benchmarking first Creating a library Delayed library loading Generating multiple libraries Detecting the processor architecture at runtime Using the library
In 2016, before moving to GitHub pages as a hosting platform for this blog, I wrote a little post about CI and automated builds for C++ projects as a synopsis for the week I spent at work with this task. Currently, we’re modernizing the technological stack for one of our paramount product (neural network middleware for the NeuroMatrix processors called NMDL) and one of the tasks is to configure…