| Page Properties | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Centre Console
The Driver Controls Centre Console board is responsible for a few things including the handling of the physical button interface on the centre console, powering the Raspberry Pi responsible for the driver display, powering fans for rPi cooling, and toggling the BPS Indicator for the driver. The following sections will break down how each of the above tasks are implemented, and the rationale behind these design decisions.
Let's begin by addressing the buttons, how they're powered, and how the board handles them. The figure below is a photo of the buttons we are using in the car (19mm ones). These buttons have 5 exposed pins: LED +, LED -, Normally Open, Normally Closed, and Common. The LED +/- are used to power the LED rings surrounding the buttons - these LEDs are setup as outputs through a GPIO Expander going to a FET Driver responsible for sending the appropriate voltage to the LEDs to power them on. When a button press is detected, the firmware sends an I2C message to the IO Expander corresponding to the LED of the button pressed. The FET Driver inputs are normally pulled down; the IO Expander pulls up the pins on the FET Driver when a certain LED needs to be powered, and the DET Driver drives the LED output high to turn on the LED. The GPIO Expander was used because the controller board is already handling so many IOs like the button signals, display enable, fan enable, and a few other things. By using the IO Expander, we relieve the MCU from handling so many individual LEDs, and simply using an I2C bus to enable the LEDs. The FET Driver is used to provide the necessary voltage (~12V) to the LEDs.
The button signals themselves are handled in a very simple manner: like the diagram below states, the 19mm button uses the Common and Normally Open as the switching pins. The Common pins are grounded, and the Normally Open pins are filtered using an RC filter with fc = 1.5kHz and tr = 0.23ms. These filtered signals are passed to an Inverting Schmitt Trigger for a clean digital input to the Controller board. For rationale behind why the buttons are filtered this way, refer to Hardware 101.
Let's now address the rPi and how it works with the Centre Console board. First of all, the rPi required 5V supply, and since the board only has 12V from the car, and 3V3 from the Controller board, a 12V to 5V switching regulator is used. This regulator design was provided by TI. The regulator was tested given different load currents, and proved stable with minimal ripple - this is key for powering the rPi. The rPi can communicate with the controller board via UART, and the rx/tx pins are connected appropriately. The rPi is mounted on the Centre Console board using its appropriate 40-pin receptacle. Finally, the Centre Console board also houses a Real-Time-Clock chip along with a 32.786kHz Crystal that are responsible for providing time to the rPi when not connected to WiFi (This has not been fully tested, as there were some issues initializing an extra RTC on the Pi). This RTC uses I2C to communicate with the Pi.
The decision to place the Pi on this board makes sense since the 5V regulator can be placed on there and not on a separate board - this also made communication with the Pi easier since a Controller Board is already housed on the Centre Console.
Finally, using the same logic and electrical path as the button LEDs, the BPS LED is connected to this board, and turns on when commanded by the Pedal Board.
This board design is quite simple, as it involved solving a few simple tasks - handle the button signals, button LEDs, BPS LED, and host the rPi.