Display Hardware Rationale

Owned by Akshay Gaitonde
Last updated: Oct 16, 2024
2 min read

🌍 Overview

This is the hardware design of the display, including the panel as well as any graphics driving hardware associated with it.

 Problem statement

Controls must show the driver critical information relating to the state of the car (i.e. speed, backup video feed, BPS faults, etc.). Controls is also tasked with ensuring the driver has enough information for simple actions such as turning.

 Research insights

There are many different configurations for the display. We can drive the display using an external computing device such as a Raspberry Pi. We also have a choice of display panels, display size, and display interface.

 Solution hypothesis

The solution is successful if we are able to view pertinent data in readable formats (i.e. speed is displayed as decimal numbers, icons if used can be rendered, etc.).

 Design options - Graphics Driving Hardware

There are multiple ways we can display graphics. We want to have some nice graphics and a better time programming them than the previous design that utilized Nextion software. With that, we have 3 options.

 

Option 1 - Raspberry Pi Zero

Option 2 - Raspberry Pi 4/5

Option 3 - Custom board + display library

 

Option 1 - Raspberry Pi Zero

Option 2 - Raspberry Pi 4/5

Option 3 - Custom board + display library

Overview

Use an off the shelf device for running a graphical application and keep it small.

https://www.raspberrypi.com/products/raspberry-pi-zero/

Use an off the shelf device for running a graphical application but including some ports like Ethernet and full size USB.

https://www.cytron.io/p-raspberry-pi-4-model-b-2gb

Use the integrated graphics processing library and a controls board we design to drive graphics. [OLD DESIGN]

(i.e. Daybreak’s Nextion display)

Pros and cons

Low power

Cheaper

  • $15

Python/C development

  • slightly higher (15W)

  • $50

  • Included with display and we can integrate the graphics commands in the LSOM or a PSOM

  • No control over functionality implementation

  • We must design layout to fit what could be reasonably possible in library calls

Decision 1

  1. Option 1 - Raspberry Pi Zero

We prioritize compact circuitry as well as being able to develop in a more developer friendly environment.

 Design options - Display Panel Type

There are also multiple panel options we can consider. We want the ability to display graphics in color through a medium that is robust in light/dark environments, refreshes decently fast, consumes as little power as possible, and is cost effective.

 

Option 1 - IPS/LCD Panel

Option 2 - OLED Panel

Option 3 - TN Panel

 

Option 1 - IPS/LCD Panel

Option 2 - OLED Panel

Option 3 - TN Panel

Overview

LCD panels are commonly used in industrial and consumer electronics applications because they have pretty solid color accuracy, viewing angle allowance, and brightness.

OLED panels are more common in artistic environments and gaming because they have the best color accuracy and vividness as well as good viewing angle ranges.

TN panels are falling out of favor because even though they typically update the fastest, they have much worse colors, brightness, and viewing angle range.

Pros and cons

  • ~$50-150

  • Bad clarity in direct sunlight but may work with an anti-glare coating

  • ~ 2-10W for <10”

  • ~ 10-20W for 10-15”

  • ~ $200+

  • Risk of image burn in over time

  • ~ 3-15W for <10”

  • ~ 15-30W for 10-15”

  • ~ $30-100

  • ~ 2-8W for <10”

  • ~ 8-15W for 10-15”

Decision 2

  1. Option 1 - IPS/LCD Display

We want a display that can be viewed from multiple angles while prioritizing the power efficiency. IPS/LCD offer a compromise between the two.

​  Design options - Display Communication Interface

There are multiple ways we can communicate with the display from the graphics driving hardware. We want an interface that is reasonably implementable (meaning we could make it or buy it easily), is suitable for video streaming, and is manageable to wire.

 

Option 1 - HDMI

Option 2 - UART

Option 3 - SPI

 

Option 1 - HDMI

Option 2 - UART

Option 3 - SPI

Overview

