nAst1: Progress and Concepts Thread

[The_Raven]

It is hokey, but calculating barometric pressure is a bit tricky. It grabs it on ECM bootup before the engine is started, then it will readjust during driving conditions using the assumption that 100% TPS will roughly give you barometric pressure on the MAP (and some other heavy math). Problem is when you add boost and elevation changes. 100% TPS no longer gives you a hint at barometric pressure. Add to that the 5000+- ft elevation change that can happen and the problems compound.

Adding a dedicated 1 BAR MAP for barometric readings is a quick and easy way to implement it. There are averaging calculations ($8f) that can calculate a new barometric pressure, but to get instant accuracy a seperate sensor is the most effective method. If there are free a/d channels then why not?

Playing in excel I get a good resolution table at 26x32 size. If you run n/a you have a 26x16 table (just ignore the 100-250kpa columns)
400-3000rpm x200rpm increments
3000-7800rpm x400 rpm increments
20-100kpa x5kpa increments
100-250kpa x10kpa increments

Is the 1 BAR just used for BARO in nAst1?

The way it reads to me is that it uses the 1 BAR MAP for anything under 1 BAR of manifold pressure, then switches over to the 3 BAR anytime there is positive intake pressure. If that's the case, I can see there being transitional problems when going from vacuum to pressure.

[Google Adsense]

[brian89gp]

That is one way of looking at it, I had read it differently. Switching back and forth sounds complicated.

[robertisaar]

sorry about the ridiculous delays everybody, pirate wifi isn't always a consistent thing. :/

Throwing an idea out there for the MAF implementation. Using $2E as the reference.

MAF is relatively simple, set the constants for injector size and whatnot then based on actual airflow it will calculate BPW off of an A/F variable you give it. PE modifies this A/F variable. That is if I understand right.

exactly what i've been planning.

nAst1 is not really what I was expecting at all.

I'm disappointed with the push for MAF integration, something I will never use, given the choice.

If I understand the current integration correctly, I will need to run both a 1 BAR and a 3 BAR MAP sensors to take advantage of the 3 BAR MAP fueling and spark? Seems hokey to me, and also makes it difficult to swap between codes, to test, with more complexity than needed.

I would have hoped for a single VE table as well. The size of just one of those tables would give enough resolution for the entire RPM range that is being sought after here. With the 3 tables for VE, that equates to a 17x51 table! 17x17 for the entire range, at least in 1 BAR would be more than enough. $59 is 16 x 31 for the main VE table, with options to use just the main VE table or also have an idle/closed throttle table for those engines that have different VE needs at the same point (RPM x load). I find even the 16 x 31 adequate. Sometimes it would be nice to have a higher RPM range, but even my engine isn't going too far above the current table limits.
Maybe change it to a 1 BAR table, and then use a second table for above 1 BAR? Possibly set it up as 1 BAR, 2 BAR and 3 BAR tables? Even then it would still be nice to see it as a single table. Just read back through Brian's comments, it seems like he was suggesting the same thing.

The use of extra A/D inputs is exactly what I'd like with other ECMs and code as well.
It would be nice if there was at least one input that was even set to just spit out the counts on the ALDL datstream, to make it easy to integrate a WB02, or oil pressure, or fuel pressure, or second MAP (for logging pressure drops across intercoolers or throttle bodies, etc), basically something that doesn't even need to affect any of the calculated outputs (injector, spark, etc), just something used for logging and can be set-up however the user wishes.

High coolant temp cut is a VERY bad idea. You never want to shut down a hot engine, you always keep it running, either at idle or near idle, to bring the temp down. When you shut an engine off, the coolant is no longer flowing and can not remove the heat from the engine, after which heat soak occurs and will raise the engine temp even more for a short period. I have many times shut my engine off at 180* to restart it moments later at over 200*. This is why many engines also suffer from hot restart issues, where the fuel in the fuel rail actually gets boiled and becomes vapour in the fuel rail.

