Built-in GPS tracking weirdness

Hardware
1

For fun and giggles I did the same thing the guy did who tracked his reindeer.

I am sure you know about this little project.
The only differences were that I set the sensitivity of the accelerometer somewhat higher, and did the sync every ten minutes compared to his 15.
I made sure I had superb GPS reception in my car and then I took it for a ride.
Instead of Azure etc… I used some different GPS tracking software and a little PHP script to decipher JSON that I use elsewhere.

NotecardGPStracking
NotecardGPStracking658×807 118 KB

I get a very weird picture, please note all the markers on top of each other. That’s every time the sync happened, the GPS positions in between were lost. Am I missing something?

1 Like
2

Hey @FEW, thanks for posting. We do know about that project! :smiley:

Are you certain that you are routing out the GPS coordinates and not the tower location information? In my routes I was using where_lat and where_lon on the _track.qo file, as opposed to tower_lat and tower_lon.

For the markers, it looks to me as though you are adding new markers to the map each time, as opposed to updating the coordinates to an existing marker. For my project, I have an animation function that gets the marker for each reindeer from a state object, and then calls setLngLat to update the Mapbox marker.

Hope that helps!

3

Thanks for your quick reply.
Yes I am sure I evaluate the correct fields.

some php code:

....
$request_body = file_get_contents('php://input');
$data = json_decode($request_body, true);

$unixtime =     $data['when'];
$lat =          $data['where_lat'];
$lon =          $data['where_lon'];
$vel =          $data['body']['velocity'];
$bearing =      $data['body']['bearing'];
....

and then standard code that I also use in different applications (eg to forward JSON locations from a LORA network to my traccar server):

...
curl_setopt($ch, CURLOPT_URL, "http://127.0.0.1:5055/?id=$id&lat=$lat&lon=$lon&                           
timestamp=$unixtime&speed=$vel&bearing=$bearing");
...

So I receive the un-altered JSON message generated on the note(card/hub) side in my php script. JSON decode it, convert it into a PHP array, and pick the pieces that I am interested in.

Please note that the overlaying arrows in the posted picture change direction, so the $data[‘body’][‘bearing’] value changes, just not the where_lon and where_lat values. Per sync that is.

What I find interesting though is that velocity and bearing are contained within the body of the JSON message, while where_lat and where_lon are a level higher, (together with tower information).

I hope my ignorance is being excused, but I was kinda expecting latitude and longitude to be part of the body of the ‘file’ - together with bearing and velocity - and not part of the transmission information - a level higher.

I cannot find any documentation about the data format either. Maye somebody can point me to it, please.

4

Hi @FEW . You can view the JSON of a Note on Notehub.

  1. Double-click on an event in the list of events on Notehub.

image
image1134×566 39.7 KB

  1. Click the JSON tab on the top
    image

Why is where_xxx at a higher level in the JSON structure
All Events are time stamped and location stamped. That is why it appears at the top level and not in the body.

The body is meant to be the “user defined” data, while the structure outside of that is defined by Notecard. For certain features like card.location.track the body field is pre-defined.

In the general case, if you use note.add to create a custom body that data is also time and location stamped.

Hope that helps!

1 Like
5

So this basically verifies the problem that I am seeing.

NotecardJSON
NotecardJSON970×1069 28.3 KB

Block A - body - aka User Data:
Data is being updated per tracking event, in my case every couple of seconds (does not mean it is being synchronized that fast). This means I get updates on bearing, some sort of distance (miles? knots? meters?), jcount (whatever that is), and velocity (knots per second?) BUT NOT: LATITUDE and LONGITUDE at an update period of around 5 seconds (rate of 0.2 Hertz) in my application.

Block B - aka Cell Data:
This is where at the moment I get my lat and lon data from, as there is nothing indicating location in any way in block A.
The problem is, latitude and longitude will only be updated per sync, and stay the same for 15 minutes worth of data points (from section A). That’s a lot of data that is garbage.

That leads to those many overlaying location points on the map that I was reporting initially, see picture above.

Is there a way to add gps_lat and gps_lon data points to the body section?
This way bearing and velocity would not feel so alone and would be usable. :wink:
And I would get valid location points every 5 seconds and not one(!) every ten minutes.

6

That is unexpected behavior. The _track.qo file is meant specifically for tracking location, and the where_lat and where_lon should update when there is new GPS location data available, not on a sync.

The tower_lat and tower_lon of course only update on sync.

Can you share the output of entering the following Notecard requests:
{"req":"card.location.mode"}
{"req":"card.location.track"}

Thanks very much!

7

Sorry for the delay, I cleaned up my lab at home, and could not find anything any more…

Here’s the requests:

{“req”:“card.location.mode”}
{
“seconds”: 5,
“mode”: “periodic”
}

{“req”:“card.location.track”}
{
“start”: true,
“minutes”: 60,
“heartbeat”: true
}

And yes, of course, I DO NOT USE tower_lat and tower_lon.

8

BTW:

  1. Why is the resolution of where_lon down to 14 digits? That is nanometers?! Latitude seems to be reasonable.
  2. What is jcount?
  3. What is journey?
  4. What is motion? The reported sensitivity level? Or is it the de-bounce excess counter of the accelerometer?
  5. Distance is in meters?
  6. Velocity in knots or meters?
  7. Why is USB true if I hook the thing up to a battery pack with confirmed floating D+D- lines?
  8. I assume temperature is in deg C?
  9. Any chance we will get elevation?
9

I got it to work with the following workaround:

“jcount”: 1
“where_olc”: “87G75376+QGQ7”,
“where_lat”: 40.1644575,
“where_lon”: -74.93864453124999,

“jcount”: 2,
“where_olc”: “87G75376+MC5V”,
“where_lat”: 40.1644575,
“where_lon”: -74.93864453124999,

“jcount”: 3,
“where_olc”: “87G75376+9664”,
“where_lat”: 40.1644575,
“where_lon”: -74.93864453124999,

“jcount”: 4,
“where_olc”: “87G75375+3XGW”,
“where_lat”: 40.1644575,
“where_lon”: -74.93864453124999,

and so on…

We notice that where_lat and where_lon will not change, the OLC field does change though. My guess is that on the notehub-side somebody did not do the pointer-arithmetic correctly and constantly points to the first field (again, just a guess, I have done it before).
GitHub - Bogdaan/open-location-code: Open location code for php has php code to convert OLC (open location code) to longitude and latitude and it works now.

YAY!

I guess you will want to fix the pointer problem - and if it is only for security reasons.

There are still a couple of open questions about units and resolution.

Thank you for your time.

10

Hi @FEW! Thanks for your report out. This does appear to be a bug. I will share this with our development teams.

I will follow up on units and resolution a bit later.

11

Unit Info: What are the units of measurement in _track.qo

GPS Accuracy: What is the Accuracy of GPS Measurement

Elevation:
Elevation data is not available on Notecard via GPS.

An enhancement request has been logged with development team.

USB: true - still investigating

12

Has any progress been made on making the elevation data available?

13

Hi @tjw_scion,

If you’re interested in deriving elevation from GPS coordinates, you’d have to use a third party service as that isn’t available from Notecard/Notehub. Elevation can alternatively be ascertained from barometric pressure of course, but that type of sensor does not exist on the Notecard.

Hope that helps!

Rob