You are currently viewing Повідомлення у форматі NMEA, що надсилає u-blox NEO-6M GPS приймач у автоматичному режимі

Повідомлення у форматі NMEA, що надсилає u-blox NEO-6M GPS приймач у автоматичному режимі

Під час виробництва комерційних, чи аматорських проектів з розробки розумних речей, іноді потрібно отримувати точні дані про розташування кишенькових чи стаціонарних електронних пристроїв у просторі та часі. Як це відбувається?

На прикладі поширеного і простого у використанні GPS-приймача u-blox NEO-6M ми у стислій, концентрованій формі розглянемо і покажемо, які дані можливо отримати, підключивши NEO-6M GNSS-сенсор до платформи NodeMCU з скриптовою мовою програмування Lua.

Рис 1 . GPS приймач u-blox NEO-6M підключено до ESP8266 з прошивкою NodeMCU / Lua

Існує декілька способів взаємодії з цим (і подібними) GPS-трекером, однак, оскільки ми вже маємо готовий модуль GY-GPS6MV2, де шину I2C не виведено на штирі, а серед інтерфейсів наявний лише pin-header підключення по UART, то розглянемо цей варіант.

Модуль з u-blox NEO-6M є зручним для початківців на наш погляд, адже абсолютно не потребує вихідних налаштувань, щоб почати ним користуватися. Після подачі живлення цей “сенсор” починає по черзі видавати в UART на швидкості 9600 бод, текстові повідомлення у форматі NMEA.

З апаратної точки зору, мікроконтролер ESP8266 має буквально півтора фізичні порти UART. Один повний (йдеться про сигнали Tx-, Rx-) порт UART0 – використовується для підключення консолі розробника, а інший, UART1 – має можливість лише передавати дані (тобто тільки Tx-).

Апаратні порти UART у ESP8266 жорстко прив’язані до певних GPIO і їх неможливо “перекинути” внутрішнім мультиплексором у програмний спосіб з одних виводів на інші.

Тому маємо:

  • UART0 це завжди Tx / D10 (GPIO1) і Rx / D9 (GPIO3);
  • UART1 це відповідно Tx / D4 (GPIO2).

Для дизайну рішення з використанням підключення по UART, як бачимо, лишається не так багато ходів:

  • або потрібно відмовитися від консолі розробника, що буде вкрай незручно;
  • або ж потрібно підключатися до обмеженого апаратно UART1.

Але існує інший, кращий шлях. Бібліотека функціональних C-модулів платформи NodeMCU нещодавно поповнилася ще одним цікавим і корисним модулем – softuart, який дозволяє організувати додатковий віртуальний порт UART. До того ж, віртуальний UART-порт може бути організовано майже на будь-яких двох GPIO-виводах мікроконтролера ESP8266.

Посилання на документацію: https://nodemcu.readthedocs.io/en/release/modules/softuart/

Скористаймося нагодою і у статті не лише висвітлимо повідомлення від підключеного GNSS-приймача, а і зробимо це через модуль “softuart.” – потрібно ж перевірити, чи новий модуль взагалі працює. Тим більше, що синтаксис і принципи роботи аналогічні з модулем апаратних UART – “uart.” прошивки NodeMCU.

Щоб не тримати інтригу, одразу зазначимо, що “softuart.” працює і нашу задачу з підключення u-blox NEO-6M ми виконали. Щоправда, як і попереджає документація: “Software implementation of serial port can be unreliable and some reception errors are to be expected”. – виявилося цілковитою правдою.

Порівняно із апаратним UART, який ми теж перевіряли раніше з цим самим модулем GPS, програмний UART сипле “сміттям” так, що нам довелося навіть дещо переписувати код парсера пакетів, що був розроблений нами раніше для драйвера апаратного інтерфейсу “uart.”

На Рис 2. ми наводимо сирі дані із “сміттям”, що потрапляють у NodeMCU до фільтрів і парсера. У варіанті реалізації через апаратний UART, проблеми “сміття” не було взагалі.

І це ще дуже добре, що задачу з очищення даних довелося виконувати саме на Lua, адже як відомо, ця мова має вдосталь потужних інструментів обробки і перетворення текстових рядків з шаблонами, паттернами, пошуком і підстановками.

Рис 2. Сирі дані, що отримано від GPS-приймача у консоль через UART (працюємо через програмний емулятор UART, C-модуль softuart)

Після обробки події :on() фільтрами та парсером, формується масив повідомлень (нам було зручно так зробити для тестування)

Рис 3. Впорядковані дані що отримано від GPS-приймача у середовище NodeMCU

Типи вхідних повідомлень

Повідомлення, які вдалось отримати від GPS-приймача u-blox NEO-6M при старті з автоматичними налаштуваннями:

Ретельно вивчаючи документацію виробника, ми сподівалися знайти хоча б якесь поле у протоколі, яке відповідає за поточну таймзону і перехід на літній / зимовий час. Але ні, такого поля немає. В усіх типах повідомлень передається лише час UTC.

Поля повідомлень та їх призначення

Посилання на документацію з сайту виробника:

https://www.u-blox.com/en/product/neo-6-series#tab-documentation-resources

GPRMC – Мінімальні рекомендовані дані

Приклад реального повідомлення:

GPVTG – Курс та швидкість відносно поверхні землі

Приклад реального повідомлення:

GPGSA – Геометричне погіршення точності GNSS та активні супутники

Приклад реального повідомлення:

GPGGA – Дані прив’язки системи глобального позиціонування

Приклад реального повідомлення:

GPGLL – Широта і довгота, з часом визначення місця розташування і стану

Приклад реального повідомлення:

GPGSV – супутники GNSS у полі зору

Приклад реального повідомлення:

Висновки:

  • бувають GNSS-приймачі, що готові до роботи зразу після подачі живлення;
  • модуль softuart працює і це значно посилює слабкі місця апаратної архітектури ESP8266-12;
  • у програмній реалізації інтерфейсу UART багато переваг з огляду на архітектуру ESP8266, але є і недоліки у вигляді “сміття” яке потрібно ретельно відфільтровувати;
  • застосування програмного інтерфейсу надає можливість не лише отримувати дані від GNSS-приймача, а і надсилати приймачеві команди (цю можливість ми не розглядаємо у даній публікації);
  • не всі типи повідомлень NMEA, що підтримує u-blox NEO-6M (а підтримується щонайменше 20 різних типів повідомлень), він надсилає через UART за замовчуванням;
  • протокол повідомлень NMEA досить простий для парсингу;
  • якщо є високі вимоги щодо заощадження об’ємів оперативної пам’яті, оберіть лише один тип повідомлень і працюйте лише з ним, наприклад GPRMC;
  • наявність в дизайні розумного пристрою GNSS-приймача не вирішує проблему встановлення поточної часової зони та переходу між зимовим / літнім часом;
  • пам’ятайте про необхідність написання обробника переривань у мінімалістичному стилі, інакше буде постійно спрацьовувати вбудований Software Watchdog ESP8266 і пристрій буде раз по раз рестартувати.