[Android Head-Units] Tuatara:
I think you're right - it probably is a resistive system. RF communications devices are often basic FM modulation circuits (like remote controlled cars), which are based on a connect/break (forward/reverse) or resistive (steering) input. This remote (does it use a battery when in FM mode - i.e. not wired up?) would internally use a resistive ladder to 'change' the FM signal to the Parrot head unit. When the cable is connected, it appears to only have two contacts and a locking pin (i.e. no power, and disconnect the internal FM circuitry), which could only then be a resistive ladder.

I'm certain this would be easy to get to work ... but you're basically buying the remote to get a 'plastic shell' for the buttons and a few resistors. I'm going to build one of these myself (using an Atmel MCU, digitally controlled resistor, rotary encoder (with push), joystick input, and a few buttons/switches. I'll make a design which works over USB (any key press) and resistive (MCU resistive ladder controls).

Current parts list I'm considering (all through-hole, so anyone would be able to build):

ATTINY861A-PU, 8 bit AVR Microcontroller 20MHz 512 B, 8 kB Flash, 512 B RAM, I2C 20-Pin PDIP - NZ$3.72

MCP4161-502E/P, Digital Potentiometer 5kΩ 257-Position Linear Serial-SPI 8-Pin PDIP - NZ$1.64

Joystick Switch, 2 axes, 0.05 A@ 12 V dc Through Hole 12V dc - NZ$1.95

Bourns 24 Pulse Incremental Mechanical Rotary Encoder with a 6 mm Flat Shaft (Not Indexed), Through Hole - NZ$1.81

The trick would be then the "decoration" to make it look good. Like Zaphod and UI graphical elements, I'm an engineer, so I'll just cannibalize some other device for appropriate covers. :D

Plans for something are underway!

---------- Post added at 11:12 AM ---------- Previous post was at 11:04 AM ----------

Hey Zaphod ... for now, it's the only way we can refer to it on the forums (like Tuatara's ROM - all I did was hack the binary and make ClockWorkMod possible ... I actually wrote very little in the way of source code). Don't take offence with that recognition! :D

That was just a 'drive-by' thought I had while making the material-themed backgrounds. It's definitely grown on me too. All in favour?

---------- Post added at 11:17 AM ---------- Previous post was at 11:12 AM ----------

Awesome! And you build it from source? :D I (necessarily) used Oma's Rockchip binary for the current ClockworkMod. Did you get all the mounts working properly? That was the issue I ran into when using other Rockchip builds ... mine would boot, but go no further.

---------- Post added at 11:22 AM ---------- Previous post was at 11:17 AM ----------

I've thought about this, and looked into the issue a bit. The Rockchip recovery sequence uses the misc.img to store information as to what operation to perform in recovery. If we can use this information - i.e. read it - check if update.zip exists, if so - run the original recovery, if not then run the TWRP/CWM recovery. The two recoveries "should" be able to co-exist with a switching script running the actual application(s). That way, there is no special action needed ... original recovery runs on first boot (after flash), TWRP then runs normaly thereafter - unless there is an update.zip, at which point the original recovery runs instead. Should be possible/practical.

---------- Post added at 11:27 AM ---------- Previous post was at 11:22 AM ----------

Just hook it up to the reversing lights! The camera doesn't use any significant power (i.e. to affect the lights/dim them), and the +12V signal from the lights to the head unit input uses no power. As long as the switching is (reasonably) clean (no spikes) ... you can just wire it up directly without any problems. Low-tech, reliable, and easy to do.

When we're done with it, everyone should want one. :D