0
$\begingroup$

I'm using an ublox EVK M8T and I'm trying to make a script that displays in text console in real time the data from NMEA and also the time marker from when an event happens. Is there a possibility to display either the rising or falling edge value of tm2 or do someone have any documentation on how to do it since it in text console the tm2 is being displayed in a hex format? I've tried an implementation in matlab and pyth , both unsuccessful at the moment. enter image description here

 Packet Console  
        09:53:52  L -> UBX CFG,  Size   9,  'Config'
        09:53:53  L -> NMEA GPRMC,  Size  64,  'Recommended Minimum Specific GNSS Data'
        09:53:53  L -> NMEA GPGGA,  Size  65,  'Global Positioning System Fix Data'
        09:53:53  L -> NMEA GPGLL,  Size  52,  'Geographic Position - Latitude/Longitude'
        09:53:53  L -> UBX CFG,  Size   9,  'Config'
        09:53:53  L -> UBX-TIM-TM2, Size 14,  'Time Mark 2'

    Text console

        09:54:05  $GPGLL,4420.99497,N,02601.85621,E,095405.15,A,A*65
    09:54:06  $GPRMC,095406.12,A,4420.99496,N,02601.85609,E,,,221118,,,,A*78
        09:54:06  $GPGGA,095406.12,4420.99496,N,02601.85609,E,1,,,128.5,M,,M,,*51
    09:54:06  $GPGLL,4420.99496,N,02601.85609,E,095406.12,A,A*6A
        09:54:07  $GPRMC,095407.16,A,4420.99495,N,02601.85599,E,,,221118,,,,A*74
    09:54:07  $GPGGA,095407.16,4420.99495,N,02601.85599,E,1,,,128.6,M,,M,,*5E
        09:54:07  $GPGLL,4420.99495,N,02601.85599,E,095407.16,A,A*66
    09:54:08  $GPRMC,095408.13,A,4420.99494,N,02601.85592,E,,,221118,,,,A*74
        09:54:08  $GPGGA,095408.13,4420.99494,N,02601.85592,E,1,,,128.7,M,,M,,*5F
    09:54:08  $GPGLL,4420.99494,N,02601.85592,E,095408.13,A,A*66
        09:54:09  $GPRMC,095409.15,A,4420.99493,N,02601.85591,E,,,221118,,,,A*77
$\endgroup$

closed as off-topic by pericynthion, uhoh, Nathan Tuggy, GremlinWranger, Fred Dec 31 '18 at 7:53

  • This question does not appear to be about space exploration within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    $\begingroup$ ... I personally like the Teensy 3.5/3.6 boards (they have a fast CPU, a decent amount of RAM and PROM, a µSD slot, and include a single-precision FPU) but another option might work better for you. $\endgroup$ – Alex Hajnal Dec 31 '18 at 1:24
  • 6
    $\begingroup$ I'm voting to close this question as off-topic because it does not relate to space exploration $\endgroup$ – pericynthion Dec 31 '18 at 4:32
  • 2
    $\begingroup$ @AlexandruLapusneanu I've also voted to close but I am glad you were able to get some help here in the interim. Isn't this a perfect match for Stack Overflow? In fact, you have a very similar question there already. I think the thing to do would be to put some work into updating that question based on (and linked to) information in the answer here. The more details you can add there about what you have tried already and why it isn't sufficient, the more likely it will be you get a helpful answer. $\endgroup$ – uhoh Dec 31 '18 at 5:38
  • 1
    $\begingroup$ @AlexandruLapusneanu after a half-day you can make a substantial edit again, and that will bump it up in the active question queue so more people will see it. There is Geographic Stack Exchange as well, you can check to see if similar questions get answers there, but I think SO is the right place. I also recommend that once you post there you "babysit" the question and respond quickly to comments (like 60 seconds) as long as it seems productive. $\endgroup$ – uhoh Dec 31 '18 at 5:42
  • 2
    $\begingroup$ Add a partial script, example, anything that shows you have put in some effort first before asking. So I'd say don't worry about migrating this question. Put your time and energy into improving your [SO question] and include description of all your work and possibly links to the answer here. $\endgroup$ – uhoh Dec 31 '18 at 5:50
1
$\begingroup$

