USB mp3 player

[the fat bastid]

Last update: 3/12/18 - hardware (this is all getting out of hand. i may rework these posts.)
I'll be using this post as a workspace/starch pad/think out loud space for this project. It won't be coherent/helpful for awhile and probably shouldn't even be read by a regular human or attempted in any way yet.

Difficulty (from easy to hard): Harder than I think it will be.
Do I know what i'm doing (from doofus to expert): uh...kinda?
Estimated time to completion: 1 year after the earth crashes into the sun.
Expected frustration abandonment rate: 40%

I want the ability to plug in a usb stick and play music files.

My cd changer broke a long time ago. The cartridge stopped latching. Instead of fixing it I got the audiophile headunit. 6cd+mp3? good enough to entertain me for a long time. The mp3 decoder chip that oems use has gotten better over time but ours is still temperamental. Things like burn speed, media type, bit rate, etc etc can all cause a file to not play. I burned a cd for the first time in years for my car. Works fine in my computer but about half don't play in the car. Blah, I'm tired of this. I want more formats, more songs and less physical media (i've had cds get skips while IN the car.)

p.i.e adapters and the like will add an aux port but that is only controllable by the device that is plugged into it. Headunit control seems to have been worked out by the audio companies for the next generation of headunts like this:
but for us we are s.o.l (the connectors on the back seem to be physically the same but it is just too damn big to fit.) Turns out the difference is that the federal mandate to switch to CAN BUS took effect in 2008. Our cars use the odb2 spec (96-07)

Why not just buy an aftermarket headunit?
This should be cheaper than any touch screen double din head unit. As long as I count my time as worthless, haha.
I like knowing exactly what i'm hooking up. Don't waste money on features I don't use.
In the future I can change things exactly as I like. (like adding a new audio codec to the computer).
I don't want to lose the steering controls/sub/amp or have them half work or have to add any extra hardware to get them back. I've done the full aftermarket system in the past and just don't feel like fooling around with harnesses or splicing or running wire.

So I'm thinking I'll hook up a small computer to the cd changer plug in the trunk. One of the main things to figure out is how to interpret the signals coming from the headunit. Let's take a look at the connector. (thanks to andrew hammond)

+-+ +---------+ +-+
| 1 2 3 4 5 6 |
| [] [] [] [] [] |
| |
| 7 8 9 10 11 12 |
| [] [] [] [] [] [] |
+-------------------+

Pin Function
1 ACP + (called "audio network" on the ford schematic)
2 ACP Shield (treated as a n/c on schematic)
3 GND (ground)
4 n/c
5 Audio Left + (called "cd left sig in")
6 Audio Right + (called "cd right sig in")

7 ACP - (called "audio network" )
8 CDENABLE (called "audio system on")
9 +12V Power (unfused)
10 Audio Shield
11 Audio Left - (called "cd left sig out")
12 Audio Right - (called cd right sig out")

A note about the schematics. I got the 2004 marauder audio and the 2007 premium audio mercury mariner schematics from mitchell. This project is working off the marauder stock headunit because the mariner one does not show the aux input at all since (i guess) nothing is hooked up to it by default. Could the pinout be the same and work the same? I can't say. The main connector is also wired differently on the non-speaker outputs, i'm surprised it works for our car. Maybe I'm looking at the wrong thing? I'll attach them both when I can.

This should save about 6 pounds.

After pulling down the overhead console for an unrelated project, I broke 2 of the clips that hole it up. I never want to pull it down again so while I'm here i'll upgrade the limited 2 digit display to something more robust. (it will eveuntally connect to the raspberry pi to display info like mpg,tire pressure, etc) I just picked up a 2004 console.
The display window is the same size so i figure i could swap the lcd inthe housing and rig up some chips to control it. I was wrong. The 2003 2 digit is 83x22 but the 2004 dot matrix display is 100x35. the display sits back a little from the window to fit in there. The problem is that i can't use the 2003. the 2003 housing is what holds the lamp/mode/lamp buttons. I really don't want to fab up buttons that will look like ****. I'd like that oem look.

in the meantime, I've asked samsung for a pinout for the scg-80s16a (the 2004 dot matrix lcd). if they don't get back to me, i may be screwed. it seems to use a motorola mc908az60acfu as a controller. It has 16 pixel height.
The lcd from the 2003 is a futaba 2-bt-92gn. they did not respond to an e-mail. Both devices are probably custom made for ford which makes it harder to track down specs. It seems to use a ucq5812epf as a controller.


Both lcds are VFDs (Vacuum Fluorescent Displays) but the replacement will a oled of the same color (a light blue) so it should appear the same.

Build order:
1) bench supply. I won't go into this but basiclly this: link
2) Overhead lcd. lcd+audrino+bluetooth connector. then i put my overhead console back up.
3) actual mp3 thing

