Code branch

jartzi · Post by **jartzi** » Fri Apr 10, 2015 9:02 am

Is it possible made code branch at current SW situation? I think Distributor, EDIS and other old stuff is mature enought to been removed in future releases. This "old stuff" branch can be only for bug fixes.

There seems to be very limited memory space in MS2 to made any new.

Post by **jsmcortina** » Fri Apr 10, 2015 10:38 am

Interesting idea, but that's not going to happen.

James

jartzi · Post by **jartzi** » Fri Apr 10, 2015 12:11 pm

Why? Old stuff does not need CAN and other.

subwoofer · Post by **subwoofer** » Fri Apr 10, 2015 1:27 pm

In terms of development, the MS2 is close to end-of-life I think, if I was the developers I would focus the effort where there is room to grow still.

dontz125 · Post by **dontz125** » Fri Apr 10, 2015 2:05 pm

While I agree that the MS2 code is getting cramped, I disagree that it's nearing the end of its development life - there are a number of features I'd like to see to make it easier for bike installs. I would also disagree that a dizzy install doesn't need CAN; a uS running the tranny is an obvious example.

Post by **muythaibxr** » Fri Apr 10, 2015 2:18 pm

We will not be adding anything other than bug fixes.

dontz125 · Post by **dontz125** » Fri Apr 10, 2015 7:12 pm

Power valves (5-wire dumb and/or stepper), safety input pin, long tooth code?

Something I broached with Jean a month or three ago was the possibility of a code mod that would activate a ProgOut pin when staged injection kicked in; this would be integral to the injection code allowing rapid response, rather than the slow and erratic ProgOut subroutine. This would allow full sequential for 4-cyl engines AND allow discrete powering of secondary injectors that would also be controlled by the primary injector drivers (injectors 1P and 1S would be driven by channel 1; injector 1S would only be powered upon 'staging'). I have a circuit ready to test that would bring in the various injectors ONLY if the particular channel wasn't currently squirting. Obviously, Gradual Staging would not be an option, but the advantage of sequential injection at low revs would be a point to ponder.

I realise and appreciate that you fellows are focusing your development efforts on MS3. That said, the MicroSquirt that James has been so earnestly flogging over the past year and more with truly neat applications has always been less than well-suited to motorcycle service, despite the ad copy. These options amongst others would be definite improvements, especially if I can get my uS 4+4 card out of the "vapour-ware" category.

As motorcycle ECUs go, the MS2 is large, clunky, and a rolling invitation to shorts from spray and small animals; the MS3 is even more so, to the point of being awful. The MS3Pro and MS3P-module have interesting possibilities, but the price is just horrific. Barring the various MS3-OEM module concepts that have been bandied about in different threads, the uS (and uSM) will continue to be the primary B&G product contemplated for the mid- to low-budget motorcycle market. Having capabilities needed / desired for less-difficult installations will make for easier sales and happier customers.

(I now return this soap box to its normal duty of propping the garage door open, to allow the exhaust fumes out)

Manu · Post by **Manu** » Sat Apr 11, 2015 12:05 am

It may be time to think about a uMS3 ? A core module with ms3 processor and just basic inputs/outputs ? Not a so evolued module as MS3pro module.

Cheers,

Post by **muythaibxr** » Sun Apr 12, 2015 3:56 pm

The fact remains that as far as the developers are concerned (James and I) it's not getting anything more than bug fixes. We will consider minor features if they greatly enhance functionality, but only after they've gone into ms3 first.

dontz125 · Post by **dontz125** » Sun Apr 12, 2015 4:20 pm

Fair enough, but under "greatly enhance functionality", how about the long tooth code that matt_gsxr came up with? Pulling a number out of my backside, I'd say around half the UJMs and sportbikes from the 80s to mid/late-90s use the 1 Long 3 Short wheel pattern, and a huge majority of singles and twins use a single long tooth, and NONE of them can be fitted with a uS or MS1/2/3 without fairly significant surgery. Some have small, easily swappable trigger wheels; some - like the FZ/FZR family - have the teeth on the alternator rotor / flywheel, which is about 4" OD x 1.5-2"tk, taper + keyway fit onto the crank. Not an easy fix, and certainly not cheap. A simple adaptor circuit is all that's needed to go with the code, but that code patch is needed to really open this market.

600 rotor back.JPG

600 rotor side.JPG

