David,
Supposedly the baud rate is NOT and issue with the RS232. My understanding based on comments of "supposedly" someone who did something similiar indicated that when they set the baud rate at a Non-Standard value and tested using an oscillosope, that the baud rate was set to that Non-Standard value.
True, RS232 only defines the voltage limitations on data and control wires – it does not define data rates. But my experience of RS232 many years ago when programming in QuickBasic was that the chip inside a PC was programmed only to accept the data rates I mentioned within a 5% limit. I have no experience of VB but if you have got it to accept 7.8kbs, then you are obviously right.
I also have no experience of Chrysler cars. The information I used was after a Google search found this article:
http://www.cnblogs.com/shangdawei/p/3570499.htmlThat clearly states that Chrysler’s CCD bus is a shared digital data bus using collision detection. It is similar to the Philip’s I²C bus, and there is no provision for analogue signals. Consider that the controller has to monitor a whole range of parameters, ie. engine speed, road speed, fuel and oil levels, engine temperature, seat belt status and dozens more things – sequentially and at high speed. Analogue signals in that environment would get extremely noisy and would require filtering, and that takes time. Each sensor would need addressing and that requires a digital signal – so why go analogue? They may use analogue signals for some applications – but not, I think, over that bus.
How do they then use a digital oscilloscope with an Auto and a PC? Hankook I believe makes one.
Digital signals can be read by any ‘scope – digital or analogue.
The advantage of using a digital storage scope like the Hantek one I use, is that any data waveform can be stored and viewed with no constraints on time.