I'm starting to mull the rest of the system.
I was looking into amps to power the sub (a jl 6.5 in the stock box which was heat gunned a bit.). I was unhappy with the offerings of class-d amps. Then I noticed that texas instruments released a brand new chip that looks to be the best class-d chip currently being made. new enough that no current amp design would have it. But i don't know **** about about making a pcb. By serendipity, one of thier example projects to show off the chip is a car amp! amazing! So I ordered some chip samples and even had 5 pcbs made. These ran more expensive than I wanted but it is a 4 layer 2oz copper pcb that is about 8x8 inches, so pretty high end stuff. I only need 2 so if anyone wants to buy 1,2, or 3 of the other ones they would be $70 each, yikes!
I talked with the creators of the pcb and there are a few changes to the docs right now. (they will update them soon but as of now the november dated stuff needs this)
"We found that the Input Clip detector was preventing the Fault pins of the TPA devices from reporting correctly so we removed the R58 resistors. The pullup of 12V on R7 is also wrong, it should be 5V, this 5V can be taken from nearby on the board with a small blue wire. The line on the schematic that reads:
“C39/R41 and C40 not populated (Input C)" should also be corrected to say: “C39/R42 and C40 not populated (Input C)""

The amp and its specs are here. The chip can be changed with any of the other 44 pin ones.
One thing that still needs to be worked out is the shell/heatsink that it needs to sit in.
A few years ago there was an amp that cost thousands and sounded great. people figured out it was powered by a $10 chip.

These amps have no eq or crossover built so i need something to handle that. I'm also looking for something to do time delay. these 3 functions can be handled by one thing called a digital signal processor. Lots of car sound companies make these but then i noticed that minidsp has one for the car based on an analog devices chip. I bet most of the audioson, audio control, jl, etc are all based on one of those chips. I doubt they are developing their own ICs for these things. If they can do it, could i? I'm more hesitant to do this on my own because the day of turning knobs is over. These modern dsps are all configured via software. AD's come with their sigma software but may be too dense for me to understand and is used for product development. Also, the array of ICs offered are confusingly and/or ambiguously named. Not every company calls them dsp.

The signal coming to the dsp will be digital to avoid interference. Why convert digital to analog to digital back to analog? I think spidif coax is better than glass here just because of how rough a car can be on things. so the digital signal is one wire instead of many that can run all the way to trunk, the dsp, then the dsp's rca can be just an inch or two into the amps, then the speaker wire runs back. since the voltage is higher on the speaker wire it should be less susceptible to interference than the low voltage rca signal.

I may move the pi to be the headunit or just build my current plan then upgrade from there. not sure yet. There should be enough room to stick a 7 inch lcd in the dashboard with a little room on the side for ports. we'll see. not sure what i want to do yet.

Just realized that the CDE line is acutally a switched line that is car on/off and NOT a 'radio is on?' line

[the fat bastid]

hardware description and build will go here.

List of crap needed: (incomplete)

1. male connector ( to connect to the cd harness). Tyco electronics 174051-2 series AMP multilock 040. http://www.te.com/usa-en/product-174051-2.html
2. rs485 transceiver. MAX3485. The 3.3v version of the 485 to use with the pi. https://www.maximintegrated.com/en/p...s/MAX3485.html.
3. Computer. raspberry pi (the brain) https://www.raspberrypi.org/products...-pi-3-model-b/
4. LM7805. voltage regulator to drop the car's 12v to 5v to power the pi. https://www.fairchildsemi.com/pf/Lm/LM7805.html
5. A 220 uF and 1 uF filter capacitor, electrolytic for the 7805.
6. ti-ua78m33ckcs. voltage regulator to drop the 10v (from cde) to 3.3v to power the reset switch and turn the pi off when the radio is on/off. http://www.mouser.com/ProductDetail/...rDG1C6LA%3D%3D
7. 0.33uF and 0.1uF cap for the ua78m33ckcs
8. relay to flick the reset switch so the pi can turn on when CDE goes hot.
9. 2 pin header for p6 (the run header)

