nAst1: Progress and Concepts Thread

[robertisaar]

hmm....

we're using a low-pass filter to convert a PWM signal to an analog voltage.

is it possible to convert the frequency of the wheel speed sensors into a voltage, which the differential amp can recognize and work with?

[pocket-rocket]

It is, but then I'm also looking at frequency comparators too. I believe this is what I originally had in mind but thought of differential amplifiers as well.

Dave, where are you!?!?

[robertisaar]

here's a good question: how many "channels" can volt differential amps or frequency comparitors work with? it would be nice to have them all in one circuit, but i imagine if need be, there can be two different comparitor/amp circuits, just pair the sides(one front and one rear wheel), then run the output of the comparitors/amps through an OR gate, and then feed that to the ECM's A/D port?

it would allow all of this to be fed into a single input, which is almost a MUST have at this point in time, though 2 MAY work if necessary, but absolutely no more than that.

[Superdave]

Dave's not here.

You'd need to compare the front wheel speeds against each other, the rears against each other and then the front against the rear. No matter how you set up the logic for this it's going to be problematic.

http://ww1.microchip.com/downloads/en/AppNotes/00795a.pdf

[robertisaar]

sidenote: the E-side of the 94-95 LT1 setup is BARE! there is almost 32KB of continuous PROM space that's free.

i was looking around in the LT1 BIN for the subroutine to deal with the lookup, and imagine that, they're not 4 seperate tables in $EE, they're all one continuous table in 128Hz increments. leave it to Tunercat to overcomplicate something. it's a single 16 bit 77 entry table in EE code with EASILY adjustable min and max frequencies of the table, meaning as long as it's an increment of 128Hz, you could go from 0Hz to 65536Hz if the hardware supported it.

