Hello! I am working with 4 Murata’s 2AB development boards and would like to configure a 1 to 3 system. With the CLI firmware, I can successfully receive data from 3 responders at the same time, no problem. However, this is only possible if I connect them all to PC where I send initf and respf commands via serial port. I want to put them on tripods and use external battery to power the boards, but after power cycle, the boards stop communicating and they have to receive commands again in order to recommunicate which is done via PC. Therefore, I was wondering if there is any way to let the boards remember the previous settings and recommunicate automatically after power cycle. Or is it possible to send initf and respf commands remotely? Any help will be greatly appreciated.
Hi @edward ,
Yes it’s possible to let the boards remember the previous settings.
On the CLI, run your command “initf” or “respf”.
When this command is running, type “save” in the CLI.
This will save your configuration even after a power cycle.
Hi Wassim, thank you very much for the reply. Yes, it worked fine. I just have another two questions:
- Does the CLI firmware allow external power supply to power the development board instead of plugging the board into computer? I am using Murata’s 2AB development boards.
- Is it possible to send initf and respf commands remotely?
Any information will be greatly appreciated!
Hi @edward ,
1/ if you already saved the configuration, then you can use external power supply and the board will start with the saved mode.
2/ In the SDK, the communication ways are either uart or usb. Then, it’s not possible to send these commands remotely.
Hi Wassim, thanks for the clarification. Do you know if it would be possible to modify the CLI firmware so the responders can not only receive messages but also send messages? In addition to initiator to responder mode, we would also like to get responder to responder measurements.
Hi @edward ,
No, we cannot for the simple reason that the TWR exchange in the SDK0.1.1 is defined as per FiRa https://www.firaconsortium.org/.
If you want to use one initiator and 2 responders for example, then you shall use one to many mode:
Example commands below:
Initiator:
INITF 4 2400 200 25 2 42 01:02:03:04:05:06:07:08 1 0 0 1 2
Responder1:
RESPF 4 2400 200 25 2 42 01:02:03:04:05:06:07:08 1 0 0 1
Responder2:
RESPF 4 2400 200 25 2 42 01:02:03:04:05:06:07:08 1 0 0 2
Please check the documentation about INITF/RESPF parameters in the Developer guide for more details:
Hope it helps,
Wassim
Hi Wassim, we already did one to many mode and now we are interested in responders only where we use them as UWB anchors. The reason why we want to realize responder to responder measurement is to build a system of responders (anchors) that automatically know their positions relative to an origin so we do not have to manually calibrate each responder. Do you mean the only way to determine the responder positions is still manual calibration?
Also, could you please elaborate on what has been defined in FiRa? Since the code can realize initiator and responder functions, why is it not possible to combine the two functions into one so one device can perform initiator and responder tasks at the same time? That is also why I have the remote control question. If they allow remote control, we can easily send commands to switch the roles.
Moreover, do you possibly know which file in the CLI firmware records timestamps and calculates distance? Your information is greatly appreciated.
Hi @edward ,
" Do you mean the only way to determine the responder positions is still manual calibration?"
If you want to access devices remotely, I can imagine plugging RPIs for example to devices and then you can access these RPIs remotely to send commands over usb/uart.
I’m only trying to think loudly here, and don’t know about what may be the cost of this solution.
“could you please elaborate on what has been defined in FiRa?”
Unfortunately, It’s very difficult to explain what’s defined in FiRa in one comment as there is a lot of information in their specification. I guess you need to be a member to access all their documentation.
Membership Information | FiRa Consortium.
why is it not possible to combine the two functions into one so one device can perform initiator and responder tasks at the same time?
yes agree, this is because you can only do 1 FiRa session at a time in one device in the actual SDK.
This will hopefully be possible to do a multisession FiRa on one device in a next SDK release (~ in 3 months).
“Moreover, do you possibly know which file in the CLI firmware records timestamps and calculates distance? Your information is greatly appreciated.”
The timestamp is recored in “dw3000_mcps_mcu.c” file .
The distance is calculated inside the uwbstack library, so you cannot access the file.
But it’s displayed in “fira_app.c” file.