I understand that chasing analog noise and crosstalk is basically a dark art, but in this case I think I may have encountered an actual firmware bug:
Test setup: UE9, current firmware, ethernet connection, LJTick Current Shunt
Electrical connections:
- Current Shunt configured with resistors connected between the various INX+/- and VS/SGND terminals to generate ~10mA and ~15mA test currents (important that these currents are different by ~5mA or more).
- LJTick itself connected to AIN2/3.
- Oscilloscope probes clipped to OUTA and OUTB on the LJTick and referenced to SGND
To repeat problem: use LJStreamUD to configure a 20Hz 3-channel stream that includes AIN2, AIN3 *and* EIO_FIO (channel 193 per section 3.2.2)
Observed Behavior: for a subset of the sampling interval (~3ms out of 50ms for 20Hz), the lower of the two values of AIN2/3 is drawn up to almost match the higher of the two values, per the attached TEK00000.PNG from my scope.
Related but less-thorough observations from poking around with LJStreamUD:
- Channel 194 (FIO, MIO) does not appear to have a similar effect
- This does not seem to occur during the actual sampling of AIN2/3 (i.e., the values received via LJStreamUD are unaffected by this glitch)
- This effect occurs, though less drastically, with a resistor bridge : {GND - 100 - AIN2 - 220 - AIN3 - 220 - VS} per attached TEK00001.PNG In this case, the signals are drawn toward one another by ~10%.
- This does not appear to affect AIN 0/1
- This does appear to affect AIN5/6 (on the breakout board)
- None of this occurs if I do not stream port 193 (i.e., nothing similar appears to occur, though it would be difficult to catch, with SingleIO Mode)
- Depending on the detailed stream configuration and/or timing of my button clicks, the impedance between AIN2/3 remains low even after stopping the stream. In this case, power-cycling the UE9 restores the nominal behavior (Hi-Z).
Hypothesis: something about sampling EIO_FIO digital ports as part of stream mode is interfering with the management of the analog mux/buffer magic inside the UE9, and AIN2/3 are briefly being bridged by a relatively low-Z internal resistor or some such in the vicinity of a few hundred to ~1K ohm. This could conceivably yield the behavior I'm seeing in both of the attached screenshots.
This is important to me because in my production setup, we are tapping into the outputs of the LJTick and monitoring their values as part of a self-consistency-checking safety component, and that safety component has been getting a serious case of the grumpies from this effect.
Thanks in advance for any help you can give, and let me know if there is anything else you need to help diagnose this problem.
.png%3Fitok=PHGBxf6M "EEV Blog Reviews LabJack T7-Pro & Software Tools")
.jpg%3Fitok=B1YcuDFK)
.png%3Fitok=Ybt-OlgU "LabJack + JEDI One Can Create a Powerful Distributed DAQ Ecosystem")
Updates after further investigation:
I see something similar. Here is what I have so far:
Have you been able to reproduce this without the Current-Shunt? To pin this issue on firmware we need to show that the signal source is not the cause. More interesting still is that the UE9 does not have a means to drive the AIN pins.
I am guessing you are seeing the effect on ain3 because it has the smaller test current (AIN3 jumping up to meet AIN2). Try switching the test currents so that AIN3 has the larger and AIN2 the smaller.
As to other signal sources, the second scope capture in the original post shows a similar effect with a resistor bridge in place of the LJTCS: line up 100,220,220 ohm resistors in series across vs/gnd and connect AIN 2/3 across the center 220. The pulse is the same size, but the effect is a little different. I suspect something more pronounced might occur if you use 1K,2.2K,2.2K, but the effect may start to confound with the input impedance spec for the analog inputs.
Please try firmware 2.28: https://labjack.com/support/firmware/ue9/beta
With 2.28 I no longer see the pulses that were present before. I do however see some ringing from the multiplexer switching. Adding some capacitance greatly reduced that ringing.
Confirmed: 2.28 appears to fix this problem. I will be running a few more tests before I deploy it in my production environment, and I will keep you posted as to how that goes.
Many thanks for the quick turnaround!
I spoke too soon: while the analog problem has been fixed by 2.28, the values reported in the stream for special channels 193/194 are now corrupted. LJStreamUD is not a great tool for diagnosing this (it assumes all channels are to be scaled to an real number of volts), but the text box for the input channels configured to stream 193/194 do show different values for stream vs. polling mode, and in stream mode they do jump around over time.
In my own interface software, printing out the hex values for the DIO ports suggests that an analog input value is accidentally being transcribed into the payload slots for the special stream values 193/194: of the two bytes, one is very noisy, and one is only slightly noisy, rarely flickering in the LSB. Also, the DIO values drop to zero if I remove all analog inputs from the labjack, i.e. by unplugging the CB37 I'm using as part of my test setup, leaving all analog inputs on the UE9 free-floating.
Interestingly, I can reintroduce the noise in the DIO values by rubbing my thumb over the DB37 on the labjack.
I have verified with a scope that this does not affect the digital output voltages, just the reported values.
I have also verified that reverting to 2.26 restores the DIO stream data to its original (correct) behavior.
Let me know if you need any more info to keep chasing this.
Please try 2.29.
Though I still have some small amount of testing to perform, 2.29 appears to solve the DIO streaming regression in 2.28 while retaining the fix to the analog input problems in 2.26. If I encounter anything else, I'll let you know, but I'm almost ready to bless this for deployment to my production environment.
Many thanks for the fast turnaround!