Jump to content

Davidv

Members
  • Posts

    323
  • Joined

  • Last visited

  • Days Won

    32

Reputation Activity

  1. Like
    Davidv reacted to Simon in MR2/ST205 and Knock   
    Highly likely.
  2. Like
    Davidv reacted to Adamw in Cold Start - Pre Crank Prime and Crank Enrichment Tables   
    I think with engine temps of 10°C and 94% ethanol you are going to struggle with cold start and there will be little you can do from a tune perspective to help.  The vapour pressure of straight ethanol is very low so there will barely be any vapor in the port at that temp no matter how much fuel you dump in, it will just remain as liquid. Somewhere below around 10°C there is not enough vapor produced to support combustion.  This is the reason why pump E85 gets reduced to E60-E70 in winter so there is a little more of the volitile solvents available to create some vapor in the port.
    In regions like Brazil etc where they predominantly use straight ethanol it is common to use heated injectors to get around the problem.
  3. Like
    Davidv reacted to hexdmy in tps and MAP accel fueling together   
    Bumping this topic... I'm surprised no one else has interest in this. OEM systems I have worked with do this, and it makes sense. At low throttle openings, a change of throttle angle is a better trigger for transient fueling than map for engines that have low / noisy idle vacuum. However, at steady throttle angles, on a turbo engine, as the boost builds, there can be a need for additional fueling, otherwise you get a lean spike. I've noticed this when tuning steady state and then doing transient sweeps, if you tune to the sweep, you get a inverse V in your fuel map. 
    Certainly this is not reinventing the wheel, just doing what the OEM's have already been doing for many years, and for good reason. 
     
     
  4. Like
    Davidv reacted to Brad Burnett in VVT Control Theory - Offsets and Cam Timing   
    cool .. Was trying to get ideas  for my turbo/rewire thats about to happen.  The idea of a maf sensor for this very purpose was on the table.  But id be concerned with maxing it out in the turbo application as im not going to be running any huge pipes.
  5. Like
    Davidv reacted to Adamw in Hella SSR Relay fuel pump control issue.   
    Yes, it is even more critical than fuel injector control.  Spill valves are controlled just like injectors - they usually have battery voltage deadtime compensation and other PW compensations based on solenoid characteristics as part of the control strategy.  Because fuel is not compressible and the HP pump is a mechanically driven piston pump, to keep the fuel pressure near target the spill valve needs to add exactly the same amount of fuel to the rail as the injectors let out.  The only way it can know how much fuel the pump is capable of delivering at any instant is by knowing camshaft position (i.e how where the pump piston is on its cam lobe).   Say if the ecu calculates it needs 0.2cc of fuel added to the rail and it knows the pump capacity is 0.4cc per stroke, then it needs to close the spill valve when the piston is exactly half way up the cam lobe.
     
    The graph at the top right of the russian picture is a better representation of what P&H looks like.  So a short patch of 0V (this is the "peak" current), then the rest of the opening time is just short pulses to 0V (typically about 25%DC).
  6. Like
    Davidv reacted to Adamw in Fuel Pump Control for dummies   
    Fuel pump heating the fuel is a myth in my experience.  My injector flow bench has 2x 044's in about a 10 lire tank and I only get about 5 degrees increase over a couple of hours.  
    Say if your pump pulls 10A, that is only ~140watts, DC motors are about 80% efficient and vane pumps are up in that ball park too, so you may have something like 50watts of heat produced by the pump, most of it will be radiated off the large surface area tank etc.
    Also, see this one:
     
  7. Like
    Davidv reacted to Richard Hill in Reccomendations for setting up per cylinder EGT?   
    this is how to input an ecumaster can egt board.  Should be similar (byteorders may be different )

    HTH,
    Richard .
  8. Thanks
    Davidv got a reaction from iliasfyntanidis in Knock Setup on G4+ Plug in - EVO 6   
    Okay so there are a few stages to setting it up.
     
     
    1. Wiring
    Run one wire to the knock1 or knock2 wire on the link loom, and one to sensor earth, polarity unimportant. must must must must use shielded wire. The knock sensor outputs a very low voltage signal that's prone to interference.
    2. Initial settings
    Since you are using the 'wideband' knock sensor and an engine with an ~86mm bore has a knock frequency in the ~6khz range select your Freq Channel as 4-10khz Wide Band.
    Set Ignition Retard limit to 0 degrees.
    Set the RPM high and low lockouts however you like. (500rpm likely not ideal for the low setting)

     

    3. Cylinder balancing
    Your knock sensor is mounted closer to one cylinder than the others. It picks up vibrations, so the vibrations from that one cylinder will give a stronger signal than the others.
    So what you need to do, is hold the motor at say 4000rpm (no load) and check the signal strength of each cylinder.
    You can check the signal strength by pressing F12 to get to the runtime values screen and looking at these numbers, knock level cyl 1/2/34

     
     
    See how in that example above, the numbers are 235 / 160 / 255 /145. You need to get these numbers as balanced / equal as possible.

    You can adjust the values up or down by tweaking the numbers up and down in Knock control > Cyl setup > Cyl 1/2/34 knk level gain
     

     
     
    Best to start with a value of 1 for the cylinder that's closest to the knock sensor, and increase the other values to suit. If one of the values reaches '2' (maximum) you can reduce some of the other numbers to less than 1.
    4. Non knock noise levels
    Since the knock sensor picks up vibrations, there are of course vibrations happening even when there's no knock. As RPM increases, the amount of 'natural' background noise increases too.
    The ECU can tell that knock is happening, because there's an unexpected large spike in the 'noise' from the motor around the time of the iginition event. Soooo, you need to find out what the background noise level is for your engine.
    According to the manual, a 2 row table with full throttle and 0 throttle is sufficient but this is up to you and how long you want to spend on it haha.
    So head to Knock control > Knock target, right click on the table and select Axis setup to define your table similar to this (if you want)
     

     
    Then you need to run a datalog through the rpm range at full throttle to see what the values are for this table. (and coast back down off throttle for the zero TP target, although I'm guessing not much knock happens at 0% throttle)
    Open the datalog and bring up a screen to show engine rpm and the knock level global.
    Knock level global has a maximum value of '1000'. If you find that you are hitting 1000, you need to reduce the Gain Channel number on the main knock sensing setup page to something a bit lower and try again. Remember that the '1000' has to be the maximum even including allowance for knock which is much stronger signal than the background noise so you need to allow headroom for that too.
     

     
    Once you've established these background noise levels for the motor in your table, increase all of the numbers in the table by 20% to give it a bit of a margin against picking up normal engine noise as knock.
    At this point, because you've set the maximum ignition retard to 0 degrees in your first step, the ECU isnt taking any action against knock.
    Now that you've got everything setup though (unless I've missed a step here, haha) you can turn the knock sensing on by setting an ignition retard limit here, to say 3 degrees or 5 degrees or whatever you want:

    Then as per reccomendations from the manual, it's best to test that knock sensing is working under a scenario that minimises risk of damage to your engine.
    So you could drive along at low load / low rpm and induce knock by creeping the timing forward until it knocks and you can see from the runtime values table (F12) that it's working.
    From here, it should all be working awesomely. (No responsibility taken for blown up motor though! This is just what has worked for me)

    Hopefully it all makes sense though
    Where are you based / what is the car used for? 
    Keen to hear how you get on.
  9. Like
    Davidv got a reaction from Simon in Preventing E-throttle gear breakage Beams 3SGE (and similar)   
    Hi, 
    On the default settings I've broken a few sets of E-throttle gears, and I've seen a few other people mention similar. 

    (I've busted 3-4 gears already)

    So I've been looking at ways to mitigate this. 
    Initially I started just looking at the throttle mapping itself, setting the max and min to 2% and 98% so it's not trying to bang into the end stops.
    But then realized that the e-throttle clutch can be used to help as well, by softening the clutch near the end stops. 

    So I'm using a table like this, and havent had any breaks since: 






    Perhaps it might need fine tuning on an individual basis to make sure it's not slipping too much near the extremities, but it's tested as working well tracking to its target even with high motor DC / fast accel/decel rates.
  10. Like
    Davidv reacted to Adamw in CAN Hub   
    I think the reason they do a CAN hub is probably because most of their devices come pre-terminated "plug and play".  We dont do that so much and most feedback seems to suggest the flexibility is prefered.    A CAN bus doesnt need a "hub", the whole system was designed to be a main "trunk" that the devices can just splice into parallel anywhere along the line.  A $200 hub is just a very expensive way to splice two wires into 4...  But the Haltech hub should work with any bodies  CAN bus including Link if you really want to pay that much.

     
    I've never used these yet but I've noticed recently you can also get CAN bus specific DTM connectors including "splitter hubs" and terminating caps which could be a nice way to do it if you wanted easy expandability:

     
  11. Like
    Davidv reacted to paulr33 in programmable logic   
    I didn’t have any issues with speed and always had fast updates on my display. The problem with my setup was when I needed to change something on the display I had to put it all apart and plug it into the PC seperately to update the 4D systems screen and then the arduino code seperately and also the screen would drop out and flicker because the wiring was always loose from the plugs. 
    The plex usdm is a commercial solution and I can change the scenes and layouts and customise to my hearts content while sitting in the car via USB on the side of the display. 
  12. Like
    Davidv got a reaction from redmist in 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.
  13. Like
    Davidv reacted to redmist in programmable logic   
    I've currently got all 6 seven segments and the 8x8 Matrix to work with Link "generic dash" can bus output. There is some work to do with my neopixel library conflicting another of my libraries, and a weird issue with my can bus adapter only picking up frame 0 or 1 when you start to introduce a delay (like writing to the 7 Segs). However given a correction of my frame issue I'm not seeing any problems with refresh from the Nano. Weird thing is the Nano will do several hundred main loops prior to picking yet another frame 0 from the buffer. 
    Although there is a deep imprint of my keyboard in my forehead I'm enjoying battling with the cheap ahrse and very flashy intelligent 7 Segs, 8x8 and neopixels... the cheap can bus adapter... not so much.
  14. Like
    Davidv reacted to Richard Hill in programmable logic   
    I moved away from using generic dash as it employs a compound CAN message, which can be a bit of a mouthful for both the ECU sending and the device receiving.  I prefer to use messages which are split over several CAN IDs such as transmit generic dash 2.  The only problem with Generic Dash 2 is there's appears to be a  bug in the non driven wheel speed (1 byte assigned, but shows as 0-1000kph, guess the text was copied from generic dash).  Not a problem though if you aren't planning on going more than 158 MPH...
  15. Like
    Davidv got a reaction from MagicMike in 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.


  16. Like
    Davidv got a reaction from MagicMike in 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.
     
  17. Like
    Davidv reacted to redmist in programmable logic   
    Nice job David!
    Thank you for the pointers to Pauls well presented site. Thankyou Paul for spending the time and effort to detail such. 

    I gather the reason people have migrated from the arduino mega/nano to the teensy (or other platform) is because it's just too slow? I suspect by the time I generate interrupts from the flappy paddles and insert new frames on the canbus I'll simply ask too much from this stupidly cheap device. 
    My dash is currently being benched (chose a mass of 7 segments as they are bright in sunlight for the open race car), have it testing libraries and some basic code to pull frames  and data from the canbus... it just needs some proto board... me to design and print a case (I'll keep away from PLA now thanks Dave!!!) and a tonne of tidying in code and wiring. 

    Think I'll design and print the case around the ability to replace it with a Raspberry Pi Zero W. The nano seems fast enough, but does not seem reliable. I've also broken apart the canbus frames with my Pi based radio telemetry such that given the 7 segment and nanopixel libraries I shouldn't have too much issue migrating to the Pi. 

  18. Like
    Davidv reacted to Brad Burnett in Beams 3SGE + G4+ Xtreme 1983 Toyota Carina   
    Yep, i have S54 throttle motor on my 3s Beams with black top 20v ITBs.
    I even wired in a cruise control switch from a 350z last week and now have full functional cruise control with DBW itbs.  It makes my 25 min commute to work at 85mph quite comfortable.
  19. Like
    Davidv reacted to paulr33 in programmable logic   
    Good work. I ended up going for a plex usdm but making the arduino CAN display did help me learn it all and how it works which was good fun 
  20. Like
    Davidv reacted to Simon in How do you use cal tables with digital inputs?   
    You can't is the short answer. 
    Im not actually sure that MAF should even be an option currently in the Di channels.
  21. Like
    Davidv reacted to tarlo in Co2 boost control   
    i have co2 boost control on my skyline using the fury to control it. I just use a 1kg co2 bottle with a 3 pot mac valve it works really  well however i needed to use pneumatic needle and seat valves to get it smooth which also saves co2 they were about $10 from a air plant shop. Can run a 3psi spring and achieve 40psi can do nice boost vs speed tables etc awesome for track. If you need any info let me know and ill email you pics  

  22. Like
    Davidv reacted to DriftCentral in Birdgeport driveability?   
    Hey guys I was wondering if there is anything I can do to address the jerkyness of a bridge Port 13b at the lower RPM and load range for better drivability especially in the cruising around zones 
  23. Like
    Davidv got a reaction from dynoiasi in Suggestion: New Mixture Map logic for improved results   
    Hi, 

    Currently with mixture map you set a threshold so that samples within say 25% of the centre of a cell vertically and horizontally.
    This pool of results are used to contribute towards an average value in the centre of the closest cell. 
    However this means that you've got 25% variation of rpm and load, contributing to a static value in the centre - and you need to throw away 75% (?) of recorded values.
    I have another idea that can let you use all of the data instead, and improve the results.
    For simplicity's sake imagine a 4x4 grid, and our current load and rpm point is 25% of the way towards the lower RPM value and 25% of the way towards the lower Load value. 
    If we interpolate these values, as per what the ECU does. 
    Note: I have just titled the columns and rows with percentages to show what percentage of the each cell we are interpolating from.



    We get a value of (25% * 25* 10) + ( 25% * 75% * 30) + (25% * 75% * 20) + (75% * 75 * 40)
    = 0.625 + 6.075 + 3.75 + 22.5

    = 32.95 is the table value that interpolation produces. 

    Now lets say that you wanted to add 10% to this value.

    If we just adjust the closest cell by 10%, as per current Mixture Map strategy. Then our bottom left cell changes to 44 so our table now looks like this:



    If we do the interpolation again, but with the new value to represent running the car again after the update:
    We get a value of (25% * 25* 10) + ( 25% * 75% * 30) + (25% * 75% * 20) + (75% * 75 * 44)
    = 0.625 + 6.075 + 3.75 + 24.75

    = 35.2 as the new overall value. Which is only makes 6.8% difference to the interpolated value, rather than the 10% we wanted.

    On the other hand...

    If PCLink De-interpolated the 10% that it wants to add.

    Instead of adding 10% to the one cell, we split the 10% addition across the 4 cells based on the same percentage that the value was interpolated from initially. 

    So:
    Top left cell: (10 * 1.1 * .25 * .25) = 0.6875
    Bottom left cell: (30 * 1.1 * .25 * .75) = 6.1875
    Top Right Cell:   (20 * 1.1 * .25 * .75) = 4.125
    Bottom Right Cell: (40 * 1.1 * .75 * .75) = 24.75


    = 35.75 is the table value that de-interpolation produces. 

    We were trying to add 10% and this new value produced is 10.5%. So that's pretty good!  
    (The 0.5% error comes from rounding to 3 decimal places in my example)
    So it's accurate to the provided data in every instance. Which is especially relevant when it's applied 1000s of times across all of the cells. You dont need to throw away any of your recorded data, it all contributes to the cell values.

    Mixture map is pretty good for roughing out a map initially but because of the inaccuracies of the "nearest cell" method I don't really use it that much anymore when trying to dial in a fuel map. You always overshoot or undershoot unless you set your cell tolerances impossibly tight and have millions of samples.

    And, since this is all only done in PCLINK rather than the ECU, there's not really any worry about the overheads of the extra maths involved. It's worth having it chug away for a few minutes longer if you can get an awesome result on first or second iteration of Mixture map logging.

    So - that's my Friday night suggestion. 
    Thanks for reading if you got this far, haha.

     
     
  24. Like
    Davidv got a reaction from Tim D in Suggestion: New Mixture Map logic for improved results   
    Hi, 

    Currently with mixture map you set a threshold so that samples within say 25% of the centre of a cell vertically and horizontally.
    This pool of results are used to contribute towards an average value in the centre of the closest cell. 
    However this means that you've got 25% variation of rpm and load, contributing to a static value in the centre - and you need to throw away 75% (?) of recorded values.
    I have another idea that can let you use all of the data instead, and improve the results.
    For simplicity's sake imagine a 4x4 grid, and our current load and rpm point is 25% of the way towards the lower RPM value and 25% of the way towards the lower Load value. 
    If we interpolate these values, as per what the ECU does. 
    Note: I have just titled the columns and rows with percentages to show what percentage of the each cell we are interpolating from.



    We get a value of (25% * 25* 10) + ( 25% * 75% * 30) + (25% * 75% * 20) + (75% * 75 * 40)
    = 0.625 + 6.075 + 3.75 + 22.5

    = 32.95 is the table value that interpolation produces. 

    Now lets say that you wanted to add 10% to this value.

    If we just adjust the closest cell by 10%, as per current Mixture Map strategy. Then our bottom left cell changes to 44 so our table now looks like this:



    If we do the interpolation again, but with the new value to represent running the car again after the update:
    We get a value of (25% * 25* 10) + ( 25% * 75% * 30) + (25% * 75% * 20) + (75% * 75 * 44)
    = 0.625 + 6.075 + 3.75 + 24.75

    = 35.2 as the new overall value. Which is only makes 6.8% difference to the interpolated value, rather than the 10% we wanted.

    On the other hand...

    If PCLink De-interpolated the 10% that it wants to add.

    Instead of adding 10% to the one cell, we split the 10% addition across the 4 cells based on the same percentage that the value was interpolated from initially. 

    So:
    Top left cell: (10 * 1.1 * .25 * .25) = 0.6875
    Bottom left cell: (30 * 1.1 * .25 * .75) = 6.1875
    Top Right Cell:   (20 * 1.1 * .25 * .75) = 4.125
    Bottom Right Cell: (40 * 1.1 * .75 * .75) = 24.75


    = 35.75 is the table value that de-interpolation produces. 

    We were trying to add 10% and this new value produced is 10.5%. So that's pretty good!  
    (The 0.5% error comes from rounding to 3 decimal places in my example)
    So it's accurate to the provided data in every instance. Which is especially relevant when it's applied 1000s of times across all of the cells. You dont need to throw away any of your recorded data, it all contributes to the cell values.

    Mixture map is pretty good for roughing out a map initially but because of the inaccuracies of the "nearest cell" method I don't really use it that much anymore when trying to dial in a fuel map. You always overshoot or undershoot unless you set your cell tolerances impossibly tight and have millions of samples.

    And, since this is all only done in PCLINK rather than the ECU, there's not really any worry about the overheads of the extra maths involved. It's worth having it chug away for a few minutes longer if you can get an awesome result on first or second iteration of Mixture map logging.

    So - that's my Friday night suggestion. 
    Thanks for reading if you got this far, haha.

     
     
  25. Like
    Davidv reacted to Joe Bucci in EMAP (Exhaust Back Pressure) Sensor   
    Here is an example of mine. Source is EGR port, which may skew the number from actual, but I don't have a way to source off the manifold of turbine housing right now. The far side of the canister will go to a braided line. The braided line will go to a firewall mounted pressure transducer. I suppose the transducer could be screwed directly into the canister.

×
×
  • Create New...