RIOT 10 year anniversary promotional board

Development Endeavours
1

Purpose

To celebrate the 10 year anniversary which will happen in December 2022, I would like to propose creating a special RIOT board for that occasion.

It would be interesting to see what happens when board design is shared amongst a large community like with RIOT. Also, it will be a great way to share expertise and learn useful aspects of the full lifecycle of a product.

Other open-source OSes have done this before but more as a partnership than coming from the community.

The Idea

We can collect a list of people interested in contributing to this project, along with some information about what they can provide (expertise, time, money). Once we have enough people we can start with sorting out tooling, admin details, and specifications (what do we want to provide and how will we accomplish that).

We can use the board for promotional purposes (giveaways) but maybe also we can distribute it on tindie or from our website?

I would like to avoid any politics and bureaucracy on this, keeping it completely community-driven and fun (ie, no looking for sponsors or dealing with creating companies).

How To Start

Please write down if you are interested and what things you can contribute, such as:

  • PCB design expertise
  • Adding board/cpu/radio support
  • Funding
  • Manufacturability experience
  • Enclosure design
  • Access to EMC test equipment
  • Distribution and logistics

Things of that nature. Once we have a list of people we can sort out the next steps.

EDIT: It seems already there is quite some interest so I will add some useful links

pad for some structured information

matrix chat for bouncing ideas

EDIT2:

We are still looking for people with enclosure design experience, maybe comfortable with a 3D printer and basic molding concepts?

It would also be good to have someone familiar with logistics and distribution though we may not need to take it that far.

2 Likes
2

So, obviously I am interested and here is what I can contribute:

  • A bit of PCB design, mostly digital with some EMC protection experience.
  • I am willing to donate hundreds of Euros for board production (assuming I can keep a few for myself and for giveaway).
  • I have some experience in manufacturability of electronics and assembly (dealing with PCB manufacturers).
  • I have passed EMC qualification for non-wireless devices in Canada before and have some access to HAW Hamburgs equipment (though I don’t know what that is).
  • I don’t mind championing this projects (ie, pushing it forward, taking some responsibility).
3

For quick conversations we have this matrix room

4

Also interested. I can contribute:

  • PCB design, some digital, some analog. No EMC protection experience.
  • Manufacturing experience doesn’t extend past ordering PCBs and soldering them myself.
  • Driver support and whatever other category of code I’ve contributed in the past
5

Also interested, can contribute:

  • Some board design experience up to USB (short enough I never had to do impedance matching)
  • Had boards manufactured in automated processes (but small series)
  • A long (and mutually exclusive) wishlist :wink:
6

OK, here goes my wishlist (maybe some people add and we can start polling):

  • Cheap (ideally 10€ – nrf52840dongle shows that works for almost everything on this list, but it may be subsidized)
    • that means: no built-in programmer
    • SMD-only would be nice (also nice because it can then sit flat, although a USB-C connector violates that again)
  • USB
  • 802.15.4 radio
  • blob-free
  • BLE radio
  • RGB LED
  • LiPo connector
    • with USB charging
  • Extensible through solder-on connectors, eg. UEXT, mikrobus or any shield system
  • Something that sets it apart from existing boards

There’s a few things I’d like but can easily be served by tack-on boards:

  • Ethernet (1, 2)
  • Audio
  • Storage
  • Exotic radios
  • Infrared
  • Display
7

Also interested, can contribute:

  • Driver support, specifically radios
  • Some PCB design (mostly digital)

+1 to the wishlist of @chrysn. A 2.4 GHz transceiver (for both BLE/IEEE 802.15.4) and a IEEE 802.15.4 SubGHz transceiver would be awesome.

8

as a intro for new people, the USB connector is a must. Are you saying that there would be no programmer, because the USB would not have the right FTDI/etc. bit-banger to run the JTAG?

I’m enthusiastic about such a project.

9

If it had a SubGHz transceiver don’t we get into the NA vs Europe (850 vs 900) regulatory concern. If we have a transceiver, do we have to get the device certified?

10

do we have to get the device certified?

I don’t think we will get the device certified officially (as that would end up costing lots of the moneys) but I would like to go through the pre-certification process and use the tools we have available though educational channels. (ie pick a standard and try to get them to pass whatever tests we are able to perform).

This would be good insight for those who have not gone through the full product release cycle.

If we do end up selling them I imagine we would have to have some disclaimer of “development kit only, not for commercial use” or something.

If it had a SubGHz transceiver don’t we get into the NA vs Europe (850 vs 900) regulatory concern.

Can we just limit our application to 433? I thought everyone liked that frequency?

11

Are you saying that there would be no programmer, because the USB would not have the right FTDI/etc. bit-banger to run the JTAG?

I’m saying there would be no programmer because the device has a bootloader flashed in, and a means of flashing software through it even when an OTA upgrade went wrong. (riotboot-dfu can do that if there is a USB connector).

