Next Base 312 GPS format

StanislavM

New Member
Joined
May 26, 2017
Messages
7
Reaction score
0
Country
Russian Federation
Hi
is there any specification notes about the format of GPS data from this DVR?
In attachement there is sample in Hex,
i suppose ANE - means A- GPS valid N - coords are in North, E - coords in East, next are float (4 bytes) for longitude and next are float(4 bytes) for latitude.

1-jpg.31299


Is there any player that shows G-sensor information to determine the next bytes meaning?
 

Attachments

  • 1.jpg
    1.jpg
    60.5 KB · Views: 135
I've found that speed depends on the bytes:
HEX - speed value
4000 - 1.0
4100 - 1.1
000f - 1.1
0020 - 2.0
8000 - 2,1
f000 - 4.0
0001 - 4,3
0002 - 1,7
0003 - 6,9
0010 - 4,6
0030 - 8,6
0100 - 1,7
0200 - 3,4
0300 - 5,1
ffff - 24.1
00ff - 24.1
ff00 - 4.3
d001 - 1.4
d000 - 3,5
d040 - 12.0
d840 - 12,5
c000 - 3.2
2000 - 5,4

Does anybody know how it's calculated?
 
github.com/kbsriram/dcutils is go source of a program that decodes the gps info on 312GWs with older firmware. It does not work with the latest firmware as I have just discovered.

I hope Nextbase (Tiffany?) may reply and explain what has changed. Otherwise, I guess it is time for some hacking.
 
I could be wrong, but I'm sure I've seen 312 footage with either GPS in decimal or HMS. Maybe it changed during a firmware update ?
 
I think the format in the MOV file is raw gps (knots and so on). The conversion to decimal or HMS
is done in software. But perhaps you are speaking of the display in the video itself: "the GPS Location Stamp" ? That's not the issue here: it is the non-video part of the MOV file that encodes the position that seems to have changed.

I need explore the sggps source properly and explore what may have changed.
 
Well, erm, obviously :) Unfortunately Nextbase don't post release notes for new firmware, although they say that are about to change that. I haven't noticed any change in the "Location stamp" in the video itself, but I maybe I should do a careful comparison.

