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.
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?
Hey @FEW, thanks for posting. We do know about that project!
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.
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.
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.
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.
And I would get valid location points every 5 seconds and not one(!) every ten minutes.
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"}
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.
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.
