[Android Head-Units] Tuatara:
Hey everyone ... sorry for the absence and for these late replies - I been very, very busy and haven't had a moment of time for myself. Just grabbing a breather now, to keep up some contact. :(

I've tried to get the TWRP builds to work on our device, but was unable to get them to work successfully. They would partially boot, but then fail and end up in a boot loop/boot lockup of sorts. I gave up, since I already had CWM working successfully and completely.

CWM uses swipe to select - up/down to move, left to select, right to cancel.

P.S> I've also got a 5002 with no buttons, so the swipe enabled CWM was critical for me as well.

---------- Post added at 06:33 PM ---------- Previous post was at 06:28 PM ----------

I know this is an old question, but I'm using an E1552 with my unit ... no issues after disabling the CD-ROM mode, and the other devices (keeping only modem). It boots up every time, reconnects fine (before the 2 hour shutdown), and has no issues with connectivity while driving around town or into the countryside. Loss of connection is also handled as normal. To set the device mode, it's a simple (AT) command to send to the device COM port. Using Putty it works fine. I had posted this information in a reply of mine for another Huawei modem a while back somewhere.

---------- Post added at 06:36 PM ---------- Previous post was at 06:33 PM ----------

There are some issues with the APN settings being retained across updates. You will need to reset the settings to default before you can adjust them again. It should automatically read them from the Modem/SIM card you're using anyways. Try the instructions in this link Reset APN

---------- Post added at 06:40 PM ---------- Previous post was at 06:36 PM ----------

1.1.4.2 has a known issue with unpacking (was also discovered by another user in the forums). The fix was released in a revised ROM - 1.1.4.3 is the one to use, and it has no issues being modified through the Factory Tool 4.4.

---------- Post added at 06:45 PM ---------- Previous post was at 06:40 PM ----------

I've also experienced the flickering a few times too, so I'm also aware of this issue. It is definitely some issue with the Thine chip (the HDMI over firewire link to the display). This issue is very transient, and comes and goes - but it is present and (somewhat) repeatable. I'm going to be experimenting with shorter cables and possibly with changing the impedance on the connection, as I think it is related to a clock synchronization issue - i.e. the dot clock loses sync, and the display can not handle the (damaged) data stream.

There is some interference due to the 3G stick I'm using though - the shielding is not perfect - especially for the firewire cable, and the head unit itself. I'm going to put the 3G stick on a USB extender (off a hub), and modify my stick to use an external antenna. I'll let you know if that solves the issues, or if it is something related to the cable or connection.

---------- Post added at 07:06 PM ---------- Previous post was at 06:45 PM ----------

The issue isn't in the ROM ... this is a problem in the configuration. I haven't changed anything in the ROM which could have affected the 3G network or APN settings.

If you ask Google - "android reset apn settings not saving" ... you'll see that this is a common issue, and it randomly affects users. Reset the APN settings, and then reboot your device. If you're on my ROM just use the Reboot App. When your device has booted again, it should either automatically have read the APN settings from the dongle, or it will allow you to enter them.

---------- Post added at 07:14 PM ---------- Previous post was at 07:06 PM ----------

Besides fixing the spelling of my name (alias), I will definitely get on to making a new ROM, with all of the changes migrated, as I'd made before. I'll also look into a way of adding easy (configurable) support for turning on/off the bottom bar (for those with hardware buttons), adding in the new apps with audio ducking support, and anything else which you recommend (PM me with the things I should address!!!).

I'm also still working on the design of my 'cheap & cheery' volume control, button control, USB and Resistive Wire interface board for controlling this headunit (or other head units). I've come up with some great parts I can use (digitally controlled resistors, rotary encoders, Atmel chip as the MCU, etc.) but I now need to order them and complete the design and build. I'll document everything I've done - but I'm just going to be making this on vero board - so anyone can then follow my design, and build it to suit their individual needs.

---------- Post added at 07:17 PM ---------- Previous post was at 07:14 PM ----------

I'll see if I can make my next ROM update work as an updateable ZIP. It'd be a good way of performing an in-place upgrade for the future (once you'd already fully flashed a re-partitioned ROM of mine - not sure what would happen with a mixed set of partitions, or if my ROM would then run out of space in the old partition sizes).

---------- Post added at 07:19 PM ---------- Previous post was at 07:17 PM ----------

Hay Zaphod - sorry ... truly sorry that I've been so out of contact. Just PM me, or send me an email (do you still have my contact details?) and I'll reply to you there for anything directly needed. Getting your ROM to be fully rooted OOB should be a straight-forward process. I'll see if I can spot the issue.

---------- Post added at 07:26 PM ---------- Previous post was at 07:19 PM ----------

The RDS functionality is in the MCU code. I believe that in the source code there are hooks for the RDS data, but AFAIK this has not yet been implemented. I've built a number of devices which process the RDS codes from the Silicon Labs chipsets, and have pulled out most of the RDS features you've listed above. Specifically AF, CT, PI, PS, PTY, and RT. I never implemented the traffic support, as often they're not even provided by stations, or the updates aren't useful and are far too late - especially since we have Google and Maps. :D

Hopefully the RDS development is proceeding and we will get these features available sometime soon. Otherwise ... if I could get hold of the source code for the MCU ... :D

---------- Post added at 07:29 PM ---------- Previous post was at 07:26 PM ----------

The script is run EVERY TIME after the full system is available. The code I have in the script determines if CWM is already installed, and if the ViPER directories have been created. If you change this script, it will change in the next ROM. However, I'm thinking I will make the init.d system work AFTER BOOT, and not PRE BOOT as it does now. There is very, very little which would need to affect the system before it is fully running IMHO.

Wait for the next ROM build from me (coming soon) - 1.1.5, and your init.d method will work just fine.

---------- Post added at 07:34 PM ---------- Previous post was at 07:29 PM ----------

Most of my work and changes were in the system and configuration files. I will see if I can separate those out and post the changes to GitHub.

Similarly, I'll see what I can do about providing the ClockworkMod sources ... although a lot of those were taken from Oma and his builds, mostly extracted from a number of ROMs done by him - so it would be binaries and a lot of configuration files again. I'll try to do that soon, so that everyone can see the changes which were made in the ROMs I made.

---------- Post added at 07:43 PM ---------- Previous post was at 07:34 PM ----------

Overlay capability on the video in signals is not possible in the current hardware. There is no means for the Android device to digitize the incoming video, and there is no means to overlay another video signal on top.

I bought 3 of these cameras (one rear, front left, and front right). DealExtreme. They are completely metal, good connectors, and have a nice overlay (3 segments - green, yellow red), and are well designed. The video quality is perfect on our units, and the night vision/visibility is excellent - especially considering how cheap they are. I have had no issues with water-tightness on them (yet). My two front mounted ones are still 'reversed video' and have the overlay on them ... but I'm hopefully going to have the time soon to open them up and figure out how to remove the overlays and flip the video (it should only require cutting two traces to the video chip). Once I have that solved, I'll document that process for anyone else who wants front (nose) mounted cameras.