Adamw

The bottom one is the only one showing correct polarity. So for it to work you will need to find why the cam sensor disappears. It suggests to me that the cam sensor is only getting a ground through the crank sensor wiring somehow, so you either have some wires crossed or the pinouts of one of the sensors is wrong.

If you want help with anything you need to attach your tune and a log.

Unfortunately no - at least it is not functionality we had planned for the near future.

If the coils are wired wasted spark then yes you could run it with no sync to get a capture. Otherwise you can run the engine fully sequential as I mentioned earlier using the cam window sync mode. This will at least give you the home position scope, it may freak out when the cam is moved but Im not sure.

Need a scope capture at crank speed and one at fast idle as many of the mazda sensors flip polarity around idle speed so if it does flip we need to know which edge doesnt move in relation to TDC/spark. If you cant do one with cam fully home and another fully advanced, then just a capture at home and a mechanical measurement of how far the cam can advance will be sufficient.

Ok, sorry I cant help with a Mac, I have never touched one so dont have any experience to offer. G4+ used an old silicon labs VCP where as G4X uses a FTDI chip that does both VCP and a direct native USB, so the fact G4+ worked with a similar setup is not really relevant. I have however seen some other users claim that G4X can work with a mac but I have no idea what emulator system they are using. You may have to experiment with various different VM systems before you find one that works. The error you have suggests the VM is not passing the USB commands through to the real ports correctly. Edit: Yesterday on the facebook group "Link ECU Tuning and Tips" there is some discussion about this subject. Some claim it works, others claim it only works on older macs and not the latest. Parallels and VMware fusion are the two options that are mentioned.

This is an error that I havent come across before. Are you using the latest PC Link V6.19.65? Is it windows 10? Do you have an entry in both the com port section and the Universal serial bus section like my pic below? Which one is showing the error?

Unfortunately the VVT is still not controlling well. You are going to have to go back to custom PID and experiment a little to see if you can improve it - otherwise leave it for the tuner. Generally I would set up a time plot like below with cam position and target plotted on top of each other, they should generally follow each other reasonably well. You can see in this pic below exhaust is not too bad, but inlet is bouncing around +/-5deg when its trying to target 20deg. This is probably too much proportional. Your DBW calibration still doesnt look right. Are you using the TPS calibration in the E-throttle section where it moves the throttle automatically?

No, there will only be a fault reported if there s a bus problem. This would be things like incorrect bit rate, wiring, or wrong ID. There is no way the ECU can know if the steering system is happy with the data format or not. I suspect it will likely just not work.

I think the answer to the first one is it was probably designed to only allow a valid number to be entered, and a decimal point (or a comma for some europeans) is generally not considered a valid way to start number, it would usually have a zero in front of it. I have seen some discussion which says if the range of numbers never exceeds 1 then the leading zero can be left off, but it is not common - at least in my world. It might be an American thing to leave the leading zero off and not something I had ever considered people would try. I will ask Vaughan if it can be made to work without the zero when he is back from holiday. The table axis setup one I cant quite understand what you mean, I will attach a video at the bottom to show how I use it and how it works for me and maybe you can elaborate after seeing that. As far as I have noticed it is similar or the same as how it worked in G4+. The search has definitely slowed down a bit since G4+ as the way the sorting works in the background had to be sacrificed since it was bogging down slow laptops too much with all the extra parameters that G4X has. As for the AFR target tables: Most basic core functionality that every/most users will need has a hardcoded table that is always there and always being processed in the background but any "extra" functionality that only select users will need will be allocated one of the "GP tables" only when/if they turn the function on. This way you dont have the micro working hard all the time processing hundreds of tables that no one is using. Recent firmware gives all users 45 of these GP tables (FYI, You can see how many GP tables you are using by clicking the Table Allocation wrench down the bottom of the ecu settings tree). AFR target 1 is a core hardcoded table and AFR target 2 is allocated to a GP slot when you turn on multifuel. So that is some background of why they are different - but I dont actually know why they originally choose a different size for AFR target 1 - I suspect it may be for legacy reasons so that G4+ maps can be imported easier or something - or it could just be they didnt think that resolution was needed for AFR target. But I will again ask Vaughan about that when I can. Video: https://1drv.ms/v/s!AiYbYlZQuRHPvS6HtlMCowX3PXbj?e=MrYxLN

Hi Brad, Thanks, I had already reported this as a bug a couple of months ago but in my testing I had only noticed it on some of the less commonly used tables and I stated the fuel and ign were working correctly so it possibly didnt get the attention it deserved. I see it is planned to be fixed for the next release. I will update the task so that we look at fuel and ign as well. I just gave it a quick try but cant reproduce the problem with the ignition table. Sometimes I see a very small amount of movement but cant get it to do anything too weird. If you find any steps that make it obvious please let me know. But Im hopeful the more obvious problem tables will give them the clues they need anyhow.

Since none of the messages on the opengarages page use "Byte 0", Im assuming they are naming the first byte "Byte 1", whereas we call it byte 0. They say engine speed is in Byte 1/2, but the CANdo example has data in byte 1,2, 4, 7 & 8, so there maybe something else beside engine speed that is needed. They also do not say which is the high byte, and what bit rate is used, so you'll have to make a few assumptions. I would start with a bit rate of 500K. Set up like this and see if anything happens:

Yeah, looking closer. Control on the intake cam is a bit erratic. I notice you have PID setup set to custom, did you try it on the defaults? It looks like you need to do a TPS calibration as your TPsub shows 97% when your TP main shows 4%. And if you set your E-throttle target and idle base pos and idle ign tables to something like below it will probably improve your idle alot.

Are we talking for an auto trans? How does the ECU receive the signal? Is the signal just on/off or some sort of message that contains info on how much the torque needs to be reduced by? Is the signal active for the whole time the TR is required, or is there some timer and ramp functionality required after the signal? Is it turbo or NA? How much does torque need to be reduced by (maximum percentage)? What ecu do you have?

It is a long way off, only in early development. It will be a year or more at least.

Reading through the notes of the recent changes to temp input capabilities it does look like the intent was to allow the temp inputs to be used in this way, but I think pressures may have been overlooked. I will get this on the list to have another look at. In the mean time the work around would be to do it via a GP input and math block like below. I know, a bit of a ball ache...

That doesnt sound right. Might pay to return it to be tested. Have you tried both extension cables and both knock sensors to rule those out as the culprit? On mine the noise level it is pretty uncomfortable on full volume. And to confirm - this is a Knockblock right? Not a Knock Link.

Yes the storm blue has internal knock control. The knock input pin is shared with the DI3 pin so the only limitation is you can only have one or the other.

Change trigger 2 edge to falling and change DI 2 to rising. Otherwise should be good.

As requested earlier, can you please do a log of it cranking. How to do a log: https://www.youtube.com/watch?v=_P1LRANeO4A

What do you mean by "manipulate the trigger angle"? What doesnt work in sequential mode with a cam sensor?

Here you go. MXS Strada - Eryin HKS CT230R FURY + EGT.zconfig

No, it is not necesary to use the pin 1 ground in the round comms connector, this is only used for a common ground for RS 232 devices.

Use either of the Stoich closed loop modes, they were designed for cat/emmisions use and have a 0.02 lambda dither built-in to the control logic (ie the lambda with dither +/-0.02 La either side of the set point)

Try these. MXS Strada - Eryin HKS CT230R FURY + EGT.zconfig chemical_fury_021220 CAN update.pclr