nAst1: Progress and Concepts Thread

[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]

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.

[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]

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.

[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?

[pocket-rocket]

4x data logging sounds nice.

Sent from my HTC One X using Tapatalk 2

[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.

[caffeine]

Sweet!

[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.

[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...

[caffeine]

Does the MAF stuff currently work?

[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.

[robertisaar]

caffeine: i had to clear out my inbox the other day, forgot to save our conversation on the speed signal...

were you running a magnetic speed sensor or the speedometer buffered optical unit?

if you're using the magnetic setup and need a /2 operation done to get the signal close, i just found by far the simplest way of going about it.

[caffeine]

I'm using a magnetic speedo and ideally a /2 divisor would get me close with 4.11 gears. What's your idea?

[robertisaar]

i'm not sure if the cavity will be open on your connectors, but the 7727/7730 and derivatives have a pin for VSS output that is run at half the fequency of the 4K/PPM signal, so it's obviously named the 2K/PPM signal circuit....

here is a small section of the diagrams Ludis made of the 7730 boards.



explanation for those that haven't caught on:

VSSHI is the "high" for the magnetic VSS(the "low" goes directly to ground once inside the PCM). VSS# is the optical VSS signal coming from the speedo buffer. VSS is the signal that goes to the IC that the 6811 uses for most of it's timing critical I/O stuff.

anyways, following VSSHI, signal goes through a 51K resistor, filtered by a cap of unknown value(forms a low-pass filter), goes into the U24 IC. there the signal goes into a zero-crossing detector(magnetic VSS causes a large spike in voltage, both positive and negative, so when the signal goes above, then below the 0 volt threshold, an event is registered). from there, the signal branches off and goes into U10 for further signal conditioning for use by the processor. the branch we're interested in stays within U24 and goes down to the divider.

the divider is programmable, there are 3 circuits(DIVA, DIVB, DIVC) that are processor controlled and are chosen in the calibration via KSPDDIV. possible divide values are 1, 6, 7, 8, 9, 10, 11. so the raw magnetic VSS signal can be divided by one of those numbers, then pushed out to U14, then back into U24.

normally, the VSS4000# circuit is used to drive the speedometer(and odometer) and so you setup the KSPDDIV divisor to divide the magnetic sensor's signal as close as possible to 4000. doesn't always work great depending on the number of cuts in the VSS reulctor and tire height. with RWD, you also have to factor in final drive ratio. a lot of the time, you can't get very close to a divisor with anything other than factory or close to factory parts combos. in the case of the T56, the VSS reluctor and final gear multiplication tends to put the maximum divisible value out of range, so the speedo would never really read correctly(though the speed the ECM calculates would be accurate if the correct PPM signal is entered). the F40 with it's ~60,000 pulse/mile setup also runs into the same problem.

well, now an interesting solution would be to simply move the cluster's 4K PPM signal over to use the 2K PPM circuit, making the divisible possibilities 1, 6, 7, 8, 9, 10, 11, 12, 14, 16, 18, 20, 22. i don't THINK /2 would be in effect with /1 on the 2K circuit, but i could be wrong.



in any case, note two VSS 2000 output circuits, one is inverted, one is not. seeing how the normal 4000 PPM signal is also inverted, it's safe to assume that would be the route to go with the 2000PPM signal. so, VSS2000A# is the winner here, on a 7730, it comes out to B12. on a 7727, it comes out to B16.

further signal modification for a magnetic sensor is most easily done after the divisor since it's a variable frequency DC signal, rather than AC. if you can't get it close enough with the divisors, then that is the route to go. otherwise, you would have to buy commercial, like the dakota digital unit, or use a DRAC from a truck. me, being a DIY kind of guy, i have plans of using an ATTINY or ATMEGA(probably running on a version of Arduino) to allow for VERY fine resolution of a final divider/multiplier, just haven't wanted to write out code for anything lately, let alone something i've never worked with.