[jale france]

Originally Posted by adrian@vishnu

.

We think that our customers value this and are willing to spend a bit more to have a product that does it all without having to get extra modules if desired that end up taking it to similar money.

I'm agree with that !

[Mike@N54Tuning.com]

Originally Posted by adrian@vishnu

Theoretically it is possible that any module on the CAN bus could record VMax, but it is unknown if any unit does. Frankly a BMW tech is about the last person I would trust on giving accurate info about that. Nost would not know and just regurgitate what is presented to them, and what is presented to them is what BMW Germany wants us to think. However one thing that is known is that out of the 100s of people running speed delimitters, there is not a single instance of this causing any issue to warranty or otherwise. So people can assess the risk for themselves.

I suspect the reason the DME has direct sensor access has little to do with the CAN sample rate (which is very fast), and more to do with the fact that the DME must continue to run the car in some drivable form in the event of a CAN bus failure (say CAN_H and CAN_L are shorted togeather).

You are right that it is quite possible to do the speed delimitting function in cheap low end processors. But the issue is that to do it along with other high rate features requires a higher end processor. It would be possible to construct a unit similar to the Procede with several cheap low end processors all doing different things, but it would be a headache, and cost saving would be minimal. Having a single processor to do everything means that we do not have to worry about communications between modules, software upgrades to multi modules etc. We can implement a change to the O2 sims or speed delimitter as a firmware upgrade to the unit which can be done without removing the tray to get to the ECU in a few minutes. We think that our customers value this and are willing to spend a bit more to have a product that does it all without having to get extra modules if desired that end up taking it to similar money. Evidently both approaches have appeal in the market to each others customer base which seem to be characterised quite differently.

I can't remember what the voltage is of the wheel speed signal, so cannot comment on whether it can be done without 12V, but neither do I care. Adding the 12V during a Procede install takes about 30 seconds, and provides significant benefits. My personal engineering take is that to suck 5V from the DME which has not been power budgeted in the DME design has some risks. However BMS has done it successfully, so I cannot deny that it works. I just don't think it is the most robust solution from an engineering perspective, but I am a pretty conservative engineer. The Procede is a very robust design and follows modern electrical engineering practises.

I only brought up the simplicity of the hardware required for the SLD as someone had suggested it was impossible with the 18F. So that it has been done with the 12F refutes that.

From BMS' perspective offering these parts like the downpipe fix ala-cart makes sense as many customers use them with flash tunes, TMAP tunes, older procedes, etc. This method allows those to add on the feature without having to upgrade or replace their tune. Same goes for the speed limit defeat. Most (myself included) have no intentions or desire to exceed 155mph even if warranty was not an issue and are happy to save some money and complication up front. Those select few who want it can always pop it in the PnP harness later.

Mike

[adrian@vishnu]

I have not looked up the post from Shiv, but I believe he was suggesting that the JB3 processor could not do it at the same time as the many other tasks that need to be done when running an engine.

In truth, the task of speed delimitting is much less that crank sensor offsetting. With the speed delimitting you are only translating the frequency. If a processor has the right peripherals, this is not that difficult. With crank sensor offsetting, you are translating the phase of every edge to 0.1 degree accuracy. This means the processor has to calculate the position of each of the 116 edges in each revolution, and it is a complex calculation. At 7000RPM, that is 116 revs per second which is calculating edge positions at 13.5kHz (13500 times per second). This is by far the most processor intensive task done in the Procede, but we still manage to do speed delimitting (which gets to many kHz also) as well as read and create the boost PWMs, and all the other many things that need to be done.

So we chose a higher end processor to future proof us for these features we have added. We have only had one upgrade of the main unit, and that was to reduce our costs and integrate features that were previously external. There will not be another as we have still got alot of room to move with this hardware.

BMS did it a different way. Given your goals you mention, the BMS method makes good sense. We had different goals, and as a result our product and customers are different. But if not for the cost difference, I think there is little doubt which approach is superior. You have many customers, but I would be surprised if any made the choice because the JB3 has superior hardware/features. If there is any feature the JB3 does that Procede does not do it is our choice.... not inability of the hardware.

