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
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:
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.
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.
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?
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?
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.
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.)
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
So, I think that I’m very much onboard with this.
Can it have a unique IDevID built in too? 
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)?
is funny joke, haha
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.
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.
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)
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.
I also tend to think this would be nice. Maybe a little bit “less end” product could be feasible, such as the Ruuvitag. That one is just a tiny multipurpose board with BLE + some sensors.
802.15.4 is not a must for me, BLE on the other hand
The transceiver is the same. We could just pick a radio that supports both.
It’s now part of the IEEE 802.15.4 standard
After looking up some rules I found the following:
- Any electronics produced, sold or distributed will need certification (dev kit or not)
- Radio or not, if the device runs more than a few kHz it needs certification
- There are some exceptions for hobbyists with less than 5 devices
- There are no real useful exemptions for kits or so
It seems CE can be self declared but FCC can’t… Looking into this I am getting a bit concerned with the consequences and requirements of even starting this. This looks like it may be a bit more expensive than I have anticipated. We may require an already certified radio (or no radio) since intentional transmitters certification is pretty expensive.
I would like to point out again that we have lots of resources available within our group to do some pre certification and self declaration stuff, but I don’t know if that will be enough.
Maybe it would be worth investing more time into exemption rules, like the hobbyist one.
I know about the EU situation. Seems like it’s very similar in the USA. The EU makes an exception since 2014 in EN 61000-6-xx. Don’t ask me about the paragraph. ^^ That is why they always add this " ENGINEERING DEVELOPMENT, DEMONSTRATION OR EVALUATION PURPOSES ONLY" blabla disclaimer. See Evaluation Board/Kit Important Notice
As long as you don’t advertise it as educational board, fun board etc. you are fine. And of course you need that disclaimer.
I still think that is a nice project. Something I could need. Having nice tutorials for that board, great support in RIOT. That sounds great. Especially, if that is going to be a RISC-V MCU 
If you want to do a proper CE, FCC certification and market is more towards fun projects. How about having a crowdfunding for it? So, you do all of your testing before the certification and make sure that the costs are down to a minimum for the certification. And the money gets collected via a crowdfunding campaign. When the Web of Things implementation is done, I am also happy to market it for Web of Things compatibility. I can try getting some of the companies in the W3C on board for using and market it a bit. That’s maybe they could be interested in.