tag corrupted, damaged?

[sdetweil]

I suddenly have 1 tag that is misheard from 2 anchors. reported as on the other side of the anchor board

one should report about -20 to -45, but reported as +44 other should report at + 20-25, reported as -15

both 'wrong' sides are further away from the tag. almost like the CTE is corrupted somehow.
this persists across power cycles on the tag.

I replaced the tag with one of the others and this one is behaving to the same two anchor boards.

any debug suggestions? tag last flashed 3 weeks ago

[perssonmagnus]

Hi,

This seems strange. A few questions:

1. Is the tag visibly damaged physically? They are quite robust, so just double checking if there is any damage on the antenna area.
2. Do this failing tag give the same signal strength (RSSI value) on the anchor side as the tags you say are working?

A weak signal strength can give bad results, and could be caused by physical damages as well as SW. This is a setting saved in flash (TXPWR command), maybe there is a low value saved since before or that memory area has been corrupted somehow?

Have you tried reflashing the tag?

Best Regards, Magnus

[sdetweil]

I have not examined the tag board inside the case. it has been hanging on its screw mount for a while now.

I will examine the logs for the RSSI value. I don't use that I have not modified the TXPWR value from the original code.

I have not reflashed the tag, waiting for this kind of info to examine what might be wrong.. I see there is no command to retrieve the flash value for txpwr.. I can add that, BUT have to reflash to get it

does reflash wipe the flash storage as well?

is there some use limit on the flash storage, number of writes? (some memory systems have that constraint) my software programs the ID (AT+ID=) on each test run.(which causes 2 flash writes). I added commands on a previous update to retrieve the values, and so COULD test if the values set match the incoming values, and not make update requests.

I also program the rate, which causes a flash update.

my startup at the tag, sends these commands

AT+ADV=0" ,   // stop advertising if active
 "AT+TXRATE=62" ,   // set rate,  write flash 1 time
    "AT+ID=" + idvalue,   set ID (NS and Instance), write flash 2 times
    "AT+GNS",  // get NS  (from memory)
    "AT+GIN",  // get INstance (from memory)
 "AT+ADV=1", // start advertising

all my tags are identical sw version and data flash then program as needed on demand by additional info

the tag code in main.c is changed to read the Namespace and Instance from flash , instead of hard coded

static void btReadyCb(int err)
{
    unsigned char tbuf[40];
    __ASSERT(err == 0, "Bluetooth init failed (err %d)", err);
    LOG_INF("Bluetooth initialized");
    bluetoothReady = 1;

    storageGetTxPower(&txPower);
    LOG_INF("Setting TxPower: %d", txPower);
    setTxPower(BT_HCI_VS_LL_HANDLE_TYPE_ADV, 0, txPower);

    buttonsInit(&onButtonPressCb);
    storageGetNameSpace(pDefaultGroupNamespace, sizeof(pDefaultGroupNamespace));  // added
    storageGetInstanceID(uuid, sizeof(uuid));  // added

    btAdvInit(advIntervals[advIntervalIndex], advIntervals[advIntervalIndex], pDefaultGroupNamespace, uuid, txPower);
    btAdvStart();
}

I send the commands in a loop (javscript)

for (let c of TagCmds) {
            console.log("sending " + c)
            const response = await TagSerial.send(c, options)
            console.log(response)
            await delay(100);
        }

but there is a 100ms delay after each, in the theory there may be some async processes going on somewhere (write to flash returns before commit complete for example)

[sdetweil]

I appear not to have saved the log from the center anchor but here is from left (hearing badly) I don't see the RSSI as different

