Input and Output to actuators/sensors (in the future)
Moderator: Matt
Input and Output to actuators/sensors (in the future)
Since we know the input for the fuel temp sensor for the z31 ecu, can we utilize this for another purpose........say an IAT combined with a map sensor? Assuming the code is doable. Or finding an unused or freeing up an output like the that idle controller and using to control water inj or boost control? I'm bugging a few guys at work that could help out. They were 6800 programs waaaay back. Any thoughts on this? Interesting? Crazy? Dumkopf? Aushlache?
sounds too hard.... seriously though you need to find an A/D output register, read it and then we can mointor it
if you want to take something the ecu actually uses, you would need to stub out where the ecu uses it, change the ecu to use that value and then read the ram address
instead, i suggest using wideband extra inputs and reading through that interface. i am going to support that in the software and its hell of a lot easier
if you want to take something the ecu actually uses, you would need to stub out where the ecu uses it, change the ecu to use that value and then read the ram address
instead, i suggest using wideband extra inputs and reading through that interface. i am going to support that in the software and its hell of a lot easier
now i've got the T/E on my desk, im doing the code to use two auxillary inputs.
what i will do is give you an aux1.csv and aux2.csv files to use to convert volts to output value
i linearly interpolate those values in the table against measured volts and display it on the screen and log it to your log
you can use it for boost, outside temperature whatever etc
what i will do is give you an aux1.csv and aux2.csv files to use to convert volts to output value
i linearly interpolate those values in the table against measured volts and display it on the screen and log it to your log
you can use it for boost, outside temperature whatever etc
good question.... it sets the mode to either read A/F mixtures, DTC codes and also sets IDLE RPM fine tune on my car
it would go into the HD46510 but i dont know what register is a result. however modifications to the ECU would not be simple to use this input since I would also have to disable all the other code that uses that input
the autopatcher currently only intercepts the interrupt routine and runs my code.
any disabling of other ECU code will require additional patch routines to cut/replace them and are ECU dependent. this is why i suggest using wideband inputs which are currently implemented for techedge. you can take a 0 - 5 volt input and then use a translation table for whatever you want
i haven't forgot about the innovate unit either. i will be getting a chunk of time in the next few weeks to start looking at the SDK. if someone was willing to loan me their unit for testing that would help also but i can always post out test releases for testing the serial communications
it would go into the HD46510 but i dont know what register is a result. however modifications to the ECU would not be simple to use this input since I would also have to disable all the other code that uses that input
the autopatcher currently only intercepts the interrupt routine and runs my code.
any disabling of other ECU code will require additional patch routines to cut/replace them and are ECU dependent. this is why i suggest using wideband inputs which are currently implemented for techedge. you can take a 0 - 5 volt input and then use a translation table for whatever you want
i haven't forgot about the innovate unit either. i will be getting a chunk of time in the next few weeks to start looking at the SDK. if someone was willing to loan me their unit for testing that would help also but i can always post out test releases for testing the serial communications
-
GZ@hybridka
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
What ecu is in question here, the Z31?
Does anyone happen to have a basic correct (dis).ASM for this ?
For the outputs, first you need to map out the 6303's port pins to the original outputs. Surely there are a couple emissions related solenoids on the engine that would use a switching transistor on the board itself (these are the easiest to steal).
Once the port pin(s) is mapped on the hardware side, finding out how the code switches it originally is a trivial task. Assuming the emissions related code is fairly well condensed and not spread out all over the program, The routine(s) can be patched so that both the output control is freed up, and the space within the original program loop re-used for the modified switching routine.
Its actually nice to have all the extra emissions stuff, both for the hardware aspect and because of the good amount of code space and ram available. The code space can also be used for other modifications, as an example I have my launch limiter and consult timing correction modifications done in what used to be AIV routine.
If you have an egr temp sensor input, this is good. Assuming it uses a thermistor and hd46510 channel, the hardware would support an IAT thermistor with only a few bias resistor changes.
The egr sensors dont seem to use a standard thermistor table > real world temp value conversion like that of the coolant sensor within the code, so this function would need to be coded in (otherwise you would just have and 8 or 10bit ADC value to use).
It would be rather easy as so long as there is free space/emission routine (and if code isnt very cryptic).
Does anyone happen to have a basic correct (dis).ASM for this ?
For the outputs, first you need to map out the 6303's port pins to the original outputs. Surely there are a couple emissions related solenoids on the engine that would use a switching transistor on the board itself (these are the easiest to steal).
Once the port pin(s) is mapped on the hardware side, finding out how the code switches it originally is a trivial task. Assuming the emissions related code is fairly well condensed and not spread out all over the program, The routine(s) can be patched so that both the output control is freed up, and the space within the original program loop re-used for the modified switching routine.
Its actually nice to have all the extra emissions stuff, both for the hardware aspect and because of the good amount of code space and ram available. The code space can also be used for other modifications, as an example I have my launch limiter and consult timing correction modifications done in what used to be AIV routine.
If you have an egr temp sensor input, this is good. Assuming it uses a thermistor and hd46510 channel, the hardware would support an IAT thermistor with only a few bias resistor changes.
The egr sensors dont seem to use a standard thermistor table > real world temp value conversion like that of the coolant sensor within the code, so this function would need to be coded in (otherwise you would just have and 8 or 10bit ADC value to use).
It would be rather easy as so long as there is free space/emission routine (and if code isnt very cryptic).
Last edited by GZ@hybridka on Sat Jun 02, 2007 9:02 am, edited 1 time in total.
-
GZ@hybridka
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
I think I meant 6802, and not 6303 above, but all still applies.
About the diagnostic potentiometer, I think that uses the AD (46508/10), but seems to be set up on a pin as a comparator on my ecu's and not an ADC. It could probably be reconfigured, but I wouldnt want to try it. Maybe with the hd46510 at least you have a proper datasheet (iirc).
Im still looking for hd46508cpa-2 datasheet for plcc44, cant find it anywhere.
About the diagnostic potentiometer, I think that uses the AD (46508/10), but seems to be set up on a pin as a comparator on my ecu's and not an ADC. It could probably be reconfigured, but I wouldnt want to try it. Maybe with the hd46510 at least you have a proper datasheet (iirc).
Im still looking for hd46508cpa-2 datasheet for plcc44, cant find it anywhere.