KarlB

I did not test it with an empty stream. I did all my tests with user streams that had frames assigned.

I've recently encountered some odd behavior while running a Thunder on the bench. When setting one of the six available CAN streams for CAN2 to transmit a user stream at 1Hz, the ECU basically vomits those frames at at insane rate and immediately fills the buffer of my PCAN dongle. If I turn off that stream and turn it back on at 1Hz, the problem persists. The behavior seems unchanged if I alter which user stream to transmit or which ID setting I have for that stream. If I set the transmit rate to some value other than 1Hz, the problem resolves itself. At this point I can set the stream back to 1Hz and it behaves as expected. The problem does not re-appear across firmware reflashes. So it seems that the very first time you initialize a stream, if you have it set to 1Hz, it will flood the bus with packets. I'm using PCLink version 5.6.7.3632. Below is my firmware information: ECU firmware version : 5.6.7.3631 Bootcode Version : 1.9 Board S/N : 40499 ECU type : 39 The config I have attached has had Streams 1, 2, 3, 4, and 5 for CAN2 set to rates other than 1Hz, so they seem to operate fine. Stream 6 has not been touched. Thunder CAN2 Issue.pclr

Bumping this to provide an update. The car is back together now (after some cylinder head woes). We removed four of the six throttle return springs and re set all the throttle plates. It idles nicely with fully closed throttles at 850RPM with 15 degrees of timing. The e-throttle response is much better. It's still not great, but seems to be acceptable. I did some testing with retarded ignition timing before pulling the springs and I wasn't happy with the resultant exhaust gas temperature. The idle base DC table is set to 3D and uses AP(main) as the secondary axis. This allows tip-in to be smoothed out by feeding in air via the idle motor at low pedal angles.

I have a set of S54 throttle bodies driven by a modified S85 actuator. The motor requires ~70% DC before there is any actual motion in the system. The system oscillates wildly without a very low P-value, which instead leads to integral windup and large overshoots. The lack of a feedforward table means I'm basically dead-ended without making hardware modifications. I'm in the process of removing some of the return springs (which I'm reluctant to do in the first place). I'm also not convinced this will solve the problem, so I'm trying to explore all my options.

I'd like to get more torque out of my e-throttle motor by installing a 24V boost converter on the "+14V Aux 9/10" pin. I know the MC33886 H-bridge driver in my G4+ Xtreme is rated to 40V on the input. Is this supply rail isolated internally or is it tied to some other protection circuitry that would be unhappy at elevated voltages? For example: the Aux 9/10 rail might be diode isolated to the main rail for load dump protection. Are there filter caps on this rail? If yes, are they rated to that higher voltage? What is the "+14V Aux 9/10" voltage sense circuit scaled to? Will I rail the ADC if I put 24V on that net? If so, is the ADC input externally overvoltage protected or are you relying on diodes internal to the micro to provide that protection? I'm trying to understand if there are any technical reasons why this won't work. I understand that there are thermal limits in both the driver and the motor windings that may preclude this from being an effective solution.

I have an application where I wired a G4+ Extreme to an I-6 using direct spark coils, and a cam sync on Trig 2. My preference was to do the initial start and run-in using wasted spark and re-configure to sequential at a later date. When the engine only ran on three cylinders, I realized that pairwise cylinders must be wired together. What I'm asking for is the ability to pair ignition outputs in software rather than having to physically wire them that way. I have done this in the past using ECUs from other vendors and it's very convenient.