Using the library with esp32s3

[brightproject]

Good day @flybrianfly😀

I use a cyclone m1025c that produces M10 ubx format.

Using u-center, I successfully connected to the device via uart, configured it to output only ubx and a frequency of 10 Hz.

This library is intended for Arduino compatible boards and for stm32, but it seems that it does not work on esp32 boards.

This code calls the hardware Serial, in esp32 this is done differently and after flashing the device disappears via usb, only forced entry into the boot mode helps.

ublox/src/ubx.h

Line 144 in b472d38

HardwareSerial* bus_;

If you comment out the line

gnss.Begin(GNSS_BAUD)

Then usb is detected on the device as a com port and behaves as usual.

The pseudocode is:

#include <Arduino.h>
// #include "freertos/FreeRTOS.h"
// #include "freertos/task.h"
#include "esp_system.h"
#include "esp_log.h"
#include "driver/uart.h"
#include "string.h"
#include "driver/gpio.h"
// UBX parsing library
#include <ubx.h>

#define SERIAL_BAUD 115200
#define GNSS_BAUD 115200

#define UART_GNSS UART_NUM_2   // UART2 — GNSS
#define UART_GNSS_TX_PIN (GPIO_NUM_38)
#define UART_GNSS_RX_PIN (GPIO_NUM_39)

#define BUF_SIZE (1024)

// binary output OK
bfs::Ubx gnss(&Serial2);

static const char *TAG = "uart_example";

void uart_init()
{
    // --- UART GNSS (UART2) ---
    uart_config_t uart_gnss_config = {
        .baud_rate = GNSS_BAUD, // GNSS speed
        .data_bits = UART_DATA_8_BITS,
        .parity    = UART_PARITY_DISABLE,
        .stop_bits = UART_STOP_BITS_1,
        .flow_ctrl = UART_HW_FLOWCTRL_DISABLE
    };
    ESP_ERROR_CHECK(uart_param_config(UART_GNSS, &uart_gnss_config));
    ESP_ERROR_CHECK(uart_set_pin(UART_GNSS, UART_GNSS_TX_PIN, UART_GNSS_RX_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE));
    ESP_ERROR_CHECK(uart_driver_install(UART_GNSS, BUF_SIZE * 2, 0, 0, NULL, 0));
}

void setup() {
  Serial.begin(SERIAL_BAUD);
  // Serial2.begin(GNSS_BAUD);

  uart_init();

  Serial.println("communication with GNSS");

  if (!gnss.Begin(GNSS_BAUD)) {
    Serial.println("Failed to establish communication with GNSS RX");
    while (1) {}
  }

  // Serial.print("Serial port speed: ");
  // Serial.println(SERIAL_BAUD);
}

void loop() {

  // forwarding serial2 to serial
  // if (Serial2.available())
  // Serial.write(Serial2.read());
  // Serial2.write(Serial.read());

  // delay(20);

  if(gnss.Read()) {
    Serial.print(gnss.fix());
    Serial.print("\t");
    Serial.print(gnss.num_sv());
    Serial.print("\t");
    Serial.print(gnss.lat_deg(), 6);
    Serial.print("\t");
    Serial.print(gnss.lon_deg(), 6);
    Serial.print("\t");
    Serial.print(gnss.north_vel_mps(), 2);
    Serial.print("\t");
    Serial.print(gnss.alt_msl_m());
    Serial.print("\t");
    Serial.print(gnss.alt_wgs84_m(), 2);
    Serial.print("\n");
  }
}

Is it possible to adapt the library code for esp32?
Thanks!

[flybrianfly]

It seems like there are a couple options:

1. Add the ESP32 specific options, like we did with the SBUS Library
2. Have the user configure the serial and then just take a pointer to the HardwareSerial object for parsing by the library.

Either could work - I'm leaning toward option 2 since I'm sure other vendors will do some weird stuff with the way they implement Serial and there are already vendor specific ways to increase the serial buffer size.

[brightproject]

It seems like there are a couple options:

Changed the function like this:

bool Ubx::Begin(int32_t baud) {
  Serial1.begin(baud, SERIAL_8N1, 39, 38);
  while (comm_timeout_count_++ < COMM_TIMEOUT_TRIES_) {
    if (ParseMsg()) {
      return true;
    }
    delay(COMM_TIMEOUT_DELAY_MS_);
  }
  return false;
}

And this:

