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

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.

Parents
  • 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

Reply
  • 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

Children
No Data
Related