For anything you'd like to see added to Speeduino
User avatar
By cx500tc
#8568
So, your permutations are basically (number of solenoids) ^ 2. 1 solenoid = 2 possible; 2 solenoids = 4 possible; 5 solenoids = 32.

I'd argue that for most situations, some solenoid permutations are mutually exclusive, i.e. you wouldn't engage both 1st gear and 3rd gear solenoids at the same time, nor would you actuate reverse and any other solenoid simultaneously, and again you would lock up the torque converter in any gear other than the highest forward gear. So, essentially, you would have only two solenoids powered simultaneously, basically when up or downshifting or when in top gear with overdrive, no?

Such conflicting conditions, if they're not disallowed early in the firmware operation, must be denied before any solenoid state is changed. In a similar vein, even if the user tries to force a gear change, the unit should deny any change that results in either engine over or under speed conditions.
PSIG wrote:I'm thinking the digital inputs should be whatever is most foolproof, so perhaps opto. Those inputs have been called-out by others. As planning placeholders, I would designate PWM outputs for TCC (lockup) and EPS (pressure), and digital outs for Reverse, Reverse Lights, and Start-Safety switch (neutral/park or NSS). Even with one more hi-amp digital for "other", that leaves four to operate shift solenoids, which (in most designs) translates to permutations of 16 gears as I calculated below, and does not even consider using the low-outs instead. :D My 4-speed OD trans with lockup uses four solenoids for everything (one pressure, one TCC, and two shift), plus one optional for reverse lights. Default is 2nd gear and max line pressure for limp-home with no solenoid inputs (disconnected controller {0,0}) for example.

Number of shift solenoids permutated to number of possible transmission gears:

Solenoids: 1
Permutations: 2
{0} {1}

Solenoids: 2
Permutations: 4
{0,0} {0,1} {1,0} {1,1}

Solenoids: 3
Permutations: 8
{0,0,0} {0,0,1} {0,1,0} {0,1,1} {1,0,0} {1,0,1} {1,1,0} {1,1,1}

Solenoids: 4
Permutations: 16
{0,0,0,0} {0,0,0,1} {0,0,1,0} {0,0,1,1} {0,1,0,0} {0,1,0,1} {0,1,1,0} {0,1,1,1} {1,0,0,0} {1,0,0,1} {1,0,1,0} {1,0,1,1} {1,1,0,0} {1,1,0,1} {1,1,1,0} {1,1,1,1}

Solenoids: 5
Permutations: 32
{0,0,0,0,0} {0,0,0,0,1} {0,0,0,1,0} {0,0,0,1,1} {0,0,1,0,0} {0,0,1,0,1} {0,0,1,1,0} {0,0,1,1,1} {0,1,0,0,0} {0,1,0,0,1} {0,1,0,1,0} {0,1,0,1,1} {0,1,1,0,0} {0,1,1,0,1} {0,1,1,1,0} {0,1,1,1,1} {1,0,0,0,0} {1,0,0,0,1} {1,0,0,1,0} {1,0,0,1,1} {1,0,1,0,0} {1,0,1,0,1} {1,0,1,1,0} {1,0,1,1,1} {1,1,0,0,0} {1,1,0,0,1} {1,1,0,1,0} {1,1,0,1,1} {1,1,1,0,0} {1,1,1,0,1} {1,1,1,1,0} {1,1,1,1,1}

Low-out placeholders (if all outs are either hi or low amp) could be speedometer (dig and analog), pressure, temp, etc.

David
User avatar
By cx500tc
#8569
I'd suggest treating most inputs in a way that permits them to be either analog or digital:
input_op-amp.png
input_op-amp.png (4.23 KiB) Viewed 8059 times
The op-amp would be powered from the vehicle's 12V system and therefore, itself, mostly immune to any over-voltage condition. Being configured as a voltage divider due to R1|R2, it would also divide down voltages to make them compatible with an Arduino. D1|D2 serve to clamp the op-amp output to the 0/5V rails, and since they are on the output / buffered side of the op-amp, there is little likelihood any input voltage excursion that would cause the output to exceed 5V will deliver enough current to pull the 5V rail out of tolerances, as in a pure +12V from the battery positive applied to the input should be easily clamped by this with little negative affects.

Other, specifically "digital" inputs, I'd suggest going through an opto-isolator, but a somewhat simple transistor as a buffer of sorts could be used too.


On the output side, don't forget you're talking about controlling, mostly, solenoids, so they have a back-EMF component to consider.
User avatar
By PSIG
#8574
cx500tc wrote:So, your permutations are basically (number of solenoids) ^ 2. 1 solenoid = 2 possible; 2 solenoids = 4 possible; 5 solenoids = 32.
If it were that simple, 5² would be 25 permutations. ;)
cx500tc wrote:I'd argue that for most situations, some solenoid permutations are mutually exclusive, i.e. you wouldn't engage both 1st gear and 3rd gear solenoids at the same time, nor would you actuate reverse and any other solenoid simultaneously, and again you would lock up the torque converter in any gear other than the highest forward gear. So, essentially, you would have only two solenoids powered simultaneously, basically when up or downshifting or when in top gear with overdrive, no?
No. Transmission designs that require a separate shift solenoid for every gear (one for 1st, one for 3rd, etc.) are relatively uncommon. For most designs 3 shift solenoids generally serve for up to 8 speeds. In those, the solenoids serve multiple gears using unique permutations, such as the example I gave. The solenoid activation of my example is exactly the permutations listed for 4 gears with 2 solenoids, though not in that order. 2 or 3 analog solenoids are separate from this and optional for pressures and lockup.

