_track.qo: which one is position time?


I’m looking at _track.qo from card.location.track. I use best_lat and best_lon from the event (assuming it is the GPS if available, and tower if not), but what is the position time? There is no best_location_when field.

– gaute

Hi @gauteh,

I just tested out a basic tracker to see which response arguments are routed, and I do see best_location_when (it’s underneath best_location_type). Do you not see this in your events?

  "event": "588f4749-d61b-4f51-9a6c-86c0191cbdef",
  "session": "e28bf74c-e43b-4630-a134-ca5538fa05b6",
  "best_id": "TEST",
  "device": "dev:864475041085845",
  "sn": "TEST",
  "product": "product:com.blues.rlauer:global_tracker",
  "received": 1663599901.584736,
  "req": "note.add",
  "when": 1663599571,
  "file": "_track_test.qo",
  "updates": 1,
  "body": {
    "motion": 2,
    "seconds": 91,
    "status": "no-sat",
    "temperature": 30.125,
    "usb": true,
    "voltage": 5.1445312
  "best_location_type": "tower",
  "best_location_when": 1663599899,
  "best_lat": 43.073787499999995,
  "best_lon": -89.44367187499999,
  "best_location": "Shorewood Hills WI",
  "best_country": "US",
  "best_timezone": "America/Chicago",
  "tower_when": 1663599899,
  "tower_lat": 43.073787499999995,
  "tower_lon": -89.44367187499999,
  "tower_country": "US",
  "tower_location": "Shorewood Hills WI",
  "tower_timezone": "America/Chicago",
  "tower_id": "310,410,17169,77315601",
  "project": {
    "id": "app:56667ef8-0573-4e6f-9df4-28aecd91902e",
    "name": "Global Tracker",
    "contacts": {}
    "event": "22de9420-a001-4a38-a6be-fdc1efc7cc85",
    "session": "1139beb3-3a9a-4717-8032-6bb4c7ab0c74",
    "best_id": "DRIFTER20",
    "device": "dev:864475044217650",
    "sn": "DRIFTER20",
    "product": "product:no.met.gauteh:sfy",
    "received": 1663600779.613395,
    "req": "note.add",
    "when": 1663600748,
    "file": "_track.qo",
    "updates": 1,
    "body": {
        "hdop": 1,
        "status": "heartbeat",
        "temperature": 17.4375,
        "time": 1663597121,
        "voltage": 4.796875
    "best_location_type": "gps",
    "best_lat": 61.351602500000006,
    "best_lon": 5.39933203125,
    "best_location": "Dale",
    "best_country": "NO",
    "best_timezone": "Europe/Oslo",
    "where_olc": "9FH7992X+JPW4",
    "where_lat": 61.351602500000006,
    "where_lon": 5.39933203125,
    "where_location": "Dale",
    "where_country": "NO",
    "where_timezone": "Europe/Oslo",
    "tower_when": 1663600777,
    "tower_lat": 61.338139,
    "tower_lon": 5.40578,
    "tower_country": "NO",
    "tower_location": "Vestland",
    "tower_timezone": "Europe/Oslo",
    "tower_id": "242,1,12711,14321"

It had firmware 1.5, upgrading to 3.4 now.

It’s now sending the field. But it’s spamming with tons of track.qo messages, and it thinks it’s on USB…

Which seems to have burned a significant amount of credits.

Hi, we are getting the same error on another notecard with version 3.4 where it starts sending large amounts of track.qo at high frequencies. These are notecards that operate without any MCU. They have been reset before being re-configured as described here: sfy/sfy-drifter at main · gauteh/sfy · GitHub

Regards, Gaute

Hi @gauteh,

Would you be able to add me (as a viewer) to your Notehub project that is showing these additional track notes? (You should have the proper email address already, but if not, just let me know). Also can I confirm that the only three requests you send are the ones listed in that github repo?


Hi Rob,

thanks, I’ve added you. If you look at 2022-09-24 22:49:05 and earlier for device: dev:864475044203262 you should see an episode. As you can see something happend with the accelerometer at the end before the device went MIA, but those errors might have been due to voltage drops in the end.

Correct, the device was reset and then those were the requests issued.

The same happened with dev:864475044217650, but those events have now been deleted from notehub (I have them on our systems though).

Regards, Gaute

Thanks! Looking into this in detail and will reply ASAP.

BTW, are you only seeing this behavior on a single device after upgrading to 3.4.1?


Thank you. We saw it on dev:864475044217650 as well, but have not seen it on other devices.

Hi @gauteh,

I ran these issues past the team and we have some ideas to explore.

A _track.qo note with "status":"usb" occurs when the tracker senses a change on the USB pin state on the Notecard. The current sensed state of the USB is shown in the "usb" field. It appears that the Notecard is sensing a rapidly changing state of the USB pin. There could be 3 possible causes:

  1. Bad Notecard (unlikely if you’re seeing it on two different devices)
  2. Bad Notecarrier (also unlikely if on two devices)
  3. A bad connection / not quite fully seated M.2 connector (my guess)

VUSB is pin 13 - we have noticed that the USB connection, being toward one edge of the M.2 connector, is susceptible to being unreliable if the Notecard is not fully inserted into the M.2 (e.g. if it is at a slight angle).

The next step is to determine whether, at the time of the rapid-USB-switching did the Notecard / Notecarrier actually have voltage on M.2 pin 13 or not (i.e. was there an intermittent 5v, or was there 0v on that pin ?)

Are you using a custom Notecarrier or one of ours, and do you expect the Notecard to see voltage on the VUSB M.2 pin 13 when the tracker is active (assuming this is a “no”).

Bottom line is if the Notecard isn’t properly seated and it’s sensing a lot of vibration (or corrosion even), this can occur.

I also noticed in your project you have a significant number of accelerometer IO errors. These should be resolved in the upcoming 3.5.1 developer release of the Notecard firmware. Let me know if you want to test an RC of that release.


1 Like

Hi Rob,

sorry for the delayed response. Things suddenly got really busy. We’ve now lost one of the devices, but still have one that experienced this issue - we’ll inspect it for issue 3 before unmounting the Notecard. Corrosion is possible. One of the devices experienced this issue while just sitting still, but maybe it was moved first.

We powered these devices with three D-cells industrial alkaline batteries (Duracell Pro Intense) which we’ve had good experience with previously. However, we skipped the super-caps, and I suspect that in some cases in poor connection and simultaneous GPS usage, the voltage drops.

We have been testing out notecard- with great success, especially increased I2C transfer rates is a game-changer. If you have a newer version I’d be happy to start using it.

We’ll investigate further and report back.

Best regards, Gaute

The lost device was found, filled with mud. So that explains the frantic messaging. We still have one other that had the same issue, but I’ll consider this resolved for now.

(The electronic have been cleaned).