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.