02-13-2024 04:39 PM
Kevin,
You raise an astute point - spark RF interference could explain the signal synchronization artifact. I appreciate you proposing such an insightful experiment to isolate that variable. In fact, after initial observation of this phenomenon, RF noise was my first suspicion. I had shielded the entire spark rig inside a grounded RF cabinet without relief. I also attempted your suggested test of placing the removed sensors at equivalent distances. Yet the alignment persisted in the absence of pressure waves.
Thank you again for sharing your insights - your expertise regarding possible oversights is extremely valuable at this junction!
I will keep updating the thread as I go along if you find any other suggestions to help me overcome this issue.
Regards,
02-14-2024 12:52 AM
After looking at the zoomed in chart, I'm going with ZYOng's assessment that there is cross talk. You posted 2 examples of how you configured the DAQ channels and looking back, both are wrong.
The Single Channel version only has 2 channels, 0 and 1. The Multiple Channel version sequentially configures 3 channels on the same task. This results in only the 3rd channel configured, ai0. As Kevin Price pointed out, that channel is an order of magnitude bigger than than the other 2. The other 2 may be just cross talk. Cross talk is very common in multiplexed DAQ boards.
Please use the Single Channel version set for all 3 channels (ai0:2).
Please keep the data on a single chart, not 3 separate charts.
Keep the higher sample rate
Use the graph pallet to zoom in on all 3 together,
Please use a shift register to return the errors into the DAQ read. You could have errors that are ignored.
02-14-2024 03:19 AM - edited 02-14-2024 03:35 AM
Two problems:
1. the multiplexed DAQ, prone to crosstalk.
better switch to a real simultanious sampling DAQ.
If the pulses can be seperated, a software solution would be to ignore them 🙂
2. EMI due to the high dI/dt in the spark.
Shielding and keeping the area between the current loop as small as possible .
And the cabling geometrie. If possible try to put the pulse generator at the spark end of the tube and the cable to the tube in line with the tube axis.
The spak unit ground connection should be connected to the generator! Short ! Low impedance!
Better isolate it to the electrical grounding of the tube (would need some ceramics, not just a kapton film, you don't want to build a coupling capacitor.. OK migth be not that easy)
The sensor cables should also be in line with the tube to the other end. (but I wouldn't attach them to the tube .. cable microphony).
(Edit: Hey, see it as a feature, you also have the ignition time in your sensor data, so one more distance to evaluate :D)
ICP sensors are already relative low impedance, what signal conditioner do you use?
What is the excitation current ? (can you increase the current? higher current lowers the impedance -> less prone to noise and EMI )
The 6259 don't support IEPE/ICP sensors without a conditioner according to the spec.
If you use one multi channel conditioner, place it near the DAQ (just because the DAQ input is high impedance and prone to EMI)
And check if that conditioner isn't the spike distributor (catching the spike with the first, nearest sensor and share it to the others 😉 ) by disconnecting the first sensor and run a test.
If you missed the signal conditioner (well, current injector and DC-Offset remover) to supply the ICP sensors, it's point zero on my list 😄
02-15-2024 07:05 AM
@Henrik_Volkers wrote:
If you missed the signal conditioner (well, current injector and DC-Offset remover) to supply the ICP sensors, it's point zero on my list 😄
Do not simply supply a constant voltage to the sensors! That will burn them!
The magic white smoke wouldn't leave the housing, but the elektronics.