Hi guys,
I agree with all of you guys. Let me respond to your questions DiBosco:
- The PANS controls completely the BLE interface and there is no option at the moment to send data via user characteristics. The list of restricted and available interfaces are listed here: https://www.decawave.com/dwm1001/api/
SoftDevice also restricts or blocks a certain interface for the same reason. The BLE would not work correctly if you let the user do what they want.
The SoftDevice idea is in general obsolete and it really limits the range of real-time application the user can create. Yves has mentioned correctly the reason of the limitation. That is the reason why Nordic is abandoning the SoftDevice and open-sourcing the code with the Zephyr community https://www.zephyrproject.org/. It has however the luxury to do so since BLE stack is no longer the hot selling know-how. - The DW1000 is only a transceiver as Andy mentioned. The measurement and LE logic is done in PANS using the nRF52 MCU. The schematics might help you to understand the physical blocks:
https://www.decawave.com/dwm1001/schematic/ - If your intention is to write a new LE then you can get the measurements via UART/SPI/SHELL/BLE/UserApp/Gateway and do the calculation as you need. The position calculated by PANS can be ignored or you can disable the internal LE.
- The PANS will keep track and select the most suitable Anchor to do the measurement with. It will ‘roam’ as you move the Tag across the installation. This cannot be changed or controlled by the user. But you can get the Anchor addresses and distances to them (as mentioned in the Q3 above).
Regarding the business strategy: as Andy and Yves have mentioned, Decawave is a semiconductor company. The development of a system which would satisfy every user is very expensive or rather impossible. Hence there were a set functionalities which have been defined and implemented and I think DWM1001+PANS already help a lot of users/clients. There will be always some unhappy clients but to make a product successful there are technical and also business sides. Both are limited.
Decawave is a start-up and cannot be compared with a public traded company like Nordic, which exists here for almost four decades. Decawave might get there, but the evolution takes time.
Another reason is there is no standardization of the RTLS at the link/network/transport/application layers which would simplify the adoption of the technology. So the more skilled companies/groups do invest to their own solution and if Decawave open-source a comparable solution it can have a negative effect on the market development. When the investments will be recovered there is a high chance some valuable open-source implementation will pop-up. This needs time to evolve.
I think the suggestions to solve your issues by Yves make sense. Another option is to develop your own system which I can say is very challenging and expensive. Or you can buy one if you have investment capacity.
I hope this would help.
Cheers,
TDK