Adrian

[raylandm]

the bald guy that chases bugs bunny all the time.

Originally Posted by cstmx_ryder

What's FUD?

[Mike@N54Tuning.com]

Originally Posted by adrian@vishnu

I have not looked up the post from Shiv, but I believe he was suggesting that the JB3 processor could not do it at the same time as the many other tasks that need to be done when running an engine.

In truth, the task of speed delimitting is much less that crank sensor offsetting. With the speed delimitting you are only translating the frequency. If a processor has the right peripherals, this is not that difficult. With crank sensor offsetting, you are translating the phase of every edge to 0.1 degree accuracy. This means the processor has to calculate the position of each of the 116 edges in each revolution, and it is a complex calculation. At 7000RPM, that is 116 revs per second which is calculating edge positions at 13.5kHz (13500 times per second). This is by far the most processor intensive task done in the Procede, but we still manage to do speed delimitting (which gets to many kHz also) as well as read and create the boost PWMs, and all the other many things that need to be done.

So we chose a higher end processor to future proof us for these features we have added. We have only had one upgrade of the main unit, and that was to reduce our costs and integrate features that were previously external. There will not be another as we have still got alot of room to move with this hardware.

BMS did it a different way. Given your goals you mention, the BMS method makes good sense. We had different goals, and as a result our product and customers are different. But if not for the cost difference, I think there is little doubt which approach is superior. You have many customers, but I would be surprised if any made the choice because the JB3 has superior hardware/features. If there is any feature the JB3 does that Procede does not do it is our choice.... not inability of the hardware.

Adrian

There is no doubt that there are major hardware and implementation differences between the two. Also no doubt that both have just a fraction of the processing power of say an iPhone. What really matters are the algorithms and tuning implemented with each. Customers who are testing BMS' latest software are learning that even coming from where we were a few months ago there is much to look forward to. I'm sure the same holds true for your upcoming V4 changes.

On upgrades, BMS has the philosophy to include what might be reasonably required but in the event some major and unanticipated change allows their customers to inexpensively upgrade. For example if you bought the first JB3 unit two years ago and wanted to update it to the newest unit today it would only cost you $65. Given the current climate of BMW with respect to increasingly tighter software changes this model has a lot of merit. With any given software update BMW could make changes that might render current hardware and/or harnesses in need of an upgrade. For example changing the way they monitor boost solenoid current, checks for bank to bank narrow band o2 sensor variances, tighter CPS to VANOS angle checks, etc. Buying the fastest hardware doesn't often protect you from future obsolescence.

Mike

[Willizm]

This is better than a presidential debate.

[HPFREAK]

Originally Posted by Willizm

This is better than a presidential debate.

You are so right because in this debate useful information gets exchanged

[adrian@vishnu]

Originally Posted by Mike@N54Tuning.com

There is no doubt that there are major hardware and implementation differences between the two. Also no doubt that both have just a fraction of the processing power of say an iPhone. What really matters are the algorithms and tuning implemented with each. Customers who are testing BMS' latest software are learning that even coming from where we were a few months ago there is much to look forward to. I'm sure the same holds true for your upcoming V4 changes.

On upgrades, BMS has the philosophy to include what might be reasonably required but in the event some major and unanticipated change allows their customers to inexpensively upgrade. For example if you bought the first JB3 unit two years ago and wanted to update it to the newest unit today it would only cost you $65. Given the current climate of BMW with respect to increasingly tighter software changes this model has a lot of merit. With any given software update BMW could make changes that might render current hardware and/or harnesses in need of an upgrade. For example changing the way they monitor boost solenoid current, checks for bank to bank narrow band o2 sensor variances, tighter CPS to VANOS angle checks, etc. Buying the fastest hardware doesn't often protect you from future obsolescence.

Mike

