New head unit with wifi reception?

I'm now starting to think of "cool stuff" I can do with a full blown android head unit. Imagine slapping on an arduino and a batch of relays... you could drop the 4WD ECU, and reimplement it in software, with feedback display for the sensor states (for example, sometimes the 4wd light goes into blinking mode, so it would be possible to output the ACTUAL state of the sensors to know where it is jammed up!). Proper control over 2H, 4H, 4L, 2L <-- yeah, that is a thing if you want it to be, by leaving the ADD disconnected when the transfer case is in 4L.

 

Update after second day of commuting....

So I ripped out the kenwood microphone and replaced it with the microphone that it came with. Phone calls are now working correctly, the other side hears me, and claims it to be clear. One thing to note with the call audio; the other party can be heard exclusively from the FRONT-RIGHT speaker -- not balanced or distributed at all. It all comes out of one speaker. Now thing is, while on the surface it has a "bug" feeling to it, since a phone receiver is MONO, thus just sends one audio channel, it is apparently *by design*. Something about reverberations being picked up by the microphone and feeding that to the other party to the call. Ok, sounds like a weird excuse, but whatever. At least I can hear the other party well enough so I'm ok with that.

I also plugged in a USB camera. This is where things start to get a little bit hairy. The camera itself works very well, the image I see on the LCD is very crisp and clear, excellent contrast, etc. This is the camera I'm using;

$52 ELP 5mp HD USB Camera Module for Computer Mini UVC USB2.0 Video Embedded Webcam Board with 2.8mm Lens OV5640 Laser Engraver Lightburn Camera,3.3ft/1m Cable for PC, Laptop, Jetson Nano

https://www.amazon.com/ELP-Megapixel-Camera-Module-2-8mm/dp/B01GHNSG8G -- the only thing with this is that it is not quite as wide of an angle as I'd like. I may step up to the 170 degree lens. BUT, the angle of the lens isn't what makes it hairy. What makes it hairy, is the impact that recording has on the head unit's performance. It basically pulls it to its knees, which makes it basically useless.

HOWEVER, there really are only two things that could cause this effect, both of which can be mitigated through software. Before you ask, no, I haven't actually checked to see what exactly they are doing wrong.
1) If they are doing something really stupid, like software transcoding. This will put an enormous load on the CPU, which frankly, is unnecessary. The video stream from the camera should be muxed straight into an mkv or mp4 file without transcoding.
2) The recording program does NOT appear to have any way to adjust WHERE the data is being stored, so even though I stuck in an sdcard, the video data is being stored to the eMMC. This means that storage performance will be negatively impacted to some degree, depending on the characteristics of the actual eMMC chip, and how they are using it.

One other complaint I have about their "DVR" program, is that it can't be configured to automatically start background recording when the head unit powers up.

Once again, of course all of this can be fixed with a better recording program, and since this is ANDROID, which allows you to install other software, or even write and install your own software, this can be fixed. I was just hoping to get away with not having to do any actual hard work.

What I would really like to achieve with this, is an automatic looping video recording to the sdcard, to an mkv file, with a gps logging track.


EDIT: There seem to be a good number of dashcam applications in play store. Maybe one of them will do the job properly.

The description on "DailyRoads Voyager" seems to fit the bill. I'm going to try out the ad-supported free version and see how it goes.

Another edit: https://github.com/encryptix/DashCam -- open source !
Another open source: https://github.com/dhodge229/AgilCam-Android
The second one looks like it may be a better starting point, but it appears to be doing some transcoding.

 

Hey @hazard2600 : I looked again at the camera you ordered, wondering if maybe the load the camera puts on the system might be related to the camera itself. I was looking for something along the lines of an h264 encoder integrated in the unit. Mine, I think, just does mjpeg or raw. So it could be that the head unit is demanding h264 from Android, which the camera can't supply, thus forcing a software transcode. In any case, there is no indication on the product page if yours does h264, in fact, it indicates video format as YUV, which basically means RAW (uncompressed). If memory serves, YUV at 720p will probably cap out at about 10 FPS on USB2.0. Aside from that, I did see one hilarious claim; "Angle: 360^". LOL. It can see backwards? HAHAHAHA.

 