+UUDF:323032303031,-71,48,-18,-74,38,"6C1DEBA09A66","LEFT",293344
+UUDF:323032303031,-73,48,-18,-74,37,"6C1DEBA09A66","LEFT",293410
+UUDF:323032303031,-72,48,-18,-73,38,"6C1DEBA09A66","LEFT",293479
+UUDF:323032303031,-73,48,-18,-81,37,"6C1DEBA09A66","LEFT",293540
+UUDF:323032303031,-72,48,-18,-69,39,"6C1DEBA09A66","LEFT",293607
+UUDF:323032303031,-72,48,-18,-69,39,"6C1DEBA09A66","LEFT",293676
+UUDF:323032303031,-72,48,-18,-70,39,"6C1DEBA09A66","LEFT",293738
+UUDF:323032303031,-71,46,-18,-73,38,"6C1DEBA09A66","LEFT",293800
+UUDF:323032303031,-71,46,-16,-74,38,"6C1DEBA09A66","LEFT",293932
+UUDF:323032303031,-71,46,-16,-73,38,"6C1DEBA09A66","LEFT",293999
+UUDF:323032303031,-73,46,-16,-77,37,"6C1DEBA09A66","LEFT",294274
+UUDF:323032303031,-72,48,-16,-69,39,"6C1DEBA09A66","LEFT",294345
+UUDF:323032303031,-72,48,-16,-69,39,"6C1DEBA09A66","LEFT",294486
+UUDF:323032303031,-71,48,-16,-73,38,"6C1DEBA09A66","LEFT",294683
+UUDF:323032303031,-72,50,-16,-69,39,"6C1DEBA09A66","LEFT",295028
+UUDF:323032303031,-72,52,-16,-69,39,"6C1DEBA09A66","LEFT",295100
+UUDF:323032303031,-72,52,-16,-69,39,"6C1DEBA09A66","LEFT",295169
+UUDF:323032303031,-71,52,-18,-73,38,"6C1DEBA09A66","LEFT",295311
+UUDF:323032303031,-72,52,-18,-70,39,"6C1DEBA09A66","LEFT",295438
+UUDF:323032303031,-72,52,-18,-69,39,"6C1DEBA09A66","LEFT",295505
+UUDF:323032303031,-71,52,-18,-73,38,"6C1DEBA09A66","LEFT",295572
+UUDF:323032303031,-71,52,-18,-74,38,"6C1DEBA09A66","LEFT",295702
+UUDF:323032303031,-71,52,-18,-75,38,"6C1DEBA09A66","LEFT",295766
+UUDF:323032303031,-73,52,-18,-69,39,"6C1DEBA09A66","LEFT",295836
------------  here is where I replaced the tag 
+UUDF:323032303031,-71,-22,-24,-66,39,"6C1DEBA09A66","LEFT",6508
+UUDF:323032303031,-71,-22,-24,-76,37,"6C1DEBA09A66","LEFT",6528
+UUDF:323032303031,-73,-22,-24,-76,37,"6C1DEBA09A66","LEFT",6574
+UUDF:323032303031,-83,-22,-22,-77,38,"6C1DEBA09A66","LEFT",6604
+UUDF:323032303031,-71,-22,-22,-66,39,"6C1DEBA09A66","LEFT",6634
+UUDF:323032303031,-72,-22,-24,-73,37,"6C1DEBA09A66","LEFT",6658
+UUDF:323032303031,-71,-22,-24,-66,39,"6C1DEBA09A66","LEFT",6704
+UUDF:323032303031,-71,-22,-24,-76,37,"6C1DEBA09A66","LEFT",6729
+UUDF:323032303031,-71,-22,-28,-76,37,"6C1DEBA09A66","LEFT",6783
+UUDF:323032303031,-70,-22,-28,-66,39,"6C1DEBA09A66","LEFT",6864
+UUDF:323032303031,-71,-24,-28,-66,39,"6C1DEBA09A66","LEFT",6989
+UUDF:323032303031,-71,-24,-28,-66,39,"6C1DEBA09A66","LEFT",7063
+UUDF:323032303031,-71,-24,-28,-66,39,"6C1DEBA09A66","LEFT",7315
+UUDF:323032303031,-71,-24,-28,-76,37,"6C1DEBA09A66","LEFT",7567
+UUDF:323032303031,-71,-24,-30,-66,39,"6C1DEBA09A66","LEFT",7650
+UUDF:323032303031,-71,-24,-30,-76,37,"6C1DEBA09A66","LEFT",7674
+UUDF:323032303031,-71,-24,-30,-66,39,"6C1DEBA09A66","LEFT",7703
+UUDF:323032303031,-83,-24,-30,-77,38,"6C1DEBA09A66","LEFT",7726
+UUDF:323032303031,-71,-24,-30,-66,39,"6C1DEBA09A66","LEFT",7748
+UUDF:323032303031,-71,-24,-28,-66,39,"6C1DEBA09A66","LEFT",7776
+UUDF:323032303031,-83,-24,-28,-77,38,"6C1DEBA09A66","LEFT",7800
+UUDF:323032303031,-71,-24,-28,-76,37,"6C1DEBA09A66","LEFT",7852
+UUDF:323032303031,-83,-24,-28,-80,38,"6C1DEBA09A66","LEFT",7879