In outright measurement of MIPS (Million instructions per second), you are correct that an iphone would beat the procede hands down... but could you take the processor in an iphone and do what we do in the Procede? No you could not. The processor used in the Procede is designed to provide highly deterministic processing of electrical signals. It is designed for use in automotive applications with pulse type sensors inputs and transducer outputs. This is what enables it to accurately measure the position of an edge referenced to a global internal timer, and then to create new edges phase changed with the same reference. Events are automatically stored by peripherals with the time references with no CPU intervention required, and the CPU can then come and process later with all data stored for the event. In summary, because of the peripherals available on our processor, we can provide better performance in these applications than other processors without such peripherals but running 10+ times greater MIPS.

Algorithms and tuning are important, but what you are going to see with V4, is that having the advanced hardware capability has given us some flexibility in algorithms that is not available to our competitors, and the benefits to the driver of the car have already been reported here. I am sure the latest JB3 will show improvements, but I will be intereted to see if it can replicate the leaps and bounds we are making.

What you say is true... BMW could change some fundamentals that effect assumptions we have made, but really the Rev 1 Procede is very similar to Rev 2, and all we did was move some hardware we had external from the main unit into the Rev 2 unit. Therefore we are looking at several years with no major changes in that area, and I doubt there will be. However there have been minor DME software changes that we have been able to adjust too with no hardware changes... like changes to O2 sims and changes to fuel pressure control to name 2. Time will tell, but I don't forsee anything at the moment. I am quite confident that rev 2 users will be able to go for the life of their car with only 5 minute firmware/map upgrades.

Adrian

[phazedkid]

Originally Posted by Brad@PSI MOTORS

You are so right because in this debate useful information gets exchanged

true enough.

this thread (at least 2nd half of it...) is really civilized and informative. i vote it as the exemplary civil technical discussion. keep it coming guys!

[kjrulz]

Now this is what I've wanted to see...finally. A respectful discussion between the major two piggyback vendors.

[onefastman]

+1 It really speaks highly of both of you that you can discuss something with out resorting to mud slinging unlike some vendors couch ar cough.

[Mike@N54Tuning.com]

Originally Posted by adrian@vishnu

Algorithms and tuning are important, but what you are going to see with V4, is that having the advanced hardware capability has given us some flexibility in algorithms that is not available to our competitors, and the benefits to the driver of the car have already been reported here. I am sure the latest JB3 will show improvements, but I will be intereted to see if it can replicate the leaps and bounds we are making.

Feedback on both beta systems has been very positive! As I said earlier both sets of customers have great things to look forward to as well as both platforms have seen huge improvements over the last year.

Going by what has been written by yourself and others on the V4 changes it is quite a departure from what you were doing with V3. It had always been assumed the JB3 PID was functioning like the V3 PID with regard to boost control. Now reading technical explanations of the V3 I can see there was very little in common with the algorithms. The JB3 used TMAP out converted to boost as its process variable and the factory boost target as its set point. Ultimately I think history will show this is a better approach than the duty cycle set point used by V3.

Now with BMS having access to a wider range of data via the new data-logging system better PID tuning has dramatically improved overall performance. Perhaps had a different PID approach been selected earlier in V3 development you would not be going to the extreme steps of separating boost control from the ECU completely as you are with V4 today.

Mike

[scalbert]

Originally Posted by Mike@N54Tuning.com

The JB3 used TMAP out converted to boost as its process variable and the factory boost target as its set point.

Hrmm, Terry must have been busy today.

adrian@vishnu
Yesterday, 08:23 PM

Mike@N54Tuning.com
Today, 09:34 PM

Anyway, where was the highlighted coming from? Was it:

A) Derived from modeling
B) Calculated from the current duty cycle
C) Something else

Secondly, how can the PV be the TMAP out to the DME? Your Process Variable is the variable to which you are trying to control. Your SP (setpoint) is the target. If you are targeting stock boost, as described, and the PV is the output to the DME, it should run stock boost. Clearly is does not and perhaps the normal definitions of PV and SP are being misinterpreted. I have tuned hundreds of loops; temperature, pneumatic and hydraulic (very fast reaction needed as fluids do not compress like gases so response speed is critical) and may be misreading the information.

