Lon, lat not included in starnote note

Hi,

I’ve gotten starnote to work, but it doesn’t seem to send the special _lon _lat fields.. ? It does send payload + other fields I have. Would this happen if it doesn’t have a position?

{
  "event": "537cd023-e287-848d-ad6d-45846c593be1",
  "when": 1746016095,
  "file": "spec.qo",
  "body": {
    "max": 0.0022602081,
    "timestamp": 1577837130366
  },
  "payload": "//9XXNBVnDoGLqUyJx1sDsARHxJBE6EUmhTEEJ4LPgp4B9kHpwo1CJsFMQTwAvMDEwRIAtMB/wE6AgkCjgFaASsBOQFNAWgBTAFQAakBngFEAVgBxQAGAYwBhAGoAXQB6QCnAJgAgwCJAMwA7wDOAKEAeQBnAIkAmACOAGsAXQBqAGEARABOAFIAdAB7AHoAcACFAEcAOgAxAC8AUwBUAEcARgAyAA==",
  "transport": "ntn:skylo",
  "best_id": "STAR01",
  "device": "dev:860264054655247",
  "sn": "STAR01",
  "product": "product:no.met.gauteh:sfy",
  "app": "app:4c5e935c-7acb-4f20-bca0-cda95e9fd1d2",
  "received": 1746016211.941448,
  "req": "note.add",
  "status": "success",
  "fleets": [
    "fleet:22ad4e5e-43e3-4499-ad02-eaec0c2938c0"
  ]
}

Hi @gauteh,

By default, compact templates omit certain metadata fields to preserve bandwidth. You can restore lat, lon, and timestamps by following these instructions.

Just note that when you update a template, you also have to sync it again with Notehub over cell/wifi before using ntn mode again.

Thanks,
Rob

2 Likes

Yes. That’s what I did, but they are not included.

Two other things which are not consistent with docs:

  1. track.qo notes are synced over ntn
  2. Adding regular notes to the notecard doesn’t work when it is in ntn mode. Presumably this will start working when it next time gets a cell connection?

How long before it retries cellular after having fallen back to ntn?

Yes. That’s what I did, but they are not included.

Got it - and yes I think you were on the right track initially as if there is no location data available, it will be omitted from the response.

track.qo notes are synced over ntn

I believe this is by design as the _track.qo Notefiles should be synced the same way over ntn vs other transport options.

Adding regular notes to the notecard doesn’t work when it is in ntn mode. Presumably this will start working when it next time gets a cell connection?

Correct. It gets a little more complicated if you are using the "delete":true argument in your templates, which will clear queues automatically as documented here.

How long before it retries cellular after having fallen back to ntn?

I believe the default is 60 mins, but can be overridden with card.transport/seconds argument (not currently documented).

2 Likes

Sounds good, this suits my use case pretty well. I don’t need the _lon, _lat fields if _track.qo is still synced (they will most likely just be copies of the latest _track.qo anyway).

Why isn’t location information included in this _track.qo file synced over starnote:

{
  "event": "b8b070d2-f86f-89b7-a72b-626c41bc0eeb",
  "when": 1746441552,
  "file": "_track.qo",
  "body": {
    "status": "heartbeat",
    "temperature": 15.0625,
    "voltage": 4.5429688
  },
  "transport": "ntn:skylo",
  "best_id": "STAR01",
  "device": "dev:860264054655247",
  "sn": "STAR01",
  "product": "product:no.met.gauteh:sfy",
  "app": "app:4c5e935c-7acb-4f20-bca0-cda95e9fd1d2",
  "received": 1746442026.880456,
  "req": "note.add",
  "status": "success",
  "fleets": [
    "fleet:22ad4e5e-43e3-4499-ad02-eaec0c2938c0"
  ]
}

Hi @gauteh,

What are your card.location.mode settings?

I just tested these configs out on my Starnote and I do see GPS location data appear in both regular _track.qo Notes and in the heartbeats:

