Anyway, look at programmable parameters, specifically PP 2C and 2D.
We have a reflow workstation in our lab, but I agree that if you replace the chip more than once the pads may separate from the PCB.* Since I have been looking into this I have now generated a desire to have a good working unit for general OBDII use after this project and do not want to bugger up a perfectly good unit. I don't know about you, but my soldering skills to repeatedly solder a chip in and then back out seem to destroy pads.
OBDLink currently doesn't support setting protocols (ATSP) above 8. We plan to implement this functionality in the coming weeks.* I am willing to spend a bit more for both capabilities in one product. So I am still looking around.
I notice you limited your suggestion to the ElmScan 5 and did not mention your newer product, whose name escapes me. Would it be capable of this as well?
Good point, I forgot that you need to have a way to set the mode bits.I thought that OBDPRO used the ELM 327 command set. That doesn't offer a way to set the 'high voltage' state (SW CAN has 3 states). You can't get to some functionality without that, so perhaps they added a superset command or something.
— OBDLink MX: world's smallest, fastest, most advanced OBD/Bluetooth adapter with SW and MS CAN support. Read the review to learn more.
— Need to look up a diagnostic trouble code? Try the most up-to-date, free DTCsearch.com!
You cannot send me a private message using this forum. Use my email instead: vitaliy[@]scantool.net.
I didn't have anything specific in mind, I was just thinking in terms of completeness. If you are going to put in the right transceiver, it seems like it would make sense to give access to the state.
In terms of bit rate, they call it 33.33, but everything I've seen suggests that it is 500K / 15, or 33.333333... So, if you can set the rate divisor you are probably OK. The only gotcha would be that most CAN controllers don't just take a rate, like a UART. You also have to program a bunch of segments and propagation delay stuff. I'm not sure if this is inherited from Bosch, whose controller is spectacularly complicated, or what (see Silicon Labs chips and the Bosch companion doc, or the simpler Microchip CAN Module doc to see what I mean). So, I could envision firmware not handling a previously untested super low rate correctly, but you'd have to test it to see.
My understanding, Bosch being the inventor of CAN, licenses all CAN hardware and the conditions of the license is that all products be compatible for both bus lengths and different manufacturers hardware. Every time you buy a CAN chip a royalty has already been paid to Bosch.
My hesitation is rather or not the firmware is at the right level for these sorts of applications. Right now it is basically SW and DW CAN passthru with basic filtering and rate control. It has no higher level protocol knowledge of GMLAN, in fact we use it on several, very different, systems. Making the host application wholly responsible for something like GMLAN is pretty demanding. Without researching it, I wouldn't be sure if certain timing requirements are hard to meet.
Probably not with SW, it's pretty slow and very forgiving. But I'll have to think about it before I consider mentioning it to the powers that be.
While the car is running the SW/LS CAN is fully awake and running with the speed for example as you mentioned coming across from the HS CAN, as well as most/all the other instrument cluster/DIC data.......rpm, coolant temp, fuel level, fuel consumption data, ABS status, trans gear, diagnostic status etc etc.
If the ign is on and radio etc on, then probably the wake up state is not absolutely necessary. It is implemented as a seperate line on the driver chip.
Of course, that could be conditional safety logic in the nodes themselves, but either way it surprised me. I've worked on the high speed side quite a bit, so I expected the low speed bus to be really simple and forgiving.
I'm swamped at work now, but it's something I'd like to look more closely at when I can find the time.
The modules that are on my Chevy HHR’s SW GMLAN are:
Remote Control Door Lock & Tire Pressure
and of course the Body Control Module.
I can see Theft Deterrent turning off, but the others I would think should be visible at all times.
On the HS CAN all the real time data channels use around 400kbs of 500kbs available (? - 80% util), so at 33.3kbs it may get a little tight if it is all happening at once.
A G8 for example on the LS has ~14 modules depending on options fitted:
HVAC; Infotainment display; Bluetooth; Theft deterrent; instrument panel; Radio; Rear seat entertainment; Telematics; GPS; Seats with memory; external object detection/parking sensors; tire pressure monitoring; occupant protection and of course the BCM in the centre of it all.