Unwanted output signal jitter

[b1arrk5]

This is just a guess, but the adc has to charge it's capacitor for each read, I'm wondering if you're doing the ADCIN commands too fast to allow it to fully charge between readings. You are using the R/C timer in the ADC, and the sampling time is set to 20us. I usually set it for 50us, and use a little delay between successive readings.

Good Luck!

Jerry.

[LinkMTech]

I've been doing some more digging using Darrel Taylor's upgrade to the search engine: http://www.picbasic.co.uk/forum/showthread.php?t=4751
and found a nice description of another way to use A/D instead of ADCIN from Melanie that I am also going to try: http://www.picbasic.co.uk/forum/arch...php/t-352.html

I remember increasing the sample time to 100us before and maybe even more but it didn't make a difference. I'm sure if it's not configured right in the first place it wouldn't even matter! Man, am I glad that these devices are made to handle the all the flashing I can muster up.
One thing that's really bugging me, for lack of understanding, is that I have to keep the pot variable "Low_set" in the FOR/NEXT loop or else it won't give me the adjustable output. I thought that declaring Low_set = (ABS(low_adj-128))*8 once before going into the loop would be enough and that occasionally opening the door to let the flies in with ADCIN to update the variable "Low_set" would do the trick. BUT NOOO!!! I got the one read and it stayed fixed at that setting no matter how many flies I let in.

Low_Add_pulse:
    IF low_adj<=127 THEN GOTO Low_Trim_pulse ' Check pot position and go
    FOR x = 1 to 10                          ' Count to 10
       FOR i = 1 to 100                      ' Count to 100
            IF Sig1=1 then                   ' Input OFF then:
            PAUSEUS low_set                  ' Adjustable delay using pot
            LOW Inj1                         ' Turn OFF output
            ENDIF
            IF Sig1=0 THEN HIGH Inj1         ' Output ON if input ON
      NEXT i
            ADCIN 1, low_adj                 ' Check pot after a 100 loops
                                             ' for smooth adjustment
      NEXT x
      Low_set = (ABS(low_adj-128))*8         ' Declare every 1000 loops or
                                             ' adjustment not possible
            
GOTO Low_Add_pulse                           ' Do it again

I gotta believe that it's possible to do what I'm trying to do. The tired part of me says "just show me how to do it!" but the bigger part thanks you guys for the clues and direction so I can learn to be a confident PBP programming dude.

Thanks

[skimask]

Maybe I'm missing the point here...
What are you trying to accomplish?
You have a pulse from 'Something A' going to 'Something B', and you want to build a programmable delay, not to change the pulse width, but to delay the pulse itself by X time? Like a time shift or something?
What's this for? Ignition timing or injector timing?

[LinkMTech]

Hi skimask,
I'm putting this circuit between the motorcycle's ECU and fuel injectors. You may already know how they work but just for clarification; the ECU will pull the injector low for about 2.5ms and it's pulse width will vary about 8%. I want to to able to expand that to about +/- 20% within three RPM ranges along with some other fancy hoop jumping.
The -20% control will delay the ON time of the output signal to the injector but supposed to keep the OFF time unchanged for reduced pulse width.
The +20% control should keep the ON time intact but delays the OFF time of the output signal for increased pulse width.
I tried PULSIN, that will never do. Especially at 14K RPM where I will have to deal with input signal overlapping!
I tried PULSOUT, looked promising, if I was helping an old lady across the street, but that got nasty looking with all the looping and checking I had going.
So dealing with the signal as it happens seems to be the right direction if only for the jitter at the opposite end!

[skimask]

the ECU will pull the injector low for about 2.5ms and it's pulse width will vary about 8%

On all of the fuel injectors I've ever put a 'scope on, the pulse varies a heck of a lot more than 8%. I'd even venture to say that any injector's pulse width would vary 8% at a steady state just to keep the closed loop program in the ECM happy. It's possible this bike has something else going on that keeps the fuel injector pulse practically steady, but I tell ya, that's something I haven't heard of lately.

The -20% control will delay the ON time of the output signal to the injector but supposed to keep the OFF time unchanged for reduced pulse width.
The +20% control should keep the ON time intact but delays the OFF time of the output signal for increased pulse width.

If it was me, I don't think I'd delay the start of the pulse. If you delay the pulse width at the start, the fuel might not be there in time for the intake valve to open. Remember, it takes X amount of time for an injector to open and start spraying that nice cone shape properly, whereas the closing an injector is much more of a solid event, at least that's what I've seen from the high speed video from one of my relatives at GM (neat video too, can see practically every tiny little droplet of atomized fuel in the spray pattern). I think I would shorten up the tail end of the pulse. If anything, at least the fuel will be sitting there on the intake valve or at least in the intake stream, ready to be sucked in, even if it is pooled up on the intake valve, which in any halfway decently designed intake system, will get swirled up and re-atomized by the swirl and heat of the valve.

But, be all that as it may be, it's nearly impossible to determine what the ECM will determine should be the NEXT pulse width. If it was me, I think I'd try a system that would LAG by one pulse event. Keep tabs on the previous pulse, modify that pulse width, shoot that pulse width on the next event, while at the same time, using a timer, measuring the current pulse width, while again, using a timer, to keep track of the current pulse width and stop it as required.
But then again, as fast as today's ECMs operate, it may (and probably will) still flag a failure and go to open loop, because you're messing with the pulse width, thereby the air/fuel ratio, which the ECM will eventually see in the O2 sensor. Unless, you plan on running open loop continuously...which in that case...never mind...Go for it! Just remember that a stoich A/F ratio of 14.7:1 with 20% of the fuel removed is an A/F ratio of about 17.6:1...lean enough to make donuts out of piston heads and make sticks out of exhaust valves and instantly put ports in your otherwise smooth cylinder walls!

[LinkMTech]

But, be all that as it may be, it's nearly impossible to determine what the ECM will determine should be the NEXT pulse width. If it was me, I think I'd try a system that would LAG by one pulse event. Keep tabs on the previous pulse, modify that pulse width, shoot that pulse width on the next event, while at the same time, using a timer, measuring the current pulse width, while again, using a timer, to keep track of the current pulse width and stop it as required.

That was my initial thought too! But since I'm just coming out of the starting gate, I didn't know how that would be possible without a crystal ball. Thanks to some info I found on slick ways of using timers by DT, you're right, I think I will drop the notion of delaying the start of the pulse and keep tabs of the previous pulse to work off that.
This circuit will not be used blindly but in a monitored state on a dyno and is only the basis of the system. I know there are products out there for this but then there are also more than one type of shoes too.
Thanks for the confirmation!

[skimask]

This circuit will not be used blindly but in a monitored state on a dyno and is only the basis of the system.

I guess my big question is...why do you want to mess with the pulse width anyways?
Are you adding on some crazy turbo, tuned pipe type things or what?
I mean, closed loop is closed loop is closed loop. It's efficient, clean, keeps parts where they're supposed to be, etc.etc.etc. (and again I don't what kind of system you're dealing with).
Now...WOT is another story... Are you looking to basically 'bypass the rom' in the ECM and feed more fuel under WOT/open-loop conditions?