Things needed:
not sure what relay to use or the best way to flick it off (and relay circuit? just and gates? spdt switch?). Might get lucky, the pi may not mind if it is jumped all the time. will test when it gets here.
the grounds need some resistors that i can't remember.
should double check all those cap numbers

will upload my terrible schematic when i can. If this goes we will replace the onboard sound with DAC for the best quality possible from the pi.

a 2 pin header most be soldered on to the run jumper. This jumper can power on the pi from standby. the pi doesn't truly power off when shutdown is run. it goes into standby. This jumper can also reset the pi so be careful. this is a hard power off and not the way to power down (can cause sd corruption)

looks like the answer to the power questions may be to add another chip into the equation as a watchdog. The ATtiny85 uses much less power than the pi in standby and can wrangle the CDE and power correctly.
It can be programed to jump the run header so a relay may not be needed there.

Since the CDE line is not a power signal i don't really need a voltage regulator on that line. the same could be achieved with a simple resistor divider but i already had the regulator.

So the first thing to be built is the overhead console (which i'm not sure will fit yet until it arrives). Here is the current wiring diagram. The main problem is that the voltage from harness is totally unknown at this point. I need to test it and figure out how to regulate it, if necessary. there are 4 wires, one of witch is switched.

Finished the bench power supply. This will allow me to power and test things in house instead of out in the car.


An important note for the BT module. The hc-05 and hc-06 are physically the same but the hc-06 has a limited instruction set and can only work in slave mode. Normally this would be fine but I want the ability to program the micro via bluetooth since it will be inaccessible in the overhead console. This can only be done with a hc-05. A hc-06 can be flashed into a hc-05 but i don't feel like building a lpt to sci cable and trying to find/build a computer with a lpt port (or buy the expensive usb2spi converter). the hc-05 is only $7ish so it isn't worth much fiddling time instead of just buying one. Anyone want to buy a hc-06?

prelim building of the lcd circuit complete. It currently displays gibberish because i think the timing isn't right.


Ok, after fooling around with the timing port registers, etc. the lcd is now working. Not only that, but i hooked up the bluetooth module to it and can send data to it from my phone and it will display on the lcd.
Next i need to think about how to handle the sending of variables. then setup the bluetooth link to the pi. then set the bluetooth mod so i can program the aurdino if i ever need to (to add more features or fix bugs, whatever) without pulling the console done. The trick here is to have the bluetooth module reset the arduino using its led pin.

One thing i was thinking about was how to to control the diplay from the car. The mode button will be rewired but i realized that I could use the homelink buttons too. I don't have a garage so those buttons have never been pressed. I took out the module and opened it up. Turns out circuit board is just held in by two tabs at the back. press those down and slide it out. A stripboard I have alllllmost fits perfectly. I should be able to shave down the sides a hair to have it fit. I'll have to chop off the front a so the holes line up. then i can solder on some microswitches and run the wires out power connector slot and into the Micro.
When the buttons are pressed the micro will send a signal to pi who will feed back the new information to display.
I'll have 4 buttons to control the display now. I'm thinking on/off, change info left, change into right, and set display hold/alternate.


so here it is finished. I had to sand down the bottom to make it thiner as well as the width. The corner is broken off because i was hacksawing it while not supporting the bottom. the button holes in the case didn't align up exactly with the board holes so that is why the buttons are a little off, there is some leeway here as the plunger that pushes them is rather big. The terrible solder job is because I first tried using a surface mount led that was so tiny i couldn't tell anode/cathode. of course it was in backwards and blew out one of the switches (it got crunchy) so i had to rewire a large portion of it around damaged areas, etc. the led HAS to be in that spot (which also caused *****y wiring) because the clear 'transport' contact to the little house light connects there, in between two of the buttons. I used a 3 pole, 2 color one i got from a monitor. the middle button flashes green, the other two do amber. I wish i had them the other other way but, eh, it works, don't want to rock the boat of this fine craftsmanship. I was thinking of adding a speaker to make the buttons 'boop' but i decided against it.

This is acutally wrong and doesn't work right. I'll post the new button setup eveuntally.

Here is the updated wiring diagram.

the 4 buttons are the 3 homelink and the lamp button. they are wired to go from high to low when pressed.

The wiring harness that connects to the compass has the following pins: +12v switched, ?????, ~+9v switched, GND, NC, NC.
The harness on the homelink is +12v PERMANENT if needed.
I wish an illumination line was up here.
the 3.3 regular on the hc05 rx is line is becuase on mine, the breakout board the trace goes right to the module. That does NOT work on a 5v voltage. "VCC, voltage supply for logic, the standard voltage is 3.3V, and can work
at 3.0-4.2V" This could be a voltage divider but i happen to have extra regulators.

At first i wanted to put all the components into the compass case. I now see that this is difficult for a few reasons. My solution is to make individual modules that will be mounted around the inside of the ohc. there is plenty of room overall. There is going to be SO MANY wires. haha

after blowing up a few regulators the correct pin out seems to be:
1,2,3,4,5,6
12,gnd,9,?,nc,nc

the clearance on the homelink buttons and the compass buttons is different. the compass button is much smaller. I had to shave the button down a bit and move it around to get it to work. Eventually i gave up and ordered some samples from e-switch. much better.

the ohc is agonizingly close to being finished. problems with the button logic with the led is maddening. (need some diodes to make the logic work right)
I'm thinking about running a dim line up to the ohc. From there i can connect to an analog pin on the micro, then the micro can read it and send the correct command to the lcd.

I connected the dim line with a voltage divider (4.7k and 3.3k). works fine. the display doesn't get very dim but that is because it is an oled. it is isn't own backlight.



So there it is. It is scrolling some dummy information. It won't do anything useful until I tell the raspberry pi to send it useful information (which it will take from various sources like the mp3 player, compass ic, bluetooth odb scanner,etc)

After some fiddling with button controls i consider the hardware for the ohc done. here is the parts list:

overhead console information center
.33uf cap
.1uf cap
3.3 regulator
audrino micro
bluetooth serial hc-05
oled nhd-0216cw-ab3
micro switches x4
wires
zip ties
4.7k ohm resistor
3.3k ohm resistor
10k ohm resistor x2
stripboard
total is about $60, could be as low as like $45 if shopped around.
The 2 10k resistors are there because 2 pins had their internal pull ups blown out so i need to add one manually.

whoops not tottaly done. waiting for some pins to repin the stock connector to use that isntead of direct running wires down the a pillar

[the fat bastid]

Hardware post continues (it is full):
I pinned the connectors and ran the 6 wires across the front of the headliner and pushed them in, then down the a-pillar into the area above the e-brake. Then I pined the usb ends to connect a regular usb connection so i can still program the arduino with a laptop. One thing about the dimmer is i attached it to the orange/black line from the light switch. this seems to be the 'lights that only come on at night, dimmer controlled" while this is fine, I think the light blue/red may be 'always on and dimmer controlled when lights on' i'll have to investigate this more.

One other thing is my car has the old problem of lights on gauge flicker. My lcd brightness dances a lot. It uses an analog read of 1024 steps to report the voltage. when off it will read 0-2. which is fine. However it will spike to 100+ here and there, and thus flicker, exactly like the lights. In an old thread the solution was to run a ground to G102 (which is under the passenger kick panel) I may try attaching a wire from the light switch ground to g102 and hope for the best. Otherwise, I'll have to rewrite the dimmer code to ignore sudden spikes.

I spun up som obd2 pcbs for the elm scanner. All thanks to this guy's work
https://github.com/Spartelfant/ELM327-BT



I attached the unused digital 13 to the old light on off line for my boost gauge. then told to arduino to act accordingly. I attached the boost guage and fuel pressure lights to the dimmer line and ground coming down the A-pillar. the only problem now is that the lights won't come on if the ohc isn't there but that shouldn't be that often haha.
Now that I did the triple gauge pillar there is SO MANY wires jammed behind there and the dimmer switch. I also added a regullator from 12 to 5v for the arduino digital 13.
I had to take down the ohc because the display stopped working. one of the little plastic nubs crushed a cap. Seems to be working fine now and i'll put it back up but first i'll use it to see if the gps data gets there correctly.


I've finished assemblying the obd2 scanner. I had thought it would be a right angle connector but it is not. So it will hang down instead of hanging out. it should be ok. What may bigger problem is size of the project case. It fits fine but has a lot of room above it so that mean the connector and leds will be sunken down quite a bit. I'll see how things look once cut out. I may raise the connectors and leds or maybe extend a plastic 'light rail' for the leds.

I used a elm327L chip which is not pin compatible with the elm327 (pin 6 is not baud rate) so I think I blew up the chip. Waiting for new regular one.
I slapped in a new chip and I was still having problems. I tested the hc-06 in loopback and it was only sending. Turns out that when I flipped the connector I raised a pad and broke the connection. A quick solder fix. After that it started working fine!

I started building the power control unit for the pi next. The idea here is to use a ATtiny85 as a watchdog on the CDENABLE line. It uses almost no power so it can be on all the time. when CDE goes high (aka the radio is now on) it will all the main power line on the pi to go high.

First thing to do was program the attiny85 mcu. There are a few different ways to do this but I find the easiest is to use an arduino uno like so:


Next build the circuit:

and


Notice anything wrong? If you said you can't blow 3 amps through a 2n3906 you are right! Those little transistors are rated for like 300mA at best. So then i got some mosfets...but a mosfet needs a higher gate V then S-D V to start it. since both are 5v and not the needed 7-8v, ugh. So now some digital mosfets are in the mail!

So i finally got it to work, i replaced the venerable lm7805 with a lm1084 and the 2n3906 with a bd912. allowing for up to 5 amps. also, the bd912 is setup with the 3906 in a darlington configuration so the current flow will trigger correctly.

While this now technically works, it will overheat pretty damn fast. The regulator has to dissipate (14.4-5)*5 watts at the worst. For a heatsink to be that size it would need to be like a 10x10 square of fins. Just too damn big and counter to the design goals. So, the solution here is to switch out the linear regulator with a SMPS (switch mode power supply). Since these are much more efficient (about 80%) the heat should be much more manageable.

I finally built the amp:


It works great! However, after building I realized that the design doesn't have a remote turn on lead, which makes it unusable as a car amp since it would drain the battery. I'll have to either redeign the pcb or add an external relay or something from the cd changer's turn on lead. humm...

I have ordered a switching power supply for the pi brain as well as designed a pcb for it. the pcb will be the first one i've ever made. the chance for it working is probably low haha.

SOFTWARE

OHC
There are 4 buttons for the ohc. the mode button and the 3 homelink buttons. this is 16 total combinations of button combonations that could be mapped. Here is a list I have now:
the buttons generate 1,4,9, and 16. the total is used to decide what to do.

button - total - thing to do.
0000 - 0 - nothing pressed. do nothing
1000 - 1 - set info 1
0400 - 4 - hold display
1400 - 5 -
0090 - 9 - set info 2
1090 - 10 -
0490 - 13 -
1490 - 14 -
00016 - 16 - toggle display on/off
10016 - 17 -
04016 - 20 -
14016 - 21 -
00916 - 25 -
10916 - 26 -
04916 - 29 -
14916 - 30 - reset

What else could be done? if you have any ideas let me know!

While the ohc itself works fine, even reading the data on the pi works fine. however there is a problem with doing this in a script.
In python, ruby, perl, etc's serial module the flush buffer function just does not work. I ran across one vague post about some other software in the pi 'hanging onto' the bluetooth buffer. with no further information, I have no idea what to do about this.

Turns out the flush problem has to do with the time it takes to open the bt buffer. At first i had to add a 3.4 second delay after it was open to flush it. Disabling the wifi on the pi made the bt much quicker. Down to about 1 second which is as fast as it gets.

I decided I wanted real-time updates of whatever is being displayed. So that means we need to update the display 4 or 5 times a second (or so). This complicates things beuase the buffer on the arduino is only 64 bytes (but i swear it seems like 64 bits). I updated the hardware serial cpp file to get it to 256 which is the largest 'safe' value. This increase memory usage a lot, limiting program size.

Still, the buffer just totally fills up too damn fast. I need to make the updating smarter with what the pi sends to the arudino.

paying attention to timing is very important. I had a pretty big delay in the lcd displaying its info. this is what was causing a massive backlog in the buffer being not read. One thing that lowered it was to stop using slow native commands like clear display. Instead I just pad the display buffer if the string is too short. Another step was to cut down the latch delay from 1milisecond to 1 micro second. The timing in the datasheet shows the falling edge is only 400 nanoseconds so 1 millisecond was thousands of times slower!

Removing these delays fixed any buffer problems. I then added to the arduino to ask for data when it didn't have any and not to ask for stuff while it is has some. This means the buffer will never overflow again. However, when the micro is screaming for data 900 times a second, the pi will have trouble establishing a connection. So, we need some heartbeat code. The pi now says 'i'm alive' when it comes up then the micro starts asking for stuff. the only problem here is that if the micro goes down and comes back up it will just sit and wait for that heartbeat signal from the pi again which will never come. So, I need to send a special command to micro every so often so see if it is alive. While this is a norm for most projects I really wanted to have the micro just process incoming data with no need for a 'protocol'. oh well, that is why these things exist.

[the fat bastid]

(software continued)
Ford ACP
At first I had hoped it was a simple 'if this wire has any signal that means do something' but, alas, it is more complicated than that. Our cars use the Ford Audio Control Protocol (pin 1 and 7). This is a serial communications protocol based on the rs485 spec , kind of like the old rs232 (those old small 8 pin D ports on your computer that you never used).

Some specs about the protocol:
1 start bit
9 data bits
no parity
1 stop bit
9600 baud.
Standard UART stuff. We'll need a chip to translate the wire signal to the computer. Something similar to the max485 will be used and hooked up to a raspberry pi.

Communication (from andrew hammonds)

* a delay of 1642us (16 Bit times) will indicate a start of new message

* the 9th bit in a byte must be set in the last byte of message to indicate
the end of message

* Acknowledge is given with 0x06

Byte 0 – Medium/Priority, should be 0x71

Byte 1 – Changer functional address, should be 0x9A or 0x9B

Byte 2 – Head unit address, 0x80 on receive, 0x82 on transmit

Byte 3 – Command control byte

0xE0 – Handshake 1, byte 4 should be 0x04
0xFC – Handshake 2, byte 4 must be the same for transmit and receive
0xC8 – Handshake 3, byte 4 must be the same for transmit and receive
9xFF – Current disc status in byte 4

Byte 4 – 0x00 Disk OK
Byte 4 – 0x01 No disc in current slot
Byte 4 – 0x02 No disc at all
Byte 4 – 0x03 Check current disk
Byte 4 – 0x04 Check all disc

0xC2 and 0xD0 – Change or request current disc

Byte 1 – 0x9A – command to change disc
Byte 1 – not 0x9A – request current disc
Byte 4 – disc number

0xC1 – Control command

Byte 4

Bit 0 – Fast search
Bit 1
Bit 3
Bit 4 – change Random status
Bit 5 – change Loudness status
Bit 6 – change Play/Stop status
Bit 7

Send back byte 4 with actual mode

0xC3 – Next track

Byte 4 – Track number

0x43 – Previous track

Byte 4 – Track number

The last byte in all message is a checksum of all previous bytes. Simply add
all bytes of message to calculate the checksum.

Message examples

To display current play time, disc and track number:
Byte
0 1 2 3 4 5 6 7 8
0x71 0x9B 0x82 0xD0 Disc No Track No Minutes Seconds Checksum

No disc message:
Byte 0 1 2 3 4 5
0x71 0x9B 0x82 0xFF 0x01 Checksum
(/andy)

There is a problem here in that this is a 9 bit uart but the raspberry pi only supports 8 bit uart. now what?
More complications of course!


OBD
I'm using the library from here: https://github.com/brendan-w/python-OBD. It works pretty well. Be sure to use the async connection or it will hang the program.
Our cars protocol is:
SAE J1850 PWM (pulse-width modulation — 41.6 kbit/s, standard of the Ford Motor Company) (protocol 01)
pin 2: Bus+
pin 10: Bus–
High voltage is +5 V
Message length is restricted to 12 bytes, including CRC
Employs a multi-master arbitration scheme called 'Carrier Sense Multiple Access with Non-Destructive Arbitration' (CSMA/NDA)

Checking PID 00h and 20h shows the following PIDS are supported
PIDS_A: 101111111111111110111001100100 01
PIDS_B: 100000000000000000000000000000 00

00 PIDS_A Supported PIDs [01-20] bitarray
01 STATUS Status since DTCs cleared special
02 FREEZE_DTC DTC that triggered the freeze frame special While this one is labeled as not support, I'm pretty sure it only toggles on when a code is thrown. I'll need to test it.
03 FUEL_STATUS Fuel System Status (string, string)
04 ENGINE_LOAD Calculated Engine Load Unit.percent
05 COOLANT_TEMP Engine Coolant Temperature Unit.celsius
06 SHORT_FUEL_TRIM_1 Short Term Fuel Trim - Bank 1 Unit.percent
07 LONG_FUEL_TRIM_1 Long Term Fuel Trim - Bank 1 Unit.percent
08 SHORT_FUEL_TRIM_2 Short Term Fuel Trim - Bank 2 Unit.percent
09 LONG_FUEL_TRIM_2 Long Term Fuel Trim - Bank 2 Unit.percent
0A FUEL_PRESSURE Fuel Pressure Unit.kilopascal
0B INTAKE_PRESSURE Intake Manifold Pressure Unit.kilopascal
0C RPM Engine RPM Unit.rpm
0D SPEED Vehicle Speed Unit.kph
0E TIMING_ADVANCE Timing Advance Unit.degree
0F INTAKE_TEMP Intake Air Temp Unit.celsius
10 MAF Air Flow Rate (MAF) Unit.grams_per_second
11 THROTTLE_POS Throttle Position Unit.percent
12 AIR_STATUS Secondary Air Status string
13 O2_SENSORS O2 Sensors Present special
14 O2_B1S1 O2: Bank 1 - Sensor 1 Voltage Unit.volt
15 O2_B1S2 O2: Bank 1 - Sensor 2 Voltage Unit.volt
16 O2_B1S3 O2: Bank 1 - Sensor 3 Voltage Unit.volt
17 O2_B1S4 O2: Bank 1 - Sensor 4 Voltage Unit.volt
18 O2_B2S1 O2: Bank 2 - Sensor 1 Voltage Unit.volt
19 O2_B2S2 O2: Bank 2 - Sensor 2 Voltage Unit.volt
1A O2_B2S3 O2: Bank 2 - Sensor 3 Voltage Unit.volt
1B O2_B2S4 O2: Bank 2 - Sensor 4 Voltage Unit.volt
1C OBD_COMPLIANCE OBD Standards Compliance string
1D O2_SENSORS_ALT O2 Sensors Present (alternate) special
1E AUX_INPUT_STATUS Auxiliary input status (power take off) boolean
1F RUN_TIME Engine Run Time Unit.second
20 PIDS_B Supported PIDs [21-40] bitarray
21 DISTANCE_W_MIL Distance Traveled with MIL on Unit.kilometer
22 FUEL_RAIL_PRESSURE_VAC Fuel Rail Pressure (relative to vacuum) Unit.kilopascal
23 FUEL_RAIL_PRESSURE_DIRECT Fuel Rail Pressure (direct inject) Unit.kilopascal
24 O2_S1_WR_VOLTAGE 02 Sensor 1 WR Lambda Voltage Unit.volt
25 O2_S2_WR_VOLTAGE 02 Sensor 2 WR Lambda Voltage Unit.volt
26 O2_S3_WR_VOLTAGE 02 Sensor 3 WR Lambda Voltage Unit.volt
27 O2_S4_WR_VOLTAGE 02 Sensor 4 WR Lambda Voltage Unit.volt
28 O2_S5_WR_VOLTAGE 02 Sensor 5 WR Lambda Voltage Unit.volt
29 O2_S6_WR_VOLTAGE 02 Sensor 6 WR Lambda Voltage Unit.volt
2A O2_S7_WR_VOLTAGE 02 Sensor 7 WR Lambda Voltage Unit.volt
2B O2_S8_WR_VOLTAGE 02 Sensor 8 WR Lambda Voltage Unit.volt
2C COMMANDED_EGR Commanded EGR Unit.percent
2D EGR_ERROR EGR Error Unit.percent
2E EVAPORATIVE_PURGE Commanded Evaporative Purge Unit.percent
2F FUEL_LEVEL Fuel Level Input Unit.percent
30 WARMUPS_SINCE_DTC_CLEAR Number of warm-ups since codes cleared Unit.count
31 DISTANCE_SINCE_DTC_CLEAR Distance traveled since codes cleared Unit.kilometer
32 EVAP_VAPOR_PRESSURE Evaporative system vapor pressure Unit.pascal
33 BAROMETRIC_PRESSURE Barometric Pressure Unit.kilopascal
34 O2_S1_WR_CURRENT 02 Sensor 1 WR Lambda Current Unit.milliampere
35 O2_S2_WR_CURRENT 02 Sensor 2 WR Lambda Current Unit.milliampere
36 O2_S3_WR_CURRENT 02 Sensor 3 WR Lambda Current Unit.milliampere
37 O2_S4_WR_CURRENT 02 Sensor 4 WR Lambda Current Unit.milliampere
38 O2_S5_WR_CURRENT 02 Sensor 5 WR Lambda Current Unit.milliampere
39 O2_S6_WR_CURRENT 02 Sensor 6 WR Lambda Current Unit.milliampere
3A O2_S7_WR_CURRENT 02 Sensor 7 WR Lambda Current Unit.milliampere
3B O2_S8_WR_CURRENT 02 Sensor 8 WR Lambda Current Unit.milliampere
3C CATALYST_TEMP_B1S1 Catalyst Temperature: Bank 1 - Sensor 1 Unit.celsius
3D CATALYST_TEMP_B2S1 Catalyst Temperature: Bank 2 - Sensor 1 Unit.celsius
3E CATALYST_TEMP_B1S2 Catalyst Temperature: Bank 1 - Sensor 2 Unit.celsius
3F CATALYST_TEMP_B2S2 Catalyst Temperature: Bank 2 - Sensor 2 Unit.celsius
40 PIDS_C Supported PIDs [41-60] bitarray
PID check calls to PIDS_D through PIDS_G just throw out of range errors.

These are just the standard pids. Every manufactuer uses tons of non-standard PIDs. Something like FORscan can read them but I'm not sure how to yet.
My rear O2s are off so ymmv

Raspberry pi
Using a method called bit banging we can use this software pigpio to translate 8 to 9 bit. Playing with software serial communications is like eating glass. getting everything to sync up like this will be...fun.

the raspberry pi uses linux as it os. Instead of using hardware encoder chips we will offload the decoding work onto the OS. this will allow us to play nearly anything as long as their is software available on Linux that does the job.

The audio program we will use is mpd which will be fed commands from its command line (mpc). so we take the apc command, translate it to music command. done! Just that easy!


steps so far:
1) format micro sd card. if it is over 32gb you must use fat32format. The card must be in fat format.
2) Download pi's NOOBS image. copy the contents on to the card.
3) plug in mouse,kb, network, audio, hdmi, and finally power (5v 2amp micro usb)
4) install raspbian, install mpd, install mpc
5) copy music into mpds music dir, run mpc add all command (it is in the manual)
6) force audio through the jack (instead of hdmi) with raspi-config
7) mpc play 1 to test.

