Differences

This shows you the differences between two versions of the page.

--- newsletters:2026-08 [2026/09/22 14:15] – [Localization] osnr
+++ newsletters:2026-08 [2026/09/22 14:20] (current) – [Object tracking] osnr
@@ Line 130: / Line 130: @@
         * Raw centroid of contour
         * Compute centroid transform by registering centers at a few different points
-        * Same-side arc contour
+        * Same-side arc contour or opposite-side arc contour: if you just take the side either near the camera or away from the camera, you know it's consistently the arc of the top or bottom of the object
-        * Opposite-side arc contour
+          * {{.:pasted:20260922-141914.png?200px}}
+          * This was most promising for a while and felt most principled
 Interpolation (SAM2 is pretty slow, 60-100ms per frame)?
@@ Line 183: / Line 184: @@
 I found a few issues this month:
   * Bad sync pattern: the single pulse I was using (from IB to itself and to OOB) was not distinguishable enough from actual RFID protocol communications. I probably could have tuned the thresholds and detection algorithm, or just have OOB decode IB RFID messages directly, but instead using a longer / more unique pattern for now. We sync every round, not just at reset time, because there is drift
-  * Tearing: rounds would stomp previous rounds in RAM on the radio mid-copy, so even if they were fine on the OOB radio, we were getting torn data on the PC which was totally wrong, so you'd get apparent desync in the middle of the round
+  * Tearing: rounds would stomp previous rounds in RAM on the radio mid-copy, so even if they were fine on the OOB radio, we were getting torn data on the PC which was totally wrong, so you'd get apparent desync in the middle of the round. Need to lock the slots on the circular buffer on the radio.
@@ Line 190: / Line 191: @@
 === Localization ===
-I've started doing localization. It feels more valid than last time -- less garbage and random flickering, and when it works it works.
+I've started doing localization. It feels more valid than a couple of years ago -- less garbage and random flickering, and when it works it works.
 {{newsletters:img_8474.jpeg?400px}}
+A big limitation right now is just pickup range. I made a decoding improvement, to use phase and not just amplitude, which helped a lot, but still more to do next month.
+We can definitely pick up on the tag at 1ft -- 3ft is when it gets sketchier. (way below the advertised 10m range of UHF RFID...) And if we can't pick up on the tag, we definitely can't localize:
 == Problem tiers ==
@@ Line 205: / Line 210: @@
   - Successful RN16, decode correctly, send correct RN16 back, get EPC from tag, decode correctly, checksum succeeds. We have a valid EPC from the tag!
-We're starting to break these out into the PC UI.
+(These are tiers for an individual hop. There's a further sequence of tiers that is about the whole round of hops, where we're hopping every 20MHz to cover 800MHz to 1080MHz to get the wideband channel estimate.)
+We're starting to break these tiers out into the PC UI.
-{{.:pasted:20260922-141500.png?300px}}
+{{.:pasted:20260922-141500.png?600px}}
 Note that we can only localize with data where we know we've decoded the tag response correctly, since only then do you have verified-good bit timing boundaries and reflective/non-reflective distinction! For now, we've been using only tier 6 data, but I guess you could use lower tiers if you have a known-good RN16 but not EPC? But in practice, I don't know if there's a way to establish that. The checksum is really reassuring compared to anything else where you might literally be decoding noise (our decode is often 'maximum likelihood' style where you assume meaning is there and find the most likely place for it to be, rather than yes/no).