We noticed the PANS system uses 15 time slots that cycles through all 15 at a rate of 10 Hz (making each slot have an update rate of 150 Hz), but we are investigating if we can have 1 Tag act like 15 Tags so that we can get an update rate of 150 Hz.
We do not know how to achieve this but we were thinking there might be a way to alter the firmware to designate every time slot to only 1 Tag instead of the system doing nothing in each of those other 14 time slots.
P.S. We are using MDEK1001.
This is not possible with PANS.
In order to reach such an update rate, you will have to develop a fully custom firmware.
Understood, thanks for your reply Yves.
If it is of interest we have developed a system which generates 100 Hz positions for a single tag.
The raw range measurement rate is actually faster than the PANS system but we then filter the ranges to reduce noise before using ranges to up to 8 anchors to calculate the best fit position. This gives us a more accurate and lower noise position and the raw PANS output.
Andy this is quite impressive, is the system you developed limited to 8 anchors total or does it only collect data from the nearest 8 anchors, implying a possible network of more than 8 anchors?
Currently up to 20 anchors supported but that’s only because for initial testing we statically allocated memory per anchor. One of the last things we need to do for initial release is change that to dynamic allocation, then it will go to over 200 anchors.
Our big down side is that we only support one tag at a time unless they are far enough apart to not see each other. We can time slice between multiple tags and interpolate the range data to fill in the gaps without significant performance hit but any more than two tags and we currently need to increase system latency (currently 60 ms) and we still lose position accuracy if you’re moving much (our target market is automotive test so we need to track 1-2 g accelerations).
On the drawing board is an idea that I’ve prototyped and which seems to work which will more than triple our range measurement rate. That would allow us to use smaller time slices and so support more tags at once. But that’s long term plans, we need to get the current system out the door first.
I see, your system is very appealing since we are only interested in a system with one Tag but with a fast update rate (for precise high speed tracking) and 16 anchors.