I recently delivered a consulting project I have been working on, but it isn't working as expected in the client facility. I had been testing this for months in my own shop and it was working flawlessly.
Background
This is in reference to the project I described in the blog submission page https://forum.pjrc.com/threads/62695-Laser-gates-for-measuring-sports-ball-velocity
Essentially I have a bunch of laser light gates, using the Teensy to capture the timing of the beam breaks and beam restorations to a very high accuracy. To synchronize all the gates, I have a common trigger pin on each of the four Teensy 4.1 boards that synchronizes the ARM_DWT_CYCCNT register to zero. This ensures that when the cannon fires the softball/baseball that the relative timing for each of the gates is synchronized and I can do the math/geometry to calculate the ball's incoming and rebound velocity.
This was working awesome in my own facility. However, when I moved to the customer facility, there appears to be a ton of noise/bouncing on this trigger pin and keeps resetting the count even in the middle of a shot.
Setup
I currently have a Raspberry Pi4 that is doing the computational side of things. It connects to each of the light gates over I2C and has a single pin dedicated to the common trigger. I will note that the cables from the RPI4 to the gates are each about 8 feet long, with shielded 4 strand cable. I had anticipated wanting to prevent any sort of bouncing, so basically added a debouncing capacitor, as shown in the image below. This circuit is in the main electronic box on the RPI side of the cables.
I assumed that this would charge the cap when the RPI was driving the pin high, and discharge when driving the pin low, acting like a low-pass filter for any high frequency bouncing
Potential issues and attempted solutions
1. The customer facility has a ton of static electricity. They have artificial turf covering every inch of the floor and the amount of static buildup from even walking around is incredible. I have told the customer to zip-tie the cables up off of the ground, and today they are going to try and ground all of the metal frames of the equipment. They will give feedback on the addition of grounding to all adjacent metal today or tomorrow. Any other suggestions?
2. On the current firmware, I don't have that trigger pin set up as INPUT_PULLUP, but instead just INPUT. However, I would expect that with the RPI actively driving the pin high and low, that this wouldn't be necessary. Do you think this would this help?
I guess I am at a bit of a loss. In 1.5-2.0 months in my own shop, I never saw a false trigger. Now it is happening on about 50% of the shots of the cannon.
I am just trying to find a couple of potential things to try remotely before I fly out there with my scope and bag of tools to try and debug things. Any help would be greatly appreciated.
Background
This is in reference to the project I described in the blog submission page https://forum.pjrc.com/threads/62695-Laser-gates-for-measuring-sports-ball-velocity
Essentially I have a bunch of laser light gates, using the Teensy to capture the timing of the beam breaks and beam restorations to a very high accuracy. To synchronize all the gates, I have a common trigger pin on each of the four Teensy 4.1 boards that synchronizes the ARM_DWT_CYCCNT register to zero. This ensures that when the cannon fires the softball/baseball that the relative timing for each of the gates is synchronized and I can do the math/geometry to calculate the ball's incoming and rebound velocity.
This was working awesome in my own facility. However, when I moved to the customer facility, there appears to be a ton of noise/bouncing on this trigger pin and keeps resetting the count even in the middle of a shot.
Setup
I currently have a Raspberry Pi4 that is doing the computational side of things. It connects to each of the light gates over I2C and has a single pin dedicated to the common trigger. I will note that the cables from the RPI4 to the gates are each about 8 feet long, with shielded 4 strand cable. I had anticipated wanting to prevent any sort of bouncing, so basically added a debouncing capacitor, as shown in the image below. This circuit is in the main electronic box on the RPI side of the cables.
I assumed that this would charge the cap when the RPI was driving the pin high, and discharge when driving the pin low, acting like a low-pass filter for any high frequency bouncing
Potential issues and attempted solutions
1. The customer facility has a ton of static electricity. They have artificial turf covering every inch of the floor and the amount of static buildup from even walking around is incredible. I have told the customer to zip-tie the cables up off of the ground, and today they are going to try and ground all of the metal frames of the equipment. They will give feedback on the addition of grounding to all adjacent metal today or tomorrow. Any other suggestions?
2. On the current firmware, I don't have that trigger pin set up as INPUT_PULLUP, but instead just INPUT. However, I would expect that with the RPI actively driving the pin high and low, that this wouldn't be necessary. Do you think this would this help?
I guess I am at a bit of a loss. In 1.5-2.0 months in my own shop, I never saw a false trigger. Now it is happening on about 50% of the shots of the cannon.
I am just trying to find a couple of potential things to try remotely before I fly out there with my scope and bag of tools to try and debug things. Any help would be greatly appreciated.