Volty MIR - Progress

Trying out several approaches to the DIY in-car display.

Previous posts

Volty MIR - Overview
Volty MIR - Android automation
Volty MIR - Installing the rear camera

Approach #1: The original plan

The original plan was to have two switchable video sources for the in-car display: an Android device with the map, and a video feed from the rear camera.

Get the LCD

For the display, I thrifted a digital picture frame.

I initially liked the frame for its 16:9 ratio, which matches the smartphone I planned to use. It appears that the LCD is somewhat-standard part that was common in portable DVD players. With an analog input a whopping 480x234 resolution, it sounds terrible, but looks decent for the camera and just good enough for the smartphone if using PAL encoding (PAL looks sharper while NTSC has much worse horizontal smearing)

Build the display

To mount the LCD in the car, I designed and 3D-printed an enclosure for it.

Power, power switch, and video inputs are in the back, and a brighness control dial is on the side.

It's a rather janky build. The print took many hours and warped. I melted the internals of the power switch I intended to use while soldering onto it, so I had to improvise with another scrap switch that could fit into the opening. power and video plugs are not hole-mount types, so they are "reinforced" by silicone. (This is where I also learned that silicone has an expiration date)

Brightness control was added afterwards. Luckily, one 1K potentiometer was enough to turn brightness from full to comfortable-at-night.

Show maps

Maps will be served by my old Android smartphone.

See Android automation post for details.

Since the display video input is only analog, HDMI output from MHL has to be converted to analog too, and the resulting setup is somewhat ridiculous:

[Smartphone]--USB---[MHL dongle]---HDMI---[HDMI-to-Analog]---RCA---[Display]

But it works pretty well.

Side note: Some Android G1 models sold in Europe and Asia were capable of analog video output through the 3.5mm jack.

Mount the display

Display mounted in the car, on the flat portion of the dash in front of the driver.

The way it is mounted is the reverse of the usual magnetic mount + sticky metal plate on the device. Here, the metal plate is stuck to the dash, and the magnets are in the bottom of the display. It's not a very good solution, and eventually, the metal plate detached itself along with the display. If this was a final version of the display, I might have considered to glue it onto the dash.

Switch the inputs

To switch the display between the rear camera and the map, I could use a simple two-contact Reed switch, which is operated by a magnetic field. The idea was to add a small magnet to the shifter, and to mount the Reed switch in a way such that shifting to R would switch the video signal to the rear camera. So I designed and printed this tightly-fitting enclosure.

I had some issues with the Reed switch triggering too soon (or the magnet being too strong), but it should work.

Of course, there is a more "proper" or "hardware" way to check if car is in reverse, which is to open up a specific fuse panel (or a wire connector?) on the passenger side, where a wire outputs 12V for the reverse lamp when driver shifts to R.

Or, if I want to go manual, I could use this old-school switch.

I just wanted to solder something in an Altoids box :)

Results

This is alright.

What I like:

• Location: Place in front of the driver is sufficiently flat (for purposes of modeling and 3D-printing), but still reachable if needed.
• Display size: Just large enough to not be obstructive.
• Display aspect ratio: Matches that of the smartphone and the camera.

Potential improvements for this:

• Improve the enclosure for better mounting and fit to the car.
• Bundle all of the wires into a single multi-pin connector.
• Route the power and brightness (and possibly other controls) somewhere more reachable.
• Make brightness automatic. A circuit using a photoresistor and an adjustable potentiometer? Or just put it on the Arduino with the rest of the controls.
• Map provider (smartphone) can be upgraded to any other device capable of producing analog video.

Issue(s) I see with this setup:

• The premise of using a fully-capable Android device to project to a low-resolution non-interactive display is somewhat self-defeating. I know this is what I planned with modularity in mind, but seeing the map of the streets without being able to zoom, scroll, or recenter the map would be frustrating. My initial idea is to connect a keyboard to the Android device, but since it already has an MHL dongle on its USB port, I would have to resort to bluetooth, with its own issues. I do have a bluetooth keyboard I could salvage though.

Approach #2: iPad

Another old device I had laying around was iPad 2 (WiFi version), so I thought I could try to make that into an in-car display, too. (I specifically wanted to upcycle something I already had) But that did not work out as well as I had hoped.

The plan

• Mount the iPad to the central console, (partially) covering the built-in display.
• Install navigation software that works.
• Automate the software to wake (or power on) and launch a navigation app when the car is turned on, and go to sleep (or power off) when the car is turned off.
• Feed the video from reverse camera into the iPad and display it somehow.

Compared to the above setup with an Android device and a display, there are some advantages:

• Interactive - This would not be just projecting a screen, I could interact with the app(s).
• Single device - no need for additional cables, converters, etc. for projecting the screen.
• Larger screen.
• Better battery life. Not that it matters much.

Mount the iPad

The iPad fits rather nicely onto the central console:

But since the built-in screen is covered, there's the minor inconvenience of being unable to see the radio station, or fully configure A/C.

Navigation Software

This was quite an adventure into jailbreaking, downgrading, and sketchy tools. There are only a handful of navigation apps that still work on old iOS versions.

Usable map and navigation apps for old iOS versions

