Программа для отображения цифровых сигналов

Мы живём в цифровую эру. Даже если вы не имеете понятия, в чём разница между процессором и оперативном памятью, GSM и GPS, вам всё равно нужно смириться с тем, что подавляющая часть окружающих вещей содержит в себе что-то цифровое. Это может быть простая RFID-метка на пакете молока или в билете на общественный транспорт, либо же сложное устройство, упакованное в красивый корпус.

Всё замечательно с точки зрения потребителя, поскольку устройства становятся умнее, меньше и дешевле. Одновременно с развитием технологий появляются и новые идеи, упрощая нашу ежедневную жизнь. Мы, инженеры, превращаем эти идеи в реальные устройства.

Когда речь идёт о реальных устройствах, сразу возникает потребность в работе с реальными сигналами, которые нужно посмотреть, проанализировать, сравнить, и.т.д. Для этих целей созданы несколько библиотек (например, gnuplot), но мне они кажутся слишком сложными и перегруженными функционалом. На моем месте работы у нас есть библиотека для внутреннего пользования, позволяющая строить одномерные сигналы и это восхитительная вещь. Она делает ровно то, что от неё требуется и даже чуть больше. Она прекрасно служит единственной цели: построить сигнал.

Однажды на собеседовании меня спросили, был ли у меня опыт и умею ли я читать и анализировать сигнал в двоичном виде, и этот вопрос меня очень сильно удивил, потому что кому захочется это делать "на пальцах", когда гораздо проще построить сигнал и посмотреть на него?

Вот почему я решил написать приложение, построенное на библиотеке, которую я упоминал ранее. Приложение тоже не перегружено функционалом и делает ровно одну вещь: отображает с указанными параметрами файл, который был ей передан. Например, вот результат передачи двух файлов с разной структурой (сверху комплексный 16-битовый сигнал, снизу действительный 8-битовый) в программу:

Необходимое приведение типов тут реализовано достаточно просто, программа читает файл в виде массива байт (uint8_t, если быть точнее), а затем указатель на этот массив передаётся в библиотеку через reinterpret_cast.

Есть у программы и одна нерешенная проблема, а именно работа с упакованными сигналами. Сигналам ГНСС требуется всего 1-2 бита для эффективного квантования, так зачем тратить целый байт на каждый отсчёт? Несколько раз я видел оцифровки сигналов, которые были упакованы насколько это позволяет логика. Это сигнал с приёмника GPS/ГЛОНАСС диапазонов L1 и L2, в котором каждый байт выглядел следующим образом (если делить на биты): 

|GPS L1 Inphase|GPS L1 Quadrature|GLN L1 Inphase|GLN L1 Quadrature|GPS L2 Inphase|GPS L2 Quadrature|GLN L2 Inphase|GLN L2 Quadrature|

На данный момент я не могу придумать способ, как пользователю лучше сообщить способ упаковки сигнала программе. У меня есть пара идей, но они достаточно сложные и запутанные для конечного пользователя и я не хочу их использовать. Так что на данный момент перед отображением сигнала его нужно распаковать.

В любом случае, если вы как-то дочитали до этого места, то вы либо заинтересованы в этой программе, либо один из моих друзей, которым я наскучил ссылками на этот блог. Я не уверен, имею ли я право выкладывать прямую ссылку на программу, но если вы собираетесь её использовать в каком-нибудь некоммерческом проекте, смело пишите мне на электронную почту, которую можете найти в правом столбце этого блога.

Digital Signal Visualization

We live in the digital era. Even if you have no idea what is the difference between RAM and the CPU, or between GSM and GPS, you have to accept the fact that the vast majority of the surrounding things have something digital inside. It may be either a simple RFID chip on a pack of milk or public transport ticket, or a complicated device hidden in a beautiful enclosure.

Everything is great from a consumers point of view, because the devices are getting smarter, smaller and cheaper. Simultaneously with the technology advancement new ideas appear, simplifying our daily routine. We, the engineers, convert those ideas into real devices.

When there are real devices there are real signals, which need to be viewed, analysed, compared etc. There are several libraries made for this purpose (gnuplot, for example), but they're too complicated for me and overloaded with possibilities. At my work we have an internal library for building one-dimensional signals and it's one hell of a software. It's doing just what you want from it and a bit more. It's great at serving one exact purpose: plotting the signal.

Once I've had an interview and I was asked about any experience in analysing the signal in the binary form and I was genuinely confused by this question: why would I want to analyse it this way, when it's much easier to plot it and view?

And that's why I've decided to make an application based on our internal library. It does one thing: displays the file you've specified with the parameters you've mentioned. For example, here's the result of passing two files with different data structures (complex vs real, 16-bit vs 8-bit) to the program:

Casting to the required type of data is pretty simple, program reads file as an array of bytes (uint8_t actually), and then the pointer to this array passed to the library via the reinterpret_cast. 

One problem isn't solved yet: dealing with packed signals. GNSS signals require only 1 or 2 bits to be efficiently quantized, so why would one want to spend one byte per every sample? Several times I've seen signals, which are packed beyond any reasonable point. It was a signal from GPS/GLONASS L1+L2 receiver and every single byte looked like this (separated to bits):

|GPS L1 Inphase|GPS L1 Quadrature|GLN L1 Inphase|GLN L1 Quadrature|GPS L2 Inphase|GPS L2 Quadrature|GLN L2 Inphase|GLN L2 Quadrature|

For now I can't figure out a way for user to tell the type of packaging to the application. There are some ways, but they're pretty complicated and I don't want to use them. So for now you have to unpack the signal before you visualize it.

Anyway, if you've managed to read this far, you're either interested in this application or one of my friends I've bothered beyond any reasonable level. I'm not pretty sure if I'm allowed by the corporate etics to give the direct link, but if you need it for non-commercial use, feel free to contact me via the e-mail, which you may find at the right side of this blog.