updated pigpio to 56. noobs has 50 by default.

First thing you need to do is get a micro sd card. There are differnet classifications and each size uses a slight different scheme. Be sure to check what they mean here. and what the PI likes here. I thought mine was too slow but then I checked the datasheet for it and it turns out to be fine. double check that!

I decided not to use archphile distro. I'll be working on this section now as I wait for other hardware bits to show up.

[the fat bastid]

Refrences:
The best site i can find for the orginal yampp stuff: http://www.mictronics.de/projects/cd...ocols/#FordACP
Then this guy ported the yampp code to audrino: http://www.instructables.com/id/Ford...-Arduino-Mega/
Then this guy used it build something similar to what we want (bluetooth instead of usb) http://www.instructables.com/id/Ford...e-with-stock-/

[Drewstang]

Did you ever complete this? I'm interested in using Pi for auto / video through a touch screen android unit to monitor the PCM data.

[the fat bastid]

Did you ever complete this? I'm interested in using Pi for auto / video through a touch screen android unit to monitor the PCM data.

Still banging away at it slowly. Right now I'm learning on the fly about building the power control unit. It is a process of "oh wait, this IC doesn't work exactly like i thought, I need to order this other one <wait like a month for it to show up from china>" rinse and repeat.

1) gps: hardware and software done
2) obd: hardware done. software not started
3) tpms: hardware done. software not started
4) ohc: hardware and software done.
5) power control: hardware being worked on
6) pi audio stuff: software not done.