Yeah, I saw that. Isn't it amazing?! lol
It was cheap. so I figured at least it's "their recommendation". so if there are any issues, they can help out. I'm trying to block out some time to get it all installed. Right now I've got multiple home renovations going on that is taking most of my time. Once that's all done though, I'm going to get this all installed.

Cheers on the write ups! It's not often I find people more technically savvy than me lol

 

You are talking to a computer engineer with an overblown case of "I'm going to do everything myself". According to my wife, when I'm about to work on the house, the first thing I'll do is take the chainsaw into the forest and cut down a few trees, then haul them to my little saw mill and cut them up into lumber.

I *really* wanted to do a design and build from the ground up on a head unit. I picked a dragonboard 410c as a brain, and designed a nice addon board for it with some audio and power control ICs, SPI-to-USB converters, stuff like that. I even have a few samples of the finished boards printed and sitting on my work bench.... but just don't have the time to work on it lately (2 boys under 3, and a home reno project to finish up before the market crashes so we can ditch this place and upgrade). So broke down and went with the China head unit.

I did another test with the video recording using dailyroads voyager. That program allowed me to control the video settings and storage destination, so I tried out a whole bunch of different options. The storage location had basically no impact on performance, which means that we are NOT dealing with a storage bandwidth limitation. Changing the video resolution DID have a significant impact on performance. Higher resolution = lower performance. That very strongly implies software video encoding. What I did notice with dailyroads, is that it allowed 3 choices of video encoding --- h264, h263, and mpeg4. The important thing to make note of, is that my camera cannot output ANY of those formats, which means that transcoding is *DEFINITELY* being performed. I've been trying to dig through the Android camera access APIs to see if I could somehow grab the raw video, but I'm starting to think that this may not be possible. I'm seeing descriptions in the process along the lines of extracting the video to a virtual surface, and feeding that virtual surface into a media encoder. Most mainstream Android devices have dedicated hardware video encoding accelerators.

I may need to go at this from a different angle, which is to bypass the Android APIs for the video recording. I know I can build ffmpeg to run on Android, which can access the Linux v4l2 device directly from devfs and perform a simple stream copy to a file. So this may be the best option. It certainly would have the lowest overhead of anything. I'm going to have to look at the permissions and selinux context of the video devices though, hopefully it will be possible to access them without root access. If it does require root, then I don't mind it that much, but it is a heck of a lot simpler to share the work without that extra step.

I think ffmpeg will definitely be the ticket here....
http://writingminds.github.io/ffmpeg-android-java/
^^ that has a sample application that lets you "run an ffmpeg command" and see the output of it. Great starting point!!!

ffmpeg also has an output segmenting option;
http://www.ffmpeg.org/ffmpeg-all.html#segment_002c-stream_005fsegment_002c-ssegment
Basically means that it can split the output file at specified intervals, for example, every 5 minutes. The nice thing about its segmenter, is that it won't just break the file hard at the specified time, but it will rather wait for the next I-frame and start it there. An I-frame is a "full" image, whereas other types of frames depend on the previous image and update it. So if you begin a video on anything besides an I-frame, it won't show properly until the next I-frame appears in the stream. So if you set the ffmpeg segmenter to split the file every 5 minutes, it might go for 5 minutes and 18 seconds, or some other value, depending on the frequency of I-frames in the source video file.

Now I just need to figure out about devicefs permissions, and see about including a GPS stream, maybe in the form of subtitles? Or I could just log the GPS stream separately and correlate them later on.

Edit: I'm not sure if the Android permission "android.permission.CAMERA" will add an application to the camera group or not, but I'm going to try that on the ffmpeg sample application and see if I can capture a stream like that. If it does work, then I just need to make a few adjustments to the sample application, like add a foreground recording service triggered by the activity, and store the command to repeat. Also capture a few intents to auto-start and stop recording when the head unit is powered on/off. Plus be nice to be able to record from multiple cameras simultaneously (add a second one pointing out the back in case of being rear-ended).

Seems that ffmpeg is able to add multiple video streams into a common mkv file. This is good news, but I'm a bit worried about how it will handle segmenting, since it is very unlikely that the i-frames will line up between the two. Hopefully, it will be smart enough to start the new file with the stream whose i-frame appears first, and continue with the old file until the second stream's i-frame appears, then switch it to the new file with an offset.

Edit 2: I should be able to hack GPS logging into the mkv file as a subtitle track. I'll have to log the GPS separately, and then join it in as a post-processing step.

 

