nAst1: Progress and Concepts Thread

[robertisaar]

no, and it's really only a hardware issue at the moment, something i need to document via a picture or two on how to fix. the code to deal with it can be ripped almost byte for byte from a few different applications, including the 94-95 LQ1/A-body L82, 88-93 3800s, and i think the 3.3s.... they're all roughly the same in that area. some tweaking of the P6 MAF code to work with a P4 also works(94-95 3800, LT1).

the MAF sensor input has a ~160Hz low-pass filter, which worked fine with the 50Hz VATS signal or the up to ~150Hz low frequency MAFs used on some 88 applications, but obviously the up to 11 to 12 KHz range that modern MAFs run up to, that's a problem. could run a serious pulse/frequency divider to get it into the 160Hz range(figure a /75 operation would bring 12,000 down to 160), but i'm not sure how well it would work out.

IMO, it's certainly a better option than going through a frequency-voltage converter, since we're only dealing with 8 bit A/D channels compared to a 16-bit 1000mSec timer. with a resolution of .01526mSec and a range of 976 to 12,240Hz, the timer counts will be between 5 and 68 thoughout the entire range... granted, that's not a big range. doing straight period measurements to calculate MAF frequency would result in a pretty large error even at the lowest frequencies(68 counts is 963.8Hz and 67 is 978.2, so even at the lowest end, a difference of almost 15Hz with a single timer count, a difference of 1.5%). the way GM worked around it was to setup pulse accumulators, which seems to work decently well. with some software filtering, i don't see sensor error being much of an issue.

maybe converting it down to a lower frequency would be easy, since down at 160Hz, you're down at 409 counts(160.2Hz), the next slowest rate at 410 counts is 159.8Hz... that doesn't seem like it would need any filtering at all(.25% difference between the two values). down at 17Hz, the difference is measured in the hundreths of a Hz. i imagine i could setup the table itself to be used for either, just need to be aware of which table is in use(a simple flag at work here).

lots of possibilities. fitting them into what little space is left in the 32KB BIN is the challenge.

[caffeine]

Does the MAF stuff currently work?

[robertisaar]

ugh, i just haven't felt up to coding these past couple weeks... wifey's work schedule had me all messed up. now that it won't be effecting me anymore, i can probably get around to finishing this up.

