Third iteration of the portal project (see white_box).
As a starting point, the layout of @dop3j0e's Atmega32u4 breakout/development board v2 will be used. The rest of the curcuitry will be designed around it. This has the benefit of not having to design the tiny circuitry around the smt chip again.
The step from perfboard to PCB also has the benefit of having a clean circuit instead of some sort of constant construction site.
As experience showed, the possibility of the AP or the portalchip crashing is high. Right now, this is solved via a complete power reset so the AP and the chip reboot.
Since this is somehow problematic, when the shackspace is closed and someone tries to open the door from outside. When one of the devices crashes, said person has almost no possibility of rebooting the portal since it is mounted inside.
To solve this, a third device will be used to monitor the AP and the portalchip and powercycle the system if one of them goes down. The AP will send keepalives over serial to the portalchip. The portalchip will toggle a pin every x seconds if it receives the keepalives from the AP. If one of the two devices fail, the watchdog chip will just cut the powersupply via a relay and the whole system will reboot.
The shutdown-mon project team is building a device that monitors some parameters of the space and interrupts the shutdown (read: doorclose) process and alarms about the wrong parameter. To do so, the shutdown-mon needs an interface to the portal to be able to know if a shutdown has been initiated. Also there is a plan for building a Display that shows some information about the shutdown-mon and the portal. For this purpose, all devices will get a CAN-Interface. The benefits are that multiple devices can be on a single bus and communicate with each other.
Right now there is a buzzer in the portal which makes some noise to signal a status. It does so by beeping at different intervals/lengths. hadez wanted the possibility to produce different melodies for the different states to make the states more recognizable.
The AP is able of sending commands to the portalchip e.g. to open/close the door. But it has no command frame to transfer the name of the keyholder. Also there is no frame for the keepalive.
These frames need to be implemented.
The AP-DB just consists of a field for the member name, one for the members cryptokey and one for the expiration date of the dataset. A field for the name of the member needs to be added to the DB in ordner to be able to display the name on a display.