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 204: / Line 209: @@
   - Successful RN16 response from tag, we decode it correctly, send the correct RN16 back, then get an EPC from tag, then decode it incorrectly and fail checksum
   - Successful RN16, decode correctly, send correct RN16 back, get EPC from tag, decode correctly, checksum succeeds. We have a valid EPC from the tag!
+(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.