Card.location mode and track issue

Hardware Notecard Cellular
1

I am using a Notecard NOTE-MBGLN on a NOTECARRIER-A, powered by a SCOOP board as an add-on to one of our devices. The SCOOP is powered by the device batteries, at 6V.

The device has 2 modes: Active and Inactive.

In Active mode, it configures the Notecard to get GPS location every 5 min and sync data to Notehub every 10 min. It also send data packets to the Notecard every 5 min.
In Inactive mode, it configures the Notecard to get GPS location every 1h and sync data to Notehub every 24h. No data packets are sent.

I understand that the location mode is “periodic” and if there is no movement detected, the location will not be updated.

Here it is the source code:

J *req = NoteNewRequest("hub.set");
JAddStringToObject(req, "product", productUid);
JAddStringToObject(req, "mode", "periodic");
JAddStringToObject(req, "sn", serialNumber);
JAddNumberToObject(req, "outbound", (state == NotecardState::Active) ? 10 : 1440);
JAddNumberToObject(req, "inbound", 1440);

if (!NoteRequestWithRetry(req, 5))
{
    ESP_LOGE(TAG, "Failed to configure Notecard");
    return ESP_FAIL;
}

J *locReq = NoteNewRequest("card.location.mode");
JAddStringToObject(locReq, "mode", "periodic");
JAddNumberToObject(locReq, "seconds", (state == NotecardState::Active) ? 300 : 3600);

if (!NoteRequestWithRetry(locReq, 5))
{
    ESP_LOGE(TAG, "Failed to configure Notecard location mode");
    return ESP_FAIL;
}

J *trackReq = NoteNewRequest("card.location.track");
JAddBoolToObject(trackReq, "start", true);

if (!NoteRequestWithRetry(trackReq, 5))
{
    ESP_LOGE(TAG, "Failed to configure Notecard location tracking");
    return ESP_FAIL;
}

The device entered Active mode on Friday 5pm until 7.06pm. It then entered Inactive mode until Tuesday at 7.41am, until 9am.

The location packets were not generated every 5 min, sometimes more, sometimes less. Also in Inactive mode, which happened during Saturday, Sunday and Monday, also I cannot understand why there was 2 location packets (_track.qo) on Saturday and on Monday, but not on Sunday.
Here it is the location packets:

image
image1465×606 79.4 KB

image
image1313×156 18.3 KB

image
image1464×706 91.1 KB

I would like to know the reason why this is happening like that and if it is a configuration issue.
Thanks!

2

Hey @paulolima,

Welcome to the Blues community! And thanks for the detailed post and screenshots. Your configuration makes sense to me. As for your questions:

The location packets were not generated every 5 min, sometimes more, sometimes less.

In periodic mode seconds isn’t a guaranteed interval. Notecard kicks off a GPS search at the configured interval when it detects motion, and each Note is timestamped when the fix is acquired—which can be anywhere from a few seconds to a few minutes after the search begins.

Notecard can’t use its onboard GPS and cellular modem at the same time, and when both are needed, data syncs take priority.

Which brings us to your data. On Friday your _track.qo Notes start off being captured at 5-minute intervals nearly exactly, and then there’s a long stretch after ~6:00 where they get irregular. There’s also a long stretch between 6:03PM–6:49PM where no new Notes are uploaded.

My guess is that your tracker had weak cellular coverage during that stretch. If it did, Notecard would be attempting to retry the cellular connection, which would delay / queue GPS searches, and thus break up the nice 5-minute intervals of the _track.qo Notes.

Also in Inactive mode, which happened during Saturday, Sunday and Monday, also I cannot understand why there was 2 location packets (_track.qo) on Saturday and on Monday, but not on Sunday.

Notecard generates _track.qo Notes when it detects motion, regardless of signal, and that’s where these Notes came from. All four Saturday/Monday events have "status":"no-sat" and "seconds":90. In each case, a small amount of motion (motion of 7, 4, 1 and 13) triggered a GPS search. The Notecard found no satellite signal (most likely the device was indoors), so it gave up after 90 seconds and recorded a no-sat Note.

On Sunday the device likely didn’t move, so the Notecard never searched and wrote no Notes.

Assuming that’s accurate your configuration is working as designed. If you’d like a Note created on a fixed schedule even when the device isn’t moving, you could "heartbeat":true and an hours to your card.location.track request. Heartbeat Notes report the last known location and don’t turn on the GPS. See Asset Tracking with GPS - IoT Connectivity at Blues .