(Declaration of Interest - the FZR family is the core market I'll be focusing on once I get my thumb out. I certainly plan on expanding, but the Yamaha Fizzers is where I plan to start.)

The safety input ("kill") pin is a "nice to have"; the function could be sorted through an interrupting relay, but a code function would be a "REALLY nice to have".

Again with the nice to have; a lot of bikes have a power valve / YPVS / EXUP etc function that isn't really supported. A simple 2-wire dumb motor with a 3-wire pot, it can be approximated by hardware, but (speaking as one whose code-fu is truly weak) I don't think modifying the boost control to read an ADC other than MAP for the position signal would be that hard.

jartzi · Post by **jartzi** » Mon Apr 13, 2015 8:48 am

dontz125 wrote:Fair enough, but under "greatly enhance functionality", how about the long tooth code that matt_gsxr came up with? Pulling a number out of my backside, I'd say around half the UJMs and sportbikes from the 80s to mid/late-90s use the 1 Long 3 Short wheel pattern, and a huge majority of singles and twins use a single long tooth, and NONE of them can be fitted with a uS or MS1/2/3 without fairly significant surgery. Some have small, easily swappable trigger wheels; some - like the FZ/FZR family - have the teeth on the alternator rotor / flywheel, which is about 4" OD x 1.5-2"tk, taper + keyway fit onto the crank. Not an easy fix, and certainly not cheap. A simple adaptor circuit is all that's needed to go with the code, but that code patch is needed to really open this market.

Could there been added circuit which makes pulse to CAM input when longer tooth appears?

dontz125 · Post by **dontz125** » Mon Apr 13, 2015 9:02 am

I tried coming up with something like that, a timer / comparator circuit that compares the charge on a cap vs the previous cap. It was intricate and clumsy, and I'd really rather go with a known-working code patch.

Manu - that's something a lot of people would like to see, but that's a major business decision that would be made by B&G, and no amount of whining to Ken and James is going to affect that.

jartzi · Post by **jartzi** » Mon Apr 13, 2015 9:29 am

How about two halls or vr in line. If both give signel it is long tooth.

jartzi · Post by **jartzi** » Mon Apr 13, 2015 9:33 am

dontz125 wrote:I tried coming up with something like that, a timer / comparator circuit that compares the charge on a cap vs the previous cap. It was intricate and clumsy, and I'd really rather go with a known-working code patch.

About same came to my mind also. Two caps charged through diodes and resistors. One bigger which keeps average voltage and one which voltage rises much higher when longer pulse appears. And comparator to compare charges. Engine cause too much rpm/time variation for this kind of circuit.

dontz125 · Post by **dontz125** » Mon Apr 13, 2015 10:03 am

jartzi wrote:How about two halls or vr in line. If both give signel it is long tooth.

Two VRs wouldn't work, since unreliable triggering is the entire difficulty with a long tooth. Two Hall sensors might work nicely to discriminate between the long and short teeth, *if* you could get suitable devices in there - motorcycle timing covers tend to be pretty darn tight!

Manu · Post by **Manu** » Mon Apr 13, 2015 10:04 am

dontz125 wrote:Manu - that's something a lot of people would like to see, but that's a major business decision that would be made by B&G, and no amount of whining to Ken and James is going to affect that.

I was just kiding Don as I know this is a B&G decision too ;-)

jartzi · Post by **jartzi** » Mon Apr 13, 2015 10:06 am

Quick question so not bother to create new topic.

Is this bug or feature or does i not understand this right:
Seems that Semi Seq injection does not work 1 cyl engine at all.

no_squirts is 1. I cannot change it to 2.
So next is always 0.
Because of that fuel1_events[next].inj == next_fuel1_event.in and fuel1_events[next].tooth == tooth_this allways match.
So sched_now is 0
And because of that squirt never happends.

schedule_fuel function in ms2_extra_inj.c:

if (seq_inj_ctrl & SEQ_MASK_INJ1) {
// Set next event
if ((flash8.seq_inj & 0x03) == 1) {
if (next_fuel1_event.inj == no_squirts - 1) {
next = 0;
} else {
next = next_fuel1_event.inj + 1;
}
} else {
if (next_fuel1_event.inj == (no_triggers>>1) - 1) {
next = 0;
} else {
next = next_fuel1_event.inj + 1;
}
}

// Check if the next event is due this tooth; if so, it is for the next cycle
if ((fuel1_events[next].inj == next_fuel1_event.inj) && (fuel1_events[next].tooth == tooth_this)) {
// This the next cycle event
sched_now = 0;
} else {
// This is for this cycle
sched_now = 1;
}

Megasquirt Support Forum (MSEXTRA)

Code branch

Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch

Re: Code branch