Trackflow / _track.qo issue

Notehub.io
1

Hi, I’m having a problem with _track.qo generation (TrackFlow project) – it was working fine yesterday (able to create dozens of track points with the intended interval timing); today I’m only generating one track point at power-up and, sometimes, an additional point later. I did move the Notecard for the accelerometer to detect motion.

The firmware on my development board has not changed. I did add a new ProductUID to my project – but am not referencing it. The only other change was a Notecard “firmware install” to the “latest” version (dated July 7,2025) It may be worth reverting the firmware back to the previous version?

regards, Rich ..

2

Hi Rich

Thanks for the details. Generally speaking, a Notecard firmware update shouldn’t affect existing configuration, but since this behaviour change occurred right after the update, it’s worth trying to narrow things down to see if it’s related.

Here are a few checks to start with:

  1. Please verify that GPS tracking is still configured correctly by sending the following requests:

    {"req":"card.location.mode"}  
{"req":"card.location.track"}

  2. Can you try re-setting the motion configuration to be the same values as before? You can do this by issuing a {"req":"card.motion.mode"} request and then check if that changes the behaviour.

  3. It’s worth checking the active ProductUID and sync configuration to confirm they haven’t changed unexpectedly. You can do this using the {"req":"hub.get"} request.

If everything above looks normal and the issue still persists, then yes, reverting to the previous firmware would help confirm whether the change is firmware-related.

As a final check, if you’re using any voltage-based logic (e.g. modifying card.location.mode or hub.set to use voltage-related parameters), it might be worth reviewing that too in case it’s affecting tracking behaviour under certain conditions.

Let me know what you find.

Thanks
Youssif

3

Hi Youssif,
I’ll present the suggested "req"uests along with the results .. I used the “USB browser” to issue the commands & receive the response. I also include the commands sent by my micro-controller (connected to the Notecard via I2C)

{"req":"card.location.mode"} 
RESPONSE --- {"mode":"periodic"}

J *req = NoteNewRequest("card.location.mode");
if (req != NULL)
{
	//
	// how often tracks (_track.qo) are created -- update with time

	JAddStringToObject(req, "mode", "periodic");
	JAddIntToObject(req, "seconds", 120);
	success = NoteRequest(req);
}
Here, the mode is correct -- the "seconds" field (in the response) is missing when issuing the command via browser

{“req”:“card.location.track”}
RESPONSE
{
“file”: “_track.qo”,
“start”: true,
“minutes”: 10,
“heartbeat”: true,
“sync”: true
}

J *req = NoteNewRequest(“card.location.track”);
if (req != NULL)
{
JAddBoolToObject(req, “start”, true);
JAddBoolToObject(req, “heartbeat”, true);
JAddBoolToObject(req, “sync”, true);
JAddIntToObject(req, “hours”, -10);
JAddStringToObject(req, “file”, “_track.qo”);
J *rsp = NoteRequestResponse(req);
Here the ‘heartbeat’ is 10 minutes – the event list indicated this correctly
(when GPS was disabled). The “minus” sign for ‘minutes’ was documented yet seemed odd
– but it did work (prior to July firmware installation) – so I didn’t mess with it.

"req":"card.motion.mode"
RESPONSE
{
 "start": true,
 "seconds": 10
}
J *req = NoteNewRequest("card.motion.mode");
if (req != NULL)
{
	JAddBoolToObject(req, "start", true);
	JAddIntToObject(req, "sensitivity", 2);
	JAddIntToObject(req, "seconds", 10);
	success = NoteRequest(req);
}
Here again, the response has a "missing" field (sensitivity)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> {"req":"hub.get"}
RESPONSE
{
 "secure": true,
 "mode": "continuous",
 "host": "a.notefile.net",
 "product": "com.xxxxxxxxxxxxxxxxxxxxxxx",
 "device": "dev:xxxxxxxxxxxxxxxxxxx",
 "inbound": 240,
 "outbound": 1
}
Here, all the fields match my Notecard.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here's another tidbit .. keeping in mind I'm using an EXTERNAL GPS feed -- at times (again prior to firmware update) I've seen the GPS status show fields similar to the internal GPS.

Note the Lat/Lon in the GPGGA & GPRMC NMEA sentences (as provided by a GPS simulator) -- they don't match the Notecard values as returned by NoteGetLocation() [helper function] --- that was also working. It's as if the Lat/Lon fields are not being accepted by the note card -- even though I "giggled" the board to wake up the accelerometer.

Status Buf:GPS is off {gps-inactive}
Location Mode:periodic
$GPGGA,222533,4500.36,N,07323.038391106,W,2,08,1.1,200.000,M,-32.6,M,34,0000*45
$GPRMC,222534,A,4500.36,N,07323.036001246,W,6.083,90,170725,0,W*71
Lat:24.613057
Lon:-77.688662

Again, thanks for the help .. I have a duplicate system that has not been updated with the "July 7" firmware update -- and it is working properly.

regards, Rich ..
4

Hi Rich

Just checking if there’s any updates since your last post? Thanks for sharing all the configurations. Everything looks fine so far. Given that this tracker is using external GPS input, can you please confirm that the following request is being sent (this is assuming that the external GPS input is hooked to the Notecard’s AUX_TX/AUX_RX lines):

{"req":"card.aux.serial","mode":"gps"}

If this request is in place, it’s also worth checking that the external GPS source (whether simulated or physical) is properly connected and providing data. Also, if you haven’t already, I’d recommend temporarily downgrading the Notecard firmware to the previous working version. This will help rule out whether the behaviour is related to the firmware update.

Let me know what you find.

Thanks
Youssif

5

Hi Youssif,
We are sending the command “card.aux.serial”,“mode”:“gps” .. we have a “duplicate” system (microcontroller(same firmware on both) & notecarrier/notecard working fine with a GPS simulator as the “external GPS” device. We’re only using the AUX_RX line on the Notecard.

As far as I can tell, the only difference is the Notecard firmware version .. April vs July 2025.

It’s probably worth trying the downgrade – to at least eliminate that as the issue.

regards, Rich ..

1 Like