For the past month or so, I don’t seem to be able to get any more than 2 NTN notes to arrive in Notehub, even though 3 or 4 are sent. In my setup, I queue an NTN note every 4 hours and after 12 hours I sync 3 notes. Of these, only the first 2 arrive in Notehub. Here is an example 12 hour log which shows that 3 notes were successfully sent. notecard_2025-07-06T07_50_12.log (18.5 KB)
This is what I see in Notehub:
If I manually add 4 NTN notes and then sync, only the first two arrive. See this log: notecard_2025-07-06T23_03_00.log (6.9 KB)
Is there a filter to limit the number of notes at the server?
Hi @rberkelm. I’m sorry to hear about this problem. I just attempted to reproduce the issue using an NBGLN and the same firmware version you’re running, but I wasn’t successful; the 4 Notes showed up on Notehub. We just added some additional debug logging on the Notehub side to try to get to the bottom of this. Could you please run your experiment where you manually add 4 Notes again, and once again provide us with the trace log? Thanks very much for your patience!
Hi @hroche
I’ve manually added 3 Notes and had 2 Notes previously queued - total 5 Notes successfully sent according to the log, but still only the first 2 arrive in Notehub. notecard_2025-07-08T04_41_14.log (7.2 KB)
The rest must be caught and rejected somewhere in the server? I don’t think this issue is isolated to this particular Notecard + Starnote combo. I have another Notecard + Starnote set up and the same is happening to its data.
There is another issue as well which may or may not be related. The timestamp on the Notecard is currently around 7 minutes behind the actual time. The Notecard reports a timestamp of 1751952148 ( Tuesday, 8 July 2025 15:22:28 [GMT+10:00]) but the actual time is 15:29.
I reported a previous experience of this issue here: Card.time request returns incorrect time
The Notecard has remained powered for the past 5 weeks, only syncing via NTN, and other than the issue of only receiving 2 Notes, it has run without any problems.
The Notecard Time issue was supposed to be addressed in the next Dev release and LTS8. Since LTS8 is out and I am running the latest Dev release (Version: 9.1.1.17181), I assumed it was fixed, but it appears not to be.
With the additional debug logging we added on the Notehub side, we are starting to get a better picture of what’s going on, but we are still searching for the root cause. Unfortunately, we haven’t been able to reproduce the issue, still.
You mentioned that you have two setups that both exhibit this same problem. Are both Notecards using the same project?
Something that may be revealing is if you are able to reproduce the issue using NTN mode WITHOUT a paired Starnote. That is, run the experiment using NTN transport and just a Notecard (no Starnote) as we describe here. Under the hood, this will cause the Notecard to send the packets in NTN format but ultimately over UDP+cell instead of a satellite connection.
Finally, would you be ok with inviting Blues support to join your project? We are wondering if the issue is somehow dependent on the project, since we are unable to reproduce using our own projects. Perhaps if we link our setup to your project, we’ll be able to reproduce the issue.
Thanks again for your patience. We are keen to resolve this issue ASAP and apologize for the headache!
On the issue with card.time, the bug fix for that one is coming in the next developer release (and LTS patch), which we are aiming to release this week. A release with that fix has not been made public, yet.
Hi @hroche
My second setup is a different project, different firmware etc. Just going through the history… Both projects were sending 3 NTN Notes every 12 hours. Up until (and incl) June 10, all three Notes were received fine in Notehub. As of June 11, only 2 Notes were received with each sync. So, something changed on June 11. I don’t think it was on my side because I was travelling on June 9 and didn’t touch anything until I got back this week.
As requested, I removed the Starnote (without powering down) and sent 4 NTN notes. The Notecard did not sync over cellular. I let it go for ~90 min and the Notecard just kept reporting “sync: connect error: ntn: satellite module not responding”. I then power-cycled the Notecard and let it run for another ~40 min. Still no sync. I then did a ntn.reset, followed by a power cycle and added an extra Note. After that, it was able to sync via UDP. All 5 Notes arrived in Notehub. notecard_2025-07-09T02_18_11.log (256.2 KB)
I was curious to see if this process might have solved my issue, so I reconnected the Starnote, power cycled the Notecard, let it do a cellular sync. I then changed to ntn mode, queued 4 Notes and sync’d via NTN. Unfortunately, only the first 2 Notes arrived in Notehub, as before.
I’ve invited Blues to my project. Hope you can find some further clues there.
Thanks for the additional debug work. We really appreciate it, and I’m happy to report that I think we’ve fixed the issue. Of course, you should validate that we’ve actually fixed it on your end.
We were ultimately able to reproduce your problem and traced the problem back to a timeout issue with Routes. We believe the Route you’re using is particularly slow (more than 10 seconds) and was causing us to hit a timeout path specific to NTN that we hadn’t exercised before. There was a Notehub bug in that path that we’ve fixed.
Thanks again for your patience. We’re lucky to have customers like you to help us make our products better. Please let me know if the issue persists, but I am cautiously optimistic that it should be resolved.
Hey @hroche , that is great news! Thanks so much! Just so I understand things a little better, does this mean the process of routing is done before the data arrive in Notehub?
The route I’m using is a dodgy temporary one to overcome an issue with rate-limits in the Blues routing on NTN Notes, as detailed here. Is there still a fix on the way for this bug? It’s been over 5 months since I reported it.
Thanks again for your great work!
Hello @rberkelm, the issue you mentioned about the rate limiting not working has been improved. It is not live yet but it will be deployed during our next deployment. I’ll mention it here when it’s deployed
