Lotussuper7

After much messing around trying too get my cable driven speedometer working properly, I have decided to try and add a stepper motor to drive the speedometer directly ( and get rid of the stupid cable , lol). I'm going to 3d print a bracket to mount the motor on the rear of the gauge , and come up with some way of connecting them (I want to keep the original Smiths gauge as it has the cars odometer). I have got wheel speed working well, so I guess my question is, Can I drive a standard Nema (14/17) stepper directly using the Aux outs, or should I add an external stepper driver and just use one digital out to drive the driver hi/low etc. Is there a benefit to either way ecu wise? Any thoughts welcome. Cheers

I have a display link running on a g4x. It works, but in my opinion was never realy polished. Some functions are very limited, and other streamed values dont show properly. With a bit of fiddling in the Can menu you can get most things working properly. Ie. I had temps showing incorrectly, decimal places in the wrong place etc. Hopefully you have some luck with it, I remember the amount I payed for it, but would like to forget. As for the knock block, that plug looks like a pc power supply connector.

Just a small one, Confirm log delete in ecu logs. If you accidentally click on delete all logs, there is no conformation dialog.

Exactly what happens. And as I said, I read another's post that said the same (unless that was you, lol). I have a standalone g4x fury.

I didnt really think it would be related. When it happens, the ecu itself just doesn't power up at all. Im 99.9% sure that its getting power when this fault occurs, as I have tested the VCC of the ecu when in that state . I have read somewhere else in the forum another person having the same issue, (probably where I should have mentioned this). The ecu has never quit once powered up. And never failed to start when the laptop hasn't just been connected (its mostly connected recently as I have been tinkering) . Its not a big deal, as it only happens every so often, just an observation. I will try and find the post on that users problem, if I can find it. As for the connection issues, not sure about that one. I have tried different Baud rates, different com ports, manual port selection, and other port related settings, however, still have not found any that will reliably hold the connection when downloading logs. Running in slow mode seems to work, however, goes slower than real time, and is a real pain, and that's only for small logs, I cant Imagine how long it would take for big logs. When running out of slow mode, I can sometimes get the logs to download quick and easy, but its hit and miss. So, in a way I think you are on the right track with it being a relay, but its not (at least in my case) the fuel pump relay, My symptoms would indicate an internal relay (circuit) in the ecu not turning on. I'm not saying that is definitely the problem, however, the symptoms would match. The fuel pump in my case simply does not turn on, because the ecu doesn't come on. As I say, it only happens infrequently, and turning the ignition on and off has always seen it come alive on the second go.

Further update to this topic. After a few very frustrating days trying to figure out what was going on I think I finally have this sorted. I have found out that the cheap sensor I purchased was rubbish, the armature that spins inside was not captured in the housing properly and was allowed to move in and out, this made the readings from the sensor very erratic. The magnets were also very weak, so I think that was why I got more erratic readings when using another hall sensor temporarily taped to the side. I have done some ' modifications' to the sensor, including drilling holes in the armature and fitting some new magnets, replacing the bushings with bearings, including thrust bearings and gutting the electronics and replacing them with a new barrel type hall sensor. Now the Vss sensor works fine, although there isnt much of the original sensor left. What I have learned from this is the sensor has to be exactly in the right place relative to the armature, or the speed reading gets very erratic. Literally a fraction of a mm can be the difference between success or failure. I used epoxy to lock the sensor in place when I managed to get a good reading. Hopefully road testing shows good results, however, rain and no roof is stopping that happening. Maybe this will be helpful for someone else.

I also have connection issues with my g4x, especially when trying to download logs from the ecu. Sometimes it downloads the log with no issues, and other times it crashes part way through, and disconnects the ecu. Tried everything I can think of, however it seems very random. Old Hp laptop running win xp offline. Running in slow mode seems to make it better for downloading logs, but very slow and not the greatest for normal operation. Hopefully this gets fixed. Not sure if it's related, but I also have an small issue where the ecu sometimes does not come on when power is applied, and it takes turning the power of and on again, then it turnes on. It's not a major thing, as its obvious when it happens as the fuel pump doesn't prime, so you notice it strait away, but it would be nice if it didnt happen. Just thought I'd mention it incase it was related.

Would be great if Link made a wifi/bluetooth unit that connected to the normal Can programming port and allowed wireless programming. That would be awesome.

Have you looked at my post on PWM fan control? I wanted to have pwm fan control, but found the interpolation between cells when going from fan off to fan running tried to drive the fan stalled for a portion of time. With help from the forum a solution using a math block has my fans working perfect. Might be worth a look! Would be nice as I have suggested in the wish list, and you mentioned in your post, to have a dedicated pwm fan/pump etc. setting, with things like 'initial kick' 'min/max dc clamp' 'timers' etc. It would mean less math for the end user, and that's always a good thing! Min/Max dc clamp values using gp PWM outputs.

