reform issueshttps://source.mnt.re/reform/reform/-/issues2019-05-23T16:30:44Zhttps://source.mnt.re/reform/reform/-/issues/5Make side walls of REFORM bottom out of more durable material2019-05-23T16:30:44ZminuteMake side walls of REFORM bottom out of more durable material*Created by: erlehmann*
A small part of black plastik came loose at the front.*Created by: erlehmann*
A small part of black plastik came loose at the front.https://source.mnt.re/reform/reform/-/issues/4Improve airflow for cooling fan2020-05-27T00:13:14ZminuteImprove airflow for cooling fan*Created by: erlehmann*
See http://yolo.pro/~zakx/reform/ for FLIR images.*Created by: erlehmann*
See http://yolo.pro/~zakx/reform/ for FLIR images.https://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/9LPC OLED UI/UX R12021-07-14T15:06:29ZminuteLPC OLED UI/UX R1https://source.mnt.re/reform/reform/-/issues/6IMX Reset should have dedicated key combo2021-07-14T15:06:38ZminuteIMX Reset should have dedicated key comboCurrently, Hyper/Circle-1 turns the device on *or* resets. Accidentally typing this combo can be frustrating.Currently, Hyper/Circle-1 turns the device on *or* resets. Accidentally typing this combo can be frustrating.minuteminute2021-01-31https://source.mnt.re/reform/reform/-/issues/7Port over pcie clock patch to use IMX8MQ_CLK_CLK2_CG2021-07-14T15:06:46ZminutePort over pcie clock patch to use IMX8MQ_CLK_CLK2_CGhttps://source.mnt.re/reform/reform/-/issues/8Investigate Sleep/Hibernate/Wake2021-07-14T15:12:09ZminuteInvestigate Sleep/Hibernate/Wakehttps://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/15Change way of defining the reform motherboard revision before compilation2023-11-27T20:17:34ZMauro MoralesChange way of defining the reform motherboard revision before compilationI thought there was an issue compiling the source code (see original report) but then realized I needed to uncomment a certain version of the motherboard rev. I wonder if there could be a different way of doing this, like passing some va...I thought there was an issue compiling the source code (see original report) but then realized I needed to uncomment a certain version of the motherboard rev. I wonder if there could be a different way of doing this, like passing some variable or using an entirely different "board" but their sources abstract from a common reform. This is just a suggestion to make it a bit more approachable for people like me who rarely touch C code, but if you don't see any value in it, then please just close the issue.
Thanks for the great work!
## Original report
I get the following error when building the latest tag of the lpc firmware
```
src/boards/reform2/board_reform2.c: In function 'main':
src/boards/reform2/board_reform2.c:1185:9: error: 'REFORM_MOTHERBOARD_REV' undeclared (first use in this function)
1185 | if (REFORM_MOTHERBOARD_REV >= REFORM_MBREV_25_R2) {
| ^~~~~~~~~~~~~~~~~~~~~~
make: *** [Makefile:404: bin/obj/board_reform2.o] Error 1
```https://source.mnt.re/reform/reform/-/issues/11Excessive Power Draw when System is Powered Off2024-01-02T14:23:17ZHayden KroepflExcessive Power Draw when System is Powered OffBoth the keyboard controller and LPC are still fully active and drawing normal power while the system is in a powerdown state. This is causing a significant drain on the battery such that it can be fully depleted in under a month. As the...Both the keyboard controller and LPC are still fully active and drawing normal power while the system is in a powerdown state. This is causing a significant drain on the battery such that it can be fully depleted in under a month. As there is no low voltage cutoff on the batteries this presents the issue that users will not be able to use the reform to recharge the batteries and must be externally changed, as well this likely reduces battery longevity.
Issues that need addressing:
- Keyboard controller needs to be able to enter a power down state
- LPC controller needs to be able to enter a power down state
- Keyboard controller needs to respond to user input and wake itself
- Keyboard controller needs to inform the LPC that the user has woken it out of power down.
- LPC controller needs to respond to a wake up request over UART.
- LPC controller needs to inform the keyboard that the system is off
- LPC controller needs to inform the keyboard of a critical low power state (can be combined with above)
- Check for any additional standby draws on the system.https://source.mnt.re/reform/reform/-/issues/12Battery percentage anomaly2024-01-02T14:23:38ZPhil HagelbergBattery percentage anomalyI've noticed that within 5 seconds of unplugging power on my Reform, the percentage indicator goes from 100% to 76%.
At 100% with the adapter the cells read 3.5V±0.1. Seconds after unplugging, they're all at 3.4V±0.1.
It seems odd that...I've noticed that within 5 seconds of unplugging power on my Reform, the percentage indicator goes from 100% to 76%.
At 100% with the adapter the cells read 3.5V±0.1. Seconds after unplugging, they're all at 3.4V±0.1.
It seems odd that the 0.1V difference would result in a 24% drop in the percentage indicator.https://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/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/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