So I finally have a few moments to open up my Joying package and I'm looking at all my parts in order to plan my installation. Somewhere I know you mentioned that you mounted your GPS to the top up your deck. But I can't find it. Can you show me a picture of your GPS antenna by chance? I'm not finding my GPS antenna in my package.

By the by, you are in Reno? What's up?! I grew up on the west side of the Sierra Nevadas on HWY 4 in a little town called Arnold (down Ebbet's Pass) and spent about 10 years between Carson and Reno thereafter. Nice to find a local resident!

 

I don't have a picture of mine, since its now inside my dash where I can't get a camera, but it looks very similar to this;
https://www.amazon.ca/RP-SMA-Active-Antenna-Connector-Adapter/dp/B00DQL6RWU

It measures roughly 1.5" X 2", and is magnetic.

Eh, aim east-north-east at a distance of around 3000 miles. There you will find me.


So I tried my little ffmpeg trick, and seems that there are *no* android permissions that translate into linux permissions. They are simply not related. That means that to accomplish this, I *will* have to do the root thing. Either run ffmpeg as a user with access to /dev/video*, or change the permissions on /dev/video* to allow the regular user to access it.

 

Haven't yet had a chance to do any of that, but did try to switch the antenna. Unfortunately, broke the end off the antenna mast since it was stuck into the base with too much corrosion. Now I have ZERO radio reception and a new mast on order. Hopefully that arrives very soon.

In case anybody needs to do an antenna base replacement, there is this writeup; https://www.tacomaworld.com/threads/how-to-replace-oem-antenna-in-fender.261341/
BUT, that writeup goes into excessive lengths to disassemble the fender. All you need to do to access the antenna base, is to remove the two black snaps from the inner fender closest to the antenna base, then you can just pull the plastic over and out of the way, exposing the antenna base. It is NOT necessary to remove the fender flare or the complete inner fender.

 

Ok, I pretty much have it figured out what needs to be done.
This post is mostly for my benefit -- taking notes, but could be interesting to others.
The selinux policy is tight enough to hold it all together, except for (a) vulnerability exploits on the very ancient kernel (3.0!!!), or (b) direct modification of the init ramdisk.

The recovery/updates don't enforce signature checking, so we can do this right, without exploiting vulnerabilities. I'll choose to make proper modification to the ramdisk.

The good news is that I am already very familiar with the selinux policy, and thankfully, china doesn't meddle with it too much. Its basically an AOSP userdebug policy, so policy alterations I've already written will apply to it.

This is the rockchip image repacker;
http://forum.xda-developers.com/showthread.php?t=2257331

Factory firmware for this unit can be found here;
http://forum.xda-developers.com/showpost.php?p=66556454&postcount=2

Code:

