Unwanted output signal jitter

[skimask]

[QUOTE=LinkMTech;48591]A couple of thoughts...

CLRW                    ' Clear all registers<<<-----CLRW works with PBP?

ADCON1 = %00000000      '<<<---What's the default 'JUSTIFY' on a 16F737?

DEFINE ADC_BITS     5                     <<<<---Why not use all 8 bits?
-------and the manual says only 8,10,12...  I don't see 5 as a legal value

Low_Adj var byte ' Input declared as byte size <<<-- You might want WORD here
Low_set var word ' Input declared as byte size    <<<<- it is? :)

Low_set = (abs(low_adj-128))*8      <<<<---these lines look a bit scary to me

That last one...
If you get a value above 32, when multiplied by 8 will overflow a byte variable. Low_set is a word, but low_adj isn't. I seem to have bad luck when mixing variable sizes like that. But that's just me...
I think the ADC_BITS might be your killer. Keep it at 8 bits, AND out the low 3 bits, and shift it down by 3 bits.

EDIT: Notice I changed OR to AND. My mistake..duhhhh...

[LinkMTech]

Thanks for the info Skimask.
Yeah, some of my comments are left overs from the different attempts to feel my way through when thinking got too hard. Now I've got something else to study "Default Justify".
I implemented all your suggestions except that one until I know what I'm doing.

Thanks again,
You guys rock!

[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!