Valet switch for anti-abuse and theft deterrent reasons is easy enough to implement with a simple bin switcher. Using one bin set for "full performance" and the other for "valet/anti-theft". I bring this up, because you had already mentioned running out of space as it is, and the space needed to implement this in the code could likely be used for other more beneficial things.

Transaxle temp sensor is a neat idea.

VVT control would be great. I was at one time looking at a 3900 for my car, and would have had to use a VVTuner from MegaSquirt in order to get that to work.

If you're really going to add 2/3 BAR MAP support then boost control would be a given in my books. I'm not a fan of using boost controllers that are not attached to the ECM, when I can help it. $58/$59 (and I believe $8F) use a fail safe type boost control system, where the boost is wastegate spring pressure with no connection to the solenoid, and using a PWM output from the ECM, will hold the solenoid closed (not allow pressure through) to raise boost pressure from there. GM decided to go with a TPS based system, in $58 that would adjust overall boost in relation to TPS vs RPM, creating a 3D boost control table. $59 added the ability to change this to MPH based, still a 3D table (same location in the bin actually), just uses vehicle speed instead of TPS as the look up. The advantage of vehicle speed based is that you can use it as a quasi traction control to keep boost low at lower speed, and also filter out boost spikes that happen in some cases just after a gear shift, that would happen at around the same speed, when at WOT throttle.

Chris, things have changed a LOT in the time i've been offline. i'll try to address all of them:

MAF is in NO way a requirement, and can even only be set to "report" MAF readings, instead of a MAF generating it's BPW value as well. useful for getting an actual VE number, assuming the MAF is calibrated correctly.

the MAP sensor issue has been dealt with. i originally wanted to have a 1BAR used in addition a 2/3BAR for boosted cars for the sole purpose of barometric updates. i still may leave this as an option, but definitely not a requirement anymore. i have the 3BAR emulating a 1BAR at all times (and for the record, anything UP TO AND INCLUDING a 3BAR can be used now, just will need to set a few values correctly). not sure how easy it will be to update baro anymore with just a single sensor, but GM did it with 8F, i'll just have to look into exactly how.

the 3VE/Spark tables: back when i was doing my original code mods to make the tables with greater resolution, i wasn't 100% certain i was going to be dealing with boost, so i took advantage of the massive amount of free space and made the tables as they were. eventually, the desire for boost control came up, and since i seem to have this obsession with incredibly small resolutions, i really wouldn't want to convert back to a single table. it wouldn't be that difficult to convert the second table to have 400RPM increments instead of 200, and still achieve the full 8400RPM range, and free up enough space for two (since both VE and main spark are setup the same) 17 X 17 8 bit tables. at that rate, assume i use both of them for VE, i'll need two more 17 X 17 areas for main spark when in boost. at that rate, the tables would start at 100kPa, and go up to 300kPa in increments of 12.5kPa. per row/column and be using the RPM in 100 RPM increments up to 2000, and 4000 RPM increments to 8400.

does everyone agree that this would be the better compromise? if so, i would need to find/create roughly 580 bytes of free space to add in the extra tables, plus whatever the algorithm will take up. that amount of space just doesn't exist on the existing 32KB PROM. the boost BPW multiplier would still be necessary due to dealing with 8-bit logic, but above 100kPa fueling would primarily be dealt with in the new VE tables instead of that table alone.