did just think of an incredibly overcomplex thought though(one that i wouldn't want to code either):

MAF + Speed-Density + Alpha-N all contributing to the fueling calculation at the same time(or perhaps give each a "range" to work in...). what an incredible pain in the ass it would be to tune, but i imagine SOMETHING out there might benefit from such a scheme...

[robertisaar]

actually, maybe not that time schedule....W-body meet is happening this weekend, i don't think i'll have enough time.

EDIT: well, maybe, i'll have a lot of time in the morning.

[caffeine]

Sweet!

[robertisaar]

currently, 1.08 has spark cut, MAP threshold to force PE(which a generic default value is applied when the patch is applied, so change that AFTER patching), TPS threshold for step 1 and 2 rev limiters(also has default value).

adding in either sometime tonight or early tomorrow is the T56 reverse solenoid/generic output control(i'll probably setup so that any 1 8 bit value can be compared against, possibly moving to 2 8 bit values later), AE while in PE issue, new fuel economy calc(that could also be used as a decent 1/4 mile calculator... the distance accumulator will be accurate within 1/128th of a mile, which is 41.25 feet, as long as there isn't too much wheelspin) that should offer some incredibly accurate trip economy values. increments of 1/128th of a mile will allow up to a 512 mile range while allowing incredible accuracy. if you go past 512 miles on a single keycycle(i've gotten close/slightly past that before), it will simply roll over, so whatever number you see, add 512 to it and manually divide it with gallons used. fuel usage will be tracked in .00061 gallon increments, for a max value of 40 gallons. will be testing the 4X datalogging as well.

notes: this code was truly meant for only 6 cylinder engines.... GM hardcoded the value that's used to create the RPM X 1 value to be correct for 6 cylinders. i have the values for 8, 6, 4, 3, 2 and 1 cylinder engines determined and noted in a new value that will be in the top section of scalars(since it's not a nAst1 addition). luckily, the RPM X 1 value didn't do a lot before i started utilizing it for nAst1, but it's still something that could have caused issues with swaps....



that will probably wrap up 1.08. seriously running out of space in a 32KB BIN.... won't be able to fit much more in before having to start designing a custom MEMCAL adapter to allow a 64KB BIN.

[pocket-rocket]

4x data logging sounds nice.

Sent from my HTC One X using Tapatalk 2

[robertisaar]

working on 1.08 additions now... potential new feature, assuming it tests well for me: 8192 baud vs 32768 baud selection. obviously, if you have any other modules in-car that depend on the PCM, they're normally disabled during datalogging anyways. well, for the time being, if it works well on the bench, there will be full-time 32768 or 8192.

if it works well, i'll be changing some code around so that when mode 8 commands are sent to the PCM to get it to quit talking to other modules during the PCM to laptop connection process, it will switch into 32768 mode, where it will happily allow datalogging at 4X normal rate. when mode 9 commands get sent to the PCM to go back to normal, it will switch back to 8192.


seems like a good scheme to me, thoughts?

[robertisaar]

it is a 6811, but it's a custom variant... a lot of features that weren't needed were removed, along with support for some custom functions.

the later GM OBD1(and some early OBD2) PCMs used a 6811F1(or in the case of the 93-95 northstar and 3100, 94-95 LT1 PCMs, two 6811F1) that as far as i can tell was an off the shelf part.

[caffeine]

Are we talking about the 68HC11 processor? If so, there appears to be open-source emulators available already...

Also, an older version of GCC appears to support the processor, although I've found GCC to produce relatively bloated code. Would be interesting to try it out. I find C sooooo much easier to understand than assembler.

[robertisaar]

too bad THRSim11 likely wouldn't work at all with the P4 units due to the way GM had them setup.

would make prototyping code a lot faster if i didn't have to work around the limitations of whatever hardware i need to brew up to simulate I/O.

[Superdave]

We totally need one of you smart guys to build a '7730 emulator program.


Would be cool to be able to import a current bin and change different input values to see if you can re-create problems that come up when datalogging.

[robertisaar]

i...... uh, i wouldn't know.

getting beyond my knowledge/experience. i don't think i would want to punch out assembly for anything more complex than the 6811, too many things to keep track of. just trying to follow CPU32 in a motorola 68332 gives me a headache.

[caffeine]

Seems kinda similar... It's been a while but IIRC x86 has 4 16-bit registers, which can double as 32-bit registers with different instructions. Some of the hardware stuff would have to be written in inline assembly, but most C compilers I know of have a way of inserting direct assembly code.

[robertisaar]

i would have no idea.... any other language/instruction set i try to get into, it makes my head spin trying to correlate new instructions to ones i know in 6811.

as an example:

C38C:
JMP L96D8    ;go do my code

96D8:
LDAA L0054   ;grab MAP A/D(1BAR real or emulated)
CMPA L9708   ;compare to MAP above which always PE
BHI L96E5    ;branch if high enough to enter PE
LDX L8B24    ;otherwise, start return to normal code
JMP LC38F    ;and return
96E5:

LDAB L0042   ;load bits
PSHB         ;temp store
ANDB $DF     ;clear PE bit(since it's not cleared anywhere else)
STAB L0042   ;save byte
PULB         ;grab real previous PE status
JMP LC3DB    ;go back to normal code, PE enabled from high MAP

i can understand this easily... only 2 accumulators to deal with(both 8-bit, but can be used as a single 16-bit), two 16 bit index registers that don't get used too often, a stack pointer, a program counter, status register... and not much else.