Lotussuper7

Have you had any luck getting this going? I'm looking to get the 1.5 litre ecoboost running,and any info you could share would be awesome. Cheers Tim

Thanks for your input. It's appreciated. I think it has standard gdi solenoid type injectors, but I'm not 100% sure on that. Will have to do more investigating. It's hard to find info on it. My other thought was to make a modified intake manifold and use port injection,and do away with the direct injection,but I guess that kinda defeates the purpose of a direct injected engine. I will definitely keep my eyes out for the direct injection addon you mentioned. Thanks for your input!

Looking for advice,comments,and calls of 'you're crazy'. Recently I came across a brand new crate engine,damaged by the courier. The damage was relitivly minor, and the engine was cheap enough that I ended up purchacing it. I could part the engine out for much more than I paid for it, but I like the thought of getting it going and powering a project car. It is the 4 cylinder, 1.5 litre Ecoboost found in various ford models. Basically I'm just trying to get some advice if people think it is possible to get this engine running using the Link Gdi ecu,or if it would just be so difficult,I would be better off parting the engine out,or selling it to someone in need of a replacement engine. Had anyone got one of these running on the link? The engine has a date code mid 2019, so I'm pretty sure it has the revised block design to eliminate the cooling issues these engines had early on. Any input, positive or negitive would be appreciated. Tim

Thanks guys for the clarification. Hope your days are going well. Kind regards Tim

Just doing a bit of a search on this topic and I came across this old post. It wasn't the reason I had changed my approach to begin with. However, seems a bit confusing. Maybe something has changed in the firmware to necessitate a change? Anyhow, just want to find the best approach going forward. cheers Tim

Just seeking some clarification on this. I was under the impression that you had your main tps opening (for idle) in the e throttle table first row (zero Aps), and the base position was mainly used to increase tps position while engine came up to temperature, tapering down to zero when the engine was warm. I originally had my car set up with zeros in the first e throttle table row, but was advised to change it by a link moderator if I remember correctly. But this thread seems to say the opposite. Looking at the supplied e throttle base maps in pc link, they show non zero values in the first row. Is there a benefit to either way when it comes to Idle control and dashpot operation? I have my car idling fine, but have had some trouble getting clean re entry to idle (rev hang). After much work it is working ok now (Getting just the right min and max clamps) but it does seem quite touchy, Any clarification welcome. Kind regards

Thanks for the quick reply. Understood. Just wanted to confirm I wasn't a genius to get it going this way, lol. The OBDlink mx+ is quite expensive, but I guess you get what you pay for. Guess I will be saving my pennies. I think the Bluetooth adapter may be the better way to go, as I see people are having problems getting the wired solution to work alongside powering the device. Thanks again for you quick reply, and the benefit you bring to the community.

