I was waiting for the release 2 of the firmware and now that it is here, I am reading documentation and source code, enjoying all the new possibilities offered to us.There is however one action that I cannot find how to perform. I need to retreive the ranging information from anchor to anchor to implement a custom auto positionning mechanism. I know that the Android application include this feature and I just want to do the same thing through UART.
This is currently not supported.
EDIT:There may be a way to perform what you want to achieve.
The dwm_loc_get will give you the distance form an anchor to other anchors once you have performed auto-position from BLE.
Note we haven’t really used auto-positioning feature for larges scale deployment. For large area, there is a risk of accumulating error in the range calculation, and the final anchor may have an error. It will have a direct impact on the trilateration engine performance.
For large installation, we recommend to calculate anchors coordinates from a floor plan and with a geometric approach. This ensure the best performance.
Thank you for your reply. Did you mean that the BLE auto positioning process “trigger” some kind of mesurement mode that enable the anchor to range with their neighbour ?
If so is it possible to do the same thing without passing by BLE ? That would solve all my problems.
Thanks again for your help
My understanding is that each anchor could be put into tag mode and range with it’s neighbors. When it has ranged, it switches back to anchor mode and the next anchor takes a turn as a tag. After each anchor has taken a turn as a tag, each anchor should have ranges of 3-4 other anchors and approximate relative positions can be calculated. More complex systems could do multiple rounds of ranging where the first four that each anchor ranged with while in tag mode are disabled, forcing it to find other anchors. This could be repeated until there are no more anchors visible to it. This would give ranging from each anchor to all other anchors that are visible to it. It would take a bit of time to do this though.
Of course, Yves’ point about the accuracy is an important one. If this were to be done in a larger system, accuracy could likely be improved if some of the anchors have known geometrically measured positions scattered throughout the system to act as correction points for the system while allowing the others to range and autoposition. This could largely mitigate the compounding error.
As for the BLE issue, my understanding is that this could be done using gateways by sending “IOT data” to and from the gateway and using the gateway to coordinate the tag mode.
Thanks for your answer. The solution you describe seems indeed possible but might require a lot of developments that are already implemented for the BLE feature.
It would save a lot of time if I could use those mecanisms to put the network into measure mode then retreive all ranging data with user IOT data.
Regarding the accuracy issue I understand the limitations here but as I am working on small scale network, I think that errors would be negligeable.
So the question is: Is there a way to enable the network “measure mode” without passing by the BLE ?
the auto-positioning can be enabled only via BLE. The Initiator will switch the whole network to auto-positioning mode when all anchors will do TWR with all of their in-range Anchors.
Once it finished, the data can be collected via BLE or via dwm_loc_get call. The BLE is the only supported method which has the limit of BLE range. You can try to use the dwm_loc_get to collect the measurements from the anchors and send them via IOT user data to the server.
Please note, that the errors of distances are not accumulated through the network. The accumulation of errors which Yves and Jefferson described are related with the auto-positioning algorithm and binding to a certain origin. This can be optimized.
While experimenting, and thinking of the same ideas, I have the following remarks.
For hudge network, precision in general does not need to be the same everywhere.
Capacity to ask to a particular anchor to switch to tag then back to anchor is a good idea.
Through this idea, it is possible to have anchor you measure with great precision, then you add anchor to extend the network.
Moreover for demonstration, this enables to have a small part (Bluetouth accessible) configured with auto positioning, then add extra Anchor to extend the region with extra anchors.
Having the possibility to copy past the position on the Androi or ask a tag to keep it’s position when changing to tag, would be great.
yes, correct. The distance measurement errors depend on the LOS condition between the measuring anchors. Each anchor do 50 measurements with each of their in-range anchors. So the distances provided via the dwm_loc_get are averaged distances.
When using anchors with great precision, the errors do not need to accumulate and a good auto-position can be created. It would be a subject of the added values which you can create with the API provided by PANS. It is true that currently PANS lacks an API call which would allow to trigger the auto-position measurements via other API calls than BLE. The reason was that the auto-position function have been added only for demo purpose. But in general the current system design allows to do scalable auto-positioning.