Blueprint scope and planning

I’m trying to nail down various hardware modules we’re going to need for our blueprints (starting with the door lock) so we can procure them locally and use them across blueprints.

I’ve done a first draft for the Door Lock and now I need a review before I go further.

  1. Please review Reference HW 1st and 2nd choice and see if you approve (especially if you are the blueprint owner).

  2. Then please look at the HW and SW scope (common, v1 and v2) proposals.

    • Common are features used across blueprints
    • v1 are features to be delivered for Jasmine
    • v2 are stretch-goal for Jasmine and probably enhancements to the blueprints in Jasmine+1

This way we can constrain what functionality we will deliver for the blueprint. Remember the goal is NOT to deliver an end product, but a technology demonstration of the Jasmine stack (OTA, networking, security and applications that implement core blueprint functionality).

You can comment in the sheet directly or in a thread here. I am working on the other blueprints this week.

I looked at the gateway blueprint and at the hardware there and it looks good to me from OTA point of view, but I have a question.

You’ve listed:
1st choice: Seco SBC-B68
2nd choice: Avenger96 or RPi4

Right now RPi4 is the initial implementation goal for the OTA stack, most likely followed by the Avenger (broad availability and u-boot test platform). Can you please remind me if B68 is the x86 board or the IMX board? While a stretch, it might be interesting to have an x86 board there to cover all the boot-loader cases.

@zyga

B68 is the x86 board. C61 is the i.MX8.

For some blueprints it is OK to have work ongoing on two reference boards - since not everyone has all the boards.

I’ve swapped the preference for gateway to RPi4 as 1st preference for now.

1 Like

Seco SBC-B68 is a Apollo Lake Intel board, SBC-C61 is an NXP i.MX8mm board.

1 Like

Thanks, so without too much foresight from my side, we have a very solid set of devices for the OTA stack, that should be more or less representative of what we can expect to find in the wild! Nice :slight_smile:

I added my comments in the sheet so they can be acted on. As a reference here the highlights as well.

  • Avenger96 as the target for the gateway has the pending risk of fw for wifi and bt. Pi4 and B68 might be the best choices if we can’t sort this out.
  • missing hardware reqm is USB host to plug in the OpenThread USB dongle
  • OpenThread sw support should be yes
  • For MQTT or CoAP we need to align with what we want to use for the doorlock demo to choose
  • Wifi access and configuration from mobile needs clarification (P2P vs softAP)
1 Like

We could use an external module for wifi/BT on avenger. For now I’ve just removed it from the list.

Good catch! Added.

Indeed.

My impression is that P2P firmware support is less common than softAP support. So I was thinking of using softAP for now.

I agree on SoftAP. Less problems and working for our use cases. It is actually already implemented and merged with the gateway blueprint image.

Avenger96 could still be an option with USB dongle or if we sort out the fw side. I just wanted to flag it as a risk.