It's subject to debate and delicate, but maybe you experienced this situation yourself while driving a car. The driver of another car, just behind you, would kindly like to travel at a higher speed. On your side however, you apparently yet travel at the maximum legal speed.
An hypothesis is the speedometers of both cars don't agree. So why not showing in real time your actual traveling speed on the back of the car ?
To put the two electronic boards plus some wiring, I made a case that fits inside the rear cup holder. Conveniently there is a 12v plug just aside. I need 3 cables: the 12v, the connexion to the OBD plug in the front, and the connexion to the rear LCD. I re-purposed old Lemo 3 way plugs, a perfect fit.
To hold the LCD panels it appends I have a Sonic the hedgehog plush on the back of the car, why not try to mimic the power-up monitors of the video game ? I printed this enclosure in PETG because I had bad experience with PLA on direct sunlight. I tried to have an ajustable, stable and discreet design.
Originally I planed to use a wireless bluetooth link, it explains why I started and kept an ESP32. It's a bit overkill for the task, but there is nice libraries for plenty of devices. I used Platform.io on Visual Studio Code, with Arduino, for the development.
One interesting point here is the use of the 3 serial ports. One for the programming / debug, one to the ELM327, and one to the LCD screen.
I also add a little Oled display for debug and showing what speed is acquired.
To display the car speed I'd rather choose the most passive, simple technology while having a large digit size. It is out of question to use something that emits light.
E-paper could do the job, but large displays are pretty expensive, and I'm not sure if they can handle the rough condition of a car parked in sunlight or a freezing winter.
Electro-mechanic Flip display would be a good choice if only the big 7 segments units were not so expensive. Besides, I'm not sure the continuous flipping would be good for the display and the driver ears.
Fortunately we can still find good old fashion 7 segments LCD in large size. I yet use some of these panel on the BIG_CLOCK project. The biggest apparently are made by Lumex, the LCDS101D40TR. The character size is 10x7 cm.
Only two digit is relevant in my opinion. At a speed faster than 100Km/h, digits should be unreadable due to the safety distance. So we have to drive only 14 segments. The PIC16F19156 can drive them directly, without multiplexing.
The code simply take the received byte on the serial port and display its decimal value from 0 to 99.
I could use a GPS module to have the car speed, but I think there are two disadvantages. First, we loose it on tunnels, and second I'd like to show what I'm reading on my dashboard.
My first idea was to use a bluetooth OBD plug, and then connect to it with an ESP32. But I did not succeed because the OBD dongle I have uses classic bluetooth and not BLE. In addition I did not found a 12v power line on the trunk that is switching off once the ignition key removed. I don't want to drain flat the car battery.
So I re-purposed the cheap OBDII reader. Luckily it uses an ELM327 clone and the bluetooth module can be de-soldered. That saves me the code of the raw CAN-bus handling, the ELM327 uses simple serial AT style commands. And it saves me the design of the CAN-bus circuitry.