Quote:
I noticed that on the raw interface when I enable loop with main program disconnected it always close the port when message is received and than reopens it. That way frequency drops alot.
unless you have a dead t-side, i'd just 'connect' and disable the datastream messages. it'll only keep-alive if necessary.
this is a good thing anyway since idle chatter will screw with your messages (and eehack requires a nice clean datastream with proper length bytes). remember i don't do unordered raw comms and recieve arbitrary bytes, i require a proper device, length, and checksum on each message or it wont even consider it valid.
furthermore i really don't want to hang the serial port open when not using it, especially since someone (like me) might want to connect and disconnect the usb interface when the program is still open; you know, when carrying the laptop inside from the car but you still want to work with the loaded data. this way you just disconnect and don't worry about it, otherwise, interface open = crash.
Quote:
Originally Posted by
kur4o
I checked the bin and it is indeed a manual bin. I have no idea how it get loaded on the PCM and still can`t identify it.
16209647 eside cal id and 16209648 tside cal id.
weird, there are a few bins like that in my archive too.
Quote:
I need some y-body 95 vins to grab some factory calibrations. I have checked all the bins I have on hand and there is no obd-2 possibility in the code or some changes and I assume it must be the onboard extra chip doing the job.
i only have these two:
http://fbodytech.com/bin/EE_16209281.bin
http://fbodytech.com/bin/EE_16212471.bin
it's definitely on a different chip that does ALL the work, but it's unclear what 'all the work' is.. the bin just seems to grab the obd-ii error codes from somewhere for display in the datastream.
i find this really interesting.
think about it:
the obd-ii tests are inherently really strict and done with crazy timers and thresholds and require interaction with the actuators.
even a simple obd-ii test could be 'decrease fuel by 20% when engine has been running for (minutes) above x rpm and y temperature and if trims <z and see if left o2 sensor goes lean or whatever'. that's a bitch of a test to do WHILE the primary chip is still processing. then it has to remember the results of that test, and re-test. there is no real evidence of that in the code.
the error codes themselves specified in the datastream do indicate this level of test is done, though.
so either those additional chips have some serious processing power, pinouts, mad context switching, and some kind of more complex IPC communication kinda like a third board (unlikely), or most of their functionality is bunk.
although it could be possible that they interact with the IPC to steal a ton of engine parameters?........ i don't see how, that'd be a hell of a chip.
a reeeallly likely possibility is that the obd-ii style error codes are just stolen from the regular obd-i tests and they were testing this platform if they could fudge 'minimal obd-ii compliance' with very minimal effort, by using obd-i tests and embellishing them slightly (adding only catalyst monitoring with a secondary o2 and chip).
Quote:
In message 0 there is two unidentified AD stream 0113 011b. Do you have any info on them. I suppose these are the rear 02-s even they are most likely to be at 012a and 012b
0x011B is specified as the rear o2 raw voltage @ byte 35 (or 36 if you start at offset 1 like the datastream documents do) although on f-platform early results indicate no reference voltage is applied, but i haven't checked to see if anything happens if you ground that pin (not even sure which pin to be honest)
0x0113 requires research. no idea what it's for.
the corvette has only a single rear O2 afaik....
Quote:
Pin d27 [byte_103] is mentioned as egr position sensor but is not used on all the schematics I checked so I decided it is not used and I suggest to use it for primary or second wideband channel.
never seen proof it's used either. it doesn't seem to do much in the code.. but it's in the datastream..
i've defined it in eehack. the definition format allows many parameters to be specified for each byte (and restricted per-view level)
Quote:
3 custom parameters on the dashboard will be great.
well, i added four, and they seem to work alright (restricted to message zero)
see new beta on my site