bool Ubx::Read() {
  while (Serial1.available()) {
    // Serial.println("Read and avail");
    if (ParseMsg()) {
      if (rx_msg_.cls == UBX_NAV_CLS_) {
        switch (rx_msg_.id) {
          case UBX_NAV_POSECEF_ID_: {
            if (rx_msg_.len == ubx_nav_pos_ecef_.len) {
              memcpy(&ubx_nav_pos_ecef_.payload, rx_msg_.payload, rx_msg_.len);
            }
            break;
          }
          case UBX_NAV_PVT_ID_: {
            if (rx_msg_.len == ubx_nav_pvt_.len) {
              memcpy(&ubx_nav_pvt_.payload, rx_msg_.payload, rx_msg_.len);
            }
            break;
          }
      }
    }
  }
  if (eoe_) {
    eoe_ = false;
    ProcessNavData();
    return true;
  }
  return false;
}

bool Ubx::ParseMsg() {
  while (Serial1.available() > 0) {
    c_ = Serial1.read();
...
}

Reading leads nowhere:

void setup() {
  Serial.begin(SERIAL_BAUD);
  Serial.println("communication with GNSS");
}
void loop() {
  if(!gnss.Read()) {
    Serial.print(gnss.fix());
    Serial.print("\t");
    Serial.print(gnss.num_sv());
    Serial.print("\t");
    Serial.print(gnss.lat_deg(), 6);
    Serial.print("\t");
    Serial.print(gnss.lon_deg(), 6);
    Serial.print("\t");
    Serial.print(gnss.north_vel_mps(), 2);
    Serial.print("\t");
    Serial.print(gnss.alt_msl_m());
    Serial.print("\t");
    Serial.print(gnss.alt_wgs84_m(), 2);
    Serial.print("\n");
  }
}

communication with GNSS
0.0.0.000000.0.000000.0.00.0.00.0.00
0.0.0.000000.0.000000.0.00.0.00.0.00
0.0.0.000000.0.000000.0.00.0.00.0.00

The GNSS receiver has a chip like this:

UBX-M10050-KB

Perhaps the parser doesn't work with the M10?

[flybrianfly]

This line seems like a bug - it is only going to print data when the GPS was not read correctly:

void loop() {
  if(!gnss.Read()) {

[brightproject]

This line seems like a bug

Yes, you're right!😀

!gnss.Read())

I intentionally inverted the logic to verify the output.
It seems to me that the ESP32 parser can't grab data from the UART fast enough.
I also tried this parser

https://github.com/simondlevy/UBX_Parser

But there's also no data when reading from the M10050 device.
However, the ESP32 can read data from Serial1 and send it back to Serial1, as verified by the code:

void loop() {
if (Serial1.available())
Serial.write(Serial1.read());
}

And by running it in U-Center.
I think all the codes on GitHub work with the old UBX format, but not for the M10 yet.
Either the ESP32 can't parse the UBX protocol properly, or I'm missing something.
Currently, I can't get an STM32 or Teensy.
Could you please tell me if you have an ESP32 available to help debug the library?😀

[brightproject]

It would be great to rework the library so that it would work on ESP32 and have the ability to send messages to configure the speed of operation and others.

Working with u-center 2 after using u-center 1 is a huge challenge.
The developers redesigned the interface, and now finding the settings is a nightmare.
I managed to learn some commands for the HEX editor, for changing the sample rate and the command to save settings.

from u-center 1

from u-center 2

After send CFG need send SAVE

UBX-CFG-RATE
Measument Period
B5 62 06 08 06 00 D0 07 01 00 01 00 ED BD
D0 07 01 00 01 00 - 0.5 Hz(2000)

B5 62 06 08 06 00 E8 03 01 00 01 00 01 39
E8 03 01 00 01 00 - 1.0 Hz(1000)

B5 62 06 08 06 00 20 03 01 00 01 00 39 89  
20 03 01 00 01 00 - 1.25 Hz(800)

B5 62 06 08 06 00 90 01 01 00 01 00 A7 1F
90 01 01 00 01 00 - 2.5 Hz(400)

B5 62 06 08 06 00 C8 00 01 00 01 00 DE 6A
C8 00 01 00 01 00 - 5.0 Hz(200)

B5 62 06 08 06 00 64 00 01 00 01 00 7A 12
64 00 01 00 01 00 - 10.0 Hz(100)

UBX-CFG-CFG
B5 62 06 09 0D 00 00 00 00 00 FF FF 00 00 00 00 00 00 03 1D AB
00 00 00 00 FF FF 00 00 00 00 00 00 03 -SAVE

In the program code I do it like this:

const static char rate_a[] = {0xb5, 0x62, 0x06, 0x08, 0x06, 0x00, 0x90, 0x01, 0x01, 0x00, 0x01, 0x00, 0xa7, 0x1f}; // 2.5 Hz
const static char save[] = {0xb5, 0x62, 0x06, 0x09, 0x0d, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x1d, 0xab};

void setup() {
  Serial.write(rate_a, sizeof(rate_a)); //set GPS update rate to 2.5Hz
  delay(50);
  Serial.write(save, sizeof(save)); //SAVE
}

void loop() {
// ANYTHING
}

[brightproject]

Unfortunately, reducing the sample rate to 2.5 Hz, as well as to 0.5 Hz, yielded no results.
The serial port still isn't receiving data from the Ublox parser.
You mentioned the need to enable UBX-NAV-PVT and UBX-NAV-EOE messages this here:

#12 (comment)

The UBX-NAV-HPPOSLLH message isn't available for my device, but I do have UBX-NAV-POSLLH, and I've enabled it.
Also, EOL isn't available for me.

Friend, I think I've found the reason for the missing data 😀
Indeed, the missing EOE was preventing the parsing from completing as TRUE.
I commented out these lines:

ublox/src/ubx.cpp

Line 134 in b472d38

if (eoe_) {

  // if (eoe_) {
  //   eoe_ = false;
    ProcessNavData();
    return true;
  // }

And I got the coveted data at the output:

3.9.52.4118612.13.0823852.27.21.1041.00.1054.40

I was confused by the altitude values
alt_msl_m() and alt_wgs84_m()
The u-center program returns values ​​of about 3,000 meters, while the parser reports values ​​of about 1,041 meters, although they look more like feet.
My actual altitude is about 5 meters above the ground.
But I'm indoors, so the readings might be more accurate outdoors.

UPD:
I don't know how, but I managed to enable it in the EOE settings, and the code returned to its default values.

[flybrianfly]

Yes, EOE is required for this parser to work, so it's good that you managed to find that.

Not sure about implementation of configuration in the library - it would be a nice feature, but there are two different ways to configure the uBlox receivers; older receivers have one method and newer receivers another. So it would be a big addition with a lot of code needed. I think the Sparkfun library supports a lot of configuration options in the meantime.