The messages being displayed on the console are NMEA, a plain ASCII text format (not hexadecimal). To do anything further with them you'll either need to write software yourself to interpret it or use 3rd-party software to do so. I've done both myself in both Perl and C++ and it was very simple and straightforward to do (here is a random example of doing it by hand in C++). Often-times you can you use (or adapt) an existing software library to do the parsing (the NeoGPS library for ublox / Arduino is one such option).

All of the common NMEA messages have been standardized with this page widely considered to be the definitive guide. Some vendors include custom NMEA messages; for these you'll need to refer to devices' manufacturers who should provide device-specific manuals. In your case, the document you want is u-blox 8 / u-blox M8 Receiver Description (including Protocol Specification), UBX-13003221.

In some cases, manufacturers offer their own, proprietary formats in addition to NMEA. To use these you will typically need to send a specific NMEA message to the GPS. The various vendor-specific proprietary formats often provide access to features or data not provided through the NMEA protocol. u-blox does this with their binary UBX protocol and the manual linked above describes how to use it (starting on p. 134). The format of the proprietary UBX-TIM-TM2 message (available only via UBX, not NMEA), for example, can be found on page 364 of that guide. Unlike the text-based NMEA protocol, you will need to use software to parse the UBX messages (the raw data isn't in human-readable form). The NeoGPS library mentioned above has partial UBX support. Another option is to forgo libraries entirely; here, for example, is an Arduino (or Linux/Unix, both platforms are supported) program that specifically supports the UBX protocol and the UBX-TIM-TM2 message; being C++ or Python it ought to be easily adaptable to other platforms. Other UBX libraries likely exist.


You say that, at least initially, you simply want to get data from the GPS onto your PC for further processing. What I'd recommend doing is to use an Arduino platform sitting between the GPS and your PC to convert the binary messages into a text-based format. The text-based format doesn't have to be anything standardized, just something you can easily parse (I recommend tab-delimited values with the first column containing the message type). You can then do further processing on the PC side. I don't recommend using, e.g., a Raspberry Pi in this type of application since those are usually used as embedded Linux systems and you want something simpler and more low-level. I personally like the Teensy 3.5/3.6 boards (no affiliation, tech specs here); they have a fast CPU, a generous amount of RAM and PROM, a µSD slot, and include a single-precision FPU. That's my favorite but another option might work better for you.

Before exploring Arduino options though, I'd suggest taking a quick look to see whether the aforementioned Python program can be adapted for your application. If you have have access to a Linux system (even the Raspberry Pi you mentioned having might suffice) this could save you a hassle (a Windows machine might also work but that platform appears to be poorly supported). Note that I'm referring here to logging to disk, not acting as a real-time translator/bridge (the previously-discussed Arduino option).

$\endgroup$
  • 1
    $\begingroup$ @AlexandruLapusneanu That was fast! I hadn't even finished editing it. $\endgroup$ – Alex Hajnal Dec 31 '18 at 0:46
  • 1
    $\begingroup$ If you like GPS questions, these could both use a 2nd answer How to detect potentially poor antenna placement from GPS data? and What exactly does C/No (dBHz) mean in u-Blox GPS data? $\endgroup$ – uhoh Dec 31 '18 at 2:01
  • 1
    $\begingroup$ @uhoh I'll take a look. $\endgroup$ – Alex Hajnal Dec 31 '18 at 2:02
  • $\begingroup$ @AlexHajnal could you provide mewith contact info in case that I have other questions? $\endgroup$ – Alexandru Lapusneanu Jan 7 at 1:52
  • 1
    $\begingroup$ @AlexandruLapusneanu I believe you should be able to adapt the Python program I mentioned to do it. That program expects a serial port (either real or emulated). I'm not familiar with ublox GPSes but typically you'll need a driver on the PC to emulate a serial port over USB (presuming the ublox presents a USB serial port); you'll see it as e.g. COM1 (Windows) or /dev/ttyUSB0 (Linux). I've only worked with GPSes with physical serial ports (a.k.a. UARTs) though. I would strongly suggest asking for more info on Stack Overflow; the folks there should be able to assist much better than I can. $\endgroup$ – Alex Hajnal Jan 8 at 0:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.