reform issueshttps://source.mnt.re/reform/reform/-/issues2021-07-14T15:12:09Zhttps://source.mnt.re/reform/reform/-/issues/8Investigate Sleep/Hibernate/Wake2021-07-14T15:12:09ZminuteInvestigate Sleep/Hibernate/Wakehttps://source.mnt.re/reform/reform/-/issues/10LPC: Automatic shutdown signal to OS on low battery condition2021-01-04T13:34:05ZminuteLPC: Automatic shutdown signal to OS on low battery conditionhttps://source.mnt.re/reform/reform/-/issues/13Suggestion: link README media from internal sources2022-09-19T21:59:01ZJC StaudtSuggestion: link README media from internal sources### Problem
The Reform images currently shown in the root README.md of this repository are linked from `https://mntre.com/media`.
I imagine it is likely implemented this way in order to locally-source these images on the MNT website/sto...### Problem
The Reform images currently shown in the root README.md of this repository are linked from `https://mntre.com/media`.
I imagine it is likely implemented this way in order to locally-source these images on the MNT website/store/etc.
However, for the sake of this repository, all of the linked media is unavailable if those filepaths are modified or if the host server/network are unavailable.
### Proposed solution
I recently created a wiki for this project (although it is extremely skeletal in its current state).
This is a great place to have version-controlled public documentation and media sources while not bloating the main `reform` repo with binary files and extra folders.
I would recommend adding the media to this wiki and linking the media within this repository to that location.https://source.mnt.re/reform/reform/-/issues/14allow longer wifi miniPCIe cards2023-01-06T19:50:39ZAdam Chasenallow longer wifi miniPCIe cardsThe mounting clips for the WLAN PCIe port assume the height of the wifi card (specifically 50.95mm(?) per [WLE200NX datasheet](https://www.pcengines.ch/pdf/wle200nx.pdf)), but I have run into a few cards which are slightly longer and oth...The mounting clips for the WLAN PCIe port assume the height of the wifi card (specifically 50.95mm(?) per [WLE200NX datasheet](https://www.pcengines.ch/pdf/wle200nx.pdf)), but I have run into a few cards which are slightly longer and others which are quite a bit longer (>60mm). The mounting points are standard and are typically secured by screws.
Specifically, these are atheros cards pulled from Extreme Networks AP
https://fccid.io/QXO-AP3825E
![image](/uploads/cf4493cb4c6f516496a94e2fb88d5620/image.png)
https://fccid.io/QXO-AP3715I
![image](/uploads/22a09d8ca793147f3ccf043fe1933ae8/image.png)https://source.mnt.re/reform/reform/-/issues/16Build CI pipeline for CAD2024-01-21T15:50:34ZJ WBuild CI pipeline for CADGoal: Reduce amount of (boring) work, reduce (human) errors and try out Computer Aided Engineering (CAE) CI ideas on a real project.
(Also it should reduce the amount of files and folders in the repo)
This is supposed to be the summary ...Goal: Reduce amount of (boring) work, reduce (human) errors and try out Computer Aided Engineering (CAE) CI ideas on a real project.
(Also it should reduce the amount of files and folders in the repo)
This is supposed to be the summary issue of the whole endeavor. I would create another issue for each non-trivial PR, but track overall progress here.
Some history: In 2016/2017 I was in the Formula Student Team "Lions Racing" developing among other things a PCB for the high voltage battery system. Back then I also got into software development and asked myself whether it is possible to create a CI pipeline for CAE similar how it is done in most software projects. Back then I used Eagle and that was really hard to automate since it always needed a GUI, so my efforts werent very successful. After leaving the team I never got around doing PCB design anymore. Then I met Lukas at 37C3 and they was interested in something like that.
A lot has happened since I was in Formula Student and there have been a few examples in this direction (see references). I would like to do this step by step first starting with a proof of concept consisting of two PRs. For this to work changes to the existing CAD files need to be done. I will probably not be able to do those or need some guidance, because I am new to KiCAD (coming from Eagle) and not familiar with the design. It would be great if someone could regularly invest some time into this so I dont get stuck for too long. As for the proof of concept I would go very low tech just using the KiCAD CLI from the docker container. After that I will for example look into KiBot.
Let me know if this sounds like a plan? It is important to me to focus on what is relevant to the team (according to the goal above). So what are task that you do often and/or are annoying/laborious or which are very prone to errors? (And of course which could be automated using CI)
Proof of concept:
- [Export BOM to artifacts](https://source.mnt.re/reform/reform/-/issues/17)
- Website to view/download the BOM on Gitlab pages like [readthedocs](https://about.readthedocs.com/?ref=readthedocs.com) for branches, tags, etc.
Further ideas:
- Export interactive BOM
- Create PDF of schematic
- Export CAD of PCB
- Run ERC/DRC
- Run collision check (CAD)
- Create CAD render with Blender
KiCAD version:
- 5.1.6+dfsg1-1 (reform2-motherboard-r2c.pdf)
- 5.1.8+dfsg1-1+b1 (reform2-motherboard.kicad_pcb)
Is this correct? Docker images only exist for KiCAD 7.X.X. I am not familiar with incompatibilities across versions, but here all KiCAD files might need updating.
References:
- https://github.com/INTI-CMNB/kicad-ci-test-spora
- https://sschueller.github.io/posts/ci-cd-with-kicad-and-gitlab/J WJ Whttps://source.mnt.re/reform/reform/-/issues/17Export BOM in CI to artifacts2024-01-21T15:50:00ZJ WExport BOM in CI to artifactsSee [this issue](https://source.mnt.re/reform/reform/-/issues/16) for a summary and the plan.
I decided to use this [docker image](ghcr.io/inti-cmnb/kicad7_auto:1.6.1) and used these bash commands
```bash
kicad-cli sch export netlist r...See [this issue](https://source.mnt.re/reform/reform/-/issues/16) for a summary and the plan.
I decided to use this [docker image](ghcr.io/inti-cmnb/kicad7_auto:1.6.1) and used these bash commands
```bash
kicad-cli sch export netlist reform2-motherboard25-pcb/reform2-motherboard25.kicad_sch --format kicadxml
kibom reform2-motherboard25.xml reform2-motherboard.csv
```
to generate [this BOM](/uploads/a226b5b71aa44dafde3c3678ae00070a/reform2-motherboard_bom_2.5D-2.csv). I spent ~~too much~~ a lot of time comparing this with [BOM in the repository](https://source.mnt.re/reform/reform/-/blob/master/reform2-bom/reform2-motherboard.csv). Although I could find a lot of similarities, I couldnt verify whether this is the correct export. Could you (@mntmn) please take a look, then I will move on and implement running this in CI.J WJ Whttps://source.mnt.re/reform/reform/-/issues/18LPC should not report 0% battery before having "learned" the battery capacity2024-03-14T18:25:05ZJohannes Schauer Marin RodriguesLPC should not report 0% battery before having "learned" the battery capacityCurrently, the LPC will report 0% battery long before they are actually empty. This means that desktop environments or upower will power down the system shortly before and as a result the system will never switch off because it *really* ...Currently, the LPC will report 0% battery long before they are actually empty. This means that desktop environments or upower will power down the system shortly before and as a result the system will never switch off because it *really* was out of battery and thus the LPC is unable to learn the actual battery capacity. This means that users who do not have automatic shutdown on critical battery levels temporarily disabled will not be able to utilize the actual capacity of their battery. This means that there are reports that the Reform with A311D would last less than 3 hours even though it can last 5.5 hours with fresh cells, full display brightness, wifi connected and casual coding, web browsing and email.
I think the user should not have to temporarily disable the automatic shutdown feature of their desktop environment temporarily so that the system switches off because the batteries were really empty at least once. The conservative defaults of the LPC were maybe chosen because at that time, there were no protected battery boards, and the 2000mAh eremit cells were not the default yet.
Maybe the LPC firmware could be changed to either:
- keep track whether the system already powered off because of missing battery charge at least once (i don't know if it keeps track of that already) and if not, do not report charging levels below 10% to the OS, preventing it from doing a soft-shutdown or
- change some default value in the LPC (probably the default battery capacity?) and make it large enough such that even with the most capable cell, the LPC would think it went down to 0% before the cells were actually empty at which point it will learn their actual capacity