The spacing on the pins isn't right for the part on the BOM; also lacks a resistor or some other driver since it's not self-oscillating.

When attempting to source the materials for the board as well as collaborate on revisions it would be nice to consider the use of the common parts library.

Pros:
This would allow users to easily access datasheets, compare compatible devices, and check on the life cycle of parts.

Cons:
I personally am not an expert in Eagle so I'm note sure if there are any easy ways to handle updating these devices so this could mean a non-trivial amount of work in swapping parts.

I''m currently thinking through a personal need as well trying to be a bit more forward thinking.

Originally, I was going to make the suggestion of exposing UART via a 4 pin connector.

Then I realized that the pins for SPI0, I2C, and UART are all unpopulated. Is there an opinion on whether the strategy is to stack boards, use a pass through header, or potentially expose any of these pins via a header in the future?

At some point this should go 3.6+ instead of keeping py2 compatibility. This mostly means being able to use unittest.mock and removing compat.py but also means fewer things to keep track of.

I've had some ideas about electrical and layout improvements to the pi-hat board:

1. All the empty space on the board should be converted into a ground plane with additional ground traces running in-between the signal traces. One benefit is that less etchant gets consumed during the manufacture process because less copper has to be removed. The other benefit is improved EMI protection. I've heard one anecdotal report that if the authbox is brought close enough to a GAST air pump, the Raspberry Pi may spontaneously reboot. No idea if that was caused by the pi-hat board, but we do have long signal traces that can potentially act as an antenna.

2. Add room for a debouncing capacitor between each Bn_LOGIC line and GND. The board still works without them thanks to the GPIO.add_event_detect(... bouncetime=150) we have in software, but that's just a simple delay. If you hold the button down longer than 150ms and release it, it will register as a 2nd press due to bounce caused by opening button contacts. There's no need for separate resistors since we enable internal pull-ups in the Raspberry Pi for the Bn_LOGIC lines.

I've been kicking around an idea for an ESP8266 board with fewer buttons.

The C2 filter capacitor is specified by part number C3216JB1E476M160AC is flagged by the manfucaturer "Not for use in new designs".

For a ceramic capacitor of that high of a voltage/capacitance it seems that its a pretty niche part.

Sticking in a 1206 footprint it appears that one can go as high as 33µF when sticking to 12v or 47µF if the voltage can drop to 10v.

Are there any suggestions for replacement parts?

Background

The intention behind J5 was to have two input pins to support a 3-position switch using software-configurable pullups (B5 and B6). After initial investigation for outputs (called L* in schematic), we determined that physical pin 7 was pulled HIGH on boot, and didn't want relays accidentally triggering before the Python code could start. The four pins we use that are pulled HIGH in default device tree, we included a stronger pulldown resistor, regardless of whether they were intended for input or output.

The problem

The stronger hardware pulldown in tag:v1.0 (R5, 1k) fights with the software pullup (guessing about 5.6k), resulting in a max 0.5V which is still considered LOW. Looking at the physical boards, this could have been a problem as early as tag:v0.3, but the pulldown was only 10k in my locally-built v0.3 and v0.4 boards.

Resolution

Desolder R5

The software uses the RPi.GPIO module to access the GPIOs. This module seems unmaintained, the last release 0.7.1 was on Feb 2022.

One known issue is that this module uses a deprecated sysfs interface which has been removed in the latest version of Raspberry Pi OS.

This is causing the code to not work anymore on that version, due to RuntimeError: Failed to add edge detection, when the code tries to register an event-driven handler for GPIO changes through that deprecated sysfs interface.

It seems like this interface has been deprecated since 2015 and is undergoing a slow death since then. We should migrate away from it ASAP.

Today, it is still possible to do an installation by selecting the "Legacy" version of the OS, but, at some point, these changes will trickle down to the Legacy version, and then the code will not work anymore on any supported OS version, which will introduce a variety of difficulties for the users, from security vulnerabilities to the unavailability of repositories.

