NTN transmission problem

The device does not transmit the packets stored in the queue. The files are successfully uploaded to the device and sent without complications via the Wi‑Fi network, but the same cannot be done via the NTN network.

In this case, the files are uploaded correctly. Similarly, after a “hub.sync”, the device initiates the login and data transmission process. After a few minutes, the device successfully connects, as indicated by the command “ntn.status” and confirmed by Notehub with a login message. However, problems arise from this point onwards: the device quickly disconnects and remains idle, without sending any messages or attempting to reconnect. Even with this disconnection, the device appears to exchange minimal information with the NTN network, as it continues to detect it for hours after logging in.

Simple sample messages, including our own messages, have been tested with the same result in both cases. I tried using the acquired GPS position along with a fixed position with the expected location (to ensure the problem does not come from the position fix). The queue has been restarted, and messages with the same format have been loaded to avoid any reading problems (when working with Wi-Fi, there seems to be no problem sending messages with different formats), the device has been reset to rule out the possibility that a process had frozen, blocking the channel, and as a last resort, the user’s configuration has been completely deleted, reconnecting to the project. All attempts have been unsuccessful.

Along the same lines, tests have been conducted to rule out a power supply problem with the device, as the setup may be unable to power it during transmission peaks in consumption. The initial tests consist of:

  • Test 1: PC connected via USB (low voltage around 4 V)

  • Test 2: PC connected via USB + LiPO battery (apparently stable voltage 4.4 V)

  • Test 3: 15 W and 27 W AC adapter

  • Test 4: Raspi 5 via USB + LiPO battery

The order of the tests corresponds to the chronological order in which they were performed. From test 2 to test 4, they transmitted packets without issues, sending up to 20 in less than 10 minutes.

It should be noted that, until a week ago, the device was able to load and send new packets without any problems. It was not until I emptied the queue by command that this problem appeared.

Hi @alex.sells and welcome to the Blues community!

I have a handful of questions for you and then I’m sure we can get this operating:

  1. You don’t mention Starnote at all, are you testing NTN mode with a Notecard WiFi only (without a paired Starnote)?
  2. If you’re using a Starnote, has this Starnote device been used/paired with other Notecards? FYI they do have to be unpaired when switching between Notecards.
  3. When you created your Note Templates, did you A) use the proper template format for NTN transmission and B) sync over cell/wifi before using NTN mode?

It would also help if you could capture a trace log of what happens when trying to sync a pending Note over NTN too.

Thanks,
Rob

Hi Rob, thanks for answering.

Q1: Yes, I am using Starnote 1.4, with the Quectel YFCA011 connected to the SAT; the same applies to the GPS antenna. I also have the notecard wifi 2.1

Q2: All the tests have been done using the same Starnoe and Notecard since day one. However, I ran the ntn.reset command while trying to solve the problem, but nothing changed. I will try it again since I’m not sure if I ran the sync with the wifi afterwards. Worth mentioning that I tried the ntn.reset once I encountered the problem, not before.

Q3: At first, I used the template provided as an example, but then I tried sending a self message:

First type of messages:

{“req”:“note.template”,“file”:“data.qo”,“format”:“compact”,“port”:55,“body”:{“_time”:14,“temp”:14.1,“humidity”:14.1}}

Self-made messages:

{“req”:“note.add”,“file”:“sat.qo”, “body”:{“data”:“2CF7F1C07230011B7094656400127E6510003FEC02”}}

Is the format correct? I have not had any problems sending them via Wi-Fi.

Either way, after some attempts, I thought the format might be the problem, so I cleared the queue and tried uploading either the first message or the second, avoiding mixing them to prevent any format incompatibility.

As for the track log i will try to get it ASAP but i tried to get them manually, form yesterday test:

>>> {“req”: “hub.sync.status”}

{

"requested": 3,

"sync": true

}

>>> {“req”: “ntn.status”}

{

"status": "initializing modem {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "initializing modem {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (22/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (25/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "status has not yet been reported {no-status}"

}

>>> {“req”: “ntn.status”}

{

“status”: “{ntn-disconnecting}{ntn-power}{ntn-gps}”

}

>>> {“req”: “ntn.status”}

{

"status": "{ntn-disconnecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "{ntn-idle}"

}

>>> {“req”: “hub.sync.status”}

{

"completed": 25,

"sync": true,

"time": 1771349517

}

>>> {“req”: “hub.sync.status”}

{

"completed": 168,

"sync": true,

"time": 1771349517

}

>>> {“req”: “ntn.status”}

{

"status": "{ntn-idle}"

}

>>> {“req”: “hub.sync”, “allow”: true}

{}

>>> {“req”: “ntn.status”}

{

“status”: “powering up {ntn-connecting}”

}

>>> {“req”: “ntn.status”}

{

"status": "powering up {ntn-connecting}{ntn-gps}"

}

>>> {“req”: “card.voltage”}

{

"mode": "usb",

"usb": true,

"value": 4.403333228349687

}

>>> {“req”: “ntn.status”}

{

"status": "initializing modem {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “card.voltage”}

{

"mode": "usb",

"usb": true,

"value": 4.403333228349687

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (1/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “card.voltage”}

{

"mode": "usb",

"usb": true,

"value": 4.403333228349687

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (6/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “card.voltage”}

{

"mode": "usb",

"usb": true,

"value": 4.403333228349687

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (10/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (12/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (14/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “card.voltage”}

{

"mode": "usb",

"usb": true,

"value": 4.396666561841966

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (17/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (18/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “card.voltage”}

{

"mode": "usb",

"usb": true,

"value": 4.396666561841966

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (20/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (20/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (22/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (22/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “ntn.status”}

{

"status": "waiting for satellite network (22/120 secs) {ntn-connecting}{ntn-power}{ntn-gps}"

}

>>> {“req”: “card.voltage”}

{

"mode": "usb",

"usb": true,

"value": 4.396666561841966

}

>>> {“req”: “ntn.status”}

{

"status": "status has not yet been reported {no-status}"

}

>>> {“req”: “ntn.status”}

{

"status": "status has not yet been reported {no-status}"

}

>>> {“req”: “ntn.status”}

{

"status": "{ntn-disconnecting}{ntn-power}{ntn-gps}"

The epoxy time seen in the logs is the following:

GMT: Tuesday, 17 February 2026 17:31:57

My time zone: Tuesday, 17 February 2026 18:31:57GMT+01:00

Hi @alex.sells,

Couple things:

  1. Which version of Notecard firmware are you running? I’d suggest updating to the latest if possible, as we’ve made some Starnote improvements recently.
  2. You mentioned your “self-made messages” that refer to the sat.qo Notefile. Did you create (and sync) a template for that sat.qo Notefile though? If not, NTN mode will just ignore those Notes when syncing.

For reference, this is my cheat sheet for quickly getting started with an attached Starnote device (including responses from the Notecard):

> {"req":"card.transport","method":"-"}
{"method":"wifi"}
> {"req":"note.template","file":"sat.qo","format":"compact","port":70,"body":{"temp":14.1,"humidity":14.1}}
{"bytes":9,"format":"compact"}
> {"req":"hub.set","product":"xxx","mode":"minimum"}
{}
> {"req":"hub.sync"}
{}
> {"req":"card.transport","method":"ntn"}
{"method":"ntn"}
> {"req":"note.add","file":"sat.qo","body":{"temp":12.3,"humidity":45.6}}
{"template":true,"total":2}
> {"req":"hub.sync","out":true}
{}
1 Like