Open Know-How sample project?

[hoijui]

Hey Karl! :-)
We are a group of Open Hardware enthusiasts from germany (mostly Berlin), who are trying to improve the state of Open Source Hardware (OSH), and we have some projects going that deal with standardization and meta-data, where we would be interested in having your project as one of the examples if you are interested.
We already have the corne covered (which I am sure you know), but as yours allows to use a RISC-V chip, we are of course extra thrilled! :-)
We have some requirements for the repo for this, with which we could also help, If you need it. First you would have to decide if the changes are ok for you, of course.

Progress

• firmware available as sources
• Open-Source License has to be specified
  • (optional) REUSE License data is available
• okh.toml meta-data file is available
• (optional) all generated files (firmware binaries, gerber files, ...) are not within the repo
• (optional) include meta-data onto the PCB, auto-generated in a CI job (see example project)
  • (optional) as text on the silk/copper layer(s)
  • (optional) as QR-Code on the silk/copper layer(s)
• (optional) no space in dir/file names

[KarlK90]

Thanks for reaching out! Of course, I'm interested in participating. What would have to be done?

[hoijui]

cool! :-)
What would have to be done...

• It would have to be open source first, meaning:
  • all the source files would have to be there (I think the firmware is there only as binary, right?),
  • and you would have to choose an open source license, and use that licenses LICENSE file in the project root.
• There would have to be an okh.toml meta-data file in the project root (see examples)

optional, but very much appreciated for being a good example:

• all generated files (firmware binaries, gerber files, ...) should not be in the repo, but rather be generated automatically for each commit (or alternatively each release). They could be uploaded as github action artifacts or (preferably), hosted on the projects pages, which you are already using. :-)
• include meta-data onto the PCB (using text and/or QR-Code)

With both of these later ones, I am happy to help and/or provide PRs, if you want.
I am currently working on establishing these two things in a sample project, using mainly KiBot for generating gerbers, rneders and an interactive BoM, and a set of my own tools (in the making - projvar, kicad-text-injector, kicad-image-injector), to inject the meta-data into the *.kicad_pcb, before using KiBot.

[KarlK90]

Hi @hoijui just as a heads up, I have started adding the required metadata to the project and will continue on this in the upcoming days.

[hoijui]

WOO HOO! :D
ehhh super Karl! :-)
das freut mich sehr zu hoeren! :-)
ich hab vor 10 tagne oder so, ein angebot gekriegt vo neiner firma in hong kong, dass sie mich gerne unterstuetzen wuerden, wegen eines meiner projekte (den https://github.com/hoijui/kicad-text-injector), und ich bin nohc immer verbluefft.. weis nciht genau wie.. also die wuerden wahrscheinlich... mindestens boards spendieren. also wenn du fuer sowas auch offen bist, das auszuprobieren... koennten wir das auch mit deiner tastatur dann machen, wenn du fertig bist.
und wer weiss, vielleicht haben die ja noch paar risc-v prozessoren fuer uns auf lager .. ;-)

... ein freund ich auch interessiert an einer split-tastatur, schaut aber noch herum (weiss nicht was so sein ding ist).
und sag gern beschied wenn du hilfe brauchst/willst, bei etwas.
danke fuer den heads-up!

[hoijui]

Just now saw that you already uploaded it to the repo when you last wrote. ;-)
thank you!

I added a progress indicator to the first post of this issue. All the leftover stuff, I would take as my responsibility, if you are not eager to do it yourself, and if you are willing to accept it into your repo, once it's done.

I would copy over most of it from the for-science-keyboard (Note: branch oseg, not master), though with reduced complexity.

[hoijui]

@KarlK90, how did you design the case?
as in: with what process/software; Are the SVGs the source files or generated?

[hoijui]

Regarding all the content files (mainly images and Markdown):
Would you like to use CC-BY-SA-4.0 for those, or also GPL?
I like GPL, but it is meant for code only, so I tend to split it up like this.
I am asking, so I can start adding license info on a per-file granularity,
for REUSE compliance (using their tool).

[KarlK90]

@hoijui Thanks for providing your help and sure go ahead.

I'll answer in more detail this evening. For the content files use CC-BY-SA-4.0.

The case files are generated from the PCB, altough that is 50/50 manual work. If you check the user defined layers on the switch footprints you can see drawings for 0mm kerf and 0.1mm kerf. I exported these layers and edge.cuts to SVG and manually deleted/modified them. That is a bit cumbersome but worked quite nice.