I am earnestly trying to understand the rational. And maybe I am missing the function of the PID loop, which I am willing to accept and discuss. Is the loop trying to control boost or the DME perceived boost?

[Mike@N54Tuning.com]

Originally Posted by scalbert

Hrmm, Terry must have been busy today.

adrian@vishnu
Yesterday, 08:23 PM

Mike@N54Tuning.com
Today, 09:34 PM

Anyway, where was the highlighted coming from? Was it:

A) Derived from modeling
B) Calculated from the current duty cycle
C) Something else

Secondly, how can the PV be the TMAP out to the DME? Your Process Variable is the variable to which you are trying to control. Your SP (setpoint) is the target. If you are targeting stock boost, as described, and the PV is the output to the DME, it should run stock boost. Clearly is does not and perhaps the normal definitions of PV and SP are being misinterpreted. I have tuned hundreds of loops; temperature, pneumatic and hydraulic (very fast reaction needed as fluids do not compress like gases so response speed is critical) and may be misreading the information.

I am earnestly trying to understand the rational. And maybe I am missing the function of the PID loop, which I am willing to accept and discuss. Is the loop trying to control boost or the DME perceived boost?

Although I refer to them as the factory boost target and TMAP out for simplicity, technically BMS refers to the variables as:

7) ECU PSI. The amount of boost the ECU is observing, generally 6-8psi during WOT activity. Used as the process variable for the PWM PID controller. Scale is 0-20psi along the left axis.

8) PID PSI. The minimum ECU PSI allowable for the given conditions. Above this value less PWM is required and below this target more PWM is required. Scale is 0-20psi along the left axis. It is normal for ECU PSI to float high above PID PSI under certain conditions such as part throttle indicating the JB3 does not need to supplement PWM at that time. As ECU PSI falls below PID PSI the JB3 must increase PWM to sustain target boost levels.

9) PWM. The boost solenoid/duty cycle/wastegate offset. Higher values indicate more wastegate closure initiated by the JB3 and lower values indicate less wastegate closure. This value is determined by the PID controller which is driven off ECU PSI and PID PSI and influenced by parameters under user adjustment.

This is taken from my JB3 logging thread which may help shed some light on the control mechanism:

http://www.e90post.com/forums/showthread.php?t=347444

The TMAP out (or ECU PSI) is being controlled externally by PWM increasing or decreasing the wastegate position. Hopefully that helps shed a little more light on how the JB3 is operating.

Mike

[adrian@vishnu]

Hi Mike,

I have not had time to look through all the posts on how the JB3 works, and largely that is because there is really only one way you can do it if you wish to utilise the DME algorithms to control boost as the JB3 and V3 do.

Basically, if as BMS claim, the DME is still controlling boost with its control system, then the DME must see its expected target boost on its TMAP input at any time when it thinks it should have boost under control... this is mainly once it has been at a moderate to high load for enough time for boost to settle. But it must also see boost changing for it to implements its control (to know to decrease duty cycle when boost is too high). So the JB3 must scale the TMAP signal so that the DME sees its target when the boost is where the JB3 wants it to be. This theory has been around since the first products. Every product (except V4 and possible CP-E) works in this way, and every JB has worked this way.

The difference between later version of this method and earlier is that at some point we pushed the boost so high that the DME duty cycle was outside its expected range. Earlier the solenoid was bypassed to get more boost, and but in later versions (JB3, V3), the tune applied an offset to the DME output to allow it to run this output within its expected range. Additionally, we had a good idea what the expected range was, so PID controller were used to adjust the PWM offset to keep the DME in its expected range.

The above methods worked fine, but in certain transient conditions, the DME would react to boost being higher than setpoint by closing the throttle. Both the V3 and JB3 worked out that the best way to avoid this was to provide an output duty cycle to get boost straight where we wanted it, but to apply a scaling so that the DME did not see a boost spike and therefore did not close the throttle. Both JB3 and V3 had models to work out what the DME wanted to see in order to implement this. In very early versions of V4 (and later V3) Procede cancelled the model we had been using and read the target direct from the CAN. This took the guess work away. This is where JB3 and Procede diverge.