{"req":"card.location.mode","mode":"periodic","seconds":300}
{"req":"card.location.track","start":true,"sync":true,"heartbeat":true,"hours":-10}
{
  "event": "f1afd4f2-4a28-81fa-960c-e95149529bd3",
  "when": 1746453566,
  "file": "_track.qo",
  "body": {
    "jcount": 1,
    "journey": 1746453566,
    "status": "heartbeat",
    "temperature": 26.75,
    "time": 1746453527,
    "usb": true,
    "voltage": 3.9257812
  },
  "transport": "ntn:skylo",
  "best_id": "Sat Tester",
  "device": "dev:xxxxxxxxxxx",
  "sn": "Sat Tester",
  "product": "product:com.xxxxxxxxxx",
  "app": "app:a3d85b64-cded-465b-a0da-da01896af440",
  "received": 1746453620.524681,
  "req": "note.add",
  "best_location_type": "gps",
  "best_location_when": 1746453527,
  "best_lat": xxxxx,
  "best_lon": xxxx,
  "best_location": "xxxxx",
  "best_country": "US",
  "best_timezone": "America/Chicago",
  "where_olc": "86MG3HC8+FW8J",
  "where_when": 1746453527,
  "where_lat": xxxxx,
  "where_lon": xxxxxx,
  "where_location": "xxxxxx",
  "where_country": "US",
  "where_timezone": "America/Chicago",
  "fleets": [
    "fleet:0908ac06-b4be-4963-94be-8b6d2795bdcc"
  ]
}

I think I have two hours on both heartbeat and period. Why would there ever be a track qo without gps? Especially on starnote.

Are you using the GPS on the Starnote or on the Notecard (GPS on Starnote is the default)? Are you able to get a GPS fix separately (e.g. looking at the response from a card.location request)?

Rob

I have a starnote with onboard gps antenna. Have antenna on regular notecard as well, and have not done any additional configuration with regards to that.

I’d be curious to see if there is any difference if you switched to using the Notecard’s GPS by issuing an ntn.gps/on:true request:

I’ll try that. Wondering if this is related to my other gps issue. Maybe a consequence of unfavorable configuration options.

No gps yet in default mode (in track.qo), but the assigned location is all over the place:

@gauteh is the location you’re seeing here before or after you ran ntn.gps/on:true? Can you invite me to your Notehub project so I can see some of the event details (you should have my email address I believe).

Hi, I haven’t tested ntn.gps on true yet. I’ve invited you to the project. I also get some messages which should have a body, but they only have a payload. And the value of the max field is sometimes negative, which should be impossible..

I would try updating to the 9.1.1 firmware release, as that fixed a critical issue with the ntn.gps API among other issues.

Looking at some of the events, I’m primarily concerned about the timestamps. They are all over the place and the only one that is correct is the one that’s in the body. Out of curiosity can you send a card.time request to see what it returns?

FYI you’re also sending a lot of data with Starnote when you send those large payloads as well. The max size of a Note when sending over ntn mode is 256 bytes and I wonder if we are uncovering an issue here with sending a large payload. Can you also send me your template definitions you’re using?

Rob

The one in the body is using rtc on my host MCU, set from a card.time request. I noticed a small error in my body timestamp, but it should only be a few 100 ms off.

I’ll send more details and upgrade tomorrow. I’ve calculated the payload length from the return value of the template call. Then the bytes field in the json, or possibly from a note.add call (don’t remember where I found that field).

I’ve updated the firmware, and set ntn.gps on true. The latest track qo events are synced over cell, but there should be some new ones over ntn in a couple of hours.

It seems that I may miss compact notes some times as well in NTN mode, there is sometimes about one missing per sync. Could there be any issue with adding compact notes when NTN syncing is in progress?

I’ve changed my code to retry adding notes on failure forever now (used to have 2 tries then drop, in case there was some error that would cause a particular note to always fail end get things stuck).

Packages are marked with red dots, so time is correct, but there is missing packages now and then. There should be one approximately every 20 minutes. Are they re-tried if they somehow fail to be sent?

Notes will be retried if there is a known communications failure. However, we are looking into an issue where large payload arguments are disrupting NTN communications. Some of your Notes have relatively large payload args and if they eclipse the 256 byte max that Skylo allows they may be lost. This is the first thing I would look at (while we concurrently diagnose this issue in Notecard firmware).