[jpsimon]

well you're half right... one of the benefits is no throttle closure, but what you're referring to in that graph isn't accurate. The whole graph is the "before" graph... What you're talking about is actual throttle and CAN throttle. So in this graph there is throttle closure, but once Shiv posts up the "after" i have a feeling that will be greatly reduced

Originally Posted by Glowin

OOOHHH!!! NMTC - No More Throttle Closure! YAY!

In the first graph, looks like two lines are superimposed, one I take it being the before, the other the after.

Notice how the blue line which must be the before shows throttle closure, but the black line doesn't? Shows 100%!
.
.

[Glowin]

Originally Posted by jpsimon

well you're half right... one of the benefits is no throttle closure, but what you're referring to in that graph isn't accurate. The whole graph is the "before" graph... What you're talking about is actual throttle and CAN throttle. So in this graph there is throttle closure, but once Shiv posts up the "after" i have a feeling that will be greatly reduced

LOL! Ooopss! Got too excited a bit early I guess! Thanks for clarifying.

PS Is there a quick explanation of why there's throttle closure like that by the DME? Like what causes it and is it fixable any way other than using Shiv's new maps?

I've got some issues with mine, where on EVERY single log I've done (tried various maps from 7-29 to 11-2, at various UT's equal to or less than default), at EXACTLY 4100 RPM there's a 1 PSI blip in boost, with a corresponding drop in Actual Ign Advance, and throttle closure like in that first graph.

Thanks for the help!

[Clap135]

the only thing i found that cause throttle closure is when target boost is surpassed....meaning the map clamp at that point is wrong.

[Kelvin1000]

Looks like this graph is pointing to throttle closure and measuring boost target error / lag. Lets see what the after graph looks like after the new CANbus boost logic...

Gotta give it a catchy name... I vote for CANboost Logic.

[shochu75]

Originally Posted by shiv@vishnu

Flashes have had access to CAN boost target. Where they didn't do so well was their ability to have the boost control system adjust it's DC mapping in order to hit the target without any over/undershoot. Which is why you see throttle oscillation on flashed cars. Especially when running a map that is mismatched to your mods.

Piggybacks, on the other side of the coin, have never had access to CAN boost target. However, unlike reflashes, they has offered the ability to apply additive PID boost logic in an effort to minimize oscillation and undesired throttle closure. The other upside to this is that they are reasonably insensitive to running map that wasn't designed for a given set of mods.

We are now taking the best of both worlds due to the PROcede's unique ability to read/write CAN data. A true stand alone boost control system that works with the DME's boost target/actual/error data and actively adapts realtime.

The advantages will be even better boost response than we currently have, a completely elimination of throttle closure, perfect targeting consistency, better partial throttle torque response, elimination of actual boost "slop", and a boost control system that hits the target immediately instead of coming 2-3psi shy of it and gradually creeping upwards from there (as it currently does in most cases when full load is demanded).

BTW, the log posted represents a "before" result. The after result will look quite a bit different

Shiv

and I jizz in my pants!

[ianthegreat]

Originally Posted by shiv@vishnu

No one is even close. lol

The new meth bits are relatively minor compared to the profound changes in boost control logic and adaption. See all those new CAN boost channels? Those were never there before....

Shiv

[oddjob2021]

shiv- i for one am very excited. great work, always pushing the bar! i hope you will send your work/findings over to abid who will make it work with his upped turbos?

Originally Posted by kenneth

I see that over 9 seconds (2s to 11s) the boost graph is so smooth that even shift points doesn't show boost variation. There must be shift points over 9 secs right?

as for this why? couldnt he be in a high gear, low roll... that would take some time to get to redline...

[Malaka1]

When will the beta maps be ready!?!?

[ridin135]

Originally Posted by Malaka1

When will the beta maps be ready!?!?

+1 Can't wait

[ren]

Hey Shiv,

Thanks for the update.
How did you get more than 10 logged channels in there? I can't do that with the v3.121 software.

[TMR]

I thought we were going to get more info last night?

[Joshboody]

Ok dumb question... I would like to understand the CANbus better. I am no electrical type engineer person so a very simple explaination would be awesome. The way I think I understand currently and some questions:
1. The CANbus is a computer logic, serial wiring system that connects sensors and actuators.
2. There can be multiple CAN systems on a car
3. Each CAN system is connected by a host and the host communicates with the ECU
4. The Proceed is inbetween the host and ECU? OR intercepting the sensor data directly before the CAN host?
5. Proceed is changing the CAN data thus reading it first as logged data and then changing it before ECU reads it?
6. Proceed logs actual boost, but target boost would be actual + correction.

OR does the procede add this "CANbus" thingy and it's an addition.

[Prince ///M]

Originally Posted by Joshboody

Ok dumb question... I would like to understand the CANbus better. I am no electrical type engineer person so a very simple explaination would be awesome. The way I think I understand currently and some questions:
1. The CANbus is a computer logic, serial wiring system that connects sensors and actuators.
2. There can be multiple CAN systems on a car
3. Each CAN system is connected by a host and the host communicates with the ECU
4. The Proceed is inbetween the host and ECU? OR intercepting the sensor data directly before the CAN host?
5. Proceed is changing the CAN data thus reading it first as logged data and then changing it before ECU reads it?
6. Proceed logs actual boost, but target boost would be actual + correction.

OR does the procede add this "CANbus" thingy and it's an addition.

The Procede works as an additional node on the CAN bus dedicated to the engine.
It is able to 'sniff' all data flowing on this specific line but cannot overwrite/modify any signal already sent by other sensors/ecus (beside possible blinking of warning signals that in normal operational conditions are not used)

The engine tune is performed as usual by intercepting and sending back modified signals directly to the wires cabled to engine ecu.

[dmurray14]

Originally Posted by Prince ///M

The Procede works as an additional node on the CAN bus dedicated to the engine.
It is able to 'sniff' all data flowing on this specific line but cannot overwrite/modify any signal already sent by other sensors/ecus (beside possible blinking of warning signals that in normal operational conditions are not used)

The engine tune is performed as usual by intercepting and sending back modified signals directly to the wires cabled to engine ecu.

Do you know this to be true? I was under the impression that the procede intercepts the CAN data inline and spits it out on the other end, not just merely listens to it. I could certainly be wrong though.

[jpsimon]

Originally Posted by dmurray14

Do you know this to be true? I was under the impression that the procede intercepts the CAN data inline and spits it out on the other end, not just merely listens to it. I could certainly be wrong though.

yeah, pretty sure shiv has stated the procede can read/write CAN data

[Joshboody]

if it didn't change the data then the ECU would read actual boost for example... right? I think Prince means that other CANbus's are read but not altered

[dmurray14]

Originally Posted by Joshboody

if it didn't change the data then the ECU would read actual boost for example... right? I think Prince means that other CANbus's are read but not altered

No, because as far as I'm aware MAP isn't transmitted over the CAN bus, rather sampled directly at the ECU. So this would be a signal-level change the Procede is doing (and has been doing since way back when, I assume).

[Joshboody]

i'm confused about the wiring and CAN host locations because all piggy wiring is contained within the ECU box with most or all piggies. JB does not read CAN data right (or does it), but has the ability to change the boost measurement signal to the ECU, so how is boost intercepted? older JB's were inbetween the sensor and CANbus, but not the newer i think.

[Joshboody]

Originally Posted by dmurray14

No, because as far as I'm aware MAP isn't transmitted over the CAN bus, rather sampled directly at the ECU. So this would be a signal-level change the Procede is doing (and has been doing since way back when, I assume).

ok, this would explain

[dmurray14]

Originally Posted by Joshboody

i'm confused about the wiring and CAN host locations because all piggy wiring is contained within the ECU box with most or all piggies. JB does not read CAN data right (or does it), but has the ability to change the boost measurement signal to the ECU, so how is boost intercepted? older JB's were inbetween the sensor and CANbus, but not the newer i think.

Again, boost (MAP) isn't transmitted over the CAN bus. It is sampled at the ECU, with a wire running directly from the sensor (wherever it is) to the ECU. At least that is my assumption based on my limited knowledge of how pressure is measured in this car.

Edit: nevermind, guess you saw the above post

[Joshboody]

but procede is reading actual boost without correction like for timing. Boost sensor in manifold still sends actual to ECU?

[dmurray14]

Originally Posted by Joshboody

but procede is reading actual boost without correction like for timing. Boost sensor in manifold still sends actual to ECU?

Again, I'm going to preface this by saying I don't know too much about the Procede internals, but based on what I do know, the signal likely goes something like this:

MAP Sensor -> Procede -> ECU

That would mean that the Procede sees the real value and uses it, while sending out a modified value to keep the ECU happy.

I'm sure Shiv could explain better/in more detail, but that seems to be the general idea.