This would not make the device fully user-unbrickable (you could overwrite the bootloader, but RIOT’s make system wouldn’t easily let you do it), and even if the user “bricked” it, it can be recovered using an external programmer.

12

433MHz is neat – I have a soft preference for anything there is standardized 6LoWPAN for, but meh.

To me the larger question is that of the application: If we do want to go the “a fun gadget” rather than the “devkit” route, the choice of radio(s) (and anything else on my old wishlist) would pretty much be determined through that gadget’s purpose.

(We can always have one more button or LED, but if want to, say, go geocaching / foxhunting with, the audio and radio parts would be picked for that purpose.)

13

So you think more something in the direction of the rad1o or r0ket than an Arduino or Nucleo?

14

If we do want to go the “a fun gadget” rather than the “devkit” route

I am strongly for “a fun gadget” for the following reasons:

  • We have attempted dev kits before with limited success.
  • Many dev kits already exist that would likely serve our purpose.
  • I want to freshen up and share the experience of the full process and dev kits typically leave our some steps.
  • We all have lots of experience working with dev kits but not so much with “end products” and I think we can learn a lot about places RIOT can improve to provide that.
  • It would generally be more appealing to the masses (although it is debatable whether we want that or not).
  • Application code would be a larger part of this, with a dev kit we would just provide hardware, with a full product we would have a (hackable) proper application.
  • Finishing/agreeing on something that has a defined, reasonable requirement seems more achievable than something open-ended.
1 Like
15

So, I think that I’m very much onboard with this. Can it have a unique IDevID built in too? :slight_smile:

16

As long as that only certifies the device’s identity (not the firmware running on it), and either we have by then found a way to persist data across reflashes or can use any security module that so happens to support this out of the box, I don’t see why not (given that these devices finally will need an onboarding story). Does the IDevID need to encompass the certificate and chain (up to which root, even?), or does it suffice to reference one (and if so, do you have a MASA at hand that is Free Software friendly)?

17

is funny joke, haha :slight_smile: I wish. If someone did want to add remote attestation, then they’d have a device key with which to sign the evidence. But that’s not my goal here.

What I see, and I haven’t proven/investigated this much yet, is that riotboot needs to maintain the data area for the private key/certificate. On some CPUs that might even be in a secure enclave. The thing/process that flashes riotboot in, needs to provision the key.

which root: well, one that the RIOT-OS community maintains.
I building a business case for cacert to offer this kind of thing, but so far, they do not. How deep should the certificate chain be? Probably not very deep if we make less than 1000 units. I.e. just a self-signed root and EE per device. We should in the design, make room for a two certificates.

As for a MASA that is Open Source, thank you for asking. https://minerva.sandelman.ca/ Comes in docker, LXC and VM containers. It includes a provisioning CA functionality, and I’d be happy to stand up some kind of provisioning workbench, once we figure out how the production process is going to work.

19

You get into a lot of regulations issues if you want to sell and market it as “fun gadget”. Then you actually have to follow all the regulations and make sure it doesn’t exceed all the duty cycles, output power etc. So, I would advocate highly against it. I don’t want to deal with the legal consequences and I guess you don’t want to as well. The device should only be appealing to a certain audience. At least developer with some microcontroller knowledge. If you want to go the fun route, remove the radio and get it certified. Still kind of expensive, but less expensive than with radio. You can still make the tutorials etc. easy to follow for a dev kit. So that potentially another audience it able to follow it. But actively advertising it as “fun gadget” can be dangerous.

20

Funny that you bring this topic up. I started to design a devkit for Web of Things. Still a long term project, since the implementation is still in progress and there are some open questions. So, it would be great to have a devkit. From my perspective it pretty much needs what @chrysn mentioned. RGB LED is not very important to me. But they don’t really add much costs to it, so fine for me. 802.15.4 is not a must for me, BLE on the other hand is. On board storage is pretty much a must for me though. I eventually want to cache the Web of Things TD. 8/16MB flash storage also isn’t that expensive. (Okay, due to the shortage it is)

21

But actively advertising it as “fun gadget” can be dangerous.

I think that the widespread route here is to go for a “kit” – even if we select and equip it to be a toy, it’ll be a toy for people who take responsibility for their own firmware. (There is an appeal to the “make it a full thing and do all the CE stuff”, as it might serve as a scaffolding to follow for other open hardware projects, but it’ll be a lot of complexity, even if we use a precertified radio module like Würth’s “proteus” nrf52840).

Even when it’s sold as a kit, I think that many uses might still be in at least some legal gray area – the relevant frequencies being ISM just means that CE conforming producers can build things for that band without the need for the user to obtain a shard of the band, doesn’t mean that everyone may build or assemble their own devices (that’s AIU reserved for people with an appropriate business license, and for amateur radio). But at least it’s not the manufacturer’s responsibility any more, and I don’t have any indication that people ever got into trouble for using radio devkits.