As such, the project needs to start migrating to another GPIO library, or to access the GPIOs in a different way.

One possible option is to use the gpio-key dtoverlay (which will create input devices for each key), and gpio-led dtoverlay (which will create a kernel-level, sysfs-accessible LED device). These options are well supported and modern, but require some changes in the code. Unclear how the buzzer should be accessed, maybe through the audremap dtoverlay (this requires a PCB change and a BOM change, but would allow playing sounds directly instead of just being able to beep).

Another option is to use gpiod, but the dtoverlay approach seems more elegant and flexible.

Either way, this needs to start soon, before users are locked out of using the code in currently supported distributions.

The purpose of this issue is to track progress in this area.

Since starting this board, we've moved most of our effort/libraries/automation to kicad. We should convert the board to make it more easily to make changes an export the BOM.

This would basically be a no-buttons script that activates an electronic strikeplate

Similar to older PC cases, we should evaluate a way to provide feedback to the Raspberry PI to know if the case it is in has been opened. At the same time, this largely predicates other things like:

• constant power
• stable storage

Similarly the "right" way to do this in the world of distributed systems is more along the lines of endpoint monitoring so that you know if/when the endpoint goes offline.

Thoughts?

Filing this to assign to myself:

Commit new docs describing support for Carvey, Nomad, and Tormach CNC mills.

I just discovered this: https://github.com/INTI-CMNB/KiBot

It's definitely overkill since we're not making PCB changes on the regular. It would just be cool to automatically generate "hardware releases". Another benefit of an automated process could be visual diffs of schematics and layout for pull requests that modify the PCB.

Ideally with an out of band control channel like unix domain socket or inotify-watching a file.

As Python 2 is still on schedule for deprecation on January 1st, 2020 (and we are approximately 6 months away from that date) community users will need to upgrade to Python 3.

The first version of Raspbian released (Wheezy) contained Python 2.7 which simplifies the process quite a bit. As Raspbian Buster is still defaulting to Python 2 (despite it's release just a few days ago) there is likely value in using the mechanisms provided by future.

Let's capture a list of TODOs and run through any proposals around the work, to capture a way for community collaboration (if there is interest).

One other change that I think is worth making: In authbox/__init__.py we have logic to replace RPi.GPIO on the import path with a fake if the real one is missing. But if you try running unit tests outside of venv, on Raspbian, and with Python2, then the real GPIO is already installed by default and it prevents unit tests from working.

Now that tests are in their own module, I think authbox/tests/__init__.py should instead do the fake RPi.GPIO replacement unconditionally.

A higher level design question though is how do we want to handle this kind of dependency injection going forward? We're doing it globally for GPIO, but via __init__() for fake queue/timer. We could also have each unit test patch the module under test.

Originally posted by @thvortex in #36 (comment)

This issue was automatically created by Allstar.

Security Policy Violation
Project is out of compliance with Binary Artifacts policy: binaries present in source code

Rule Description
Binary Artifacts are an increased security risk in your repository. Binary artifacts cannot be reviewed, allowing the introduction of possibly obsolete or maliciously subverted executables. For more information see the Security Scorecards Documentation for Binary Artifacts.

Remediation Steps
To remediate, remove the generated executable artifacts from the repository.

Artifacts Found

• hardware/pi-hat-1/ms_auth_breakout-cache.lib
• hardware/pi-hat-1/ms_auth_breakout.lib

Additional Information
This policy is drawn from Security Scorecards, which is a tool that scores a project's adherence to security best practices. You may wish to run a Scorecards scan directly on this repository for more details.

Allstar has been installed on all Google managed GitHub orgs. Policies are gradually being rolled out and enforced by the GOSST and OSPO teams. Learn more at http://go/allstar

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Filing this to assign to myself:

Planning to update README.md with a more representative photo of the Authbox, more context around the design decisions, links to related projects like FATT, and optional part numbers for ordering complete kits from a manufacturer.