[Prince ///M]

It is impossible to modify a can bus message by overwriting it.
The boost data flowing on the bus (for example) are always sent by the engine ecu and must respect the BMW ranges. The modification of such signals is operated as on all the piggys by physically intercepting the wires originally cabled to the engine ecu and subtituting them with the Procede ones.

The only messages on can bus that the Procede is able to influence without relevant drawbacks are the various activation commands (such as the code clearing) that are not frequently updated by other nodes on the network.

[RiXst3r]

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.

Piggybacks have always worked only by fooling the ECU by shifting the analog (or some PWM) sensor readings. This is how jb and other non-canbus piggybacks work.

The canbus is a DIGITAL network containing the data of over 200 real-time parameters being pulled, calculated, and read by the DME, The PROcede is the ONLY piggyback, EVER, to listen or talk on the canbus network.... which allows the procede to modify its analog sensor signals based on this data, as well as talk directly on this digital network to get the car to do things like flash the SES light, or hit its exact boost targets.

It takes piggyback tuning to a whole 'nother level... as you now have access to all the fun stuff that only a flash could do in the past, and then you have more contol than a flash, because you can actually deploy your own boost control logic by directly controlling the wastegates and other signals with the piggyback, allowing for an even greater level of control than any flash or piggyback has ever seen.

That's how I understand it anyways

-Rick

[scottp999]

Originally Posted by Prince ///M

It is impossible to modify a can bus message by overwriting it.

I wonder what is meant by this then? Need more info for clarification.

Originally Posted by shiv@vishnu

...due to the PROcede's unique ability to read/write CAN data. Shiv

[dmurray14]

Originally Posted by Prince ///M

It is impossible to modify a can bus message by overwriting it.

No, but it would be possible to intercept the message with one CAN transceiver and repeat a modified message out another.

[Prince ///M]

Originally Posted by dmurray14

No, but it would be possible to intercept the message with one CAN transceiver and repeat a modified message out another.

This is possible, but absurd for the kind of application because you had to replicate hundred of messages in order to change five of them (not to say the safety related issues and the unavoidable time delay induced).

P.S.
The engine is NOT using Can bus messages in order to work properly. It relies on the hardwired sensors only. The mesaages are communicated on the bus in order to share them with other subsystems and for debug.

[dmurray14]

Originally Posted by Prince ///M

This is possible, but absurd for the kind of application because you had to replicate hundred of messages in order to change five of them (not to say the safety related issues and the unavoidable time delay induced).

I think you'd be surprised, but who knows.

Originally Posted by Prince ///M

P.S.
The engine is NOT using Can bus messages in order to work properly. It relies on the hardwired sensors only. The mesaages are communicated on the bus in order to share them with other subsystems and for debug.

That's what I was saying as well.

[Prince ///M]

Originally Posted by scottp999

I wonder what is meant by this then? Need more info for clarification.

As already mentioned in my previous post it can write messages, but only for activations and some light blinking.

The great potential of the canbus integration is on READING messages such as boos target and actual ignition advance.

[Prince ///M]

Originally Posted by dmurray14

I think you'd be surprised, but who knows.

I really don't think so, because smart people such as Shiv and the Haltech guys don't perform unuseful actions.

[F104]

quote: "The CAN bus is a broadcast type of bus. This means that all nodes can "hear" all transmissions. There is no way to send a message to just a specific node; all nodes will invariably pick up all traffic. The CAN hardware, however, provides local filtering so that each node may react only on the interesting messages" unquote.

So one can pick up a can message with another device (node) and replace that message with a different value. But by then the ECU will have received the original unmodified message already and must be throwing up fault if it sees the same message coming it at double frequency but with two different values?

[ragingclue]

CAN messages are broadcast to all nodes on the bus, but messages are set up with 11 or 29 bit identifiers, and each device has filters set to "nab" the messages that pertain to it. At least, that's how it works in the industrial automation industry. We actually do CAN projects with Bosch on automotive components.

If you set up a device in-line from a source, and have it catch all identifiers, repeat those which its application layer determines don't need modification, and modify then resend the ones that do need modifying, then I can see how this would work; however, I'm unsure as to the effect, if any, of the delay or skewed timing of those messages.

[jpsimon]

hopefully shiv can chime in soon when he gets a chance and just put an end to the speculation

[JackFlash]

Originally Posted by jpsimon

hopefully shiv can chime in soon when he gets a chance and just put an end to the speculation

There is no speculation, only people correcting misinformation provided by your tuner. You can not modify sensor signals via CANbus. Only read existing signals. In addition the PROcede is wired to "tap" the CANbus signal not intercept/retransmit so even the imaginary solution of capturing and retransmitting is not plausible. I say imaginary because the signals originate in the ECU from hard-wired sensors and are transmitted out for other modules to reference. Not read by the ECU via CANbus as some have suggested.

[Prince ///M]

Originally Posted by JackFlash

There is no speculation, only people correcting misinformation provided by your tuner. You can not modify sensor signals via CANbus. Only read existing signals. In addition the PROcede is wired to "tap" the CANbus signal not intercept/retransmit so even the imaginary solution of capturing and retransmitting is not plausible. I say imaginary because the signals originate in the ECU from hard-wired sensors and are transmitted out for other modules to reference. Not read by the ECU via CANbus as some have suggested.

Finally.
One of the few worth to discuss with here (about technical stuff at least) .

[JackFlash]

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

Flashes do not exhibit signs of boost control problems or throttle closure unless the tables are poorly tuned, in which event they show exactly what they should be showing. See the latest GIAC Stage 2 dynos as examples of very solid boost control. This business of going up to target slowly to avoid overshoot is PROcede piggyback specific problem and related to your tuning and logic, not some inherent limitation as you are suggesting here. Looking at your logs even going up to target slowly is not prevent the boost overshoot, probably triggering this complete redesign.

[Prince ///M]

Originally Posted by JackFlash

Flashes do not exhibit signs of boost control problems or throttle closure unless the tables are poorly tuned, in which event they show exactly what they should be showing. See the latest GIAC Stage 2 dynos as examples of very solid boost control. This business of going up to target slowly to avoid overshoot is PROcede piggyback specific problem and related to your tuning and logic, not some inherent limitation as you are suggesting here. Looking at your logs even going up to target slowly is not prevent the boost overshoot, probably triggering this complete redesign.

On the GIAC Stage II logs (fully modded car) I analyzed, the engine still presents significant events of throttle closure after sudden boost request during road tests (very few on the dyno).

[enrita]

Good information guys, at least this will help less technical people to understand what is actually going on here with this CAN bus.. Helped me to understand better this point.

[OpenFlash]

Originally Posted by Prince ///M

On the GIAC Stage II logs (fully modded car) I analyzed, the engine still presents significant events of throttle closure after sudden boost request during road tests (very few on the dyno).

You'll often see throttle closure and boost oscillation evidence on the GIAC tune at high rpm (above 5500rpm). I believe this was explained to be caused by unnatural dyno loading?

And anyone who has datalogged the flash, can attest to throttle closure events while driving. It's just interesting that so many people are of the opinion that flashes are immune to such issues when, in fact, they are more prone to it.

Shiv

[cstmx_ryder]

CANBL for short? (like Campbell soup.......lol)

Originally Posted by 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.

[jpsimon]

Originally Posted by JackFlash

There is no speculation, only people correcting misinformation provided by your tuner. You can not modify sensor signals via CANbus. Only read existing signals. In addition the PROcede is wired to "tap" the CANbus signal not intercept/retransmit so even the imaginary solution of capturing and retransmitting is not plausible. I say imaginary because the signals originate in the ECU from hard-wired sensors and are transmitted out for other modules to reference. Not read by the ECU via CANbus as some have suggested.

speculation about how the new system will work, that is. not about what "canbus" is...

[Prince ///M]

Originally Posted by shiv@vishnu

You'll often see throttle closure and boost oscillation evidence on the GIAC tune at high rpm (above 5500rpm). I believe this was explained to be caused by unnatural dyno loading?

And anyone who has datalogged the flash, can attest to throttle closure events while driving. It's just interesting that so many people are of the opinion that flashes are immune to such issues when, in fact, they are more prone to it.

Shiv

No boost oscillation at all in the dyno datalog I received (Maha inertial dyno).

Maybe the rollers inertia of the Maha is higher respect to the dynojets commonly used in USA. The test I'm speaking of lasts 15 seconds for a complete pull from 2000 rpm to redline.

From your log I see a total time of about 9s: I imagine we are talking of a complete IV gear dyno test also in this case.

If so, my assumption would be confirmed (together with GIAC claims)

P.S.
The boost build up on the first graph you posted (so the old boost logic) is still very similar to the GIAC one I received.

Probably also faster considering the higher pressure level reached and the lower load due to the Dynojet.

[HighVoltage]

Originally Posted by ragingclue

CAN messages are broadcast to all nodes on the bus, but messages are set up with 11 or 29 bit identifiers, and each device has filters set to "nab" the messages that pertain to it. At least, that's how it works in the industrial automation industry. We actually do CAN projects with Bosch on automotive components.

If you set up a device in-line from a source, and have it catch all identifiers, repeat those which its application layer determines don't need modification, and modify then resend the ones that do need modifying, then I can see how this would work; however, I'm unsure as to the effect, if any, of the delay or skewed timing of those messages.

Considering the data bus rate on this particular bus, the latency would be minimal, even given the Procedes uC. Ive done 4 bus gatways @ 1Mbit with little impact on less capable cpus. Besides no one is relying on canbus for true realtime data, as mentioned that is what the direct signals are for...

[ragingclue]

Originally Posted by HighVoltage

Considering the data bus rate on this particular bus, the latency would be minimal, even given the Procedes uC. Ive done 4 bus gatways @ 1Mbit with little impact on less capable cpus. Besides no one is relying on canbus for true realtime data, as mentioned that is what the direct signals are for...

Yeah I should have stated I have no idea how the Procede works or what signals travel via canbus vs direct. I was simply stating that it was totally plausible for a properly designed system to read and write to the bus. I don't know if the Procede is set up as an in-line gateway though, which would be required. I should probably look into all this info, as this thread has really piqued my interest.