We worked out that knowing exactly what the DME wanted to see meant we could totally avoid throttle closure, but we were still limitted by the DMEs relatively slow and mushy boost control. The only way way to get around this was to bypass it... but not totally... we bypassed the control system in the DME, but we still have access to the setpoint it uses and the output it produces. Therefore we can still implement the boost reductions the DME wants for DTC/DSC, over temp etc. We know the input and output of the DME boost control, we just replaced the control itself. And we do not always use the DME targets, as we can better throttle control with pedal position by modifying it.

Anyway, that is my take on things. Please let me know where I have got it wrong in regards to JB3. To me it seems that your explanations do not make much sense as pointed out by scalbert. I think that JB3 and and V3 worked in pretty much the same way, but with different tuning goals. However I am confident that V4 is very different.

Adrian

[kjrulz]

now its getting good....dont stop

[Mike@N54Tuning.com]

Also to avoid redundancy the JB3 boost control is pretty clearly explained in this post:

http://www.e90post.com/forums/showpo...4&postcount=70

And here was a datalog created on the bench showing the basic mechanics in play:

http://www.e90post.com/forums/showpo...&postcount=135

Mike

[Mike@N54Tuning.com]

Originally Posted by adrian@vishnu

The above methods worked fine, but in certain transient conditions, the DME would react to boost being higher than setpoint by closing the throttle. Both the V3 and JB3 worked out that the best way to avoid this was to provide an output duty cycle to get boost straight where we wanted it, but to apply a scaling so that the DME did not see a
boost spike and therefore did not close the throttle. Both JB3 and V3 had models to work out what the DME wanted to see in order to implement this. In very early versions of V4 (and later V3) Procede cancelled the model we had been using and read the target direct from the CAN. This took the guess work away. This is where JB3 and Procede diverge.

We worked out that knowing exactly what the DME wanted to see meant we could totally avoid throttle closure, but we were still limitted by the DMEs relatively slow and mushy boost control. The only way way to get around this was to bypass it... but not totally... we bypassed the control system in the DME, but we still have access to the setpoint it uses and the output it produces. Therefore we can still implement the boost reductions the DME wants for DTC/DSC, over temp etc. We know the input and output of the DME boost control, we just replaced the control itself. And we do not always use the DME targets, as we can better throttle control with pedal position by modifying it.

The JB3 has never applied a special TMAP scaling based on perceived over boost or boost spike. That would slow/degrade the throttle closure safety response. This can be easily verified on a bench.

Instead of going down that road BMS continued focusing on the duty cycle PID system to avoid overshoot. This was done by modeling the target in PSI rather than duty cycle. At the same time gain was increased giving the ECU much faster targeting. In theory the JB3 PID could be left enabled without any TMAP scaling and the ECU would simply hit its factory targets faster. When properly managed the factory boost control is extremely fast and responsive, integrated, and much safer than any external boost controller could be due to that full integration and extensive R&D. It only becomes "mushy" and "sloppy" when not properly scaled for the higher boost targets. This can result in too much of the required duty cycle coming from the ECUs integral factor. That windup/slop then works against you causing overshoot and throttle closure once target is approached or during transients.

So the V4 has decided to dump that system all together and eliminate the problem, but that forces you to recreate and reinvent all the factory systems. The JB3 has found a smarter way to work with the ECU in managing boost keeping all factory systems in place. It just so turns out the JB3 algorithm is also extremely efficient to implement from a processing standpoint. There is almost no additional taxing on the processor compared to the earlier JB3 1.0 offset algorithms.

Mike

[adrian@vishnu]

Originally Posted by Mike@N54Tuning.com

The JB3 has never applied a special TMAP scaling based on perceived over boost or boost spike. That would slow/degrade the throttle closure safety response. This can be easily verified on a bench.