extra A/D channels that are ONLY reported in the datastream are extremely easy to impliment(just do an A/D read and save to RAM, have ALDL stream setup to transmit that RAM location's value), however, making that possible, plus trying to use the rest of the channels intelligently, it's difficult, from a "will this work for everyone in every situation" point of view.

now that i think about it, i've had the exact same thing happen with my coolant temps in the summer. idling along getting to a gas station, coolant starts getting above thermostat rating, shut-off to refuel, then when i get back in, the guage (and datastream), both report an extremely high value compared to what was last seen, and after starting the temp drops VERY quickly down to the stat rating or even lower temporarily. so i guess that is a bad idea. oil pressure cut is still up for debate though, no?

transaxle(or really, any temp sensor can be used) has already been integrated in my newest alpha version, and i'm actually using it(as an option, of course), to modify the rate at which TCC PWM takes place.

VVT on the gen4 660s is definitely going to be a long-term goal, since as i discovered recently, to my disappointment, the IC used to watch what would be the cam sensor(to interrupt the CPU to let it know where the engine is in it's current cycle) is missing in a 9396. "FMD2", which interestingly enough is an identical part # as FMD1, so you technically could steal one from another P4 ECM(or take both from the ECMs that have 2 FMD chips), but soldering the PLCC package isn't going to be fun. most certainly, i'll eventually be doing that myself, since i REALLY want a 3900, but it isn't going to be something anybody can just do. that's simply for the closed loop control portion of VVT events, actually controlling the VVT system itself seems to be incredibly simple for what it does, it's just the tracking of changes and correcting them as necessary portion that's not going to be easy.

the more i think about it, the more i have to admit that boost control via the ECM is a good idea, i just didn't want to use another of the precious PWM outputs, since there were already basically 0 left open in a stock application. however, if EGR were disabled, that opens up 2 PWM outputs (assuming you were using the digital EGR to begin with). one of them i was planning on using specifically for gen4 VVT control (since they don't use an EGR to begin with), the other i was considering using for the LZ9's active intake, but i suppose i could leave that to being used on what would have been the EGR 2 circuit (discrete output).



you can see why it's difficult to make decisions like these, when trying to include as many people/applications as possible is a primary goal? information from the community is largely what drives the decisions i do make.

Is the 1 BAR just used for BARO in nAst1?

The way it reads to me is that it uses the 1 BAR MAP for anything under 1 BAR of manifold pressure, then switches over to the 3 BAR anytime there is positive intake pressure. If that's the case, I can see there being transitional problems when going from vacuum to pressure.

That is one way of looking at it, I had read it differently. Switching back and forth sounds complicated.

read above, that WAS how i was going to do things, but obviously plans have changed.

[95cutlassproject]

I feel yeah on the pirated internet. Welcome back

[brian89gp]

VVT on the gen4 660s is definitely going to be a long-term goal, since as i discovered recently, to my disappointment, the IC used to watch what would be the cam sensor(to interrupt the CPU to let it know where the engine is in it's current cycle) is missing in a 9396. "FMD2", which interestingly enough is an identical part # as FMD1, so you technically could steal one from another P4 ECM(or take both from the ECMs that have 2 FMD chips), but soldering the PLCC package isn't going to be fun. most certainly, i'll eventually be doing that myself, since i REALLY want a 3900, but it isn't going to be something anybody can just do. that's simply for the closed loop control portion of VVT events, actually controlling the VVT system itself seems to be incredibly simple for what it does, it's just the tracking of changes and correcting them as necessary portion that's not going to be easy.

I am assuming the 727/730 have both FMD parts? Why not just use one of those and go the route of adding NVRAM to it instead of starting with the 9396? Much like this idea:
http://www.thirdgen.org/techboard/di...ion-board.html

You get the commonality of the 727/730 vs the 9396, twice the amount of RAM, and using the NVRAM chip it is battery backed.

http://www.moates.net/nvsram-module-....html?cPath=50
They are using it as an emulator, but you could probably use it for extra RAM space.

[brian89gp]

the 3VE/Spark tables: back when i was doing my original code mods to make the tables with greater resolution, i wasn't 100% certain i was going to be dealing with boost, so i took advantage of the massive amount of free space and made the tables as they were. eventually, the desire for boost control came up, and since i seem to have this obsession with incredibly small resolutions, i really wouldn't want to convert back to a single table. it wouldn't be that difficult to convert the second table to have 400RPM increments instead of 200, and still achieve the full 8400RPM range, and free up enough space for two (since both VE and main spark are setup the same) 17 X 17 8 bit tables. at that rate, assume i use both of them for VE, i'll need two more 17 X 17 areas for main spark when in boost. at that rate, the tables would start at 100kPa, and go up to 300kPa in increments of 12.5kPa. per row/column and be using the RPM in 100 RPM increments up to 2000, and 4000 RPM increments to 8400.

does everyone agree that this would be the better compromise? if so, i would need to find/create roughly 580 bytes of free space to add in the extra tables, plus whatever the algorithm will take up. that amount of space just doesn't exist on the existing 32KB PROM. the boost BPW multiplier would still be necessary due to dealing with 8-bit logic, but above 100kPa fueling would primarily be dealt with in the new VE tables instead of that table alone.

I still like this arrangement. 250kpa is 22psi of boost which is a decent amount for any engine that this controller would be used for.

Playing in excel I get a good resolution table at 26x32 size. If you run n/a you have a 26x16 table (just ignore the 100-250kpa columns)
400-3000rpm x200rpm increments
3000-7800rpm x400 rpm increments
20-100kpa x5kpa increments
100-250kpa x10kpa increments



The total table size for the VE/Spark tables with the 26x32 size is 1664 bytes, your current tri 17x17 is 1734 bytes. It would fit in the existing space you have already used. (disclaimer, it has been a while and I don't remember if you did the tri 17x17 for both spark and VE or just one of them)

[robertisaar]

I am assuming the 727/730 have both FMD parts? Why not just use one of those and go the route of adding NVRAM to it instead of starting with the 9396? Much like this idea:
http://www.thirdgen.org/techboard/di...ion-board.html

You get the commonality of the 727/730 vs the 9396, twice the amount of RAM, and using the NVRAM chip it is battery backed.

http://www.moates.net/nvsram-module-....html?cPath=50
They are using it as an emulator, but you could probably use it for extra RAM space.

unfortunately, the only one in the group to receive both FMD circuits was the 7749. the only reason why was for the dual injector drivers and in the case of the one year only(?) Quad4 with a 7749, for the 1X signal processing, which was also used for the dual injector driver stuff.

and i did have potential plans for using at least some of the extended RAM for pseudo-emulation, in very much the same manner, since as-is, 2KB? i could never fill that up with efficienct use for storing values.

[robertisaar]

3BAR code is finished, or at least the first version of it is. when i determine if the 9396 can run a 64KB BIN after some mods, then V2 of the boost code will be patched in, making 4 17X17 VE and main spark tables each(2 for boost, 2 for non-boost). there will be 400-2000 in 100 RPM increments, then 2000-8400 in 400RPM increments. MAP will be in 5kPa increments up to 100kPa. after 100, a 12.5 kPa increment will be present.

tl;dr version:
http://i.imgur.com/TI8uT.png

essentially, in non-boosted applications, you'll drop down to 2 spark and 2 VE tables, while boosted will have 4 of each.



but, that's the furure, assuming i can open up some more space by jumping to a 64KB PROM. as-is, there's a boost BPW multiplier table (quite similar to 8F), and a boost spark retard table (my own design). the new version will still have the BPW mult table(in fact, it's a requirement due to all other things being equal, more pressure = more air), but it won't be changed much, since VE will be the primary way of changing fueling. the spark retard table will obviously no longer be necessary at that point and it will be removed from the XDF and it will clear up a few bytes for me to use elsewhere.



anyways, to run boost, a 9396 is required(or mod a 7730), since some of the variables are stored in the SRAM, but no internal mods are needed...

speaking of internal mods, you can open up at least 3 more A/D channels that way just by moving a couple of resistors around on the board.



code will be tested as soon as i have the bench completely built(like ~90% there right now), afterwards, a real-world test with a turbo LQ1/284 is NOT far behind.

[19Cutlass94]

So now the possibility of boosting the car comes to mind... Damn you Robert!

[robertisaar]

boost is always on the mind....

MAF's can read boost as well, just can't measure it obviously. i need to get that code tested as well....

also, anybody who's planning on running MAF and speed-density, does the concept of being able to skew the fueling towards one or the other sound interesting?

currently, if the MAF option is set, it will blend the two BPW calculations together with no bias(meaning real BPW will be the average of the two), however, i may be able to setup a scalar to adjust one way or the other, depending on which you like more.