from the looks of it, i'll need to modify the algorithm a little bit due to the difference of being native P6 code compared to the P4 we're using(for example XGDX is not allowed on a P4 IIRC, i'll have to do some stack work to replicate it). otherwise, it's simple..... err, relatively speaking.

EXAMPLE:

here is stock 94-95 LT1.

[Superdave]

Robert, how hard would it be to change the shift light enable output to a different pin and also have it run when the auto flag is enabled?


I built a badass shift light tonight and i'd like to use it since i've got a kitted auto. 3 luxeon 1 red LED's from a stop light = bright as hell.

[robertisaar]

are you sure the stock shift light tables would be sufficient? IIRC, they only go to 5000RPM.

i imagine i could impliment a "track only shift light" option that would only be used when near WOT. if you have roughly the same desired shift RPM for every gear change, that would be even simpler to code, since N/V ratios wouldn't need to be setup/checked.

the only problem is finding a suitable output to use. obviously, there would be no reason to use a PWM output for a light.

7727 equivalents: A13, A18 and D2 are the only free outputs in a normal A1 car.


A13 is a digital on/off that is normally unused, only the 90-earlier cars that are converted to $A1 use it for the low coolant light or if F31 trans is selected, shift solenoid B.
A18 is a PWM output, used for AIR divert on manual trans cars or shift solenoid A if F31 trans is selected.
D2 is a digital on/off, Ludis listed it as a relay circuit, no idea why, but it is wired a bit differently than the quad drivers, shouldn't make a difference though.

so, i would recommend D2(A2 on a 7730). i'm not sure how to access it yet though, never looked into that one yet.



side-note: i have the algorithm $EE uses to make a 16 bit grams/sec value from MAF frequency 100% decoded.

[SappySE107]

Ill have to PM you but I want EE for a friend of mine down here. He has a 95 Z28 and wants me to tune and it and I don't know what I really need since I have some stuff already.

A single MAF table would be very nice to have, especially if we can convert it to work with a Stock 3400 MAF or an LS1 MAF. If the 94-95 3.4 DOHC MAF code was like that, I would like it a little more. Not now that I don't have access to one though:P

[robertisaar]

i have a little bit of EE stuff, but most of it is TC inspired ()

i already have the 96-?? 3x00 MAF converted and interpolated for the table i suggested earlier. i would need a transfer sheet for a LS1 or any other MAF.

i COULD import the code to 2E, wouldn't take more than a few minutes after i start remembering where everything is located.

[Superdave]

in regular $A1 i had my shift light turning on at 6375, "RPM ABOVE WHICH SHIFT LIGHT IS ALWAYS ON".. i left the rest of it alone.

[robertisaar]

if that's the case, and it always worked correctly, then just swapping out the RPM X 25 variable for the RPM X 50 variable would allow up to 12,750, if you needed to go that high. at that point, then only the output commanding would need to be worked out.

[robertisaar]

ROM:622D                 ldd     word_185        ; MAF frequency in Hz
ROM:6230                 subd    #$5D0           ; make lowest limit of MAF 1 table(1488Hz)
ROM:6233                 bcc     loc_6238        ; 11,216Hz
ROM:6235                 ldd     #0
ROM:6238                 cpd     #$25FF          ; 11,216Hz
ROM:623C                 bls     loc_6241        ; mult LSB by 2
ROM:623E                 ldd     #$25FF          ; cap to 11,216Hz if necessary
ROM:6241                 lsld                    ; mult LSB by 2
ROM:6242                 stab    byte_187        ; LSB of MAF Hz stored here after a doubling
ROM:6245                 tab                     ; move MSB to LSB
ROM:6246                 clra                    ; ignore MSB for now
ROM:6247                 lsld                    ; double LSB again
ROM:6248                 addd    #$241A          ; location of MAF table
ROM:624B                 xgdx                    ; move current location to X
ROM:624C                 pshx                    ; save current location
ROM:624D                 ldd     2,x             ; load value 1 entry rounded up from frequency to D
ROM:624F                 subd    0,x             ; subtract entry from 1 entry rounded down cell
ROM:6251                 pshb                    ; save D
ROM:6252                 psha
ROM:6253                 tsx                     ; point X to stack
ROM:6254                 ldaa    byte_187        ; LSB of MAF Hz stored here after a doubling
ROM:6257                 ldab    1,x             ; LSB of lookup
ROM:6259                 mul                     ; multiply
ROM:625A                 adca    #0              ; add a count to MSB of result if necessary
ROM:625C                 ldab    byte_187        ; LSB of MAF Hz stored here after a doubling
ROM:625F                 psha                    ; save LSB
ROM:6260                 ldaa    0,x             ; MSB of lookup
ROM:6262                 mul                     ; multipy
ROM:6263                 tsx                     ; point X to stack
ROM:6264                 addb    0,x             ; add LSB to D
ROM:6266                 adca    #0              ; round MSB up if necessary
ROM:6268                 ins                     ; restore stack
ROM:6269                 pulx                    ; ...
ROM:626A                 pulx                    ; first PSHX (241A + offset)
ROM:626B                 addd    0,x             ; add 241A + offset to value to make final G/S
ROM:626D                 std     word_18B        ; MAF Grams/Sec value

P6 version.

[robertisaar]

also, for the MAF code, i'll be implimenting another table: injector flowrate vs MAP. the speed-density code in A1 may or may not account for this and rely only on the VE table to adjust for the fact that at lower MAP values, fuel pressure(and flow) decrease. then again, raw MAP may get used in the final BPW calc, i can't remember off-hand, but the point is: by design MAF doesn't know about MAP values, so MAP needs to be referenced to adjust the injector constant to account for different fuel pressure. if you unhooked vacuum from the FPR, then the same value in the entire table can be used, otherwise, lower injector flowrates need to be filled in at lower MAP values.

now, the question: should i make the table setup for 1BAR or 3? technically, 3BAR would be able to get around it by adding a touch more to the above atmospheric pressure BPW multipler table, but opinions?

[SappySE107]

I almost posted before that it would be great to have 3 bar and MAF at the same time but that seemed like a bit of overkill at the same time. That and I am not sure how much the computer can do at once.

[robertisaar]

the final BPW number that eventually gets sent to the injector register will only be from one or the other(speed-density or MAF, that is). it's possible to have one engine cycle be MAF and the next speed-density, but i'm not planning on blending the two, even though it is possible, since it would be redundant and eat up a lot of processing cycles.

basically, right before the start of BPW calculating algorithm, i'll have an option bit setup that will allow for MAF to be calculated instead of speed-density. MAF will likely be a faster algorithm to execute, but the program will only execute one or the other for a given BPW calculation. there will also be(adjustable) qualifiers that only allow MAF in certain situations, such as D-TPS since the last check cannot change too quickly or frequency cannot be too high or too low(i'll probably setup DTCs for these that will illuminate the SES light), stuff like that.



also: discussion topic: what effect does altitude have on MAFs? i've read conflicting information about oxygen content changing at different elevations, not sure if a barometric correction factor will be needed for the MAF.