Looking for some advice using a generic Elm 327 adapter for realdash. I have been doing some fiddling trying to get Realdash working with a generic Elm327 adapter. Has anyone else tried this? I read that it was not possible to use a generic Bluetooth adapter for Realdash, and you needed to have an OBDlink mx(+) to make it work. Or a CAN to usb adapter like the seeedstudio etc. I thought I would give it a go with the generic adapter, and have had some success, but I dont think it is working 100%. What I did to get it going was as follows: Connect the can HI/low lines from can2 to a OBD port plug from ebay (along with power and ground obviously), Plug in a generic OBD Elm327 adapter, Changed the CAN2 setting in PClink to: OBD (ISO 15765 on CAN2), Set Bit rate to 500Kb/s, Update rate to 200hz, Set mode to DASH2pro, ID 1000, In realdash: I (originally) tried to set up the adapter selecting "Link Ecu" - Bluetooth - Select correct Bluetooth adapter from the list. This did not work, and would not connect. After some more trial and error I selected OBD from the list - Bluetooth - Select correct Bluetooth adapter from the list. This then was successful, and I was connected. I then noticed that even though I was now successfully connected, non of the gauges were functioning, However, going into the input menu (of a particular gauge) and reselecting the already selected input (ie. reselecting Coolant temp for the ECT gauge, and just reselecting it as an input had the gauge come to life!) (On a side note, one thing I noticed is that if you don't select "link ecu" and try and connect that way first, even though It will not connect, you will not have the Link specific inputs available when you connect using the OBD method, well at least I didnt from a fresh install of Realdash on android) As I said earlier in my post, it is almost working properly, but not completely. I have most of the gauges I have tried working, including the following: Rpm, Speed, ECT, IAT, Boost (although working, I think the CAL is off somewhat, or the gauge I was using was wrong for the input), TPS, and maybe 1 or 2 more I cant remember. However, when I tried to set up oil pressure as an input, I just couldn't get it to work. Tried everything I could think of, until my brain started to hurt, I just dont know enough about this CAN thing, it is very confusing. I failed at getting the engine check light to work also. I guess my question(s) are.... If I have managed to get so much going using a generic Bluetooth adapter, why is it not possible to have all the data transmitted this way? (is it a limit of the OBD protocol) And why is it said that is does not work, as it at least partially does? Obviously I have not got everything going that I wanted too (really wanted pressures etc) But I have quite a lot of the main info coming in. I am missing something as to why this is not a viable approach? The data flow seems to be almost real time, with only a very slight delay. Ie, the rev counter tracks the revs with only a very small perceptible delay, and would be fine for most people in my opinion. If I could get all the gauges etc to work as well as the ones that are functioning do, I would be a happy camper. All this was achieved without changing the XML file or the .rd file. To be honest I dont know where to start with those. I figure from my reading the XML file is uploaded when you select CAN/Lin adapter from Realdash (something I didnt do as I selected OBD instead) and I'm not sure what you do with the .rd file. Im interested if anyone else has tried this, and If they have had any better results than me. Id also like the hard word (if it is appropriate) to just go and purchase the OBDlink Mx+, because it would make life that much easier (for these reasons............... etc) If I do buy the OBDlink mx+, and upload the premade XML and. rd file, are all the major data streams coming from the G4x already configured? So it would be as easy as say... creating a fuel pressure gauge, and selecting fuel pressure from the main input choices in RD? or do you still need to go into the ecu specific input menu and mess around in there? Any help/ advice / or interest in what I have got going, would be greatly appreciated. Thanks in advance.

Thanks for the reply. Sorry, my mistake, for some reason I had it in my head that the programming port could also be used as can1, and the second (round) port was can2.( and the 'b' loom was just a alternate way of connecting Can2) I now realise that was just wrong. The ecu is the Fury x standalone. Just trying to get my head around the Can setup, as I have never dealt with Can before. (Apart from getting the displaylink going). Thanks for the info. Looks like the displaylink is on Can1 then, and I can just connect Can Hi/Low on Can2. (From the 'b' connector) to my adapter. Not sure why I thought it was that way, just had it in my head that when I got the Displaylink going (plugged into the front round connector) I had selected Can2. However, it seems my mind must have been playing tricks on me. I think one thing that made me think it worked that way was the fact I came from the Link g3 Lem that would not let the Can port work when the programming cable was connected. I had to disconnect the displaylink when I wanted to use the pc connection. Hopefully I can get Realdash working without too many troubles. Looks like I have a bit more reading to do to familiarize myself with the can setup process. Thanks for your reply

Hello. A question regarding Realdash can communication: I currently have the classic Displaylink connected and working on the Can2 output from my ecu. I would like to leave that operating if possible, but also have a connection to an adapter for realdash. My question is: Can I have both running on the Can2 network simultaneously? One on the external plug, and the other using the Can2 wiring on the main ecu connector? Any advice greatly appreciated.

Yes, a slip light is what I was after. Thanks! Will give your suggestion a go. Hope your day is going well!

Hello, can someone tell me the best parameter to reference for a traction control light?

Thanks guys for your help. I'm going to go the Analogue route thanks to your suggestions. A bit more work, but it will free up a couple of digital in's (and give me all the cruise functions). I was going to use Analogue Temp 4, it only supports a fixed internal pullup as I'm sure you are aware, that should work fine with resistance ladder (being pulled high)? What would be your recommendation on resistor values for the ladder? Thanks again

Thanks for the input. I cant really fit a factory stalk in the car, due to space requirements, so the button route is the one I will have to take. I was hoping just to get away with the 2 digital inputs (on/off and set) and of course brake and clutch inputs. But maybe I will have to go with a resistor ladder if all the buttons need to be implemented. Having the speed adjustable up and down would be nice, but I wouldn't mind not having it either. If I wanted to speed up or slow, I could just use the throttle or brake and reset the cruise, no?

Oh shit, yes, cruise control, my bad. Thanks for the info. I don't have a classic stalk, so will be adding buttons to make it work. Can I get away with just On/off and Set, or do you need resume also? I guess without resume you cannot do the increase/decrease thing. I think I have run out of digital inputs, without sacrificing another function. Hence why I ask. Cheers

When setting up traction control, would it be safe to assume that you would use a latching switch for the "Cruze on/off" button, and a momentary switch for the "Cruze Set" button? Any help appreciated.

Thanks for the reply. Looks a bit more involved than I want to get into at the moment. Just looking at the hardware I need to get the basic dash working. Any idea on the adapter? Are you using the wired seeedstudio adapter?

Couple of realdash questions: 1. Can you use a generic elm327 Bluetooth adapter instead of a Can to usb wired adapter (seeedstudio etc)? 2. Can Realdash simulate real switches and control ecu functions, like turning traction control on?off etc? Thanks in advance.

You mentioned you could drive a standard hobby servo. On that ground, could you just control a Radio control brushless/brushed speed controller and spin a brushless/brushed motor instead of the stepper, I have loads of rc gear. A brushed motor may be better as they usually have better low speed capabilities. You can also no doubt get pwm driven speed controllers for Arduino etc. Will have a look around.

Hmm, will have to think this one over. Thanks! Will keep the post updated as things progress.

That's just what I was investigating. Seems most can support around 1500 rpm with full stepping. Dependent on the driven voltage and load. The gauge require very little torque to operate, it will be the speed that may be an issue, may need to incorporate a couple of gears (or belt) into the 3d printed design. Do you know off hand how many pulses (hz) the Fury x can supply on the aux outputs? Standard steppers on full step use 200 pulses per rev, so at say 2000 turns, that would be 2000x200 = 400,000 pulses at 200kph. Maybe less obviously if gearing is involved.

Thanks for your reply. I realise how a stepper motor works as I have many years working with 3d printers. I dont think we are quite on the same page. The speedometer I want to drive does not have absolute positioning, and I dont want to drive it do defined positions. It works by spinning a magnet inside and dragging the needle around further the faster the input spins. To increase the speed showing on the speedo simply requires spinning the input faster or slower. No need for absolute position, only number of pulses per sec need to change relative to the cars speed. This is a fixed ratio driven from the gearbox output. I'm not looking for absolute precision here, just a way to have the odometer stay working, and have 'close enough' speed showing. I have the digital wheel speed available, and can display this on my displaylink screen also.

Thanks for the reply, so that would probably be the way to go then, use an external stepper driver and drive it off an aux channel using the speedometer feature, rather than drive the stepper from the ecu. I only suggested driving it from the ecu for simplicity, as I dont use a idle stepper, I figured this might have been a simple option.

Just to clarify what I was trying to achieve. My idea was to still use the cable drive input of the speedometer, and replicate the flex cable spinning the input with the stepper, I wasn't going to go as far as interfacing directly to the needle and driving to a specified angle etc.. no cool needle test sweep unfortunately. It just needs to speed up the stepper as wheel speed increases, with a tuning offset. I was thinking this could just be achieved with a math channel? The stepper driver was going to be left in full step mode to get the lowest frequency drive signal, and fastest rpm of the stepper, the cable spins relatively fast.

My original plan was to use a a4988 stepper driver to drive the stepper motor. This requires a high pulse to drive the stepper one step, There would be no need to have a home position as to stop the speedometer counting only requires the stepper to stop turning, not like controlling a air bleed that needs to reverse to open/close a valve. Can the ecu generate a frequency relative to the speed frequency generated by the wheel speed sensor?