HDMI is used for monitors, TVs, and other video media. It is a proprietary protocol that transmits video and audio (depending on the HDMI version). This protocol specifically is optimized for streaming audio/video feeds.

UART is a simple protocol for asynchronous serial communication. It's widely implemented (it only uses a few IO pins). It also is what we already use with our current leader board and display. [OLD DESIGN]

SPI is a common communication protocol used in embedded systems. The protocol allows for one controlling device (the master) to send data over short distances to several receiving devices (the slaves).

Pros and cons

  • If a device has a HDMI port, it will have HDMI drivers

  • We likely will not need this feature for our display but it would be nice to future-proof the design in case we later decide to get a larger display with a higher resolution

  • Raspberry pi zero has 1x miniHDMI

  • Raspberry pi 4 has 1x HDMI

  • Raspberry pi 5 has 2x HDMI

  • Many programmable displays exist that take commands over UART

  • Not intended for video; better for data transmission

  • Not suitable for higher resolutions

  • Not good at transmitting a continuous stream; better at short data packets

  • Signal degradation varies per situation, depends on surrounding noise, cable length, and sheilding

  • up to 10s of MHz

  • 1 or 2 B per packet

  • Signal degradation varies per situation, depends on surrounding noise, cable length, and sheilding

Decision 3

  1. Option 1 - HDMI

We want something simple and robust. In the past, we have had issues with SPI, so we used UART in Daybreak (2023-24 car). However, wiring one HDMI would be even better, especially if we use a device like a raspberry pi to drive our display interface graphics.

 Design options - Panel Configuration

We can have many different sizes and configurations for our display. This decision is motivated by what things we want to specifically include on the display(s). We have 3 options motivated by how we want to compartmentalize certain graphics, namely video feeds.

 

Option 1 - Long boi display

Option 2 - iPad size display

Option 3 - Multiple sizes

Option 4 - Small boi display

 

Option 1 - Long boi display

Option 2 - iPad size display

Option 3 - Multiple sizes

Option 4 - Small boi display

Overview

This allows us to display everything on one horizontal line. It essentially extends the current display size only horizontally. (i.e. 1300x400)

This allows us even more screen real estate to display everything. It’s what you would expect an infotainment screen to be at minimum size (7”-12” diagonal).

This allows us to compartmentalize video feeds into different screens. We could use our current display architecture for displaying important data like speed, battery voltage, etc. and have other displays for each video feed.

Use the same or similar small boi display that we already have. This is optimal to only include important information and have different screens in software for additional views. [OLD DESIGN]

Theoretical Display Layout

image-20241013-020257.png
image-20241013-021118.png

Pros and cons

  • ~ 8-10W

  • Can make information bigger (for driver visibility) or add more information (for driver information)

  • Either case leads to more flexibility in design which is good

  • 10+ W

  • We can reuse layout of 1 main display with car information and another with the rear view camera feed

  • Peripheral cam feed is an add-on if we choose to have peripheral cameras

  • If we want 2 or 3 displays, we need a raspberry pi with at least 2-3 ports; only the r pi 5 has 2 ports

  • We can reuse our 1 main display with car information and the existing rear camera system

  • If we change the display for the sake of HDMI, we might as well rethink the size & configuration (there are better options)

 

Potential Candidates

Decision 4 [NOT DECIDED YET!!]

We still have not decided on the final display yet. Options are linked above. We are currently deciding between the pad displays and the long boi.

 

Akshay Preference:

https://www.bhphotovideo.com/c/product/1828414-REG/lilliput_719_c_7_1000_nits_non_touch.html/specs

Justification:

  • 1000 nits is pretty nice

  • it accepts 9-36V power (so 12V works well for it)

  • consumes <8.5W (according to product page but I suspect that if we have the brightness at a reasonable level like 500-600 nits we can achieve this)

  • standard resolution and aspect ratio (shouldn’t be weird with R Pi )

  • $189 might be too much??

Confluence Documentation | Web Privacy Policy | Web Accessibility