100hz is pretty good :) 500hz.. that's pretty crazy. Do you know the realistic response rate of the sensor itself?Quote:
That is a bizarre sensor failure. It must be causing some kind if timing error. Probably some intermittent contactm doing something like a spark-gap, or something.
Individual cylinder pulses can really be seen on the Analog output line. The update rate for the analog data is 2ms, vs. 10ms for CAN data. I have used this to tune Weber carbs ( individual throttle-per-cylinder ), using an oscilloscope, triggered on the #1 spark. IIRC, I was able to pick out cylinder variations up to about 2700RPM, in what was, effectively, a straight six. Or, more correctly, 2 of them :) MOre than good enough to tune idle and transition to the main jets :)
There is a way to get the WB to broadcast OBDII data, using the DPID interface. But, it requires sending a keep-alive message, every 2 seconds; and, a few initial setup calls. This is part of the whole MODE 0x2c thing.
As far as having multiple protocols, in the gauge, probably not.
The following is the result of the build for the 30-0334 code. This is on a 16K ( 16,384 byte ) CPU.
There are 152 TOTAL bytes of code-space left. And, they are not contiguous. Not a lot is going to be added to the 30-0334 functionality, without going to a 32K CPU :)
****************************************
* *
* CHECKSUMS *
* *
****************************************
Symbol Checksum Memory Start End Initial #Initial
------ -------- ------ ----- --- ------- --------
__checksum 0xb89d CODE 00000000 - 000037FD 0x0000 #0x0000
****************************************
* *
* END OF CROSS REFERENCE *
* *
****************************************
16 230 bytes of CODE memory (+ 2 absolute, 152 range fill )
781 bytes of DATA memory (+ 90 absolute )
64 bytes of XDATA memory
Errors: none
Warnings: none
Any chance of making the "flasher" and some form of flash bin for each (AEM-Net and OBDII), public? :)