OK,
I'm getting hooked on this computor-car integration stuff. While I'm pulling of faceplates, poking wires etc to try to hook my steering wheel remote directly to my riocar I want to attempt to do the same with my Onstar. The first piece of advise I need...... is it possible. Let me give the facts as I know them:

When onstar is activated it sends a signal via a class II serial data circuit to the headunit (thru a single wire) to mute the headunit. The voice is then played thru the amplifier. I can easily wire the incoming sound to the riocar aux. inputs. What I'd like opinions on: Is there a possibility to wire a class II serial circuit (single wire) to the riocar's serial input and find the signal used to mute the audio.

(yes there are convertor boxes I can but which I can hook up to the mute and use mlord's new hack but I'm addicted)

There is a special 'cellphone mute' input wire on the RioCar docking sled wiring harness.

Read your RioCar manual to identify the correct wire (and its colour) and check that the signal output from the Onstar interface is either +12V when external circuit is 'on' and 0V when its not,
or
its 0v when its on, and +12V when its not.

Assuming the voltage is no more than +12V [and if its less it may still work - but you'd have to try it to find out],
then connect your Onstar signal wire to the Cellphone Mute input and with some luck, when the button codes screen in Hijack is active you should be able to see the 'fake' button code being generated by the kernel whenever your onstar system is in use and when its not.

Once you have the codes, then its a simple IR map to do whatever it is thats required
[pause the player, switch to Aux input, unpause the Aux input source etc].

[and when the phone is finished with, switch to player, and unpause].

Hope this helps.

Thanks number6. I'll try that.

Bob

Do you know if all signal wires take +12V? I was in particular wondering about the headlight signal.

Hopefully the shop manual (diagnostics section) will tell me the voltage. Yang, could you elaborate on what headlight signal your referring to. I'd be glad to look it up or try to put a voltmeter on it if I knew which one.

I believe he's speaking of the Orange cable on the empeg sled. Or the ACC as it's referred to by Pioneer.

Well I believe the 'Headlights' in use signal wire is what you're talking about.

Its used to tell the RioCar/Empeg to dim the display to the (preset) display brightness value previously selected.

Don't quote me on this, but I would be very surprised if the Headlight on signal wire and the Cellphone Mute signal wire are not using the same RS232 Transceiver chip inside the player (just different pins on the transceiver chip) to convert the incoming higher voltage (ie. the 0 to 12v+ signals to the lower 3.3v signals actually read and handled within the hardware in the Empeg.

If this is the case, then the Transceiver should handle over 12 volts - but how much more I wouldn't care to say [maybe up to 24V but I wouldn't like to test it to find out - could be expensive to get fixed if it didn't].

Thanks, I thought he was talking about the vehicle. (duh)Of course he's talking about the riocar. The dimmer circuit I'm pretty sure is +12v (99.9% sure). It works fine with my truck's dimmer circuit which is 12v.

The headlights on/in use signal wire is usually wired [in the vehicle] to the dashboard lights that light up when the headlights are on rather than wired to the headlights proper (if you catch my meaning).

This is mostly for the reason that the wiring is right there - well within 2 feet of the din slots where the tuner/headunits go - simply connect to the wires that light the dashboard up and theres your "headlights on" signal wire.

Unfortunately, in my truck there isn't easy access to the dash light wires.. I'll have to look again though.. For my Fog Light control, I actually ran a line off of the headlights to a relay to act as a master switch.. I'm thinking, if I can find a good source for the signal inside the dash, that it would work a bit better.

Yang, did you check to see if there is a headlight/dimmer wire that ran to your original headunit. Most stock hu's have such a wire to adjust the stereo with the dash lights.

Number6, I don't really understand serial circuits. Is it that a serial circuit remains hot all the time but sends signals via voltage or code to various devices or is it that the signal sent causes a serial circuit to become hot. If it is the second then if there are other devices using the circuit other than onstar won't this "confuse" the mute line of the riocar. I hope I asked this clearly enough.

The Isuzu Rodeo (which I have) has no signals in the factory stereo wires. 4 +/- speaker wires, +12VDC battery, +12VDC ignition, and ground. that's it..

With classic Serial circuits( like a serial port on a Pc and/or a modem etc) there are a bunch of control signals (up to 4 in and 5 out from memory) - which could be either on or off (i.e. 12 volts, or 0 volts) that were used for the sorts of complicated processing back in the days when we had dial telephones and the like, plus there are 1 or 2 'data' signal wires, which are where the data being communicated goes, in a on/off (serial) fashion at a certain frequency [baud rate] and in a specific format [parity, stop bits, # of bits, 5, 6 7 8 etc].


The headlight on/off and Cellphone mute inputs to the Empeg are treated as if they are Serial control signals (even though they are technically nothing to do with serial communications).

For historical reasons the devices that convert the 12 volts or more on/off to 'control signal on'/ 'control signal off' is called a RS232 Transceiver and they are generally pretty toughly designed to take all kinds of electrical conditions that would fry the average chip - which is why they are used to convert the voltages present in your cars electrical circuits for lights and cellphone mutes etc to to much lower voltages used inside the RioCars.

gotcha...thanx

So the ir translations will map it with a unique requirement which other devices on the serial line will not "set off". Am I getting it?

since you guys are talking about onstar can i hook up my fosgate amps to my stock deck with onstar most instalers are scared to do it.

I just read you original post again and theres something to be aware of.

while there is a single wire going to your headunit, it could be a simple on/off signal, or it could be a serial data signal.
The first is easy - its either on or off (0 or 12v etc as discussed).

If the wire sends a stream of pulses rather than changes to a on or off state, then you have a serial interface and that gets really really tricky.

I don't know anything much about onstar - heard about it years ago when it was first proposed and thats about it.

You should measure the signal with a digital multi-meter set to the DC volts measurement with the range of maximum of 20 volts or so. [connect the black lead to your cars ground./earth - i.e. a metal part of the car, and connect the red lead to your wire.

Read the voltage - is it 0, or 5 volts, or 12 volts?

Then test your onstar system - does the 'signal' on the head unit wire change state [voltage] and does it stay that way until you're finished with the call?

If so, provided the voltage is not much more than 12 volts [and probably more than about 3 volts] when its in a call then I think its a wire that the Mute input on the RioCar.

If it briefly changes voltage only, then thats a serial data stream of some sort and thats more complicated by a long chalk.

Yes, we could make a device that will 'decode' the signal stream sent to mute [and unmute presumably] the headunit, then turn it into the mute on/off signal to the empeg, but that requires someone to stick a 'scope on the signals and work out the signal format, bit rate etc.
But you'd need to find someone closer to you than I am.

Thanks number6, that's what I was wondering. The shop manual refers to it as a serial data cable and I believe this to send a stream of pulses. I went back and read about the onstar convertors that are sold and they contain a microprocessor. I think I may need to buy one of these. The convertor contains a mute signal I can attach to the riocar mute line.

Oh well

If you are not planning on using onstar I don't think there is a real problem. Be aware, however, that some new amps have complex hookups that aid the headunit in controlling rearseat audio and maybe other functions. These functions might be lost with a new amp. What kind of vehicle do you have thrasher?

Again, not affiliated with this company, but this may be necessary for onstar to work...

http://store.clubgp.com/itemview.asp?itemid=60

I want OnStar in my car :<

Yes you're right, when you're dealing with this of kit you're best to pay the extra $$ and get the professional convertor.

However, in the meantime, you can still go ahead with the Mute input to Empeg stuff - I'd attach a small on/off switch between your cars (empegs) +12v source and the cellphone mute - that way you can 'simulate' a incoming call simply by flipping the switch on - that lets you get the empeg side sorted - which will take a little doing, and then when your convertor arrives you can then wire it in, instead of the switch.

But until the convertor arrives you'd only have to flip the switch to be able to tell the empeg to switch to Cell phone mode, and when its unflipped, the empeg would be able to resume normal programming as it were.

You may decide that thats enough to be going on with and not bother with the convertor at all [or at least postpone it until you want it].

Does the Onstar system trigger the cellphone mute on outgoing calls too or only on incoming?

Sounds like the ideal solution, the built in isolation and switching relay would not be used in a empeg installation using its Aux input - but you'd have to get the OnStar audio 'out' signals to the empegs aux in connectors as well.

Does the Onstar system trigger the cellphone mute on outgoing calls too or only on incoming?

Outgoing and incoming calls. Hmmmm......$110 for for starmod2.....$200 for handheld scope at radio shack

Don't forget to add your time to work out the data bit format and then programming up a micro processor to do the mute function etc.

For now I'd go with a manual switch and get that bit working
[at least its something you can use], then go from there.

Personally, if you feel comfortable with hacking the OnStar system and maybe blowing it up and your head unit etc - then go for it.
If you want a simple interface with a simple installation then the 3rd party add-on kit sounds ok.

Plus, I'm sure you could find a cheaper piece of kit if you looked around on the net a bit - but you'd still be paying at least $70 or so I think..

Its your decision.

When you put it like that. Actually there is an alternative which PAC will release in the next few months. I'll probably buy that. It interfaces directly with my PAC BOSE adaptor.
Thanks for all the discussion number6. I'm slow but I'm interested in learning!

I have a 2002 chevy hd truck

The microprocessor in this case is known as "the Empeg's CPU".

If you dig around in the kernel in empeg_power.c (I think), you'll find the mute code, with some Hijack hooks attached. If you were to keep track of mute samples over time, you could capture and decode the incoming bitstream.. with a bit of luck.

Or just blow the dough and save some time.

yeah, I'm not familiar with the 2002 trucks. If you do want to switch amps you can use an Onstar adaptor as discussed in this thread. (Soundgate has one and PAC will have one soon). These small boxes have a built in amp. The PAC will plu directly into your Onstar wiring harness. I think the Soundgate will require cutting/adapting to connect.

I may just give it a try (with my $200 Riocar).

A little correction: RS-232C (and V.24, IIRC) standards use +/- 12V, not +12V and 0V. -12V is called 'mark' and is logical true (or data '1'), +12V is 'space'. Idle data line is on 'space', that is, +12V relative to signal ground. However, there are many other stadard and proprietary serial protocols with different signal levels, polarity etc (e.g. empeg tuner port, which uses inverted TTL levels), so this tells us nothing about OnStar or some other proprietary solution.

Of course, I hope that memory still serves and I didn't mix up something

Most of the systems in the truck are tied to a "class 2" serial bus which end in the ALDL connector (for OBD-2 diagnostic hook-up). The onstar mute command is on a different serial circuit which seems to contain all radio controls (including proprietary controls to control aux. cd-changer). Therefore it makes sense that the Onstar mute command uses the same tyoe of serial circuit as the head-unit to cd-changer commands.

After further research:

The complex communications between Onstar GPS, cell phone, OBD-2 etc. uses a Class B (Type 2) serial circuit (http://www.intel.com/design/auto/autolxbk.htm). The only other serial circuit in the truck is the one I am interested in. It contains a mute signal for onstar to the headunit and cd-changer as well as the proprietary controls from the headunit to the cd-changer. That appears to be it. This circuit can be interfaced independently from the type 2 circuit at the ALDL and is probably "more primitive" than the type 2. It is probably a 160 or 8192 baud data stream as described at http://www.techedge.com.au/vehicle/default.htm Is there a simple way to figure out which one it is?

According to a usenet post (http://groups.google.com/groups?hl=en&frame=right&th=c3af263feb5fbb06&seekm=m31yv9xrjg.fsf%40duchess.twilley.org#link1) That thread :P

http://www.synergy-gps.com/M12_Oncore.html

Is the reciever used in the OnStar system. Don't know how useful that knowledge is, but hopefully it's somewhere to go off of.

Tanks Chao, I was curious what GPS was used by Onstar.

You are right,
The (classic) RS232C standard was developed from earlier RS232 standards over 25 years ago and things have moved on a lot since then. Originally RS232 defined 3 signal states, Mark, Space or undefined - undefined was any signal between about -3volts and +3 volts and included everything in between.
This was required because some wires in a RS232 circuit are not required to be connected and were thus left to float (but possibly connected at one end of the cable meaning the wire could work like a long antenna which could mean their voltage could change a little from 0v due to induced voltages from adjacent wires etc.

With the advent of modern computer devices working at mostly 5 volts [or less] a more flexible approach to classic RS232 signals has developed (in a de-facto way) whereby any postive voltage [typically over +3 volts] is treated as one state, any thing less than than that the other state.

This works for most laptop serial ports now and Dallas Micro (now part of Maxim) have a DS275 Serial Transceiver chip that works exactly this way - it either outputs +5V (or whatever the input power voltage is) or 0 volts [it can produce -5 volts or whatever by stealing power from the incoming data line when its not transmitting but the chip itself will not generate the -ve voltages.
It works the same when receiving - it will work correctly with 0 volts as meaning the opposite of +5Volts.

Now we get a bunch of modern devices that use 5 volts TTL serial bus'es (like Sony's Slink to name one, and probably Unilink is another). These send data in 'serial format' and sometimes actually in asynchronous format with start,stop and parity bits - but only at 5 volts (often with inverted logic)

The E&C circuit has the following characteristics:

media=single wire (bidirectional)
bit encoding=PWM
media access=contention
error detection=parity
header length=11-12 bits
data length=1-8 bits
overhead=variable
in-message response=NO
bit rate=1000 b/s

Well thats interesting,
assuming you have the right 'interfacing hardware' you could do as Mark Lord suggested and decode the incoming bitstream in software inside the kernel.

Of course, the messages sent down this wire, won;'t just be 'mute head unit', 'unmute headunit', and there may be quite a lot of traffic down this wire to the headunit, so any kernel decoding would have to be (a) real time (or as near as can be achieved) and (b) able to decode the PWM bit stream into a binary string of bits [This would make it timing sensitive].

Once that was done Mark could just take the 'bit stream' and turn it directly into a 'fake button code' for each message (this would be a different fake button code for each unique bit stream message.
You could then use this fake code in your IR Maps without needing to know the exact message format - simply treat the relevant ones [like mute headunit, unmute ...] as button codes and act accordingly.

However I am not sure if Mark (or anyone else on the BBS) has a car with Onstar so I am not sure how we could get some data to play with to analyse it further.
We also don't know the voltage of the signals down this wire, I'd assume 5 volts TTL but thats only a guess.

One thing I can say, if you want to progress this part further you need to find someone who has access to a Onstar equipped vehicle. [and probably the ability to hack the kernel in the empeg].

number6,

I reinstalled the original headunit, hooked a voltmeter between the serial line (open because cd-changer was removed) & ground. The line voltage held around 13v. When I pushed the onstar button there was a transient drop of approx. 1.5 to 2v then the sound came on and it went back to 13v. When on pushed the onstar again (to turn it off) there was a transient drop of 1.5 to 2 v. Is this enough voltage change to use the mute line on the riocar and not worry about the bitstream? In other words, can the mute line be programmed to detect changes other than 0 to 12v and 12 to 0v?

I'm not completely electronics-knowledgable, but couldn't you put a transistor/relay inline to translate the dip in voltage to a complete drop to 0V?

Mmm.. sounds like two bursts of serial bitstreams, then back to idle levels. This will NOT be as simple as just connecting it to the mute input, since it doesn't stay in the lower voltage state after sending it's "message". The slightly lower voltage "seen" by your meter is just an averaging of ones and zeros being transmitted rapidly.

So a software decode might just do the trick.. just gotta ensure we poll every 500us or faster, so we don't miss any of the 1ms bits (1000bps somebody said..).

If you can hook up your onstar and empeg together, and fix the in-car baud rate for the "normal" serial port so that a laptop can be used (the silly software switches from 115200 to 4800bps midway through initialization, but only in car mode.. ugh..), and then hook up a laptop to capture serial output.. then I just might patch hijack for crude bitstream interception to see if we can decode anything from your OnStar unit.

??

Mmm.. I think you also said the spec says "bidirectional".. we only want to use it one-way, so it might be wise to wire a diode into that line when feeding into the empeg.. Any hardware geeks got an opinion on that?

Cheers

You should be able to do this just in software with the mute line or with the lights-on dimming line. Both of these go through a RS232 receiver, and go to GPIO lines on the strongarm (GPIO21/22 I think).

If you set the appropriate bit (eg 1<<21 or 1<<22) in GRER and GFER (rising edge/falling edge detect) and claim IRQ 11 (IRQ_GPIO11_27). This IRQ is triggered when any of the GRER/GFER things get detected for GPIOs 11-27.

We try to use GPIOs 0-10 for things that we need interrupts from, which means this IRQ is not normally claimed in the system. 2.4 has a wrapper which simplifies everything for these lines, but 2.2 doesn't.

Anyway, claim the IRQ, set GRER/GFER and in your interrupt handler you need to write GEDR with 1<<21 or 1<<22 as approprite to ack the interrupt. You should then get an interrupt on every transition (you can find the current state of the GPIO line on GPLR).

The best way to get timing information is to buffer these transitions along with an OSCR (3.6864mhz 32bit counter) timestamp, and process them in a bottom half. A first stab at a driver would just output this info that you could then post-process.

IIRC, the dimmer input doesn't have a pull up/pull down on it at all, whereas the cellphone mute line does have pulldown on the mk2a. If you have no pulldown then you're unlikely to affect the workings of the signal line - you will just snoop. A diode won't help here.

Come to think of it, this may also be enough of an interface to do ODB-II reading. Now that'd be fun... ODB-II stuff onscreen with no hardware required except a 1-wire connection!

Let us know how you get on

Hugo

You can set the incar serial rate, it's in config.ini. Can't remember the command though.

If the driver I detailed above gets written (hint: IR remotes use PWM on a GPIO line too. Worth looking at the consumer IR driver and in particular "raw" mode which just buffers the transition/timing info) then people could send you logs that could be interpreted later.

Hugo

Thanks for the great info Hugo and Mlord!!. I'll probably need some help doing this but I think I'll take a shot at it. This may also be helpful for people who want to play their empeg thru a stock GM headunit since it uses the same circuit in many GM vehicles.

Given Hugo comment re: PWM decoding in the Consumer IR kernel code,

How difficult would it be to simply take the incoming PWM bitstream from the Onstar interface and simply turn that bitstream into a button code - I think there are 16 to 21 (variable) bits per 'packet' sent on this interface according to the previously published info.

That way we don't need to necessarily 'decode' the bitstream messages, just make it a button code and feed it into the Hijack kernel as now [i.e. pretend the Mute input is a IR bit stream input].

That would then let Rtundo get some button codes from his Onstar system and then he can make a map.

For OBD-II systems interfaces, this data stream would have to be decoded correctly (and maybe written to a device/fifo like the RDS stream is, so that userland apps can get at it),

The user could then be able to set in Hijack which of the modes the Mute Input was running in - normal [i.e. Cellphone toggle input], Onstar bitstream [PWM raw data treated as button codes], or OBD-II (decoded serial data stream ) feed to fifo/character device

I guess you could do something similar for Dimmer input - to allow both Onstar and OBD-II monitoring at the same time,
[with the correct wiring to the docking sled of course].

Hmm, this is starting to sound promising - I just wish I had a car with OBD.

It not only sounds promising but I don't think there are many codes being sent over this circuit. The only equipment used by this circuit are the 1)headunit 2)aux. cassette/cd-changer 3)onstar mute Since there is no main CPU directly controlling this circuit if I remove the cd-changer (which probably has the most complex codes going back & forth to the hu) I should only have left initialization codes between onstar and the hu and codes when onstar is turned on & off. That sould be it.....or am I missing something.

Interestingly, on a side note, the speaker signals from onstar splice into the aux. player speaker wires and run to the hu. I'll bet the muting signal from onstar is the same signal that aux. cd/tape players use to activate the hu to accept there speaker signals. I just mention that because there are people in other threads who would like to play there riocar thru there stock GM hu. Since this would require the riocar to send out a signal to the hu I assume this is more complex than our plans on this thread. Just thought I'd throw it out there. If someone thinks it is possible, I'd being willing to play with it while trying to solve my initial goal. Thanks so far everyone, this has been a real learning experience!

"IIRC, the dimmer input doesn't have a pull up/pull down on it at all, whereas the cellphone mute line does have pulldown on the mk2a. If you have no pulldown then you're unlikely to affect the workings of the signal line - you will just snoop. A diode won't help here."

Hugo,
Does this mean if I am "snooping" with the mute line it is safer to use an MK2 not an MK2a?

Well, it's not dangerous (ie, won't damage anything) with either - you may just find the (10k, IIRC) pulldown may affect the signal integrity with a mk2a, ie you'll find that adding the empeg to the circuit changes the behavior. 10k is fairly weak though, you may have no problems either way.

Hugo

A possible alternative fix to gain the Onstar mute function:

Apparently the SWI-X works with 1989-1993 pontiacs that utilized the E&C circuit (the same one that Onstar mute uses). It might be possible to interface the yellow wire of the SWI-X (12V serial data in) and convert to IF (program interface by pushing Onstar button then remote mute or aux. button). Thought I'd mention this if anyone wants to try it.

Thanks Hugo, that is very comforting.