As of right now, the iPad runs iOS 6.1.3 and uses CoPilot GPS. This required jailbreaking and some fixes to make the App Store usable again. Right after I installed many of the apps I needed, Apple shut down the App Store for iOS 6. (It is back up now) Instead of being on the cutting edge of technology, I am on the blunt back edge.

GPS

This caught me by surprise. Since my version of iPad 2 is WiFi-only, it does not have a GPS chip. While at home, it happily showed my correct location (derived from known WiFi access points), so I paid no attention since most other devices that I had were phones with built-in GPS chips. But when I tried the iPad out on the road, it was clear there is no GPS chip.

I bought a cheap used bluetooth GPS module, hoping to use that. However, using a bluetooth device as a GPS source on iOS requires a jailbreak, and BTStack GPS, an app from Cydia. But this is a paid app, and Cydia's purchases have been broken for years. I tried looking for workarounds and "fixes", but did not find any.

After some more searching, I found out about high-accuracy BadElf GPS modules, first models of which had a 30-pin "dock" connector for early iPhones and iPads. All of their plug-in devices have been discontinued, but by sheer luck, I found the one I need on eBay. Combined with their official app, the GPS location works pretty well.

Automation

The Activator app from Cydia is very flexible, allowing to map almost any action to an event. What I set up:

• On power connected (car turns on): wake, unlock the lock screen, launch BadElf app (to wake/enable the GPS module), then launch Copilot GPS app for navigation.
• On power disconnected (car turns off): simulate pressing the power button, putting the iPad into sleep.
• Swiping on the status bar increases or decreases the brightness.

External Input

iPad obviously does not have external GPIO or any intentional way to read external input (from another circuit for example), but I was able to hack together an external on/off trigger using the phone jack and Activator's events for connecting and disconnecting headphones. The way headphone detection works in this iPad is checking if two contacts on the opposite sides on the phone jack are closed (connected by a conducting material). Building a "plug" out of two parallel, non-connected wires allows me to short these two wires using an external circuit to trigger an event within the iPad.

More details in this post.

The intent is to use an external trigger (gear shifter in R position) to trigger the iPad to display the feed from the rear camera.

Video Input

Since I want to use the in-car device to see the video feed from the rear camera, I need to find a way to get the video stream into the iPad. After lots of searching, it appears that none of the older iOS devices are capable of accepting video input. Only very recent versions of iOS are capable of using USB cameras (or capture devices). And, as far as I understand, microphone hardware is not fast enough to be able to sample the video signal (KHz for audio vs MHz required for video). An idea is to use a cheap WiFi camera, but for the one that I have, the app is available only for iOS 9, which, on the iPad 2, is very slow, and does not have a permanent jailbreak.

So I had a very naive idea to point the iPad's back camera at a small LCD showing the reverse camera feed, figuring that the already-low resolution of composite video cannot be made much worse by viewing it through another camera.

I took a small LCD (with analog video input) that I had laying around, and built a small enclosure for it.

Then I spent some time measuring, designing and 3D-printing a contraption for the iPad that would align its rear camera and the LCD.

It's quite a monstrosity, but it does what it was built to.

I had low expectations, and the result was still very disappointing. The composite signal from a rear camera (with brightness-contrast balanced by the camera), is shown on a small, low-resolution LCD, which is viewed by iPad's camera (which attempts to balance brightness-contrast again) at a distance of ~80mm results in a blurry, either washed-out or very dark picture, with LCD's pixels still visible. Tapping the screen to refocus the iPad camera could either make everything too bright or too dim.

Oh well. At least I got some experience printing with ASA and printing large flat items with ABS.

Results

Well...

What I like:

• Single device with a single cord coming out of it. BadElf GPS module has a micro-USB port on it for charging, so that can be hidden away.
• Good screen size.

What I don't like:

• iPad obscures the car's center console screen. This can be somewhat adjusted with a specially printed bracket.
• There are no easy ways to feed video into the iPad.
• Navigation software works, but needs a license, which I cannot even purchase.

Now What?

Getting video into the iPad is a pain. So what else could I try?

Take both ideas

Use the iPad for navigation and the analog display for rear camera. How many screens and devices do I need in a car though?

Non-invasive way

Try a non-invasive way of displaying the rear camera feed. As an example, iPad could use VNC to connect to or VLC to stream from a Raspberry Pi, which uses a USB capture card to receive the composite signal from the rear camera. Although, this is an overkill. Maybe something like this can be implemented on an ESP32, too. Automating this using Activator might be difficult.

Dumb terminal

Use the iPad as the interface to control a Raspberry Pi via VNC. However, all VNC clients that I tried on iOS6 have issues. Additionally, rear camera video quality and delay will be terrible over VNC.

Invasive way

Open up the iPad, and switch the LVDS display connector between the original source (the iPad) and an external driver (which is connected to the rear camera). This depends on whether the LCD is designed to handle such "hot plug" actions.

Another invasive way

Open up the iPad, remove one of the cameras, and instead, feed the camera pins video using the protocol it expects (maybe it's MIPI like Raspberry Pi camera uses?). Yeah, crazy. I don't know if anyone has ever done anything similar.

One Android device

Following the idea with the iPad, use a more modern Android device that can stream video from a USB camera. Use something similar to a capture device to take the video from the rear camera and present itself as a USB camera so the Android device can display it. To charge the Android device while it is using the USB camera, use a powered USB hub. This will also allow easier addition of external keyboard for controls.