./imgrepackerrk dupdate.img
mv dupdate.img dupdate.img.orig
rm dupdate.img.dump/Image/*.krnl
cp dupdate.img.dump/Image/boot.img ./
./imgrepackerrk boot.img
rm boot.img
cd boot.img.dump
<apply filesystem and selinux policy modifications the usual way>
cd ..
./imgrepackerrk boot.img.cfg
cp boot.img dupdate.img.dump/Image/
./imgrepackerrk dupdate.img.dump

Now there will be a new dupdate.img file, copy to usb disk or sdcard and install on head unit the normal way.

Note: the *.krnl files are the files as extracted from the original dupdate.img, including several bytes of crc (cyclic redundancy check) to validate the file integrity during installation. The repacking process replaces them with newly generated crc's that match the modified images. This is why it is appropriate to delete them.

 

So here is the quick low down...My shipment was missing the GPS antenna and the external mic. They said they are shipping that out immediately. So once I get those, I can test out GPS and microphone.

I just took a few minutes and threw my unit in place. It's a sweet unit. definitely odd in that it is so light without the CD player. But slick. The interface is nice. I got Google Maps to work pretty easily. It took a few times, but I was able to tether my iphone to it. I was also able to tether my iPhone for internet connectivity. I was also able to get my phone to mirror onto it quite easily.

When I first wired up the JBL harness, the audio was WAY low. But there was another matching connector on the harness. So I just swapped that out and it seems to work fine after that. The only issue I have with audio now is that high pitch static hum from the engine for some reason. Not sure how to mitigate that yet. But when my other parts come in I'll open it all back up and see what I can do. And take some pics.

The mounting unit/face plate I bought fits okay. But the adapter that goes directly around the HU face to the outer plate doesn't fit. So I'm going to have to get a different one eventually.

The Bluetooth OBDii device they recommended keeps dropping it's connection and won't work with the app. But the app does allow for a wifi device (which I have). So I will try that one out.

More to come soon!

 

Car hum sucks. Mine does *not* exhibit that characteristic, but there are enough differences between your setup and mine that could potentially account for that. For instance, your truck is a little older than mine, so make sure that all of the negative cables are well connected between engine-body, body-battery, body-amp, etc. Yours also has a different engine than mine, so it could actually be producing a hum that mine isn't.

My *guess* is that the noise is being introduced somewhere between the head unit and your amplifier. Is there any choke on the power wires leading to the jbl adapter? This is typically recognizable as a plastic black box containing a fairly large coil and capacitor.

It is also possible that the noise *is* present on mine, but that the integrated amplifier just isn't big enough to amplify it to audible levels.

The way I would try to address this, is to first check all the negatives and make sure they are perfectly solid. If those all check out, I'd add chokes to all of the power running all of the audio components inside the dashboard.

If after that the noise is *still* present, I'd try to bypass the jbl/amplifier and feed the head unit out directly to the speakers. Unless I'm thinking of a different vehicle, I believe that the amplifier will be under the passenger seat.

Too tight or too loose? Mine (Metra) seemed to be too tight, so I forced it to stretch around the head unit. This turned out to be a *WONDERFUL* characteristic, because it holds the head unit VERY firmly in place rather than allowing it to shake around on bumps or when lugging.

There are definitely some bugs in the bluetooth stack, but it should be functional on the current system image. Check your settings/about menu for the build date, if its in JUNE, its current. I know that one glitch that manifests, is that the program (make sure you're using TORQUE and not something else for now) thinks that the bluetooth service is continually switching on and off. This is not an adapter problem, but a firmware bug that they should hopefully fix soon. TORQUE can be configured to ignore that. If I was in front of the unit now, I'd tell you what the exact menu setting for it is.



I was pretty busy last night, so didn't go fully into the root, but I did check on the status of a few things. One important thing to make note of, related to my previous post, is that while they ship the thing with a fairly "stock" selinux policy, it appears that selinux is actually **disabled**. Talk about taking the lazy way out of things. My feelings on this are mixed, on one hand, it means that the system is much more vulnerable to privilege elevation exploits. On the other hand, root is trivial to obtain. Just need to "chmod 6755 /system/xbin/su" for a bare bones and wide open root with absolutely no access control. I'll still, of course, rig up something stronger than that.

 

Thanks for this thread! Recently got the idea that I wanted an LCD unit and backup camera with a recent addition of a shell to my 06. I was looking at Apple Play, but I didn't really want to shell out out that much cash. This looks like a much better option with much more capability.Placed my order for a joying today.

Looks like you're getting close to figure out a camera fix. I will definitely employ that once you get it all worked out.

Thanks again!
M@

 

The BACKUP camera will work fine, right out of the box. You will need to pick up a regular old video camera with a yellow RCA plug.
I ordered one like this for mine;

$19 Pyle PLCM12 Rearview Backup Parking Assist Camera (Waterproof Night Vision Cam, Distance Scale Line Display, Flush Mount)

https://www.amazon.ca/gp/product/B00WR6ZRV2
Its sitting on my work bench waiting for me to find the time to install it.

The camera I don't quite have working the way I want it (because of aforementioned availability of time to work on it, and its a fairly easy fix...) is USB DASHCAM for recording of traffic evidence to an SDCARD. When I get this working correctly, I'm intending to install TWO USB dashcams, one stuck to the front edge of the rearview mirror recording out front, and one in the lower passenger side rear window recording out backwards. The one out the back won't be of any use for "reversing", but it will be able to record stupid crap that happens behind me while I'm driving.

Regarding the backup camera, the way I understand its functionality, is that it is implemented entirely OUTSIDE of Linux/Android.
If you opened up the head unit, what you would find, is a large circuit board sitting on the bottom of the steel box. There is a second, smaller circuit board, connected to the main circuit board by a socket. The smaller circuit board is the "computer". It has the SoC (CPU + GPU + etc.), RAM, Flash, and related components. This is what is actually running Android. The larger circuit board is a kind of an interfacing board. It has a bunch of chips on it that do things like sound signal processing, and video overlays.

One of the control wires on the head unit is an input signal for the REVERSE LIGHTS. When that signal is powered on, it connects the video input from the backup camera, and overlays it on the LCD. As I understand it, this should happen correctly even if Android is still booting up, which means that the backup camera will work immediately when you start the vehicle and throw it in reverse, rather than having to wait for the whole thing to boot up.

So for wiring this up, what I would do if I were you, is take the reverse lights signal, and use that both to feed the reverse signal into the head unit, AND the power for the camera.
But what I'm actually going to do, is tap in to the ACCESSORY line, and feed that to a switch. The switch will let me power the camera and video input on and off as desired rather than exclusively on the reverse signal. Basically, I dont need or care for an automatic backup camera, I just want the back facing camera to show for simplification of hitching up trailers -- I'm going to make sure it is oriented so that I can see the ball.

Edit: I just came up with two brilliant ideas;
1) Using a 3-position (ON-OFF-ON) DPDT switch. Put a diode on the accessory line between the "car harness" and the addons, accessory to common on the switch, camera signals on one side, and POWER on the other side. Flip the switch one way and it turns the camera on. Flip it the OTHER way, and it keeps the head unit powered on, even when the ignition switch is turned off. We can call that the "system update" or "drive-in-theater" position.

2) Oh, I could do some really awesome stuff with something like this; https://www.amazon.ca/uniquegoods-Channel-Opto-couple-Computer-Robotics/dp/B019IHNS9U or even better, something like this;

Cana Kit 4-Port USB Relay Controller with 6-Channel I/O Interface

https://www.amazon.com/CanaKit-UK1104-4-Channel-6-Channel-Interface/dp/B004JWW1GQ or

4 Channel Outputs ,4 optically Isolated Inputs USB Relay Module

https://www.amazon.ca/Channel-Outputs-optically-Isolated-Inputs/dp/B00MXS4TOA which has **input signals**.

 

Thanks for the details on the unit, definitely helps understand how everything works. Adding a "traffic cam" is something I've wanted to add. With our current litigious society I think everyone will being going the route of Russia with dash cam soon.

Before you posted about the "system update" or "drive-in-theater" idea, I had planned to run the back-up camera on an accessory powered switch as well the back up lights. Give me the option to power it on and use it via reverse signal seems like it would give me the most flexibility. I don't think I'd go beyond that with the input signals. I could see this turning into bigger project than I expected!

 

If you're going to be doing an either-or for feeding the reverse signal, either use a SPDT switch with "out" on common, or an SPST switch with a diode on the reverse lights supply circuit so that you don't feed it when you flip your switch on. My choice would be SPST+diode, since that would avoid the potential on-off-on cycle when flipping the switch if the vehicle is already in reverse, since an SPDT switch will have a moment of NC while flipping it from one position to the other.

 

@tgear.shead do you have a url to the mettra hu bracket you bought? I wanna make sure i buy the right one to replace the one i bought. Cheers bro

 

This would be the one I bought;
http://www.metraonline.com/part/95-8214TG

Note that I did NOT use their plastic mounting brackets though. I actually reused the factory steel mounting brackets. I *may* have drilled new holes in it back in 2011, or it may be a different vehicle I'm thinking of -- hard to remember trivial things I did 5 years back.

Note that the fit is *VERY TIGHT*. It doesn't look like it will fit, but when you force it, it does.

 

Definitely planning on SPST+diode. I really should have thought more about trying to make this happen in Texas in July/August.

 

That is the one I actually bought. There is no way it's going to fit mine they way it is. I'm going to have to use my heat gun a little and drill in new holes into the brackets. Hopefully that will resolve the issue.

On a good note, I found that I only get in-loop noise when I insert the radio into the dash. I added a supressor, which did help. But now I have to figure out how to either move the noise suppressor block or find some short of noise blocking sheet/separator. I don't think anyone makes that though.

 

I've already explained that (might have been in the other thread, which you also participated in). The proper name for such a shield is a FARADAY CAGE. You can make one with a piece of aluminum foil. You wrap the foil around everything that you want to protect from stray EM, and tie it to an electrical reference (in this case, chassis negative).