nfc-door-lock-and-access-control uwb implementation

[bdodge09]

Developing an implementation for UltraWideBandImpl for a different UWB hardware solution (not the provided qm35 implementation) and running into integration problems

The (binary only) Aliro library is doing some pre/post processing of messages so it is not clear what the actual format of BLE messages sent to and from the implementation should include. For example, an InitiateRanging notification doesn't contain an overall length (2 bytes) field, but the resulting UWB M1 message seems to require I put one in the reply.

Is there any documentation on the exact use of the UltraWideBandImpl?

Also, the (default) Qurvo implementation has leaked into the general solution where vendor specific extensions to the UltraWideBandImpl class are called from the (generic) Aliro interface code. Namely, in app/src/aliro/init.cpp calls to

    const char *fwVersion = UltraWideBandImpl::Instance().GetQm35FirmwareVersion();
    const auto *caps = UltraWideBandImpl::Instance().GetCccCapabilities();

That should be abstracted.  I would do a PR but the the Qurvo source isn't available.  Please have them fix that.

[Edvin]

Hello,

I needed to reach out to our Aliro team with your question. They said the following:

We support the QM35 natively, and have not tested 3rd party UWB chips. This is not something we have tested, since there didn't use to be such a use case. So naturatlly, there might be some hurdles doing this, that we don't see with the QM35.

Also, the (default) Qurvo implementation has leaked into the general solution where vendor specific extensions to the UltraWideBandImpl class are called from the (generic) Aliro interface code. Namely, in app/src/aliro/init.cpp calls to

    const char *fwVersion = UltraWideBandImpl::Instance().GetQm35FirmwareVersion();
    const auto *caps = UltraWideBandImpl::Instance().GetCccCapabilities();

That should be extracted.  I would do a PR but the the Qurvo source isn't available.  Please have them fix that.

This is something that we are aware of, and are working on. But I don't have a time schedule for when this will be completed. 

They said that for the remaining questions, they need to look deeper into this, and they will come back to me.

Best regards,

Edvin

[Edvin]

Hello,

I see that the ticket was quite reduced right before I posted my previous answer, so I don't recall all the details that you had, or what you removed.

And I am sorry for the late reply. I was out of office for a couple of days, and had some backlog.

I got confirmation that the team is working on the implementation that will detach the drivers from being directly dependent on the QM35 HW. However, it is not ready just yet. I don't have the timeline for when it will be publicly available. For roadmap details, please contact our sales personnel in your area. Send me a direct message here on devzone if you don't have the contact details of the sales representative for your area. Please link to this ticket in that message, and verify that your location is what you stated in your DevZone profile. 

Best regards,

Edvin