Let me know if any of this is unclear and I can try to help and provide more detail.

As a side note, one thing you might want to try out is our new Notehub IQ integration, as I find LLMs are often quite good at interpreting data like this. For example you could compare your tracking Notes with session Notes (which have signal-strength data in them) to see if you could find a pattern between irregular _track.qo Notes and cell signal.

TJ

3

Thanks TJ for the explanation.

I do understand that if I increase the hub.set.outbound to 30 minutes, maybe the data sync would interfere less with GPS search. I will try that.

If I understand correctly, during the Inactive mode, where card.location.seconds is set to 1440, or 1h, the GPS search is triggered every 1h, and it tries to get a location only if there has been movement, otherwise it does nothing and wait for the following 1h trigger.

Question 1: Considering the card.location.seconds is 1440 (1h), if a GPS search is triggered at 9h00 and takes 3 min, when will the next GPS search be triggered? 10h00 or 10h03?

I don’t need it to be every 1h, so I’ll change to every 24h.

Question 2: What configuration do you suggest considering I want to have, in Inactive mode, only 1 data communication per day with the most up-to-date location, even if there is no movement detected?
I want to avoid the scenario where the once a day data sync happens just minutes before the once a day GPS search trigger, that may detect a different location, and so, have a 24h delay.

Thanks in advance for your advice.

4

Hey @paulolima,

Sorry it took me an extra day to get back with you.

Question 1: Considering the card.location.seconds is 1440 (1h), if a GPS search is triggered at 9h00 and takes 3 min, when will the next GPS search be triggered? 10h00 or 10h03?

10:00. Periodic GPS runs on a fixed schedule, so how long a search takes never pushes the next one back.

At each interval, Notecard checks whether it has detected motion since the last check. If it has, it starts a search. If it hasn’t, it skips the search and waits for the next interval.

Motion that happens partway through an interval doesn’t start a search right away. It’s picked up at the next interval.

Question 2: What configuration do you suggest considering I want to have, in Inactive mode, only 1 data communication per day with the most up-to-date location, even if there is no movement detected?

The best we have today is the heartbeat flag, which will create a daily Note with whatever the most recent location is.

{"req":"card.location.track","start":true,"heartbeat":true,"hours":24}

This Note will sync according to your outbound interval though, so unfortunately it doesn’t solve the concern you mention here.

I want to avoid the scenario where the once a day data sync happens just minutes before the once a day GPS search trigger, that may detect a different location, and so, have a 24h delay.

BUT!

We do have a pretty cool feature coming soon that I think is exactly what you’re looking for. It’s not final yet so I can’t make any guarantees, but its API should look like this.

{"req":"card.location.mode","mode":"ping","seconds":86400,"sync":true}

The idea here is you’d get a daily location ping that also triggers a sync.

This feature should make it into our next quarterly dev firmware release, but I can’t commit to specifics or dates though.

TJ

5

Hi TJ,

Thanks for the reply and I’m glad you’ll have a new configuration that can solve my concern!

In the meantime, I have been testing with new settings:

J *req = NoteNewRequest("hub.set");
JAddStringToObject(req, "product", productUid);
JAddStringToObject(req, "mode", "periodic");
JAddStringToObject(req, "sn", serialNumber);
JAddNumberToObject(req, "outbound", (state == NotecardState::Active) ? 30 : 10080);
JAddNumberToObject(req, "inbound", (state == NotecardState::Active) ? 1440 : 10080);

if (!NoteRequestWithRetry(req, 5))
{
    ESP_LOGE(TAG, "Failed to configure Notecard");
    return ESP_FAIL;
}

J *locReq = NoteNewRequest("card.location.mode");
JAddStringToObject(locReq, "mode", "periodic");
JAddNumberToObject(locReq, "seconds", (state == NotecardState::Active) ? 300 : 86400);

if (!NoteRequestWithRetry(locReq, 5))
{
    ESP_LOGE(TAG, "Failed to configure Notecard location mode");
    return ESP_FAIL;
}

J *trackReq = NoteNewRequest("card.location.track");
JAddBoolToObject(trackReq, "start", true);
JAddBoolToObject(trackReq, "heartbeat", true);
JAddNumberToObject(trackReq, "hours", 24);
JAddBoolToObject(trackReq, "sync", (state == NotecardState::Active) ? false : true);

if (!NoteRequestWithRetry(trackReq, 5))
{
    ESP_LOGE(TAG, "Failed to configure Notecard location tracking");
    return ESP_FAIL;
}