Would be great to have some filtering (as suggested to me by another helpful contributor) on the digital inputs. For example, averaging wheel speed. I was having a problem with a erratic speed sensor reading ( Discussed in another post). The use of the math block, I think has cured my issue (at least until I can fix the inherent issue) , However, it would still be nice to have a bit of a de-bounce setting related to each digital input. Peoples help on this forum is awesome. Looking forward to the next firmware release, hopefully a few new things to play with. Thanks to everyone that is helped out.

Update to this topic: I remembered that I had another miniature hall sensor, so i taped it to the side of the vss sensor housing, wired it up and managed to get a reading. The erratic behavior continued. So I have come to the conclusion that it is most likely the angle drive or the internal gear output etc I have now set up a math block that has smoothed the output for the sensor. Hopefully it is stable enough. The averaging works well. For anyone else wanting to smooth their wheel speeds, this is how I did it: 1. Set up a di for all your different speed sources. 2. Set up a math channel for the wheel you want to average, with the di you selected for that wheel as the first parameter (a). Equation = av(a,0.1) 3. Set up a gp speed input(s) for the front or rear wheels (or both), with the math channel you created above as the input. (two inputs needed if smoothing both driven and driving wheel speeds.) 4. Select the gp speed source you created above as your driven or driving wheel speed source. You can get more of less averaging by increasing the value in the math equation. Just remember averaging causes a delay in value creation, so use the smallest value that gives adequate results.

Awesome, thanks for the clarification, from the documentation I thought you had to fill in that table for traction control to function, its good you don't need too. Cheers

Hello, I am working on getting traction control working. I have configured the wheel speed inputs etc and the slip table, and understand you need to activate the torque management system. However, I am confused about the Torque request table mentioned in the documentation, I cannot even seem to find it in the software. Can anyone shed some light on what I'm doing wrong, and any other tips and advice for setting up traction control. Also, is it imperative to have a dyno to set the Torque multiplier? Or can you have a "stab in the dark". Any help appreciated.

Would a reed type be 3 wires? I would have had a look at the sensor, but I think you would need to break into the housing to see it, looks glued to me. This is the one I used From Various ford models, fiesta Ka and a few others I think. That makes sense about the pull up then. Didn't think of that.

Another thing I noticed is the sensor seems to work no matter what di settings I have... ie: Pull up on or off Leading or trailing edge (I know this wont make any real difference due to it being frequency based) and any combination or those settings all work, not well obviously, but it does work.... Pretty sure its just a hall sensor, as I have taken it apart and it just seems like a spinning disk with magnets imbedded.(and a encased sensor) Wouldn't turning on or of the internal pullup stop the sensor working in one of those states? Just curious.

Its connected to di5, so that wouldn't have worked regardless. Thanks for the info. Would your guess be a sensor fault, or a mechanical fault based on the frequency of the oscillation and the short time period the oscillation take place in? Thanks for the suggestion, This is similar to the setup I have on the front wheel, However I am hesitant to do this because there is no wiring for rear wheel speed, and it would be a real pita to add it. So was hoping to get this gearbox setup working as it is accessible without removing the engine and gearbox (just), the car is very compact and hard to work on in many respects. Especially routing things to the back of the car (it has a completely sealed bottom, tunnel included.) Reading rear wheel speed of a single wheel can be problematic if you lift a wheel too, so I would then need two sensors and average the results. Appreciate everyone's input. Thanks

