Unique device ID in RTK EVK messages?

I am looking to have multiple RTK EVK units operating remotely in the field and reporting back data to a central server using TCP Client. So far I successfully have the messages from one device streaming to a server in the cloud.
Next, I need unique ID’s in the messages so that I can tell the different EVK devices apart.

I found this similar topic NMEA $GNGGA sentence output (reference station ID)
where it talks about a GNTXT message, however I don’t see that listed under the “Message Rates” config which seems to list all possible messages the EVK can send. Do any of those messages contain a unique device ID?

If the UBX-SEC-UNIQID were available in the list of Message Rates that would be perfect. The group of messages above and below it in the datasheet RXM- and TIM- are in the list so maybe it would be easy to add in

Hi Corey,

The firmware reads the Unique ID from the GNSS, converts it to NMEA format and adds it to the start of the microSD log file.

The UBX-SEC-UNIQID message is “output”. It needs to be requested. It can’t be made “periodic”. So it wouldn’t be “easy” to add.

What would be required is a way to periodically inject the ID in NMEA format into the data stream which is output to TCP and the other message “consumers”. That’s reasonably complex and I don’t think we’ve done anything similar before. You are welcome to open a “Feature Request” issue for it on GitHub:

Best wishes,
Paul

Sorry, I did not mean to make it sound trivial. I was just hopeful it could be included without too much trouble, but I did not realize the difference between “output” and “periodic”. I will open a feature request.

I’m hoping to have 10’s of these operating stand-alone in the field but I would need some unique ID to tell them apart. The server I’m running starts a thread for each connection and logs to a file, so at least NMEA messages would not be mixed together from units reporting over the same time period. But I still wouldn’t precisely know which data corresponded to which vehicle. A workaround might be keeping a list of “likely” locations for each vehicle, then using that to associate the vehicle to the gps data file.