Instead of going down that road BMS continued focusing on the duty cycle PID system to avoid overshoot. This was done by modeling the target in PSI rather than duty cycle. At the same time gain was increased giving the ECU much faster targeting. In theory the JB3 PID could be left enabled without any TMAP scaling and the ECU would simply hit its factory targets faster. When properly managed the factory boost control is extremely fast and responsive, integrated, and much safer than any external boost controller could be due to that full integration and extensive R&D. It only becomes "mushy" and "sloppy" when not properly scaled for the higher boost targets. This can result in too much of the required duty cycle coming from the ECUs integral factor. That windup/slop then works against you causing overshoot and throttle closure once target is approached or during transients.

So the V4 has decided to dump that system all together and eliminate the problem, but that forces you to recreate and reinvent all the factory systems. The JB3 has found a smarter way to work with the ECU in managing boost keeping all factory systems in place. It just so turns out the JB3 algorithm is also extremely efficient to implement from a processing standpoint. There is almost no additional taxing on the processor compared to the earlier JB3 1.0 offset algorithms.

Mike

My description above was basic, but Procede did the same thing. Target the boost at slightly below the actual boost target to prevent a spike that could cause throttle closure.

Yes Procede also did the same things to isolate the closed and open loop components of the DME control output and apply scalings to the open loop to get steady state duty cycle into the correct range for the increased boost, and to the closed loop component to alter the gain. We went a fair way down that track in the last 6 months of V3. In the end we discovered that it was taking more effort to dissect the individual closed loop components than it would take to get a more effective standalone control system and went that way. Basically, although we could control the total control loop gain as I am sure JB3 is now, we could not accurately control the PID components that we need to get response where we wanted. I wish there was a way that JB3 could datalog boost and throttle at high rate to compare the response. V4 is ALOT quicker than our most advanced V3 (and I have yet to see anything suggested JB3 2.0 has exceeded V3) to get to target with almost no overboost and stabalise instantly than the modified DME setup was.

In your opinion the factory system is quicker/safer than any external controller, but what is this opinion based upon... How many external boost controllers have you tried? This statement you make is at best false since you have NO idea how well an independant controller could work. You are just sticking to your mantra that since BMW did it, it must be best... even though BMW had different goals to you or I. Put you money where your mouth is and lets compare them.

Time will tell if this way you are doing is smarter/better. I have my opinions on what time will show. Are you able to increase the details and resolution of you datalogging, as that would show alot.

The thing you have to realise here is that the Procede still has access to the input DME target (which you model), and the output duty cycle. With late versions of V3 we tried doing what you are doing and it worked to some extent, but we got frustrated at not being able to control the PID components accurately, so decided to replace the controller itself. It is actually very simple the PID that we run... far simpler than trying to modify the DME setup before. It takes about 3 lines of code and a few bytes of RAM to do a full PID controller. The thing is that you make assumption that our method would not be as safe... but you know we have access to the DME targets and alter our targets based in them... how safe can it get... If the DME targets go low for a safety reason... we see it instantly. You say that you can modify the DME PID to make it the fastest system available, but you can really only alter the overall closed loop gain and not the individual components like we can as we are doing the PID. We can now run alot of differential to control spikes.... can you alter the DME differential gain seperately?

Anyway, I think I understand your system quite well, and I think you probably have a good idea of ours. The questions is... what is the reason we do not run the same system. Is it because your system us better and we are just trying to use marketting hype of this new system... or is it because ours is better, and you do not have the resources to replicate it, so you are trying your best to take away from what is a superior system. How about we have a shootout to find out?

Adrian

[HPFREAK]

Originally Posted by kjrulz

now its getting good....dont stop

You sound like my girlfriend

[Fern8321]

lol this is still going on? The thread was about a speed delimiter in the JB3 which is a yes or no question, and now we have a good ol fashioned tuner battle..some things(or people) never change

[clifton23]

jeez seems like every thread on this forum has good information until it becomes a dick swinging contest by the PROcede crew and JB3 crew.

blah