Still, the only reason to even consider more than three shift solenoids is that a few designs do, or also need one for reverse, and I assume we are configuring to capture the greatest number of possible designs. Every permutation is unique, and would only be used once and exclusive of any other permutation at any given time, similar to dwelling one COP coil at a time. You could however modify the timing of those transitions to overlap, again much like overlapping dwell, in order to achieve correct operation. Not a big deal, but dependent on the user's responsibility to input the correct permutation for the correct gear, of course. That's up to the user.
cx500tc wrote:Such conflicting conditions, if they're not disallowed early in the firmware operation, must be denied before any solenoid state is changed. In a similar vein, even if the user tries to force a gear change, the unit should deny any change that results in either engine over or under speed conditions.
There are no conflicting conditions unless the user programs it that way. You can't disallow what you don't know. Nobody else knows what your setup needs for activations, or when, or why. Hopefully, you do. ;) No different than what trigger wheel setting you should use for your engine, or what rpm limit you feel is appropriate or required. So, you put that info into the unit for your use, however you use it. This is no different than Speeduino on an engine or transmissions for racing or of yesterday, where in mine I can shift from high gear to 1st at 120 mph if I want to, or am not careful. :shock: And, yes, I do engage 1st and Reverse simultaneously (depending on the trans) when using it as a trans-brake for launch control. DIY at its finest. Some day an option to 'block' certain operations could be useful (valet or anti-theft or teenager mode?), but that's way down the list I would think. Simple gets it.
Image
David
User avatar
By cx500tc
#8593
PSIG wrote:
cx500tc wrote:So, your permutations are basically (number of solenoids) ^ 2. 1 solenoid = 2 possible; 2 solenoids = 4 possible; 5 solenoids = 32.
If it were that simple, 5² would be 25 permutations. ;)
You are correct.
I mis-typed. I meant 2 ^ (number of solenoids).

I find the rest of your reply very informative and will defer to you. ;)
User avatar
By PSIG
#8598
Correct. Sorry, I should have spotted what you meant. Yes, it is a "repetitive permutation" of possible states^number of solenoids, where digital states are ON/OFF or 0/1 (2) and number of solenoids is 5 for 32 possible combinations. Bingo. The fun part is plotting all the unique combinations...
Image
David
By dazq
#8677
Ok i have added 8 chan of opto inputs, circuit is as we designed in the trigger conditioning thread.
I also added a uln 2803 for 8 chan low outputs too.
Other addtions laid out are a spi 2515 can interface,and two spi headers with cs, suitabe for spi type thermocouple boards?

I was thinking of adding sockets for two sets of vr modules(the 8 pin like on speedy)or should i have 8 sets of skts each with a single trigger in, having two feeding to the interupts like the vr hall skts do and the other 6 plain inputs to populate with opto boards if rqd?
For now i have put screw terminals for connection same as v03* but they could be changed later.
User avatar
By PSIG
#8683
I think some of those answers will be based on what inputs would be used for non-EFI, non-CAN EFI, and CAN EFI. The last one should be all CAN engine info, a few generic (mostly digital) inputs, and possibly analogs for shift select, pressure, and TTS (trans temp), so no biggie. The first would need mostly the same, plus all relevant engine info inputs. However, the second is a question for the scheme to pull engine info from the controller without CAN and preferably without sharing signals from sensors. Suggested schemes?

David
User avatar
By cx500tc
#8684
PSIG wrote:...
...the second is a question for the scheme to pull engine info from the controller without CAN and preferably without sharing signals from sensors. Suggested schemes?

David
The op amp circuit I presented earlier wouldn't present any significant issues regarding sharing sensors between this and the ECU since the op amps are high input impedance devices.

Where one might run into issues is if the existing circuit uses a bias voltage on the sensor, as do some GM speed sensors and the like. However, this just means the bias voltage has to be either be removed somehow by the hardware or accounted for in the firmware, the latter of which may be a problem if the signal level exceeds the clamping voltage on the Zener diodes. IIRC, some of those sensors were 3v3 output signals shifted up with a 1V2 bias... nothing we couldn't work out, though, regardless.


Just a thought.... ;)
By dazq
#8697
I was thinking that if the controller has connection to the speeduino serial stream that deals with engine parameters.
Any extra sensors connected to the controller can be broadcast and/or assigned to a canid address for use by any third party display connected to onboard module
User avatar
By PSIG
#8716
OK, as in share/observe the serial to/from TS and the Speeduino/MS/XYZ-brand ECM to the trans controller, and direct query when TS is not connected to the ECM? Speedy should be fairly easy to do that with, or even as a second dedicated serial. Looking at universal integration as much as possible though. I'd like to hook this up to a running MS/Emerald/Holley or OEM GM/Ford/? setup around here as well, and could do it standalone like a non-EFI setup, but would like to grab info for the Tx controller easier if possible. Lots of opportunity to configure the non-CAN ECM situations for slick setup. Maybe.

David

I uploaded logs and last tune and dyno plots look[…]

you could set 'skip revolutions' to 3, then it wou[…]

Hi, I am trying to assign Signed values to the x-a[…]

blitzbox

I've finally figured out why MAP and Lambda weren'[…]

Still can't find what you're looking for?