[KarlK90]

WOO HOO! :D ehhh super Karl! :-) das freut mich sehr zu hoeren! :-) ich hab vor 10 tagne oder so, ein angebot gekriegt vo neiner firma in hong kong...

Sehr cool, kann verstehen das du da richtig verblüfft bist 🙂. Das PCB Angebot klingt super, ich bin bisher noch gut versorgt aber falls sich dein Freund sich für YAEMK entscheidet wäre das eine interessante Idee. 👍 Ich habe hier auch noch mindestens 6 GD32VF103 rumfliegen davon kann ich bei Bedarf auch noch welche abzwacken.

[KarlK90]

* all generated files (firmware binaries, gerber files, ...) should not be in the repo, but rather be generated automatically for each commit (or alternatively each release). They could be uploaded as github action artifacts or (preferably), hosted on the projects pages, which you are already using. :-)

I like the idea to auto-generate all the artifacts for this project, although the development of the YAEMK is basically finished at this point (time to do a proper release with a tag). So my only concern with this approach is that generating all the artifacts manually takes me about 30min. Setting up CI and process would take longer I recon and would not have a time saving factor as there will not be many releases in the future. The main benefit would be a nicely working example for the community on how to do it.

* include meta-data onto the PCB (using text and/or QR-Code)

That sounds neat! There is a bit of space left on back of the PCBs right next to the split comms usb-c port that could be used for that.

Thanks for your effort and dedication in promoting my project, I really appreciate it.

[hoijui]

The main benefit would be a nicely working example for the community on how to do it.

YES! :-)
the project I linked to (for-sicence-keyboard) is one I put a lot of time into, even though I knew I will probably never want to produce it physically. Still, to copy things over from there to this project, will save a lot of time, and it will already allow to make the thing be more generic, so it will fit more easily to more general projects.
I can not say when yet, but I'll have a go at it (as it will probably also be easier for me, already knowing all the parts of the auto-generation).
.. one thing maybe: could you try to compile the firmware on CI? or maybe someone already does that (given it is qmk, I imagine that is quite likely, right?)

* include meta-data onto the PCB (using text and/or QR-Code)

That sounds neat! There is a bit of space left on back of the PCBs right next to the split comms usb-c port that could be used for that.

NICE! thanks! :-)
... just now reading this, I though...
so the way the image injection utility works, is that one manually adds a rectangle on the PCB (most likely on the silk layer, potentially on the copper layer) in KiCad, which later gets replaced by the image (e.g. the QR-code) in CI. If one were to use the source KiCad PCB directly, and not use the same process as in CI (even though it will be available through a script that one can also run locally), one would end up with a rectangle in that place on the PCB, if it is not removed. I personally to not see this as a problem.. in the worst case, one would shortly wonder what this is supposed to mean, and go on with it. It is something to consider, though. Also, if you have an idea how to circumvent this nicely, feel free to tell. Maybe there is an other way to indicate placeholders on the board? (what I need in the end, is just location and size), or one could add additional text that indicates the placeholder as such, or use only text as placeholder, with the text starting with a custom prefix, ...
We could theoretically also mix those approaches, though it might then get confusing for the users. after all, it is supposed to be a simple CLI tool. but yeah.. am open to suggestions.

Thanks for your effort and dedication in promoting my project, I really appreciate it.

Thank you for your collaboration too! :-)

[hoijui]

Soo... finally had a little bit of attention left to spend today.
I know that @cryptix is working on something on this list as well ... not spoiling anything yet! ;-)
... things are moving!

[KarlK90]

@hoijui Thanks for the heads-up and looking forward to what @cryptix is cooking 😉. I get back to the open questions over the holidays.

[hoijui]

our crawler found your project, and you are now enlisted! :-)
https://losh.opennext.eu/detail/Q3762
This does not really give any real world benefit now, but we will continue to use this standard and the crawled data, and .. well.. at least in some way, you are now a bit more findable, already. :-)

[hoijui]

work on the QR code integration is still in progress.. not forgotten!
@cryptix already did his part (a Docker image with the required tools), now it's my turn for integrating it for testing (side project), then we'll try it here too.

[KarlK90]

our crawler found your project, and you are now enlisted! :-) https://losh.opennext.eu/detail/Q3762 This does not really give any real world benefit now, but we will continue to use this standard and the crawled data, and .. well.. at least in some way, you are now a bit more findable, already. :-)

Yeah, very cool! I got the email as well :-) Thanks for the continued effort!