replacing the tag is unhooking from screw hanger, and unplugging usb cable, plugging cable into new tag, hanging back up.. run same test (which programs the tag.... etc)

here is the test environment topology

you can see more info on the forum https://portal.u-blox.com/s/question/0D52p0000CCRVmwCQH/xplr-positioning-calculations-help can't figure how to link a post, but see post labeled

Edited April 6, 2022 at 5:18 PM

[sdetweil]

and here is a pic of the right anchor and tag on the wall the picture doesn't show it, but it is square

[perssonmagnus]

is there some use limit on the flash storage, number of writes? (some memory systems have that constraint) Yes, see for example the nRF52833 Product Specification at https://infocenter.nordicsemi.com/topic/ps_nrf52833/memory.html?cp=4_1_0_3_1_1#flash.

I would assume that the APIs handling write to flash will take care of that writing identical information as was previously stored will not cause an actual write, but you need to check that, for the API that you use. See for example https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/reference/storage/nvs/nvs.html?highlight=nvs_write#c.nvs_write

Regarding the RSSI it seems to be the same, and as you keep the tag in the case I guess we could rule out mechanical damages. Is this something new or have you had problems with this tag before, or is this something that has started to happen lately?

I would recommend a reflash with erase on the troubling tag to see if that helps, if you have access to a debugger? Make sure you save the UICR register as described in the NINA-B4 System Integration Manual.

nrfjprog.exe --readuicr uicr.hex

[sdetweil]

flash memory, says limited, The CPU can read from flash memory an unlimited number of times, but is restricted in how it writes to flash and the number of writes and erases it can perform. but doesn't say where to find the limit, or how overwriting with same info might be handled..

just started with this tag, no prior issue

I do not have access to debugger.

[jakkra]

@sdetweil You can find info about how nvs works here https://docs.zephyrproject.org/latest/services/storage/nvs/nvs.html#flash-wear For detailed info regarding NRF52833 (NINA-B406) you can this info in https://infocenter.nordicsemi.com/pdf/nRF52833_PS_v1.3.pdf (it's min 10 000).

For the none working tag, did you bring it close to the C211 and see that it still gave bad angles?

[sdetweil]

did you bring it close to the C211 and see that it still gave bad angles?

did not try this, as two anchors were reading it incorrectly.

what is 'close' the location is 5 meters and 9 meters away

[jakkra]

@sdetweil if two anchors was reading the same tag good, and one anchor reading it bad, then there is no problem in the tag. It should work pretty well about 1m away, so if you get angles that makes sense from that distance, you know there is no issue per se. Then the reason for the "drop in performance" could be to due to the environment changed and you got some real bad multipath.

[sdetweil]

two anchors reading same tag bad!

physical env has not changed. as I said, suddenly one tag is reported incorrectly at two anchors..

now today anchors have new locate sw.

so I may try the tag again. haven't wanted to contaminate it

[sdetweil]

i upgraded the anchors to the 1.2 version of uconnectLocate and tried the tag again.. it doesn't exhibit the problem anymore..

[sdetweil]

on another topic, I am seeing consistent (anchor firmware 1.2) but incorrect angles reported.. i have 6 tags reporting at the same time..

how much do you think periodic advertising will improve the accuracy of the UUDF record angles?

and doesn't this require a matching Anchor code change?

[jakkra]

Just released 2.0 please try with that one.