Jump to content

TnF

Members
  • Posts

    71
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by TnF

  1. Went for some road tuning last night, latest FW and pclink version (5.6.1 build 3098) on a g4+ xtreme black and had a few issues: 1) I was recording logs of my runs. F8 to start and F8 to stop the log. First 2 logs were fine. Then on the 3rd, i press F8 to stop the log and i see this (image attached). File time was huge something like 3xx:xx:xx (in the screenshot of the saved log it shows even more now). I saved the log file and it is 24MB!! wtf..for a ~10 minute log. This is clearly a bug. I turned off the engine, closed pclink and re-opened it. Logs after that were fine.. Here is the log file. I compressed it into a rar file, after you uncompress it, it will be about 24mb. http://www71.zippyshare.com/v/sVOouj6r/file.html 2) I think this is already known, or at least fixed in other tables. So in the boost target table, when i'm working with psi units, if i enter 30 it will show 30.2 and so on. If i put the exact conversion value in kpa and then switch to psi it works correctly..Attached pic for reference (also in the forums it doesn't allow you to attach more than a single file even if the total size is under the filesize limit..fix this please and if you can increase it to 1-2mb) 3) This is a hardware issue and kinda weird. When the engine has been started (even when it is powered off), and you are connected with pclink, if i turn on my headlights it will disconnect. This is using your usb cable (assuming it is shielded). The headlights have nothing to do electrically with the engine harness. But i know the issue is caused by the headlights since they are chinese slim HID's so basically when their igniter sends a high voltage it induces electromagnetic interference. Assuming their shielding is bad it shouldn't cause this problem if the usb cable is shielded as well as the ecu (metallic case). The thing is that with the same laptop, same position, when i was running a Greddy e-manage ultimate i never had such an issue! So i believe because you are using the USB as a serial connection without any packet check even if a packet is messed up it drops the connection...but is your usb cable shielded? Cause if it is i thing the interference might go through the laptop :/ Thanks again!
  2. I'm into this as well, and it is partially related to the other request i wrote We want more control functions and types of control :3
  3. Yes that's exactly the concept i mean, i just went into more technical info regarding the types of control you can have and how to do it
  4. Yes sure, that's why i posted it here so people can see it. You can move it into the Features requests forum after, but still i think there is food for thought here for Link's engineers I hope they are reading the posts
  5. Pic added to show the bug. (don't worry about the label, it is to show that on DI5 the parameters are correct while on DI2 they are wrong)
  6. Yes exactly what you said David But Rich yes that's a nice feature to implement actually since at the moment when you are trying to identify the correct threshold values for the knock tables even with a narrowband knock sensor it is very much a trial and error process (although on my setup i have already set them up pretty close to ideal). However when having a tuning session it is pretty much impossible to replicated all the conditions, so like David explained if the i-trim tables are persistent you may catch some knock where otherwise you would never see (and it is in my case like 3-5 cells on 2 cylinders i caught once). So if the tables are persistent then the engine will be more safe since some knock may happen in one drive, then next time you start the engine it won't have to run the advanced values and it will try to put more timing slowly saving you from potential damage
  7. Thanks i already set up internal logging and i know how to do this, i wanted to confirm. However since the tables are there either way can you give us a function were the values are persistent? Or is this impossible because the ecu can't just store these values without doing a full store? Can't we have persistent tables like long term trims for things that run in closed loop?
  8. Hello. This is something i've been thinking long ago, even before i bought my Link G4+ xtreme black ecu. I am not sure if you will flip me off because it will probably be much work for you guys but on the other hand i believe no-one has such a feature and it goes more into OEM one-off applications we see in newer cars. So to get going, my idea is a feature where in the simplest form is to use a single Analog Input to control multiple parameters (in the activate-deactivate sense) like launch control, anti-lag, traction control, map switching etc so to spare DI for other stuff. Normally if you want to have control over these features/parameter you require to add switches wired to DI's for every one of these things you want to control. However assuming your analog inputs have 10bit ADC's it gives 2^10=1024 individual voltage steps from a range of 0-5V (5/1024=0.0048V per step) which gives 10 possible combinations of parameters you can control (ideally, in reality the ADC might be too sensitive so we go down to less parameters (5 parameters for a 0.02V voltage step). So from Link's side you essentially need to construct a "table" where you can set 10 different parameters to control on and off. To simplify this let's go down to 3 parameters to make this easy to visualize: where x means the function is activated and blank means it is deactivated . Of course it doesn't have to to be a table with voltages like that since if using 10 parameters will require 1024 columns for the voltage steps. The proper way to do this is via binary counting since you can easily index all combinations and calculate the state of each parameter (on or off) without an array which would take lots of space. As a follow up to the example above where we set n=3 as the total number of the parameters to control we need a binary value of n (3 in this case) digits. If we set 1st digit as parameter A, 2nd as B, and 3rd as C we have the following combinations that will always hold true (index the same) for any n number of parameters we want to control: Thus we can easily calculate and control any parameter directly through the ADC value of the analog input. This works great for both sides (Link ecu and client side of which i will go into detail later in the post). To simplify again how this should work lets break it down. In this case let's say we use all 10bits of the ADC. PcLink should have a table that you can set 10 parameters to control. It is important that these parameters are entered with the same order for both PcLink and client side. Let say we set: Let's say i want to activate B and H. This means i need to convert the binary 0100000100 (note where i put 1's, B is 2nd, H is 8th). If i do the conversion i end up with the decimal value of 260. Then the client side DAC sends a signal of about 5V * 260 /1024 = 1.27V. The link ecu receives this voltage on the analog input (ADC) and measures it as decimal 260. Converting back this decimal to binary we get 0100000100. The ecu sees the 2nd and 8th digits of the binary value are 1 so it activates functions B and H. I hope this makes it clear. We can go into more detail why this not work perfectly and the ADC might read 259 or 261, thus why i said we might need to use less than 10 parameters depending on the sensitivity of the ADC. Also you are not limited to using a single ADC. If you have 2 analog inputs connected you can potentially control 10x10 = 100 parameters. Of course we are not limited to using analog inputs for this feature, we can do this via a DIGITAL INPUT, SERIAL, CAN etc. Client wise this is very easy to do. What i personally plan to do is use a microcontroller (an arduino for example), an oled screen and some push switches to make a nice, user friendly interface where you can select what to control at any moment without having to add lots of switches and knobs. I am also planning to control more things, like boost target since a $5 arduino microcontroller gives you lots of I/O. Plus it only costs $10-$20 in materials total. I will freely provide code, schematics and diagrams if this thing is implemented. It's not that i can't at the moment, it's just i will run out of AN's and DI's which should be reserved for sensors, not for controlling FEATURES. SO PLEASE PLEASE PLEASE MAKE THIS HAPPEN! NO OTHER AFTERMARKET EMU (i know of) has such a feature and would add greatly to your products. And while you could release such a module yourself's please do not make it proprietary, we want to have the flexibility as end users (afterall that's why we bought an aftermarket ecu in the first place!) AFTERTHOUGHT: I bought an aftermarket ecu not to make more power - you only require air, fuel and right timing for that - but to get and control more features. This is so that i can modernize the car and make it more relevant as a daily and even give more flexibility for a motorsport application. All the above and more can be done really easily nowadays - you can get a cheap windows tablet connect it via usb and run PcLink on it if you want. And this is another way we should think my idea. Maybe you want to use it as to monitor stuff without a laptop, control things, think of R35 dash for example. Why bother to use OBD when you can do so much more via direct USB? It is not like hardware changes are needed, you can do this via software alone. So please consider this
  9. Hello. I have a question regarding knock clear i-trim tables function. If set to OFF will the ecu remember the knock values after several power cycles? Reason is that i want to use it as a way to identify ignition cells that produce knock while i'm driving daily without a laptop. This way after several drives i can go back and check if there is any knock and correct the ignition table. Kind regards
  10. Hello. I had notified you of this through facebook a couple months ago but it seems it has been lost somewhere. So when you set DI2 as start position you get an Active edge option instead of On level option as it should be. On other DI it shows ok (but i haven't tested all). Kind regards
  11. Not possible in my case, not to count all the negative factors going that route. Either way i was correct after all and i did it Went with number (2) aka the micro-controller route. While it can't be done in analog is much easier this way, cheaper and more efficient. What i did is to connect an Arduino micro-controller that takes measurements when the mtx-d pulls up the line and then feeds them as 0-5V to the analog inputs of the Link ecu. Then you do a table calibration there and you are done. Since the microcontroler has 10bit ADC resolution is good enough. Output is done via pulsewidth modulation at 980hz. I should add a small capacitor to smooth out the voltage but i didn't bother yet. Here the code says it all: And see my screen attachment i lost last time - mtx-d does do alternative measurements indicating they are using a single ADC
  12. So essentially I need to implement my own solution. Let's see how it goes
  13. It is doing that! I need to do some more measurements to verify exactly what it is going on, but i have potential solutions for this problem. - The simplest one is that if it does indeed a voltage measurement (aka voltage divider) when it pulls up the line, then i can technically pull up the line to the same voltage continuously so that Link can take measurements as well. Of course from what i've seen the pull-up voltage is much lower than 5V, but i need to check that using DC coupling. I will need to play with the pull up resistor though in this case since i need to much the effective resistance to the internal value since the extra one will be connected in parallel. I'm not 100% sure that this will work though. - The other solution is to put an arduino (atmel) microcontroller that will take measurements when mtx-d is not taking measurements and then output them in 0-5V analog voltage to the LINK ecu. This will 100% work for sure. - The easiest way though, is since Link has serial communication is that if you could implement their protocol/SDK so we can read values over serial. And since their system works much like canbus you can have many innovate devices connected together which can feed all the data via serial freeing up the analog inputs. But i'm not sure if that's much to ask: http://www.innovatemotorsports.com/support.php http://www.innovatemotorsports.com/support/downloads/SDKSetup.zip http://www.innovatemotorsports.com/support/downloads/Seriallog-2.pdf http://www.innovatemotorsports.com/support/manual/OT-2 SDK.pdf http://www.innovatemotorsports.com/support/downloads/Innovate-OT-2-SDK-v1.31.zip http://www.innovatemotorsports.com/support/downloads/LogWorks3Setup.exe
  14. Ok i was right! The mtx-d pulls the sensors line high everytime it wants to take a measurement! And it does this alternatively between each sensor, confirming it uses a single ADC (probably). I had a screenshot of both sensor lines connected to my oscilloscope and they were exactly half apart (i lost my screenshot but take my word for it). Frequency of the measurements was about 12.5hz. So every 80ms it takes a measurement from one sensor, aka 40ms between each sensor. So let's say at 0ms it takes a temp reading, at 40ms it will take a pressure reading, then at 80ms a new temp reading, and then at 120ms a new pressure reading! So what do you think should i do next?
  15. That's correct but apparently something ELSE is going on in this case. Normally you have the pull up voltage resistor in series with the variable resistance sensor so that you essentially get a voltage divider. But if you seen the measurements I posted above, the voltage measured between the signal line and ground, is very very small (0.0XX V) at all times (aka even when the sensor changes resistance value), essentially showing as short to ground (0V) to the link ecu. Thus something else must being going on. I spoke with my cousin which is an electronic engineer, and assuming innovate tried to keep the cost down, is that they probably used a very cheap microcontroller for the gauge, and then used a single 1 channel precision ADC that is switched between the 2 sensors. However this doesn't still make much sense if the pull-up line is fixed, but let's say they didn't have enough current capability so they switch the pull up line between the 2 sensors? This will explain why the multimeter measures 3.6V pull up voltage, due to averaging. Hopefully I have a portable oscilloscope so I will check if this is the case, because everything is weird in this system.
  16. I have actually tried this way initially and it didn't work. It seems the ADC is pretty limited, thus you have an upper limit in the ohms cal table (about 65000 ohm), but like i mentioned above when the mtx-d is connected to the sensor, if i measure the resistance across it comes out to a very high ohms value outside the range of what i can calibrate (0.8 Mohms in a particular case), similar to if i measure voltage of the signal line (0.037V in the same case). Also i am speculating how the mtx-d measures the sensors, it might have a constant current source from what we do not know. Also 3.6V is a weird pull-up voltage, this thing is not powered by a lithium battery (3.7V which is near to this value), it should have a micro-controller running at either 3.3V or 5V. Are you actually 100% sure of this? Because like i said if you read my tries above it didn't work. Also it doesn't make much sense from a calculation base of view. This is because you are actually measuring the current to determine the ohms value since fixed pull-up voltage; higher pull-up voltage = higher current through the sensor and vise-versa. I know it works on piggyback situations because most sensors are pulled up to 5V from factory either way. This is not the case here however. Maybe someone from Link can shed some light on this!
  17. Yes it is definitely not a grounding issue. I did some more research, and while it is not mentioned specifically in the help file, in order to use any type of resistive sensor connected to an AN Volt channel, you will need to add an external pull-up (partially mentioned) specifically 1K (not exactly mentioned), with the exception of the AN Temp 1+2 channels where you can either use the internal pull up or have an external one of specific values which you can select in PcLink. Please see my diagram below. If you exclude the blue circled section (mtx-d) to the right, then the Link ecu should be able to measure the sensors just fine. If you exclude the left circled blue section (link ecu) then the mtx-d gauge can read the sensors just fine. The problem here is that, when measuring a resistive type sensor you are actually measuring the current flow through the sensor and a fixed internal resistor of known value connected to it in parallel. This allows you to do a simple calculation to calculate the resistance value of the sensor and therefore the value of whatever it is measuring. However since the pull-up voltage expected by the Link ECU is 5V, if you connected the signal wire of the sensor directly to an AN volt channel directly (what I did - aka without the 5V pull up in the diagram and the 1K resistor), there is a lower current flow than what it should be, therefore measuring wrong values. And I can't just connect a 5V pull up there as pictured because if I do, 1) there will be current flow back to the 3.6V pull-up line, and 2) if (1) wasn't an issue or things blow up, the mtx-d gauge would read wrong. So i'm kinda stuck here.
  18. Isn't that the narrowband output? Why waste an analog channel when the wideband output does the same thing, better?
  19. So I tested it and it will not work Technically it can be made to work by connecting an external pull up resistor to 5V when connecting the Link ecu directly to the sensors, but i'm not sure what will be the effect if both 5V and Mtx-D pull-ups are connected to the same signal line. This is due to the voltage difference which would theoretically back feed into the MTX-D unit. I don't know what pull-up resistor they use internally so I'm not sure how risky it will be. Maybe I can measure it. Theoretically I could start using a very high ohms pull-up resistor to limit the current and test it out. But can anyone recommend? Another way to read the values is connecting it via their serial output if Link can implement their SDK, since they use a proprietary protocol.
  20. So i reversed engineered both sensors, temp is an NTC, and pressure sensor is 260ohm-35ohms (0-100psi). Both signal lines have about 3.6V pull up and probably an internal shunt resistor to measure the current and therefore the resistance of the sensor. The temperature one should logically work connected to an analog input channel and not an analog temperature channel since the signal is already pulled up. However shouldn't be normally pulled up to 5V? I'll try with PCLink and see if i can measure it normally. Btw all measurements where done disconnected completely while using precision trim resistors to feed dummy resistance values to the mtx-d gauge to see the readings (aka their calibration).
  21. Hello. I'm trying to integrate the oil pressure and temperature sensors from my Innovate Motorsports dual function gauge to my Link G4+ Xtreme black. I connected the signals to two analog input channels and i haven't had much luck. While i could connect the sensors directly to the Link ECU without any issues the problem is that they are connected to the gauge with makes several issues. I just now started to reverse engineer the oil pressure and here is what i found: While power is off, the oil pressure sensor (resistive type) reads approx, 250ohms at 0 psi, and 20ohms at 100psi. However when i turn the key on, and the mtx-d gauge activates, resistance measured goes to 0.8Mohms, and if i measure voltage it is at 0.037V. When i start the engine at 55psi, ohms is about 200ohm, and voltage 0.006V. Note that the analog input wire is still connected on these measurements but the channels is turned off, so i don't know if it makes a difference. I'll do more reverse engineering now, but any help is really appreciated!
×
×
  • Create New...