I started the test on Friday at 04:27pm in active mode, changed to inactive mode at Friday 7:14pm and changed back to Active mode on Monday at 7:45am.

image
image1447×685 90.7 KB

image
image1573×164 17.6 KB

From the message logs, we can see that:

  1. In the last Active mode, all worked as intended: _track.qo messages every 5 min (300s) or so.
  2. During Inactive mode it created a _track.qo file once a day, and at 4:27pm, the time all started on Friday. Even with no movement. This is also the intended behavior.
  3. In the first Active mode, not all went well. Data packets (not seen here) were created every 5 min and synced every 30 min (1440s) but only one _track.qo file at the beginning. It means it was not possible to get any more GPS fixes during that Active mode. To be noted that the device traveled in the exact same conditions as in the last Active mode.

Still about point 3, on Friday before 4:27pm, I was doing some tests indoors, so no GPS signal, and the same settings, I noticed that the green LED was always blinking with a 3s period or so, for a long time. I connected the USB cable to the NOTECARRIER-A and got this:

{"req":"card.location"}
{ "status": "GPS search (764 sec, 25/26 dB SNR, 0/1 sats, HDOP 0.00)
{gps-active} {gps-signal} {gps-sats}",
"mode": "periodic",
"lat": xxx,
"lon": xxx,
"dop": 0.9699999999999999,
"time": 1791272793 }

I guess 764 sec for a GPS search is too much.
Since there was no GPS signal indoors, shouldn’t the Notecard stop it and try later?

Thanks for you advice.

6

Hey @paulolima,

I’ll start with this.

I guess 764 sec for a GPS search is too much.
Since there was no GPS signal indoors, shouldn’t the Notecard stop it and try later?

Notecard only ends a search early (after 90 seconds) when it gets no GPS signal at all.

In this test your status shows 25/26 dB SNR, 0/1 sats, so the GPS was picking up a faint signal, probably through a window. When there’s some signal, Notecard keeps searching until the full timeout, which is about 1,000 seconds by default. The timeout is that long because a GPS that has been off for a while can need a long time to download satellite almanac data before it can get a fix.

If that’s too long for your use case, you can shorten it with the _gps_expiry_secs reserved environment variable.

_gps_expiry_secs = 300

That being said, I don’t think that explains the lack of data you got on that Friday trip. I don’t have a good theory for why that happened off the top of my head. To help debug this further could you post:

  1. The output of {"req":"card.version"} from your Notecard.

  2. The full contents of that 4:27pm no-sat _track.qo event.

  3. Any _health.qo and _session.qo events from Friday between 4:27pm and 7:14pm.

Feel free to obfuscate / remove anything sensitive like your location, or you could also DM me the information.

TJ

7

Hi TJ,

Here it is the information you’ve requested:

{"req":"card.version"}

{"req":"card.version"}
{ "version": "notecard-11.2.1.17592", "device": "dev:868531063311851", "name": "Blues Wireless Notecard", "sku": "NOTE-MBGLN", "ordering_code": "EB0WT1C0AXBP", "board": "5.13", "cell": true, "gps": true, "body": {  "org": "Blues Wireless",  "product": "Notecard",  "target": "u5",  "version": "notecard-u5-11.2.1",  "ver_major": 11,  "ver_minor": 2,  "ver_patch": 1,  "ver_build": 17592,  "built": "Mar 8 2026 18:54:58" }}

_track.qo:

{
  "event": "9fba40f7-e757-8aa6-a8e8-fb286cf68bfd",
  "when": 1791559639,
  "file": "_track.qo",
  "body": {
    "jcount": 1,
    "journey": 1791559523,
    "motion": 3,
    "seconds": 90,
    "status": "no-sat",
    "temperature": 25.1875,
    "time": 1791272793,
    "voltage": 3.8203125
  },
  "session": "df1f15d5-ea88-44d5-a418-cd04a92abdc4",
  "transport": "cell:lte:fdd",
  "best_id": "1111111111",
  "device": "dev:868531063311851",
  "sn": "1111111111",
  "product": "product:xxx.xxx:xxx.xxx",
  "app": "app:80878635-356e-4006-a0dd-xxx",
  "received": 1791560815.733782,
  "req": "note.add",
  "wire_length": 92,
  "batch_received": 1791560815.733593,
  "batch_number": 1,
  "batch_total": 1,
  "best_location_type": "gps",
  "best_location_when": 1791272793,
  "best_lat": "xxx",
  "best_lon": "xxx",
  "best_location": "xxx",
  "best_country": "xxx",
  "best_timezone": "xxx",
  "where_olc": "xxx",
  "where_when": 1791272793,
  "where_lat": "xxx",
  "where_lon": "xxx",
  "where_location": "xxx",
  "where_country": "xxx",
  "where_timezone": "xxx",
  "tower_when": 1791560814,
  "tower_lat": "xxx",
  "tower_lon": "xxx",
  "tower_country": "xxx",
  "tower_location": "xxx",
  "tower_timezone": "xxx",
  "tower_id": "xxx",
  "fleets": [
    "fleet:d927ac13-5704-4488-a210-xxx"
  ]
}

