734 replies to this topic

[mjr]

My cab has been at VP9.9.0.  I have just finished connecting my LVDT based plunger which puts out a 0-3.3V signal to the Freescale board and have been trying it out in 9.9.0.  There is still a small amount of noise on the plunger.  Checking this with the oscilloscope shows the LVDT puts out a steady signal until plugged into the Freescale input.  Once plugged in (even after connecting the Freescale's I/O GND pin to GND, there is still a small amount of noise.

I'll try throwing a cap on between the 3.3V I/O pin and the GND I/O pin.  I am only using the Freescale board to read the plunger and for the accelerometer's nudge.  I am NOT using any LEDWiz function nor joystick button inputs.

 

I don't know much about LVDTs, so I'm only guessing, but given that you only get the noise when it's connected to the KL25Z, the noise is probably coming from the KL25Z.  Could be the on-board clock signal or USB - there are lots of high-frequency signals running around on that board.  Filtering with a cap seems like the right solution.  You should probably try a small cap (100 nf or 1 uF, maybe) first and see if it makes any difference, and try something bigger if that doesn't make any difference or doesn't make a big enough difference.  You have a scope so you should be able to see incremental effects.  The tradeoff with a cap is that it should smooth out noise but also increase the charging time for the real signal, since the voltage level you're reading from the device will be tied to the voltage level on the cap.  Another thing to experiment with is putting the cap physically close (in terms of wire run distance) to the KL25Z vs putting it on the sensor side of the wiring.  The wires have non-zero resistance, which interacts with the capacitance to affect the charge/discharge time, so placement does make some difference.

 

Have you done any Web research on LVDTs and ADCs in general?  The whole arrangement seems tricky to me at an EE level, although my EE knowledge is very basic.  I'm wondering if the inductive element has some interaction with the capacitive element in the ADC, and there's some fine tuning you have to do to get the coupling right.  I notice that there's such a thing as an LVDT signal conditioning chip (e.g., http://www.ti.com/li...946/spra946.pdf).

 

Your 9.9.1 problem is *probably* a direct result of the noise you're seeing.  If you can fix that the 9.9.1 problem will probably vanish.  I'm guessing that it's an interaction between the launch motion detection in 9.9.1 and the high-frequency jitter - the jitter is probably tricking the 9.9.1 plunger code into thinking you're pulling back and releasing rapidly.  

 

If you can't get rid of the noise at the electrical level, it might be possible to characterize the noise and do some filtering in the firmware on the KL25Z.  But that sort of solution always creates compromises, so definitely don't give up too easily on solving it on the hardware side.

 

Nudge gain setting: in 9.9, about 1000 seems about right for most people.  In Physmod and VP 10, I think it's more like 10.

Edited by mjr, 29 May 2015 - 05:15 PM.

[Spektre]

 

My cab has been at VP9.9.0.  I have just finished connecting my LVDT based plunger which puts out a 0-3.3V signal to the Freescale board and have been trying it out in 9.9.0.  There is still a small amount of noise on the plunger.  Checking this with the oscilloscope shows the LVDT puts out a steady signal until plugged into the Freescale input.  Once plugged in (even after connecting the Freescale's I/O GND pin to GND, there is still a small amount of noise.

I'll try throwing a cap on between the 3.3V I/O pin and the GND I/O pin.  I am only using the Freescale board to read the plunger and for the accelerometer's nudge.  I am NOT using any LEDWiz function nor joystick button inputs.

 

I don't know much about LVDTs, so I'm only guessing, but given that you only get the noise when it's connected to the KL25Z, the noise is probably coming from the KL25Z.  Could be the on-board clock signal or USB - there are lots of high-frequency signals running around on that board.  Filtering with a cap seems like the right solution.  You should probably try a small cap (100 nf or 1 uF, maybe) first and see if it makes any difference, and try something bigger if that doesn't make any difference or doesn't make a big enough difference.  You have a scope so you should be able to see incremental effects.  The tradeoff with a cap is that it should smooth out noise but also increase the charging time for the real signal, since the voltage level you're reading from the device will be tied to the voltage level on the cap.  Another thing to experiment with is putting the cap physically close (in terms of wire run distance) to the KL25Z vs putting it on the sensor side of the wiring.  The wires have non-zero resistance, which interacts with the capacitance to affect the charge/discharge time, so placement does make some difference.

 

Have you done any Web research on LVDTs and ADCs in general?  The whole arrangement seems tricky to me at an EE level, although my EE knowledge is very basic.  I'm wondering if the inductive element has some interaction with the capacitive element in the ADC, and there's some fine tuning you have to do to get the coupling right.  I notice that there's such a thing as an LVDT signal conditioning chip (e.g., http://www.ti.com/li...946/spra946.pdf).

 

Your 9.9.1 problem is *probably* a direct result of the noise you're seeing.  If you can fix that the 9.9.1 problem will probably vanish.  I'm guessing that it's an interaction between the launch motion detection in 9.9.1 and the high-frequency jitter - the jitter is probably tricking the 9.9.1 plunger code into thinking you're pulling back and releasing rapidly.  

 

If you can't get rid of the noise at the electrical level, it might be possible to characterize the noise and do some filtering in the firmware on the KL25Z.  But that sort of solution always creates compromises, so definitely don't give up too easily on solving it on the hardware side.

 

Nudge gain setting: in 9.9, about 1000 seems about right for most people.  In Physmod and VP 10, I think it's more like 10.

 

I'll certainly look to fixing the noise problem, however I am curious how much of a hair trigger this launch id based on.

 

ANY A/D reading is going to have a small about of variance and that certainly seems to be the case here.  I'd expect even the photosensor to bounce a pixel value or two.

 

I'll see if the cap helps at all, but I'm doubtful that this input can be made completely noise free.

 

(As an aside, for this LVDT installation loading effects should be minimal as the output is buffered.  The IC you see termed "LVDT signal conditioning" performs the following function:

 

1.  The LVDT requires a sinusoidal excitation signal in order to couple the primary coil and the secondary coils.  The signal conditioning chip generates this.

2.  The output of the 2 secondary coils are then sent to a differential amp.  (the amplitude of which is proportional to the position of the core.)

3.  Since the output of the differential amp is a sinusoid, a filtering circuit is made to turn this into a (fairly) DC signal that is proportional to the core position.

 

My LVDT incorporates this circuit such that I need only supply it DC power and get a DC output which is proportional to the core position.  Since my LVDT is made to put out 0-5V I have a non-inverting amp to set the gain and output a 0-3.3V signal.  As I mentioned, this output is rock solid (and double buffered at that point).  However it does pick up a small amount of noise when plugged into the KL25 board.)

[Spektre]

Well the noise is not on the power line.  It looked steady but I placed a 10uF cap across the 5V pin anyway.  No effect.  Is this behavior because of the code you mentioned to estimate a plunger moving too quickly to sample?

 

Come to think of it, the 3.3V line is after an LDO regulator.  The A/D reference voltage should be steadied by that anyway...

Edited by Spektre, 29 May 2015 - 06:31 PM.

[mjr]

I'll certainly look to fixing the noise problem, however I am curious how much of a hair trigger this launch id based on.

ANY A/D reading is going to have a small about of variance and that certainly seems to be the case here.  I'd expect even the photosensor to bounce a pixel value or two.

 

It's not even remotely a hair trigger, actually.  The trigger is two sequential USB readings that register over about an inch apart in the forward direction, which is about 25% of the total travel over 20ms or so.  My guess is that your jitter is larger than it might look on-screen because of the smoothing effects of the interaction with the video sync rate, and that you're actually getting ADC readings that are quite a lot more variable than they look.

 

Have you tried putting the cap across the ADC input itself? I wasn't actually thinking of the power supply as the source of the problem - my guess is that it's signal noise from the KL25Z clock or USB or something that's bouncing around in the circuitry that you have connected to the ADC.  Given that you have all of that staging circuitry (the amp and the conditioner) connected between the ADC and the LVDT's physical coil, it's probably not just an inductor/capacitor interaction, but it could still be some kind of signal injection.  (And you have an op amp involved, too - those tend to amplify the signal as well as any noise.)

 

(And if you do want to try one more time with the power supply, put a BIG cap there - 1000 uF or 3300 uF.  There's no reason you want fast response there - quite the opposite. You want that power to be extremely clean especially given that you have an op amp in the system.)

 

Another possibility is that the firmware isn't giving the ADC enough time for the voltage to stabilize.  It's set up currently to read the photosensor capacitor output, which has well specified timing properties - and for performance reasons, the software runs at the minimum safe sampling time for that device.  With the photosensor, reading each pixel quickly is important because there are many pixels, but for the LVDT you only have to read one voltage sample per USB cycle, so you can be much more leisurely about it.  You're treating this in the software as potentiometer, right?  Try going into potsensor.h and changing the declaration of 'FastAnalogIn pot' to 'AnalogIn pot', and then comment out the 'pot.enable()' line in the constructor.  That will use the slower ADC code that will give the port longer to stabilize on each reading.   (And if that works, I can add a new explicit LVDT option in the base code to make this a permanent part of the project.)

Edited by mjr, 29 May 2015 - 07:46 PM.

[mjr]

3.  Since the output of the differential amp is a sinusoid, a filtering circuit is made to turn this into a (fairly) DC signal that is proportional to the core position.

 

My LVDT incorporates this circuit such that I need only supply it DC power and get a DC output which is proportional to the core position.  Since my LVDT is made to put out 0-5V I have a non-inverting amp to set the gain and output a 0-3.3V signal.  As I mentioned, this output is rock solid (and double buffered at that point).  However it does pick up a small amount of noise when plugged into the KL25 board.)

 

Ooh, I missed that part.  "Fairly DC" over what time scale?  The firmware is sampling quite rapidly - on the order of 15 us (microseconds).  Have you tried looking at it on the scope at that scale?  If you have any high-frequency harmonics in the 100 kHz range, those could be getting picked up on the ADC at that sampling frequency.

[Spektre]

I'll certainly look to fixing the noise problem, however I am curious how much of a hair trigger this launch id based on.
ANY A/D reading is going to have a small about of variance and that certainly seems to be the case here.  I'd expect even the photosensor to bounce a pixel value or two.

 
It's not even remotely a hair trigger, actually.  The trigger is two sequential USB readings that register over about an inch apart in the forward direction, which is about 25% of the total travel over 20ms or so.  My guess is that your jitter is larger than it might look on-screen because of the smoothing effects of the interaction with the video sync rate, and that you're actually getting ADC readings that are quite a lot more variable than they look.
 
Have you tried putting the cap across the ADC input itself? I wasn't actually thinking of the power supply as the source of the problem - my guess is that it's signal noise from the KL25Z clock or USB or something that's bouncing around in the circuitry that you have connected to the ADC.  Given that you have all of that staging circuitry (the amp and the conditioner) connected between the ADC and the LVDT's physical coil, it's probably not just an inductor/capacitor interaction, but it could still be some kind of signal injection.  (And you have an op amp involved, too - those tend to amplify the signal as well as any noise.)
 
(And if you do want to try one more time with the power supply, put a BIG cap there - 1000 uF or 3300 uF.  There's no reason you want fast response there - quite the opposite. You want that power to be extremely clean especially given that you have an op amp in the system.)
 
Another possibility is that the firmware isn't giving the ADC enough time for the voltage to stabilize.  It's set up currently to read the photosensor capacitor output, which has well specified timing properties - and for performance reasons, the software runs at the minimum safe sampling time for that device.  With the photosensor, reading each pixel quickly is important because there are many pixels, but for the LVDT you only have to read one voltage sample per USB cycle, so you can be much more leisurely about it.  You're treating this in the software as potentiometer, right?  Try going into potsensor.h and changing the declaration of 'FastAnalogIn pot' to 'AnalogIn pot', and then comment out the 'pot.enable()' line in the constructor.  That will use the slower ADC code that will give the port longer to stabilize on each reading.   (And if that works, I can add a new explicit LVDT option in the base code to make this a permanent part of the project.)

 
 

3.  Since the output of the differential amp is a sinusoid, a filtering circuit is made to turn this into a (fairly) DC signal that is proportional to the core position.
 
My LVDT incorporates this circuit such that I need only supply it DC power and get a DC output which is proportional to the core position.  Since my LVDT is made to put out 0-5V I have a non-inverting amp to set the gain and output a 0-3.3V signal.  As I mentioned, this output is rock solid (and double buffered at that point).  However it does pick up a small amount of noise when plugged into the KL25 board.)

 
Ooh, I missed that part.  "Fairly DC" over what time scale?  The firmware is sampling quite rapidly - on the order of 15 us (microseconds).  Have you tried looking at it on the scope at that scale?  If you have any high-frequency harmonics in the 100 kHz range, those could be getting picked up on the ADC at that sampling frequency.

Thanks for taking this time mjr. It really is above and beyond. For giggles I "capacitored" the 3.3V supply as well with no effect. The supply looks pretty clean now.

You're probably right about my missing a few outliers visually on the windows output, however the oscilloscope noise now (since the GND wire addition) seems capped to 50mV on a 3.3V full scale signal. That's not bad. I have not tried to noise filter the output. Mostly because my the overall gain of the circuit is less than 1. (I have to go from 5V full scale to 3.3V full scale.) However I'll give that a go next. I've been reluctant to do that because as you know that will slow the response of the plunger down.


For the power supply, I can't use any larger cap than 10uF and still remain USB compliant. I am powering the board via USB. I suppose I could use my "toys" 5V supply to the Vin pin but unless it is a slightly higher than the USB voltage it wouldn't help. (They just tie them all internally together through diodes.) I could throw a 9V battery on the line I suppose to try it out. Alternately I could remove D11 and D8 from the board so the USB power is not routed to the system at all.

The ADC not settling is a good idea as well, though I'd expect the few others here using pots would have noticed the problem. Yes, I am using this like a "POT" input. The previous U-HID-G board I was using to read the plunger was much more steady, but it's accelerometer output was unwieldy and not repeatable. I may give this a try first off.

As a last resort, I notice that 990 does not have this issue and thus the launching code must be different in 991. I doubt he code path keepers let you touch the other controllers' code, so what would I lose functionality wise if I altered the 991 code to use one of these other cotroller's launch (ala 990)?

[Spektre]

I'd rather it "just worked" but at least this is an interesting issue

I took the oscilloscope to the circuits and tried to characterize the noise. Hopefully with this and mjr's knowledge of the code's structure, we can lick this "auto-fire" issue.

Results as follows:

1. All power to the LVDT, scaler/buffer, and Freescale board were tested and all are very solid. Less than 25mV ripple on any of them.

2. The output directly from the LVDT was measured. It contains about 20mV ripple at about 3kHz which is the excitation frequency for the LVDT and well within spec, superimposed was <5mV noise.

3. The output from the scaler/buffer was measured unloaded. It looks like a perfectly scaled version of the LVDT's output.

4. I connected the scaler/buffer output to the Freescale board, with the board unpowered. There is no change in the signal.

5. I powered on the Freescale board and measured the A/D pin. There is ambient noise of 40mV or so, however with spikes to 150mV. These 150mV spikes occur approximately at 75Hz frequency (roughly every 13ms or so). Expanding the noise blips out shows they are made of up trains of spikes 4.4us apart (roughly 227Khz).

I'm assuming that this is USB communication and the joystick is being polled every 75Hz.

6. I made the same measurement while VP was running a blank table. While running I disconnected the Freescale board from USB. The table CONTINUED TO AUTOFIRE.

7. I stopped the table and reran it this time with no Freescale board connected to USB, the auto-fire did stop.


So, analysis.

1. Even with the increased noise, we are only looking at <150mV on 3.3V full scale signal. This should not be causing the triggering you mentioned.

2. I am not sure the noise seen is USB induced. While the 75Hz envelope sounds correct, the 225KHz pulses are a tad slow for USB. Any other ideas? Perhaps we could not read the A/D during the USB comms interval?

3. Something other than noise can cause the auto firing as a table that is autofiring, continues to do so even after the Freescale board is disconnected from USB. Any ideas on this?

4. These issues should be in common with anyone using the A/D pin. Are you still monitoring the thread Lemming? Do you see any instability on the plunger reading say in Windows calibration?

Edited by Spektre, 31 May 2015 - 12:24 AM.

[mjr]

Spektre: I'm afraid that none of that gives me any ideas at all.  That all just seems to make things more mysterious.

 

Have you tried running 9.9.1 with the KL25Z attached and running, but the LVDT disconnected?  I.e., nothing wired to the ADC port on the KL25Z , and no power to the LDVT.  I'm just curious if it even has anything to do with the LVDT at this point or if it's something else entirely.

[Spektre]

Spektre: I'm afraid that none of that gives me any ideas at all.  That all just seems to make things more mysterious.
 
Have you tried running 9.9.1 with the KL25Z attached and running, but the LVDT disconnected?  I.e., nothing wired to the ADC port on the KL25Z , and no power to the LDVT.  I'm just curious if it even has anything to do with the LVDT at this point or if it's something else entirely.

Hmm, Nothing connected to the port would leave it floating which would lead to all kinds of readings. I could try grounding the pin.

[Spektre]

New testing, new weirdness.

 

All test performed on 991 blank table.  LVDT removed from circuit.   Repeated 3 times for repeatability.

 

1.  I clipped ADC pin to GND.  Noted the reading in Windows calibration is very steady, variance of +/- 3 around mean.  Started up blank table.  Ball does not auto fire.

2.  Unclipped ADC to GND connection, leaving ADC floating.  Plunger begins to bounce in VP and ball may bounce off moving plunger but it does NOT auto fire.

3.  Close VP, open Windows calibration and note very unsteady signal from floating pin (as expected) +/- 1500 around mean

 

4.  Connect bench voltage supply directly across ADC pin to GND.  Set voltage to 1.0V  Note less signal variability in Windows calibration than the open circuit but significantly more than when ADC was grounded, +/- 300 around mean.  Check bench supply output with oscilloscope.  Note similar noise to when LVDT was connected.

 

5,  Launched VP and started up blank table.  Auto fire occurs, repeated as soon as a new ball enters the shooting lane.

6.  Disconnected the bench supply and reclipped ADC pin to GND.  AUTO FIRING CONTINUED AS EACH ball gets drained.

 

Observations:

 

1.  Whether or not auto firing occurs is determined upon table load and once determined is not affected by the level of noise seen.  When the table is launched with the ADC pin grounded, auto fire does not take place, even if later while the table is running the ADC is set to float and the plunger can be seen bouncing greatly.

 

2.  Likewise if the ADC pin is varying upon table load, auto fire will occur and continue to occur even if the ADC pin is grounded (and the plunger can be seen to visibly hold steady).

 

3.  The values being reported to Windows are significantly noisier than the actual voltages present at the ADC pin.

[mjr]

Okay, dumb question, but you did configure the software for the potentiometer option, right?  I'm starting to wonder if the issue is that the software is trying to read pixels off of the LVDT.  That would cause all kinds of chaos not unlike what you're encountering.

[Spektre]

Yes. I followed the guide to alter the one header file and compiled.

It IS reading the A/D pin...just noisily.

Tomorrow. I'll try altering the A/D conversion time.

Edited by Spektre, 31 May 2015 - 04:19 AM.

[mjr]

Yes. I followed the guide to alter the one header file and compiled.
It IS reading the A/D pin...just noisily.

 

Okay, thought it was worth a shot.

 

(The photosensor does read the same ADC pin, for what it's worth - it just has a completely different interpretation of the data, obviously.)

 

I think I'm out of ideas.  I've only actually built this with the photosensor, so I haven't tested anything like your configuration directly.  The closest thing anyone else has tried is the potentiometers, and the couple of people who have reported using those seemed to have no problems whatsoever with analog noise.  So I don't have any past debugging experience to bring to bear here.  Are you versed enough on mbed to maybe try writing some tiny KL25Z test programs that just exercise the LVDT analog input and see what it looks at a raw level?  I'm thinking you can get rid of all of the other software and just see what's going on with AnalogIn port on the software side.  The best debugging approach with this kind of mystery is usually to strip away everything and try controlling one variable at a time until you spot the parts that's not working as expected.  It seems like you've eliminated everything on the electronics side, so the next piece would seem to be the ADC data.

[Spektre]

Yes. I followed the guide to alter the one header file and compiled.
It IS reading the A/D pin...just noisily.

 
Okay, thought it was worth a shot.
 
(The photosensor does read the same ADC pin, for what it's worth - it just has a completely different interpretation of the data, obviously.)
 
I think I'm out of ideas.  I've only actually built this with the photosensor, so I haven't tested anything like your configuration directly.  The closest thing anyone else has tried is the potentiometers, and the couple of people who have reported using those seemed to have no problems whatsoever with analog noise.  So I don't have any past debugging experience to bring to bear here.  Are you versed enough on mbed to maybe try writing some tiny KL25Z test programs that just exercise the LVDT analog input and see what it looks at a raw level?  I'm thinking you can get rid of all of the other software and just see what's going on with AnalogIn port on the software side.  The best debugging approach with this kind of mystery is usually to strip away everything and try controlling one variable at a time until you spot the parts that's not working as expected.  It seems like you've eliminated everything on the electronics side, so the next piece would seem to be the ADC data.

Thanks, unfortunately no, other than the few lines of code changed to use the pot, I have no experience with the mbed. I'll try increasing the sampling time tomorrow and then I may be stick as well.

[mjr]

 

 

Yes. I followed the guide to alter the one header file and compiled.
It IS reading the A/D pin...just noisily.

 
Okay, thought it was worth a shot.
 
(The photosensor does read the same ADC pin, for what it's worth - it just has a completely different interpretation of the data, obviously.)
 
I think I'm out of ideas.  I've only actually built this with the photosensor, so I haven't tested anything like your configuration directly.  The closest thing anyone else has tried is the potentiometers, and the couple of people who have reported using those seemed to have no problems whatsoever with analog noise.  So I don't have any past debugging experience to bring to bear here.  Are you versed enough on mbed to maybe try writing some tiny KL25Z test programs that just exercise the LVDT analog input and see what it looks at a raw level?  I'm thinking you can get rid of all of the other software and just see what's going on with AnalogIn port on the software side.  The best debugging approach with this kind of mystery is usually to strip away everything and try controlling one variable at a time until you spot the parts that's not working as expected.  It seems like you've eliminated everything on the electronics side, so the next piece would seem to be the ADC data.

 

Thanks, unfortunately no, other than the few lines of code changed to use the pot, I have no experience with the mbed. I'll try increasing the sampling time tomorrow and then I may be stick as well.

 

 

Okay.  Switching the FastAnalogIn to regular AnalogIn is definitely worth a shot.  If it is just analog noise that's the problem, taking a longer sample might help just by averaging the noise over a longer period.  You could also try explicitly taking several readings and averaging the results to further smooth it out.  In potSensor.h, in highResScan(), you could do an average of 3-5 pot.read() readings rather than the single reading taken now.  The photosensor takes about a hundred readings per cycle, so for the pot/LVDT, where you only need one analog level per cycle, it wouldn't be a problem at all to take multiple readings.

[Spektre]

A new day and a new perspective.

I'm going to try multiple avenues to reduce the analog noise on the pin and make the values reported to Windows more in line with what is actually seen at the pin. I'll detail those later, but something else occurred to me.

There must be SOMETHING wrong with the auto fire code. If noise is present when the table loads and it autofires once, clamping the analog input to ground does not stop the behavior from continuing. Indeed disconnecting the Freescale board from USB does not stop the behavior.

Any ideas as to why this is?

 

edit:  Nevermind.  I see where in the mbed code you are sending simulated positions.  This probably explains why I am seeing a much greater variance in windows that in actual noise.

Edited by Spektre, 31 May 2015 - 05:52 PM.

[Spektre]

            // If we're not already in a firing event, check to see if the
            // new position is forward of the last report.  If it is, a firing
            // event might have started during the high-res scan.  This might
            // seem unlikely given that the scan only takes about 5ms, but that
            // 5ms represents about 25-30% of our total time between reports,
            // there's about a 1 in 4 chance that a release starts during a
            // scan.  
            if (!firing && z0 > 0 && znew < z0)
            {
                // The plunger has moved forward since the previous report.
                // Watch it for a few more ms to see if we can get a stable
                // new position.
                int pos1 = plungerSensor.lowResScan();
                Timer tw;
                tw.start();
                while (tw.read_ms() < 6)
                {
                    // if we've crossed the rest position, it's a firing event
                    if (pos1 < cfg.d.plungerZero)
                    {
                        firing = 1;
                        break;
                    }
                    
                    // read the new position
                    int pos2 = plungerSensor.lowResScan();
                    
                    // if it's stable, stop looping
                    if (abs(pos2 - pos1) < int(npix/(3.2*8)))
                        break;
                        
                    // the new reading is now the prior reading
                    pos1 = pos2;
                }
            }

Kudos on some well documented code and my apologies if I am reading it incorrectly.'
 
This snippet seems to be saying that if the sampled position is less than the previous position, and the previous position was greater than 0, and later that we have crossed the plunger's rest position then we are in a firing event.  I don't see the requirement that the distance between the znew and z0 must be greater than some threshold.  This is the check you perform to see if a firing event occurs during a "highresscan".
 
This looks in contrast to the condition for any other time:

if (!firing && cfg.d.plungerEnabled && z >= JOYMAX/6)

Where it seems you require it be pulled back at least 1/6 of the travel (1/2"). Am I reading this correctly? It seems during the "highresscan" only a small amount of noise could trigger the firing event.

[Gribnif]

&nbsp;

 
I finally resorted to tinkering with the firmware source code. It turns out that something in the logic used by the "firing" variable is causing the problem. I short-circuited the "if" statements at lines 1448 and 1509 of main.cpp by changing them to "if (0)", and that completely fixed the problem for me.
 
Not only that, but effectively removing the "firing" code in this way doesn't even seem to have any negative effect on game play, so far. I think the plunger might move the ball a little too much based on how far I'm pulling it back, but that could probably be adjusted in VP.
 
Let me know if you want me to try a different version of the code or anything, to debug what's there. Personally, I think you could just remove the firing logic, or make it optional.

 
The firing code should definitely be included.  It improves the behavior during release motions where the plunger is moving too fast for the sensor to read.  The effect isn't always obvious - it affects the consistency of release strength, so if you disable that code the difference you'll see is that the release strength won't be as repeatable for a given pull distance.
 
I'm assuming you're using the latest.  Did you change any options from the defaults in config.h, or are you using everything at defaults?  If you've changed any options, there might be an interaction with an option setting that I haven't tested.

&nbsp;
Sorry to have taken so long to get back to you, but I've been away quite a bit.

I am using the latest source code, without any changes in config.h.

I wonder if perhaps I'm getting the same kind of noise Spektre is, and that's causing the code to think I'm firing the plunger when I'm not?

Since I noticed the developer notes for the CCD included a small filter cap, I had already tried that, but I may try a larger one.

I also noticed that if I increased the delay at line 1774 of main.cpp [ if (reportTimer.read_ms() > 15) ], it helped progressively. If I went as far as about 65 IIRC, the spurious readings went away, but then of course the plunger was very laggy.

[Spektre]

&nbsp;

I finally resorted to tinkering with the firmware source code. It turns out that something in the logic used by the "firing" variable is causing the problem. I short-circuited the "if" statements at lines 1448 and 1509 of main.cpp by changing them to "if (0)", and that completely fixed the problem for me.
 
Not only that, but effectively removing the "firing" code in this way doesn't even seem to have any negative effect on game play, so far. I think the plunger might move the ball a little too much based on how far I'm pulling it back, but that could probably be adjusted in VP.
 
Let me know if you want me to try a different version of the code or anything, to debug what's there. Personally, I think you could just remove the firing logic, or make it optional.

 
The firing code should definitely be included.  It improves the behavior during release motions where the plunger is moving too fast for the sensor to read.  The effect isn't always obvious - it affects the consistency of release strength, so if you disable that code the difference you'll see is that the release strength won't be as repeatable for a given pull distance.
 
I'm assuming you're using the latest.  Did you change any options from the defaults in config.h, or are you using everything at defaults?  If you've changed any options, there might be an interaction with an option setting that I haven't tested.

&nbsp;
Sorry to have taken so long to get back to you, but I've been away quite a bit.

I am using the latest source code, without any changes in config.h.

I wonder if perhaps I'm getting the same kind of noise Spektre is, and that's causing the code to think I'm firing the plunger when I'm not?

Since I noticed the developer notes for the CCD included a small filter cap, I had already tried that, but I may try a larger one.

I also noticed that if I increased the delay at line 1774 of main.cpp [ if (reportTimer.read_ms() > 15) ], it helped progressively. If I went as far as about 65 IIRC, the spurious readings went away, but then of course the plunger was very laggy.

If you are using the optical sensor than other than it being a condition in this statement getting tripped incorrectly, the noise should not be related.

[mjr]

Kudos on some well documented code and my apologies if I am reading it incorrectly.'

 
This snippet seems to be saying that if the sampled position is less than the previous position, and the previous position was greater than 0, and later that we have crossed the plunger's rest position then we are in a firing event.  I don't see the requirement that the distance between the znew and z0 must be greater than some threshold.  This is the check you perform to see if a firing event occurs during a "highresscan".
 
This looks in contrast to the condition for any other time:

if (!firing && cfg.d.plungerEnabled && z >= JOYMAX/6)

Where it seems you require it be pulled back at least 1/6 of the travel (1/2"). Am I reading this correctly? It seems during the "highresscan" only a small amount of noise could trigger the firing event.

 

That's a good catch - I think you're right.  That check for crossing the zero point probably needs to have a distance threshold from previous readings along the same lines as the others.  I'll take a closer look and make a testing version for you to try out.