In the code, there is one "educated guess":
Code:
func toDD(spec byte, v float32) float32 {
        deg, frac := math.Modf(float64(v) / 100)
        result := float32(deg + frac/0.6)
        // An educated guess
        if spec == 'S' || spec == 'W' {
                result = -result
        }
        return result

And there is a struct:
Code:
type GPSLog struct {
        Magic         [4]byte
        _             [36]byte
        Hour          uint32
        Min           uint32
        Sec           uint32
        Year          uint32
        Mon           uint32
        Day           uint32
        Unknown       byte
        LatitudeSpec  byte
        LongitudeSpec byte
        _             byte
        Latitude      float32
        Longitude     float32
        Speed         float32
        Bearing       float32
}

I suspect these are where changes may have been made. But I have have only skimmed the code so far, and need far more understanding of the MOV format before I try anything serious.
 
Nextbase will often reply with high level firmware changes.

What is it you're trying to achieve ?
 
Extract the gpx gps track from the MOV file under linux, mainly for mapping in OpenStreetMap.
I have not tried Replay3 under Wine as yet, but even if it works, it is going to be painfully slow.

As go is portable, this will also benefit people using other operating systems. The sggps code is very fast.
 
Finally found a little time to look into this. It seems that the GPS positions are now recorded in what seems to be essentially raw NMEA format which is quite different from the earlier firmware. Not sure when it changed.
There are both GPRMC and GPGGA records which seem to repeat much of the same information. I wonder whether this is just straight from the GPS chip in the mount:? Maybe it is faster to just copy straight into the MOV file rather than do whatever formatting was happening before.

I should have a program, based on sggps, working soon. Not sure about supporting various firmwares. With any luck it will work for the whole of the Nextbase range, and maybe other makes. When I have it working for the 312GW with current firmware, I might ask for samples from other models to see what happens. Time permitting.
 
For my needs (PGPSW Verifier) I find Dashcam Viewer perfect as it outputs GPS in degrees decimal which is the format they require for camera submissions.

So with the embedded format being HMS and DV being Decimal then it must be possible to extract which format you need.
 
For my needs (PGPSW Verifier) I find Dashcam Viewer perfect as it outputs GPS in degrees decimal which is the format they require for camera submissions.

So with the embedded format being HMS and DV being Decimal then it must be possible to extract which format you need.

Is PGPSW http://pimp-my-nav.com/index.htm by any chance? I had never heard of it. Not much use under Linux, and doesn't generate a gpx file as far as I can see. But happy that it does what you need, and that it is (about to be) open source.

There is no problem extracting the GPS data now that I have found it is NMEA. Just have to find time to program that in an unfamiliar language. And decide how to handle the various different formats used by assorted firmwares. There does seem to be a firmware stamp, but it is right at the end of the file which is a bit of a pain: read the whole file to find the format, then read again to decode. (Yes I know there is some degree of random access on the filesystem.) I will know more when I have time to examine further.

My program should work on all the major operating systems since go is generally available.
 
[QUOTE="
My program should work on all the major operating systems since go is generally available.[/QUOTE]

A quick update: I now have my program working with the recent firmware. It is a bit rough and ready at present, but when I have cleaned it up I expect to make it available.
Meanwhile if anyone wants a copy urgently, drop me a note. It has only been tested on linux, but will probably also work on other operating systems.
 
My program should work on all the major operating systems since go is generally available.
A quick update: I now have my program working with the recent firmware.

A further update and a question:

My program is now pretty mature and flexible: I intend to make it freely available on, probably, Gitlab. I expect that it will work with a variety of dash cams.

But I have discovered a problem with the Nextbase videos. Before GPS lock is achieved, "GPS" records are still written with mainly zero entries and usually a time in 2080. So far I have not devised a robust way to remove these spurious entries. I am not sure that the time is always 2080: it might just be the default on my camera. I can't even detect the future reliably. How do I know when the mov file will be processed?

A complex approach might be to notice when time "runs backwards" and delete
the spurious points that way. But that is a pain.

So at the moment my program just writes the rubbish. gpsbabel can be used to clean up gpx tracks using a variety of criteria, so I am inclined to leave users to use that if it matters to them.

So my question is: is my default of just copying "what the camera says" into the gpx file reasonable in the circumstances?

A second question (to Nextbase): isn't this a bug in the firmware?
 
I have just decided to add an option to "clean" spurious points: here is the help:
Code:
$ mov2gpx -h
usage: mov2gpx [flags] [path ...]

  -O string
        Destination directory for gpx file(s) - default: MOV file directory
  -V    Display version
  -clean
        Avoid spurious (?) points with lat/long = 0/0
  -debug
        tracing to stderr
  -g int
        gpx version: 0 or 1 for 1.0 or 1.1 (default 1)
  -v    Report Firmware details,etc, if present
  -w    Overwrite an existing gpx file
  -x    Do not use NMEA GGA records
 
Can I ask what the end result is designed for ?

My Nextbase gives me the accurate, rolling on screen location albeit in not my choice of format.
 
Quite so. Linux users have a wealth of choice for viewing - my favourite is mpv. Of course that includes the gps location stamps etc.

But there are many uses for matching gpx tracks. Again linux has a wealth of relevant programs including viking, gpsbabel, gpsprune, gpsman, and josm. The last is an OpenStreetMap editor.

What seemed to be missing was a way to extract the gpx track from a dashcam
video file, until I found sggps through dashcamtalk. I found that worked only with an early version of Nextbase firmware. As I could not contact the author, I forked that into mov2gpx which I hope will handle many dashcams, although thus far I have only tested on my Nextbase.
 
Back
Top