The speed sensor I'm using passes the cable output through it, I wanted to get it going with this sensor so I can also keep my original Smiths speedo (has the cars odometer on it) it was the only sensor I could find with that option. Using a sensor like the one I used on the front wheel on the gearbox output would be a real pain, as I would have to do some major engineering to make it work. If I were to go that way it would be easier to read the driveshaft yoke, this would also require a lot of work including removing the engine and gearbox as it is not accessible otherwise. Hence why I'm trying to use this sensor and the gearbox output. The readings taken in the log are without the cable going to the speedo connected. So just the 90* drive and the sensor. The angle drive does use a flex shaft for its input, however, it is very short( within the drive casing ) so I'm unsure if that would cause it, but anything is possible. Do you think the short flex cable within the angle drive could cause this, looking at the frequency the pattern repeats. Should the di input Duty cycle oscillate that much on a vss (3 wire) Thanks for your input. Thanks Adam for your reply. I did try it using the drill before I installed it, and it did seem to have a bit of noise, however, I put it down to the drill not keeping a constant speed when unloaded. Wish I had an oscilloscope handy... The g4x can't look at the di inputs with the internal trigger scope can it? Should the di Duty cycle be more consistent do you think? The sensor was brand new, but from ebay, and not a genuine Ford item. Thanks for the tip on averaging the input value, I have previously set this up for the front wheel speed just to see it working (don't think the front needs averaging). Can you use a math block as the input for the driving wheel speed? Thanks for the input

Hi guys. Trying to get my rear wheel speed sensor reading from my speedo output of the gear box. I have it hooked up and it's working (sort of). However the reading is erratic. It generally tracked the front wheel speed, however, looks like its had way to much coffee. The orange trace is the front wheel speed measured of the front hub bolts using a gear tooth sensor, looks to give a nice stable speed trace?. The white trace is from the gearbox speed sensor cable drive output, using a angle drive and a speed sensor from a Ford Ka (non oem ebay). Powered from battery voltage. My question is, does the repetitive pattern look like a sensor fault, or could it come from either the gearbox speed output gears being damaged, or a binding in the angle drive(seems smooth to rotate by hand, and freshly lubricated) Looking at how often the pattern repeats in such small time periods makes me believe it is the sensor, not a mechanical issue. But I would love others opinions before I go replacing things. Any advice appreciated.

That is kinda what I thought the torque request setting was, but I understand its currently just for gear change torque reduction. Generally it would just be good to have some more flexibility surrounding the e-throttle tables, like offset table/tables based on temps/pressures etc. But a proper torque request strategy im sure would be a very popular feature for people with turbo cars especially. Haven't had chance to test out the idea I suggested on the road yet, as I'm still working on getting the fueling dialed in, have it is set up on it's own e throttle table, and in theory works perfect. It is only a theory though. If anyone else gives it a go, post up your thought/ observations here.

I have set this up on my car, however haven't had a chance to test it yet, as I am still working on the fueling in the boosted parts of my map. It's a open loop strategy, so not exactly like you wanted. But I recon it will work well to give you a more linear feel at boost pressures below wastgate. In general it just uses a gp pwm table with Map on the x axis and Aps on the y axis, then your main e throttle table y axis is changed from Aps to the gp target table. The gp target table is then set up to reduce the sudo Aps value as you come into positive pressure. I have no change in the vacuum part of the map. Some testing will be needed to find the right reduction in Aps per psi of boost. Hopefully it will not induce instability, only testing will tell. My gp table has an approx 10% reduction in Aps value from 0 psi Mgp to around 15 psi Mgp. Have you done any further testing?

Thanks for the reply. I have included a couple of throttle tables. (Not my actual tables, just an example) Both examples have have max throttle openings at 1000Rpm= 35 1500Rpm =40 2000Rpm =70 So you would recommend trying the approach in table1 rather than 2? The reason I thought table two might work better is because I wasn't sure if the maximum throttle opening was actually related to the torque delivered at lower Aps/Tps positions in the same rev band. I kind of figured if you were at 100% Aps in a given rev band, the engine would be accelerating usually and you would "climb" out of that rev band and into the next with a higher max Tps opening. If you are accelerating with say 40% aps constant, and going up through the rev range, the TPS value if using target 1 would be changing relative to you overall maximum opening in that rev band (even if you are nowhere near the maximum opening). Im guessing that's why you recommend less change down at lower APS positions? Thanks again for you reply. As I stated, this is not an issue, its just something I was interested in learning others approach to. Have a great weekend.

I am interested in trying out limiting the maximum TPS angle to limit torque at certain areas of the rev range. My question is: When taking this approach would you only change the maximum TPS angle at APS 100, Or would you scale all the lower values proportionally to how much the max TPS was reduced at a certain engine speed. ie. If my commanded TPS value is 40% at 80%APS (say at 3000rpm) and I wanted to limit the max opening to 40%, would you enter 40% at 100% APS and scale the lower values, or would you leave the original values leading up to your limit then just have the pedal do nothing further after the TPS angle has been achieved? ie. (APS 80) TPS 40 (APS 100) TPS 40 Im guessing if you scale the output relative to the maximum opening you may get some funny throttle behavior throughout the rest of the map? Hopefully that made sense? Its been a long day... Its not a problem, just looking for others thoughts.

Thanks. That is exactly what I was after! Going to give this a go. I'm going to set it up so it makes no change at 0 Mgp and below, then removes Aps input say 1.5 - 2% per psi of manifold pressure above atmosphere. (As a starting point) This should make it safe, if a boost pipe does come off, no positive pressure will make it into the manifold and so no adjustment to the e throttle taget will occur. (All adjustments will be negitive regardless) Should be an interesting experiment. Thanks!

Thanks for the reply's. Eventually I will set up traction control, however, I currently only have the front undriven wheel speed. (trying to find the best way to get a drive shaft sensor installed, space is tight). So if I want to try the Map vs Aps table I would create a GP pwm table, and have the output as a virtual aux, then reference the virtual Aux on the y axis of the E- throttle table? Thanks again. Tim