Jump to content

mapper

Members
  • Posts

    367
  • Joined

  • Last visited

  • Days Won

    32

Posts posted by mapper

  1. On 11/2/2023 at 11:08 AM, ROB-80E said:

    IMO nothing can compare to what the stock ECU is capable of doing.  Not MDC, Emtron, link or anything else that doesn't use the same level of inputs and calculations.

    The MAJOR drawback with the factory ECU is the ability to log (easily).  It can be done using EvoScan, but it can't be done internally.   This is the major bonus of the Motec or Emtron (or possibly even Link...i haven't had any experience here) is that you can accurately log the Center Diff control parameters just as easy as everything else in the engine ECU.

    Now don't get me wrong, you can certainly achieve great results with an aftermarket ACD solution, and the ability to find someone to tune them is probably easier too....but yeah I've been doing the factory ecu setup for over 10 years now and see no reason to change.

    The attachment is a simplified control diagram of the factory ECU.

    MMC 4WD-ECU basics.jpg

    That logic is pretty much the logic i wrote on the link with maths, VA, and GP Pwm tables. While we made improvements with stock AWD Tuning, the switch to Link unlocked a lot more potential. And at the end of the day you need to exactly know what the center diff is doing when you tune your suspension setup properly. 

  2. On 1/10/2024 at 5:44 PM, koracing said:

    You would have to export to excel as a comma delimited format and use excel to create more advanced math equations or use something like Megalogviewer to do them.  Does the MoTeC software allow importing comma delimited files?

    Yes, but you need a extra Licence for .CSV imports. We have a few professional race teams customers who use it. 

  3. Yes, we reverse engineered the Renault Megane RS 3 and replaced the stock ECU with Link Furry. We used a AIM Dash, so the OEM dash is not fully integrated yet. However, it is something we can do, if we get enough requests for the ECU Kit. 

  4. We need many more target lambda tables, like for: 

    • post start 
    • ECT based
    • IAT based
    • Exhaust Temp
    • Throttle Position
    • average load based
    • knock fuel trims (apply target trim instead of enrich, which the CL pulls back) 
    • NOS compensation
    • two separate targets for Multi fuel mode
    • Launch 

    One way I can think of to do it, is use 4,5,6D and better some more tables as a target lambda or target lambda trim instead of a fuel trim. However, the ECU should just use the richest target within the calibration, so it doesn't get too rich when several conditions are meet. Like high IAT, ECT and Exhaust Temp, which are usually hit at the same time. Using target modifier for each condition, would end up in extensively rich target lambda. 
     

  5. 15 hours ago, DerekAE86 said:

    Could you maybe utilize a 4D fuel map and set TPS Delta as the axis and remove x% of fuel as you get a negative DPS delta.

    You'd have to chose if you create the table against RPM or ECT and you'd lose the decay rate settings - but it might work?

    That's exactly what I did for testing. However, there should be some additional conditions used like PT1- like reduction of fuel de-enrichment, coolant temp compensation, and all the stuff which is used in the acceleration model, just with a negative sign, before it is applied to the fuel model. 
     

  6. When the Throttle is suddenly lifted, lambda values go much to rich, do to the small delay in MAP reading and the fuel film puddle in the ports are sucked into the cylinder. 
    I like to see a deceleration enrichment which removes fuel in these situations. 
    Wondering if other tuners are missing this too? 

  7. good suggestions
    I would also add a time delay to each filter setting. So for example when transient rpm was detected, mixture map sampling is delayed by X secs or better engine cycles until Lambda reading has stabilized

     

  8. Here is what the manual says. From my expierence the full 33 amps are reached only for a very short time, so the Razor PDM might handle it fine. On top you can define Inrush current and safety trip time.  The hardware is very capable, so I guess it will handle it just fine. 


    Outputs

    High Power

    There are 4x high power outputs with a maximum safe inrush current of 80A and a continuous current limit of 25A at 12V.

    While the maximum safe inrush current is 80A, the maximum measurable current is 60A.

    The high power outputs each share two pins of the 26-pin super seal connector.

    They can be used as high-side or low-side drivers, have a max frequency of 10kHz, and can be configured as 4 x half bridges or 2 x full bridges allowing control of devices such as e-wastegates. 

    When in full bridge mode, Output 1 is paired with Output 2 and Output 3 is paired with Output 4.  

    Outputs can be joined together to allow the use of higher current devices.

  9. The big difference on Motec's halve bridge is they can do. 10 amps compared to 2-3 amps of the other Aux types. 

    Technicaly Adam is spot on. I guess most manufacturer name there outputs which can be cofigured to a full bridge - halfe bridge

  10. In short, absolut no. In fact the upersit is the case. The latest gearshift strategy in the g4x is much more advaced than any external gearbox controller I have seen (incl. Geartronics). Checkout the the?gearshift strategy in G4x. Its fantastic?and works like charm. Give you set it up correctly.

    I highly recommend to use a strainge gauge and a barel position sensor on the gearbox. Additional a whelspeed sensor and e-throttle helps for perfect autoblip downshifts.

  11. Basically, the .DBC file is the raw communication protocol. Means it only define the raw communication format on the lowest layer. All higher layer protocols like OBD, UDS as well as functions like checksum etc. are not defined and are rules that must be handled separately. So for now I would concentrate on the lowest .DBC level.  Basically every car, tractor, industry device manufacturer works with .DBC editors to plan and setup their communication networks. One of the most used tools here in Europe is Vector CAN++. A huge tool for very big CAN projects. 

    I think also .DBC file import with a mapping function is well worth, assigning the Link CAN input channels is no big deal. But manually typing all names, offsets, multiplier, etc. is time-consuming and very error-prone. Also for you guys it will save good time in the long run. For example instead of working out a CAN template for 3th part CAN expander and add a template into the software, LinkECU user can just import the .DBC file from the 3th part device.  

     

    Vaughan:

    - Import function as you described sounds great. Check out the DBC. file import function on Motec's Dash manager. Found it well-made.  In the actual software Can values can only be logged if they are assigned to a ECU CAN Input. It would be great if on next gen ECU (or maybe already on G5) everything on the CAN can be logged, even if the channel is not assigned to a ECU function. With GPS coming on G5 and the 1000hz logging we have now, there is no reason to use any other logger in the car. So the usually Logger on the Display, we use for driver and chassis analysis, can be saved (and the budget spent into a more expensive ECU ;-) ). 

    - Multiplexing (Compound). It is available in the .DBC standard and should not be a problem. I found Kvaser Database Editor 3 easy and very straight forward to create .DBC files. Might give it a go. I can send you some example .DBC files. It would be awesome if PC Link CAN setup has the columbs added as in database editor 3,  so you basicly setup the dbc, while you cofiguring the Link CAN. And btw. it would really help to have notes and enumerations to each parameter. For things like counters setup by a Math channel (just like Adam postet it today in another treath). So when you come back later, it's clear for what I was setup.  

    - Enumerations: it's not  necessary to have user definable Enumerations in the beginning (of course, would be nice). Just the Link channels Enummerations could be packed into the .DBC file. For example, parameters like "Fault Code". "Antilag-State" should have the corresponding Text put into the enumeration slots of the .DBC. Basically everything should already been there. The CAN test calculator shows all the number>Enumeration(Text) translation. 

    - Yes, I usually set up a separate .DBC for transmit and receiving. I'm not sure if there is a combined format available and also have not played a lote with notes in .DBC editing softwares. 

    - Can Sniffer would be awesome. Also for PDM Link. Even if it is a basic list of traffic it will be quite useful for quick checks.  Second importan function for me is a static ID list with live data, so it's easy to spot what changes if for example a buton is pressed. Ideally recent changed are coloured like in Savvy or CAN Hacker Carbus Analysis software. On a next step you could basicly add all the function what Carbus Analyzer has. 

     

    Adam: 

    I found a lot of aftermarket devices support .DBC and find it a huge time saver. For example, I wrote the whole Link generic Dash Stream in Race Studio manually + additional channels in AIM Race Studio, 2-3 years ago. Manually typing in all channel names, offsets, etc. is just a waste of time. On top testing all channels for right format needs some more time. 

    Regarding floating point, the raw can messages are sent always in binary form, which are then converted to hex or decimal. Significant figures are  handled by multiplication / divisor. The internal dataformat used in the receiving/transmitting device is depending on the device, so it would not make sense to define that in the communication protocol (.DBC). The same holds true for the content of the message. So all counter, checksums, CRC etc. must be generated by a function in the Receiving / Transmitting device. 

  12. 3 hours ago, Vaughan said:

    Having a look at dbc files at the moment and it looks like they're designed for dash style setups where the runtimes are generic and it's all about displaying that data. Can either of you provide an example (file or explanation) of how you would want to use a dbc file with an ECU?

    Would you be wanting to import a dbc file to tell the ECU what to transmit, importing it to tell the ECU what data to receive or a combination of both (loading one file for transmit and another for receive)

    Or are you wanting to generate a dbc file from a custom CAN stream setup?

    Hi Vaugan 

    Basicly i should allow everything you mentioned. 

    Export.DBC file with channel names, unot etc. So it can imported in another software. A typical application is a custom dash stream. Setup all channels on ecu > export .DBC > import on AIM Racestudio > select new stream in Race studio in config > Done ✔️

    Import: 

    Again with the Dash example

    Setup the CAN output stream on Race Studio > Export .DBC in Race Studio > Import to PC link > PC Link opens a Mapping Window to map the AIM naming to a PC LINK Can Input channel. Naming should taken over from the .DBC (e.g. CAN Input - AIM name). This would make it much easier to setup custom streams between CAN devices. It's in fact for what .DBC files habe been invented. It works really good between different Mfg. Devices. With Enumerations plane text can be assigned to channel numbers. So for example for fault code count, the enumeration text is shown on the dash when a fault is active instead of just a number. Makes it 300% more user friendly. 

    Where I also see very big potential is syncing everything between LINK ECU and PDM whith DBC. In- and export. So the naming is right in the datalog. Means it shows something like "PDM HP 1  - Fuel Pump". ATMO we only see PDM HP 1 in PC link and need to check the calibration on the pdm to know whats connected there. 

    On a a later stage idealy Link is aible to generate new channels and can take over 1:1 everything from the .dbc. File. ( think thats what you meant by Dash style). I usually define all my reverse engineering findings in a DBC editor. Once done I import the .DBC into the can device. An in theory everything should work straight forrward. 

    It would be very useful if there is a CAN sniffer function on PC link and PDM Link So signals can be spot, defined in the .dbc and ploted in PC Link. Thats whats needed for reverse engineering. And is the feature. Or I should sayn it's now, because everything works with CAN nowadays.  In a perfect world there is a test transmit function also, to send byte streams to the bus (usually to test if something is activated trough the oem bus) 

    I will send you much more ideas and feedback as usual via mail.

    BR Adrian, Maptec

×
×
  • Create New...