Awesome, that's great to hear. I'm ordering mine next week. I've already got the PI kit to go on this weekend.Likely a future project, yes
MOTIV RE|FLEX - ADVANCED I/O INTEGRATION
- Thread starter fmorelli
- Start date
Please post feedback once you’ve had a chance to play with it. This will be in my future as well.
Yeah I think that is going to be the case here since it's release there has not been much movement on the development side that I have heard of. I really want to see this thing take off because of how much "Potential" it has.
@Motive, move your asses!
'New version" on the way ( I hope!) ill update when I start to play with it and figure out stuff.
For me this
is the reason why, the less tuning and logging and changing I have to do the better, I'd much rather be driving than fiddling and fixing! I just want to be confident that when I'm enjoying my ride the DME is watching my back . I'm not saying the SS isnt capable, I just prefer the more hands off and integrated solution.
I agree this would be nice, but the AIC takes just a few minutes to connect and re-scale the map to compensate for fuel. Again, we have to determine if its worth the change and $$$. So little is known about it at this time.For me this
Literally from stock turbo on E85 to now almost 700WHP on the GC-Mid we have not touched the Reflex PI map once. It's just a slave, and the Reflex/ECUtek is adjusting everything on the fly. Of course, you have to have the fuel to do this. The PFS - Drop in Brushless System we are testing is proving very robust so far, we are testing over E95 ethanol percentage to really tax the system, and at 700WHP it's not even sweating. We will test it with the GC+ approaching 800WHP in the next week or so. We will also be putting 93 in the car next week to test the flex-fuel capabilities to adjust the tune with a fuel change.
Now this is super good data.
Is there a way to see if/how it is scaling the PI? Does it collect data?
I have a never used SS AIC2-P, Additional Injector Controller, Pressure Mode (AIC2-P66HI) - For Inline 6 engines (the better version) for sale if interested!
Exactly how I intend to use it to support the BW 8474 I just finished installing.
I'm curious on the MHD control... I consistently see the wifi module drop connection in high EMI environments (drive in front of say a microwave antenna for a street camera). Hopefully loosing connection like that doesn't cause any issues if MHD is controlling the can bus communication with the reflux.
Also makes me hope you don't loosing any of the 19 or so channels you can record when logging. I don't know if the bottle neck is the ECU, the can bus, MHD, your tablet, etc.
I just ordered a reflex, so we'll see when I get it all wired up. I really want it for the PI control, but it will also be controlling my MAC valve for my external waste gate. I'm interested on details if it runs off the DME tables like the boost box does (basically a frequency converter for the PWM), or if it can just completely take over boost control like an EBC or even do something in-between where it listens to the PWM from the stock solenoid plugs but modifies it how it wants.
Also makes me hope you don't loosing any of the 19 or so channels you can record when logging. I don't know if the bottle neck is the ECU, the can bus, MHD, your tablet, etc.
I just ordered a reflex, so we'll see when I get it all wired up. I really want it for the PI control, but it will also be controlling my MAC valve for my external waste gate. I'm interested on details if it runs off the DME tables like the boost box does (basically a frequency converter for the PWM), or if it can just completely take over boost control like an EBC or even do something in-between where it listens to the PWM from the stock solenoid plugs but modifies it how it wants.
The ReFlex is hard wired into the vehicles can bus via two wires (CAN hi and CAN Lo).
Yes, but if the MHD app is the one sending the control signals (which is sounds like it may be in some cases) it's connection is often wifi, so that needs to be taken into account.
Having now also looked at the XDF's they give you for the boost box, it for sure has its own PID and target boost levels, so it's like an EBC, but has better control than an EBC. Though no adjustment for charge air temp is taken into consideration, and so the ecu target boost level for throttle control needs to be properly dealt with or else at cold temps you could see throttle closures.
I noticed they also had a feed forward for the PID, which can often times be VERY useful in getting rid of oscillations in a PID setup, or can be used for things like hitting target error quickly.... aka they may end up using the PID feed forward to help spool times.
Having now also looked at the XDF's they give you for the boost box, it for sure has its own PID and target boost levels, so it's like an EBC, but has better control than an EBC. Though no adjustment for charge air temp is taken into consideration, and so the ecu target boost level for throttle control needs to be properly dealt with or else at cold temps you could see throttle closures.
I noticed they also had a feed forward for the PID, which can often times be VERY useful in getting rid of oscillations in a PID setup, or can be used for things like hitting target error quickly.... aka they may end up using the PID feed forward to help spool times.
I don't understand what you mean by this
as far as i understand MHD alters the programming in the DME.... that's it ,I don't know of any signal being constantly sent be the platform where connection is needed, after you code the changes and disconnect from the DME Wi-Fi is not needed further, If I have this wrong please explain.MHD programs the DME over CAN bus. This means there are several different ways in which you can talk to the reflex. You could try to add some assembly code to the DME to detect what you want and send a can bus message, but this also means you need to break into the assembly code that controls the CAN bus on the DME. Often times there is a hardware peripheral added to the SOC. In this case the MSD80/81 DME uses a Tricore brand processor, which very likely has a built in CAN bus peripheral. So all you have to do is write to a register in that peripheral to send your can bus message, but they would have to find and isolate the assembly in the BMW code that does that, as it likely has a queue and a buffer in the firmware, so they would have to figure out how to add said can bus message to the queue and read out of the buffer. It sounds like on the B58 DME's they are actually sniffing the can bus for already existing packets flying around that the DME sends when things happen and triggering off of them, but I could be wrong. The MSD80/81 DME's do not have as much can bus traffic flying around on average I suspect, so it's much harder to do this on, and my original post was more centered around those than the B58 DME's.
The other way they could do it, is given that MHD is already logging all the values it does over CAN bus, MHD could be what sends the CAN bus messages to the reflex rather than the DME. This would be a much simpler way to do it, as there is no reverse engineering involved in figuring out the DME's can bus assembly code. So say you see in your log that the low pressure fuel pressure is too low in the can bus log update in MHD, now you just send the "shut off the PI and disable boost above spring pressure" CAN bus packet to the reflex from MHD and you're done. WAY easier than trying to figure out where that data is in the DME's assembly, add code to check it, then figure out the can bus assembly and add code to somehow add a request to its queue. Also doing it in MHD means doing it once, if you do it in the DME now you have to figure out where in the DME image this code is for each different version of DME code. This means doing the same work but at a different address for the assembly for each version of each DME you support. That means for every MSD80/81 and for each B58 DME's code revision you have work to do, that means modifying something like 8 different images.
Yes the latter means you have to have MHD with logging always attached for that particular way to work, so there are trade offs in both ways of doing it, as always in engineering. Way easier development, but now you always have to have MHD logging active for the protection.
I could see them doing it either way. So that's why its a valid question until we know.
Right now you also have to program the reflex over serial port over USB. TunerPro is the one that currently does this, but with CAN bus access now on the reflex, once it's tied into the DME's CAN bus, it's also very possible in the future that MHD could program the reflex for you rather than having to use a laptop with tuner pro (or something similar) to download the map, and/or the boot loader to update the firmware, it could all be done over CAN bus by MHD.
Oh, and yes on the scaling of PI for E85, the reflex has an input for the E85 sensor and a table to scale the PI tables based on it, so it makes PI with flex fuel much easier. And again, yes the reflex seems to have logging capabilities, though I have not dug into if it can send said log data over CAN bus so you could log it in MHD, but for sure if you have TunerPro hooked up over serial port over USB you can log from the reflex.
I'll add that the reflex has 2 outputs and 2 inputs that are free. You can add say a pressure sensor and have the reflex look at those values, as well as the E85 fuel analyzer, this would use both inputs.
The outputs can be used to replace a HOBBS switch to control a second fuel pump, or used to control a MAC valve. So these outputs can be setup as a logical 0 or 1, or be used for PWM output. They are open collector (they source the ground for the connection) and can handle up to 2 amps each, so for a fuel pump it would need to drive a relay of some kind (your choice SSR or old school relay). This also means it might be possible if they add code in the firmware to hook up a low pressure fuel sensor to an aux input, run a second PID, and then give a PWM signal output to control the second fuel pump rather than using on/off like a hobbs like operation. This of course would require an adequate control system of the pump that can handle that, like say a 40 amp H bridge. (this tells me the processor they used for the reflex has PWM counter/timer peripherals as well as the aux inputs being tied to an onboard ADC, another likely built in peripheral of the SOC). Note that to do proper PID PWM control of a fuel pump the ADC will likely need to be able to do something like 200k samples a second to get good resolution and response time.... I have no idea what clock speed their processor is at or what sample rate the onboard ADC can do.
I should also add that looking at the circuit board for the boost box I figured out why they had "ground" problems on some cars. On the boost box they use a TINY84 microprocessor to do their PWM frequency shift, and use a linear regulator to get the 5v for it from 12v. The board did not have any caps on the output of the linear regulator or any decoupling caps across the TINY84, making it VERY susceptible to EMI (and many people would put it right next to this massive EMI generator called your ignition coils). This was giving me issues where the TIN84 would go into "limp mode" and my boost would drop to spring pressure. Putting the proper caps on the board fixed the problem.... it's likely I suspect that most people have not had improper ground problems, but that the board did not have these caps as needed. Note I had revision 13 of the board. I gave this information to Jake so they can make a revision 14 of the board if they wish.
OH, and some more interesting information... the AIC6 uses the TAC square wave output from the DME to drive its RPM input. The reflex uses the actual crank shaft position sensor as well as the cam shaft position sensor, and thus knows exactly when TDC compression stroke of cyl 1 is, which is why it can do sequential injection instead of batch only injection, aka it actually knows the timing of each cylinder based on the crank and cam sensor pulses. This is not only safer as you get better atomization of the fuel charge (less likely to detonate), but it gives you better MPG as well... among the other benefits of sequential vs batch injection.
Sorry, that was a massive information dump, sorry if it's a TLDR.
The other way they could do it, is given that MHD is already logging all the values it does over CAN bus, MHD could be what sends the CAN bus messages to the reflex rather than the DME. This would be a much simpler way to do it, as there is no reverse engineering involved in figuring out the DME's can bus assembly code. So say you see in your log that the low pressure fuel pressure is too low in the can bus log update in MHD, now you just send the "shut off the PI and disable boost above spring pressure" CAN bus packet to the reflex from MHD and you're done. WAY easier than trying to figure out where that data is in the DME's assembly, add code to check it, then figure out the can bus assembly and add code to somehow add a request to its queue. Also doing it in MHD means doing it once, if you do it in the DME now you have to figure out where in the DME image this code is for each different version of DME code. This means doing the same work but at a different address for the assembly for each version of each DME you support. That means for every MSD80/81 and for each B58 DME's code revision you have work to do, that means modifying something like 8 different images.
Yes the latter means you have to have MHD with logging always attached for that particular way to work, so there are trade offs in both ways of doing it, as always in engineering. Way easier development, but now you always have to have MHD logging active for the protection.
I could see them doing it either way. So that's why its a valid question until we know.
Right now you also have to program the reflex over serial port over USB. TunerPro is the one that currently does this, but with CAN bus access now on the reflex, once it's tied into the DME's CAN bus, it's also very possible in the future that MHD could program the reflex for you rather than having to use a laptop with tuner pro (or something similar) to download the map, and/or the boot loader to update the firmware, it could all be done over CAN bus by MHD.
Oh, and yes on the scaling of PI for E85, the reflex has an input for the E85 sensor and a table to scale the PI tables based on it, so it makes PI with flex fuel much easier. And again, yes the reflex seems to have logging capabilities, though I have not dug into if it can send said log data over CAN bus so you could log it in MHD, but for sure if you have TunerPro hooked up over serial port over USB you can log from the reflex.
I'll add that the reflex has 2 outputs and 2 inputs that are free. You can add say a pressure sensor and have the reflex look at those values, as well as the E85 fuel analyzer, this would use both inputs.
The outputs can be used to replace a HOBBS switch to control a second fuel pump, or used to control a MAC valve. So these outputs can be setup as a logical 0 or 1, or be used for PWM output. They are open collector (they source the ground for the connection) and can handle up to 2 amps each, so for a fuel pump it would need to drive a relay of some kind (your choice SSR or old school relay). This also means it might be possible if they add code in the firmware to hook up a low pressure fuel sensor to an aux input, run a second PID, and then give a PWM signal output to control the second fuel pump rather than using on/off like a hobbs like operation. This of course would require an adequate control system of the pump that can handle that, like say a 40 amp H bridge. (this tells me the processor they used for the reflex has PWM counter/timer peripherals as well as the aux inputs being tied to an onboard ADC, another likely built in peripheral of the SOC). Note that to do proper PID PWM control of a fuel pump the ADC will likely need to be able to do something like 200k samples a second to get good resolution and response time.... I have no idea what clock speed their processor is at or what sample rate the onboard ADC can do.
I should also add that looking at the circuit board for the boost box I figured out why they had "ground" problems on some cars. On the boost box they use a TINY84 microprocessor to do their PWM frequency shift, and use a linear regulator to get the 5v for it from 12v. The board did not have any caps on the output of the linear regulator or any decoupling caps across the TINY84, making it VERY susceptible to EMI (and many people would put it right next to this massive EMI generator called your ignition coils). This was giving me issues where the TIN84 would go into "limp mode" and my boost would drop to spring pressure. Putting the proper caps on the board fixed the problem.... it's likely I suspect that most people have not had improper ground problems, but that the board did not have these caps as needed. Note I had revision 13 of the board. I gave this information to Jake so they can make a revision 14 of the board if they wish.
OH, and some more interesting information... the AIC6 uses the TAC square wave output from the DME to drive its RPM input. The reflex uses the actual crank shaft position sensor as well as the cam shaft position sensor, and thus knows exactly when TDC compression stroke of cyl 1 is, which is why it can do sequential injection instead of batch only injection, aka it actually knows the timing of each cylinder based on the crank and cam sensor pulses. This is not only safer as you get better atomization of the fuel charge (less likely to detonate), but it gives you better MPG as well... among the other benefits of sequential vs batch injection.
Sorry, that was a massive information dump, sorry if it's a TLDR.
Last edited:
The way I understand it you won't need a Hobbs switch or use one of the external inputs since the n54 has a lpfp sensor. I can't say for 100% certainty but I guess I will verify soon enough installing everything today the old reflex eos intake an bpm4...or buy the end of the weekend...side note I will probably still order the new one cause I can't help myself lol
The external reference was for if you wanted to use a PID with PWM to control the fuel pump (thus always having the pump on, and then increasing its flow rate when needed by upping the PWM, rather than off until a certain boost pressure then 100% on like a hobbs switch). If you just want to turn the second fuel pump on at any given boost pressure, then yes, because it's tied into the TMAP sensor that is in the charge pipe, no additional sensors are needed to basically replace a hobbs switch.
Lots of information but I disagree with this
statement, I am no programmer but this would just be plain impractical bordering on idiotic to require constant logging to get something as critical as this to function properly. If this turns out to be as suggested, what is going to happen when your logging devices' (laptop or computer) battery dies during a WOT pull?
Last edited:
Similar threads
