nAst1: Progress and Concepts Thread

[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/diy-prom/326987-4kb-nvram-expansion-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-kit-p-130.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.

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

[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/diy-prom/326987-4kb-nvram-expansion-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-kit-p-130.html?cPath=50

They are using it as an emulator, but you could probably use it for extra RAM space.

[95cutlassproject]

I feel yeah on the pirated internet. Welcome back

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

[brian89gp]

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

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.

[brian89gp]

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.

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

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.

[brian89gp]

http://www.bmotorsports.com/shop/product_info.php/products_id/1720

Integrated IAT plus it screws on, don't run the risk of popping off the hose or the various other (plastic) attachment methods the GM 2/3 BAR tend to use.

2.5 BAR = ~250kpa
8 bit = 256

Plus, 22psi is probably enough.

[brian89gp]

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.

So...

Keep the existing 16x16 MAF AFR table for open loop operations (though the entire thing is pretty much 14.76 or 15.03) but convert it to a 0-100kpa scale instead of LV8. The BPW calc still calculates everything the exact same way, just pulls the A/F variable from a table scaled by kpa. For PE have 1x16 tables for coolant and TPS modifiers and add one huge 32x32 MAF AFR table with a 0-300kpa scale, when in PE mode it switches to this 32x32 table instead of the 16x16 open loop one.

This has the Speed Density style tunability with the MAF simplicity. It would take a little while to get the base pulse variable set so that 14.76 AFR in the table equals 14.76 AFR from the tailpipe, but after that it easy. Any reason an idea like this would not work?


Scaling the MAF tables by kpa might allow for a single 32x32 table for both open loop and PE modes. Might (almost) eliminate the need for PE too since the kpa reading is somewhat tied to the TPS value, ie its hard to have a low kpa reading with a 75% open throttle or a high kpa reading with a 10% open throttle. There has got to be a reason this isn't a good idea or some horrible gotcha....if it were that easy then why isn't it done this way to begin with?

[brian89gp]

I retract my comment about the 5v MAF. There is more then enough MAF's out there for the LS1 and L67 to keep me happy using a GM one. Plus it would be easier to just lift the $2e code that way.

[brian89gp]

I see a large block of free space between 1FEB and 10E0 (3851 bytes) on the stock AXKK bin, enough to fit three 32x32 tables (VE, Spark, MAF AFR) with 800bytes left to spare. 32x32 should be enough for decent RPM resolution and 3 BAR.

Or if you so choose, enough to put your two 48x16 VE/Spark tables in sequential order. Would make it easier in the tuner to have one large table vs three of them.

Not nitpicking I swear, just brainstorming.


edit:

If you are concerned about loss of resolution, you could make the first 16x32 (or 48 if you prefer) the 1 BAR area, column 16 would be 100kpa. The second 16x32/48 would be 100-300kpa (column 17-32)

And thank you greatly for bringing IDA to my attention.

[SappySE107]

Its not too bad but its a lot more specific for RPM vs MAP with all those cells and it can become a game of wits if you chase every cell individually.

[brian89gp]

Howdy Ben.

Holy tables batman! Well, I guess you can't ever complain about not having fine enough RPM resolution anymore. How hard is that to tune?

I hate to suggest it (because I know what you would do with the tables....48x48...2304 cells/bytes...) but I would drop the boost BPW modifier and boost spark retard tables and convert the main VE and main spark table to 3 BAR. More accurate that way and easier for a less experienced person to just pick it up and start tuning. Probably would have to move down to 32x32 tables just to get them to fit.

Can the P4 PCM's read the extra space in 512 chips?