Jump to content

Davidv

Members
  • Content Count

    266
  • Joined

  • Last visited

  • Days Won

    25

Davidv last won the day on June 10

Davidv had the most liked content!

1 Follower

About Davidv

  • Rank
    Advanced Member

Recent Profile Visitors

1,892 profile views
  1. Davidv

    why Link?

    Most modern ECUs are very capable now, we live in a great era for ECU ownership! One thing which swayed me towards a Link though. Is, download all of the tuning software for each ECU you are considering. Have a nosey around. Is it intuitive? Is there a help file etc? Does it take bloody ages to load? Do you like the look of it? The PClink help file is one of the best and most helpful documents I've ever read. Haltech didnt stack up for me, because it's more expensive for what seems like more features and a less scientific approach to some features. Although, it's definitely true to say that whatever your tuner's preference is. Will save you some headaches and $$$ for setup and install if they know the product back to front already. A good tuner will be capable of tuning any type of ECU, but pandering to their personal preferences will likely save you some money if that's a consideration.
  2. You need to be careful when doing any "autotune" type stuff like this, because on transient conditions you get really wild Lambda results that you really dont want contributing to your fuel map. You can filter these with mixture map a bit though. CLL is still a really good feature though in that it shows you what % fuel it's added or taken away, so you can just go through your map. Then if CLL reports it needed 4% more fuel. You can multiply that cell by 1.04. Rather than needing to do a need/want equation manually. Still need to view the context though, if it's not in fairly steady state I tend to ignore results. Also, if your fuel map was previously all good then its possible you're masking another issue that you needed to setup correctly instead ie. temp correction
  3. You could have a look at the knock sensor signal for each cylinder. When an engine is misfiring, that cylinders background noise level on the knock screen can be lower. (Depending on the engine and knock sensor fitted I guess) Also the engine rpm signal can look rough. There's no monitoring of the coilpack return signals though.
  4. Davidv

    programmable logic

    Yeah the transciever is miniscule though, doesnt increase footprint: https://www.tindie.com/products/Fusion/dual-can-bus-adapter-for-teensy-35-36/ The refresh rate is good especially when optimized to minimize pixel writes. But if youre spamming it with lots of fast moving stuff or your code has a lot of unnecessary writes it can chug a bit. Moving over to realdash on a tablet is a whole bunch less work to be fair. But this is a learning exercise for me as much as anything else. The start up time, for me, is something that needs to be super snappy. Thats where a microcontroller is so good. I want to migrate my project to a twin core stm32 and a custom board at some point. So i wont need nextion it can control an lcd panel directly. But this is a huge amount of work and ive got lots to learn in the meantime.
  5. Davidv

    programmable logic

    Yeah I started out using a mega but it was starting to chug. If there are any instances where you need/want floats then youre gonna grind to a halt. Teensy is just so much faster, instant boot time compared to a pi, floating point and 32 bit calcs no sweat. Plus the dual onboard canbus of course. In your case PLA might be fine, I actually drove around for a month or two with it - it was just a whole day of left out in the beating summer sun in a sealed car that did it. But have redone in petg which should be good. If youre ever looking at getting a screen go for the nextion options over 4dsystems. Cheaper and much much much faster. 4d screens only have an 8 bit processor and have a crappy slow refresh rate.
  6. Davidv

    programmable logic

    Yep it is a plug and play swap for factory dash, and everything works. The cruise control ignition trim, I've had it automatically build some surprisingly sane ignition tables just from starting at 10deg everywhere. But still fine tuning it. I had my 3D printed housing get a bit melty left in the car on a super hot day and sagged on its mounts and warped a bit. So I've reprinted it with a more temperature resilient material. It's a bit of a mess behind the cover as its a hodge podge of lots of parts. but I'm just in the process of consolidating everything onto a single circuit board. Still heaps of work left till I'm done, but, was an awesome milestone to get it working as a plug and play.
  7. Davidv

    programmable logic

    I started out building apon the excellent work of @paulr33 with his canbus example code that he put in a post here and also on his website: http://www.paulr33.com/?page_id=16 I'm not using any of that initial code anymore as I moved from Arduino Mega to Teensy 3.6. But it helped me understand the basics immeasurably.
  8. Davidv

    programmable logic

    Ages ago I was using cruise control to do some road tuning for best fuel economy. I'd drive a set piece of road at a set speed. Then had digital inputs on the dash that added different combinations of ignition timing. So I'd go do a run at XYZ speed, which has lots of ups and downs in it to vary the load. Record a log file. Then come do that same thing again, with different amounts of ignition advance added by the switches. This showed clear as day in the CC per min fuel usage logs, and TPS, which was best. So I took this a step further and made an arduino canbus unit that would wait for certain conditions to be met (cruise control on,steady driving no tps movement) When cruise control is turned on, a virtual aux is triggered by the Teensy which sends a digital canbus input to turn on a 4D ignition table that has an analog canbus input as the load axis. Then the Teensy has a full separate ignition table in it, and outputs the can value that represents ignition advance for the table. It would collect 100 samples of fuel economy. Advance the ignition 3 degrees. wait for conditions to stabilize again. Then collect another 100 samples. Then it would compare the results of the test. If the results were better above a certain margin, it deinterpolates the current load/rpm ignition timing addition back over the 4 cells that its interpolating from. Then it checks that if there is any lower load area or lower rpm that has less ignition timing than this, it will update those values too. If the economy got worse, it would creep the ignition timing slightly back from where it started from, and do it again. Basically it's auto road tuning for MBT. (But only works in a fairly narrow rpm and load range, because you dont have cruise control turned on at 8000rpm WOT) So it iteratively builds up an ignition timing map on its own and keeps fine tuning it. Starting with 10 degrees timing everywhere, it builds up a relatively sane ignition timing map in about an hour or two which is really cool. But whats nice is that when the car comes to a stop I can store the values to Eeprom so they're not lost when car shuts off. So I'm also planning to shuffle the knock sensing logic over to this board too, so I can store long term knock trims instead of losing everything when car turns off. However, this then also scope creeped into a context sensitive plug and play digidash / 3d printed housing. With a whole bunch of other crap going on like auto dimming, changing screens based on what you're doing, xy plots, histograms, etc etc. Also takes all of the standard dash inputs like lights, indicators, etc etc. Work in progress! (Its for an 80s car hence LCD type look) Working through some bits at the moment like estimated range off remaining fuel, and things like that. Has been a good learning experience and I'm pretty happy with the results so far. Once the auto dimming became functional It's been really nice to drive with. Trust me though, you dont want to see the code hahaaha.
  9. An example: Going through the options it looks like MAF is the only one with this quirk. I want to run one of the more modern MAFs which has a humidity sensor. The fact that Humidity outputs as a frequency isnt a problem at all, as theres no input for humidity so its frequency will just be a load axis on a trim table anyway. But the mass air flow signal is digital too, and mass air flow being mass air flow is pretty critical for the rest of the modelled fuel stuff to work nicely. If a frequency based maf doesnt work, not the end of the world to be honest.
  10. The scale on the cal tables can only be volts or resistance... What do I do, for a DI when a cal table has been set?
  11. Davidv

    programmable logic

    I know its a bit of a bodge, but I've done this by using CAN inputs and outputs. You can output variables over can, do maths/programming/etc on your canbus device using the information, then send the variables back into the ECU. I do this to log a litres per 100km parameter into the ECU so I can view it in the logs with everything else (only cc per min is available otherwise) I've also used a canbus input as the load axis on an ignition table and had my device trim the ignition timing with more logic than is available on the ECU. Check out Teensy 3.6 and the IFCT library for it.
  12. What's your load axis currently? If you are using MAP you might find its beneficial to switch over to a TPS based load axis at lower load where map is unstable. Out of interest do you have any logs you could post up? And what kind of intake is on it?
  13. Since that last post spent a bunch more time working on the dash. Been trying to keep an 80s sort of theme to it while looking somewhat like it belongs in the car. It's now at the point where all of the factory dash plugs fit straight into the back of it, it uses some opto isolators to input all of the standard dash things like indicators, high beam, etc. It's got auto dimming on the screen which works great. It can log to SD card, read it back and draw XY plots or histograms or whatever. Learning a lot about interface design, and minimizing distraction. Although it looks plain with only a few things on it, when you turn on an indicator (or whatever) it flashes on screen as you'd expect. The digits for temperature turn yellow then red as you cross a certain threshold. Also building some contextual screens so that it shows you different information when you're racing vs cruise control turned on vs normal driving. Or whatever. So for example, when racing you only really want a tacho bar going from say 4k - 9krpm and only want to see temps or pressures if they're a problem. So show minimal stuff. If you've got cruise control turned on, you're likely more interested to see fuel economy data, estimated remaining range, trip meters and so on. Has been a bloody long project but feels good to be at the fun part instead of battling with trying to learn programming, trying to learn canbus, trying to learn arduino etc all at once! In other news I tried an ITB setup but results seem to indicate less power than factory setup at best of times, and when heat soaking, significantly less power. Sounds completely obnoxiously loud and looks cool though haha. Currently making a few different trumpet designs, will dyno to see which works best and then see what I can do to build an airbox around them to mitigate the temperature issues. But in the meantime, back to standard plenum because I quite enjoy the E-throttle/cruise control, and, well, it looks to make better power too!
  14. Your mixture map is whatever your fuel table is. If you have two fuel tables, you need to go into the options and switch to that instead.
×
×
  • Create New...