_session.qo:

{
  "event": "95e12a8f-3c60-4255-90b4-4abbd88814d4",
  "platform": true,
  "when": 1791564616,
  "file": "_session.qo",
  "body": {
    "closed": true,
    "why": "notecard ended the session"
  },
  "session": "a79bf266-6e59-436b-aaef-f4e6e211c0ef",
  "transport": "hub",
  "best_id": "1111111111",
  "device": "dev:868531063311851",
  "sn": "1111111111",
  "product": "product:xxx.xxx:xxx.xxx",
  "app": "app:80878635-356e-4006-a0dd-xxx",
  "received": 1791564616.370091,
  "req": "session.end",
  "best_location_type": "gps",
  "best_location_when": 1791272793,
  "best_lat": "xxx",
  "best_lon": "xxx",
  "best_location": "xxx",
  "best_country": "xxx",
  "best_timezone": "xxx",
  "where_olc": "xxx",
  "where_when": 1791272793,
  "where_lat": "xxx",
  "where_lon": "xxx",
  "where_location": "xxx",
  "where_country": "xxx",
  "where_timezone": "xxx",
  "tower_when": 1791564614,
  "tower_lat": "xxx",
  "tower_lon": "xxx",
  "tower_country": "xxx",
  "tower_location": "xxx",
  "tower_timezone": "xxx",
  "tower_id": "xxx",
  "fleets": [
    "fleet:d927ac13-5704-4488-a210-xxx"
  ],
  "hub_last_work_done": 1791564615,
  "hub_duration_secs": 2,
  "hub_events_routed": 7,
  "hub_rcvd_bytes": 67,
  "hub_sent_bytes": 872,
  "hub_tcp_sessions": 1,
  "hub_sent_notes": 7
}

_health.qo: the last file is before Friday 4:27pm and it was never sent another again until now (the device was left ON)

{
  "event": "30a74ca7-5646-8299-9791-cb88d25486b8",
  "platform": true,
  "when": 1791553664,
  "file": "_health.qo",
  "body": {
    "method": "boot",
    "text": "boot (brown-out & hard reset [17592])",
    "voltage": 3.7480469,
    "voltage_mode": "normal"
  },
  "session": "621c2a2a-b0a1-4ff2-81e5-d2d99a0d4fad",
  "transport": "cell:lte:fdd",
  "best_id": "1111111111",
  "device": "dev:868531063311851",
  "sn": "1111111111",
  "product": "product:xxx.xxx:xxx.xxx",
  "app": "app:80878635-356e-4006-a0dd-xxx",
  "received": 1791553677.610071,
  "req": "note.add",
  "wire_length": 79,
  "batch_received": 1791553677.610015,
  "batch_number": 1,
  "batch_total": 1,
  "best_location_type": "gps",
  "best_location_when": 1791272793,
  "best_lat": "xxx",
  "best_lon": "xxx",
  "best_location": "xxx",
  "best_country": "xxx",
  "best_timezone": "xxx",
  "where_olc": "xxx",
  "where_when": 1791272793,
  "where_lat": "xxx",
  "where_lon": "xxx",
  "where_location": "xxx",
  "where_country": "xxx",
  "where_timezone": "xxx",
  "tower_when": 1791553675,
  "tower_lat": "xxx",
  "tower_lon": "xxx",
  "tower_country": "xxx",
  "tower_location": "xxx",
  "tower_timezone": "xxx",
  "tower_id": "xxx",
  "fleets": [
    "fleet:d927ac13-5704-4488-a210-xxx"
  ]
}
8

Hmmm… nothing is jumping out at me unfortunately. There are a few fixes we’ve made in more recent Notecard firmware releases, but I don’t think any of them explain the behavior you’re seeing.

I’m going to run this by some people internally and get back with you.

TJ