Hi everyone,
I’m Juan, and I’m integrating the SenseCAP T1000-A into our own IoT platform, behind a self-hosted ChirpStack v4 (EU868), to track people. To make the integration solid I wanted every behaviour checked systematically against the User Guide v1.3, so I ran the tests with AI agents (Claude Opus 5.5) doing the repetitive part: queueing each downlink, watching every uplink and decoding it, and timing everything from the ChirpStack events. I pressed the button and looked at the LED and the buzzer when they asked me to. The conclusions below are me, but the measurements behind them are much more thorough than I could have done by hand.
Everything was measured on one tracker, hardware 1.6, firmware 2.8.0 (a few tests also on 2.5.0). Downlinks went on FPort 5, unconfirmed, and I take the moment they were actually sent from the txack event, not from the queue. If I have misread something, I’d be glad to be corrected.
1. The GNSS data cache (§2.4.3), the one that matters most. This is the point that most stops me from using the tracker properly. A person tracker has to report where someone has been, coverage or not, and what it measures out of coverage either never arrives or arrives hours later and duplicated. Everything else on this list I can work around; this one I can’t.
With the cache enabled in the SenseCraft app, I drove out of coverage while the tracker sent eleven uplinks. Coverage came back, and for an hour every uplink was confirmed in Event mode, with nothing from the cache. The cached fixes started arriving about an hour later, after I switched to Periodic mode and the tracker re-joined a few times (I had connected over Bluetooth). Then they came in order, with their original timestamps, one every ~3.6 minutes. Two frames that had already been delivered live were sent again. On another day, 2.5 hours without coverage left nothing in the cache at all: that data was simply lost.
This has come up here before. In How SenseCAP T1000 works when LoRa Gateway is unavailable? the answer was that cached data is sent automatically on return to coverage, which is not what I see on 2.8. In SenseCAP T1000a no longer connects to TTN, @MattijsBrunink, also on 2.8, says the cache doesn’t work for him at all even with it enabled, and sees old readings and SOS events uploaded again days later; the reply pointed to the cloud platform. I don’t use the Seeed cloud (only the SenseCraft app over Bluetooth, to configure the tracker): I see the same duplicates arriving over LoRaWAN, with new frame counters, at my own ChirpStack. So I think it comes from the tracker.
The rest, less critical but also different from the guide:
2. 0x88 doesn’t answer in Periodic mode. The guide says it returns 0x01 or 0x02 (§6.3.9). In Periodic mode, three 0x88 delivered on the same day got no status packet at all, not even after an hour and several more uplinks. In Event mode it does answer with 0x01, but not always the first time: once I had to send it twice. In Periodic mode the only way I found to read the status remotely is a reboot (0x89).
3. Continuous SOS reports every 2 minutes, not every minute. The SOS frames I received were 2 minutes apart. After stopping it with 8D00, the stored SOS frames kept arriving one per uplink, so the last one came about 12 minutes later.
4. Only the first command of a downlink is executed. I tried 8C0087, 878C01 and 8C0187 on 2.5 and on 2.8, and only the first command took effect each time. The guide doesn’t say whether commands can be combined, so maybe this is by design, but it would help to know.
5. FPending is ignored. When ChirpStack flags more downlinks pending, the tracker doesn’t come back early to fetch them; it waits for its next scheduled uplink.
6. The 0x04 uplink isn’t documented. After 0x80, 0x81, 0x83, 0x86 and 0x8C the tracker answers with a 0x04 about 2 min 45 s later, carrying work mode, positioning strategy, heartbeat, intervals and SOS mode, for example 04 01 00 02d0 003c 003c 01. Your decoder skips the second byte; I checked that it’s the positioning strategy. What I couldn’t pin down is when it’s sent: one day, commands that didn’t change anything were all acknowledged; another day, 8302 (Event mode, already active) got no 0x04. It’s a very useful read-back, and it would be great to have it documented.
7. 0x84 is answered with 0x03, which isn’t documented either, and is handy: it already carries the applied thresholds.
8. The upload beep almost never sounds (§3, “A sound will beep when the data is uploaded”). Most presses whose frame did arrive didn’t beep, and a few uploads beeped with no pattern I could find.
9. Release notes. The firmware page only has v2.8 (“improves LoRaWAN stability”), and there’s no FUOTA, so it’s hard to know whether any of the above changed between versions.
I’ve built around points 2 to 9 and the tracker works well for me otherwise. The cache is what I can’t build around. My questions:
- What exactly triggers the cached upload, why doesn’t it happen on return to coverage, and why are already-delivered frames sent again? Is a fix planned?
- Should
0x88work in Periodic mode on 2.8? - Is the 2-minute Continuous SOS interval intended?
- Could
0x04, and the0x03reply to0x84, be documented, including when0x04is sent? - Is there a changelog for 2.5–2.8, and is a newer firmware planned?
I can share raw payloads and timestamps for any of these. Thanks!
Juan