Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a unique device ID to Messages list #449

Open
becorey opened this issue Aug 2, 2024 · 3 comments
Open

Add a unique device ID to Messages list #449

becorey opened this issue Aug 2, 2024 · 3 comments

Comments

@becorey
Copy link

becorey commented Aug 2, 2024

Subject of the issue

With an RTK EVK sending messages using TCP Client, there is currently no unique device ID available to identify the device.
With a unique ID, it would enable the possibility of deploying a fleet of RTK EVK devices which all report data back to a central server, and keeping track of which device is associated with which incoming data.
The ID could be the UBX-SEC-UNIQID, the ESP32 MAC address, or some combination of those.
Reference to forum post Unique device ID in RTK EVK messages?

Your workbench

  • What version of RTK firmware are you running?
    • Beta d1.4
  • What radios are you using: Bluetooth, WiFi, and/or ESP-Now? What app are you using to connect over Bluetooth? Are you transmitting NTRIP back to the device?
    • Wifi, using TCP Client. Yes NTRIP to the device from PointPerfect.
  • Are there any additional details that may help us help you?
    • The RTK EVK is installed with a vehicle and powered by the vehicle's 12V battery. A 4G modem/router provides Wifi to the EVK. The EVK sends messages using TCP Client to a server which logs the messages to files. Data is collected for several hours each day to track the movements of the vehicle.

Steps to reproduce

Tell us how to reproduce this issue. Please post any log files from serial output that may have been generated.
Put RTK EVK into Wifi Config mode, visit the config screen with a browser. Open the list of Messages available to send. There are many available but as far as I can tell none of them include a unique ID to identify the device that is sending messages.

Expected behavior

Tell us what should happen
It could implement a similar approach as SparkFun_RTK_Firmware #476, adding a $GNTXT message which sends the GNSS unique chip ID and the last four digits of the ESP32 MAC address.
It could be sent periodically like any other message and likely would be set to a low frequency such as once every 20 fixes.

Thank you!

@nseidle
Copy link
Member

nseidle commented Aug 9, 2024

This is a great feature to add but will require a considerable amount of work to implement. We'll need to add a custom message generator which has no precedence. Please give us some time to consider how it might be added. In the mean time, if you have any ability to contribute to the codebase, we welcome PRs.

@PaulZC
Copy link
Contributor

PaulZC commented Oct 30, 2024

I've been thinking about this:

Injecting GNTXT messages periodically into the message stream to the TCP server is ~difficult. I think we would need to change the way messages are parsed, and allow injection of GNTXT when the parser finds the end of a valid message. Maybe we could modify the parser so that it searches for GNGGA, and 'appends' the GNTXT to that? Messy, but, in my mind, it could work.

What would be much easier, would be to send the GNTXT message once when the TCP client connects to the server. I.e. it is the first thing sent to the server, before the stream of other messages begins. We would need to add a client->write here.

Corey (@becorey ): would the easy option meet your needs?

@PaulZC
Copy link
Contributor

PaulZC commented Oct 30, 2024

Edited: fixed the links...

I.e. take this code and change it to client->write's

And while we're in there, we should add the brand and platform prefix to the firmware version. The version date on its own isn't that useful...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants