nAst1: Progress and Concepts Thread

[robertisaar]

i can honestly say i've never encountered a CPLD that i know of... what kind of cost/complexity issues are there to deal with?

i got A15 up to the MEMCAL via the edge-card connector, i removed that pin from the PCM's board, mounted it back into the connector and run a jumper over to the pin on the edge-card that is responsible for A15.... there is probably a better way, but that was good enough for the time.

[brian89gp]

interesting thought: on a 9396 there already exists on the board an address decoder that breaks the addresses down into 2KB blocks.... the one occupying 1800-1FFF is used by the SRAM though.

but the 800-FFF, 1000-17FF, 2000-27FF, 2800-2FFF and 3000-37FF blocks are free..... that's 10KB of space without adding in additional address decoders. that would solve quite a few space problems, but not everyone is running a 9396, nor is everyone comfortable with soldering wires to a PLCC package.

It would be pretty easy to use a CPLD on a MEMCAL adapter board to drive the chip select of a EEPROM/FLASH/NVSRAM for just about any address space you want as long as you get A15 up to the board. No latency issues from stacking 7400 logic chips either.

[ericjon262]

Steady employment is a plus, Good luck with it!

[robertisaar]

unfortunately, no.

the one time in the past couple of years that i've managed to secure steady employment and i've been busting ass pretty much every day and feel like crap by the time i get down to doing things i want to do.

it will likely slow down soon, but i don't know by how much.

[ericjon262]

any updates for us?

[robertisaar]

interesting thought: on a 9396 there already exists on the board an address decoder that breaks the addresses down into 2KB blocks.... the one occupying 1800-1FFF is used by the SRAM though.

but the 800-FFF, 1000-17FF, 2000-27FF, 2800-2FFF and 3000-37FF blocks are free..... that's 10KB of space without adding in additional address decoders. that would solve quite a few space problems, but not everyone is running a 9396, nor is everyone comfortable with soldering wires to a PLCC package.

[robertisaar]

no VSS is always going to be tricky since so much of the stock throttle follower code is dependant upon a good VSS signal.... if i couldn't run a VSS for whatever reason, i would probably look at modifying a few things. idle spark correction(have it skewed to add noticably more advance when underspeed than what gets pulled during overspeed), the IAC PID settings(similar to idle spark correction, let the ECM open the IAC a lot faster than it would close it), F16 table might be useful? the first two require the ECM to recognize an idle condition to work as well, if it doesn't consider the engine to be at an idle, it will let it stall without doing much if anything at all.

if it's happening right as the clutch pedal goes in, then that might require something else.

[caffeine]

What settings would you recommend for running an engine without a VSS? Stock settings seem like they have a tendency to stall when you're coming a stop and you put the trans in neutral.

[robertisaar]

when i have bench v2.0 built, pretty quick to test stuff at that point.

as-is, i have some partially open circuits somewhere in my bench harness that are causing interesting operation, probably due to some rough use of it. i'll have to account for that better with the next version, which is going in a larger, easier to service container.

i'm also using voltage controlled oscillators instead of 555s for pulsed signals, since while the 555 give good resolution at lower frequencies, the upper ~1/3 of the knob is crazy sensitive. the VCOs should be MUCH more linear.

[caffeine]

Any progress on a 1.08 release?

[robertisaar]

neat thing i found out while troubleshooting my existing testbench(which i'm going to have to rebuild to continue testing stuff):

the 8-bit MPH value reported over the datastream? if you run up to 255MPH, it wraps back around to 0MPH and climbs again......

i think i counted 5 full "wraps" of 255MPH before things started looking really weird(couldn't tell if counting up or down). that is over 1,275MPH. i believe this was with me running 4,004 pulses/mile as a road speed constant. going off of some rough math, that is a frequency of 1.42KHz. i don't know the value of the cap used in the low-pass filter for the magnetic VSS signal, but if it is 1nF like i suspect it might be, the filter is setup to allow frequencies up to 3.12Khz. so i was at roughly half of what the filter allows? as far as i could tell, it looked like speed was still incrementing at 1MPH intervals too, so reasonable accuracy could be expected?




also, believe i may have figured out why i couldn't get the high speed comms working.... from what i can tell, the SXR IC(the one responsible for creating the ALDL stream) doesn't support anything other than 8192 baud..... while if you were to add in your own flavor of UART transciever, you could run the ridiculous speed stuff.

[unchained01]

I bet both of those sensors are identical internally, the haltech unit just having a fancy case...

And a 300 percent mark up LOL I think so too

[ericjon262]

I bet both of those sensors are identical internally, the haltech unit just having a fancy case...

[unchained01]

I can see for obd-I and your knowledge that would be great I am running OBD-II

[robertisaar]

i'm not sure why a guage would be needed? unless you wanted to be able to check fuel composition without using the datastream, in which case it makes sense.

if i wanted to monitor composition with reasonable accuracy, i would run the variable frequency signal through a converter, then setup a LED bar meter that changes in relation to voltage. i know there are at least 10-dot resolution versions out there, which isn't horrible, i guess.