Welcome to Just Commodores, a site specifically designed for all people who share the same passion as yourself.
Have you asked this question on PCM HACKING?Well I made it through the 15 pages but didn't find the info I was looking for, so I'll ask the question
I'm wanting to run DashCommand on an Android Tablet in place of my commodore gauges which have crapped out, and I'm building a custom dash anyway.
This bit is easy and I'm got it working with the OBD2 port to get my gauges displaying correctly.
I also want to use a HUD on the windscreen just for speedo mainly (and to have a HUD).
FYI The car is a 85 Pontiac TransAM but with the internals of a VY commodore (LS1 PCM, VY wiring, BCM etc)
I've heard that you can't run multiple devices on OBD2 simultaneously because there's no assignment of who/what is requesting the data, so it doesn't know which packet is for who, but I thought maybe this would still work with a device such as a HUD, because it wouldn't be making any ad-hoc requests.
I also understand there are "broadcast PIDs" that are always sent out via OBD2 at set intervals, and then there's PID requests.
The HUD is the usual generic ebay one, so I don't have a model or details, but my question is this:
If this device is just receiving OBD2 data (via broadcast PIDs) would this work in tandem with the DashCommand software, or will it still cause issues with the HUD device due to additional data from the DashCommand's PID requests?
And if it will is there any other possible solutions for this? OBD2 Router/ write a program /arduino device to intercept all OBD2 communication and then only send specific packets to the 2 devices via 2 separate channels?
Don't forget the pic's, thanks.So every site selling devices says you can't run multiple ones, but then a breakdown of the VPW protocol that Antus sent me shows that the first 3 bytes of the data include priority, source and destination (http://www.fastfieros.com/tech/vpw_communication_protocol.htm)
It seems using 2 OEM OBD2 devices of similar purpose will likely have the same ID and so will conflict, but if I can either change the ID for one, or build something to intercept the outgoing and incoming feeds and alter the ID it would work.
I'll have everything installed this weekend so can start testing and capture the communication to see what's going on.
If the HUD is just receiving the broadcast PID it will work fine.Well I made it through the 15 pages but didn't find the info I was looking for, so I'll ask the question
I'm wanting to run DashCommand on an Android Tablet in place of my commodore gauges which have crapped out, and I'm building a custom dash anyway.
This bit is easy and I'm got it working with the OBD2 port to get my gauges displaying correctly.
I also want to use a HUD on the windscreen just for speedo mainly (and to have a HUD).
FYI The car is a 85 Pontiac TransAM but with the internals of a VY commodore (LS1 PCM, VY wiring, BCM etc)
I've heard that you can't run multiple devices on OBD2 simultaneously because there's no assignment of who/what is requesting the data, so it doesn't know which packet is for who, but I thought maybe this would still work with a device such as a HUD, because it wouldn't be making any ad-hoc requests.
I also understand there are "broadcast PIDs" that are always sent out via OBD2 at set intervals, and then there's PID requests.
The HUD is the usual generic ebay one, so I don't have a model or details, but my question is this:
If this device is just receiving OBD2 data (via broadcast PIDs) would this work in tandem with the DashCommand software, or will it still cause issues with the HUD device due to additional data from the DashCommand's PID requests?
And if it will is there any other possible solutions for this? OBD2 Router/ write a program /arduino device to intercept all OBD2 communication and then only send specific packets to the 2 devices via 2 separate channels?
Well, 2nd device arrived and it's the same story. No go in the VZ. Works on Astra, confirmed to be KWP(fast) protocol.
Forgive me for the nerd detail, but someone may find it useful.
I opened one up to see what's going on.
It's not based on a genuine elm327 chip, but a PIC18f25k80 (http://ww1.microchip.com/downloads/en/DeviceDoc/39977f.pdf) which seems to be implementes the same way.
It uses a TJA1040 CAN transceiver (http://www.nxp.com/documents/data_sheet/TJA1040.pdf)
The TJA1040 is setup with 120ohm resistor (surfacemount labeled 121 in position R2 on my device) which provides loading across the CAN high and low lines (hardware not speed**). The datasheet shows typical applications with two resistors using a split load for 'stability'.
Following some crazy idea, I removed the 120ohm resistor, with no change to the function of the device. It doesn't come into play unless CAN protocol is used. It didn't help.
This device was a fun little research tool, but useless for the VZ. I tried a few different Android BT terminal apps in an attempt just to see the raw data/signal, which just disappointed me with the crap that's out there.
The device itself is most unpleasant to work on, with 2 stacked double sided pc boards whose headers are soldered to each other.
Not that it helps anyone with a commodore but I would be happy using this mini bluetooth device with protocols other than CAN.
My next option will be a usb cable job. Hopefully that will be less drama, even if it's less convenient. If anyone has had success with the chinese ebay ones on a VZ, please chime in and let us know.
**To clarify the 'high' and 'low' terminology (I'm agreeing with you Tazzi) - There are slow and fast speeds, there are High and Low CAN lines. Instead of a single wire for serial data they use a balanced pair regardless of the baud rate. The extra confusion comes from GM also using 'single wire' CAN. They could use CAN High or the CAN Low wire. Bloody hell, my own clarification reads badly.