This is all phase one. For phase 2 I want to replace the headunit with a touch screen and move the pi behind it, get a digital out to a DSP (was going to build one from a ADAU1452 but maybe buy a minidsp one) then into the pair of TPA3251 amps that I mentioned above. I really want to run FORscan as well but that is also for phase 2 because I can't parse the output into little 16 x2 blocks.

[Drewstang]

ForScan was going to be a top priority for me plus the increased audio storage. I was thinking a 100GB SSD USB drive behind the glovebox should be sufficient. I need to do some serious studying on the control board and what functions it can handle. Something that would allow you to press a key on the display and lower or raise all windows at once would be cool.

[the fat bastid]

ForScan was going to be a top priority for me plus the increased audio storage. I was thinking a 100GB SSD USB drive behind the glovebox should be sufficient. I need to do some serious studying on the control board and what functions it can handle. Something that would allow you to press a key on the display and lower or raise all windows at once would be cool.

One problem that may crop up is that forscan is windows only. So the pi would need to run it under wine which will be a performance hit, i'm not even sure if it run it at all. Wine can be a bit picky about things. i think this is the first time i've ever wanted a windows program ported to linux and not the other way around haha.

unless the android touch unit would run it directly?

[Drewstang]

I'll have to do some research, but I was thinking the new PI 3 had a Windows OS (IoT or something) that was available. I don't know if its stable enough to run that app.