PCI-6534 receives clock data twice

[pshrew]

I have a simple test set up to test operation of the PCI-6534 board.  A test generator writes a double ended (hi-lo) 16-bit word of zeros with a one being bitshifted to the left (MSB).  This is sent to a custom board that converts the double ended signal to single ended and then sends it on the PCI-6534 board.

Something like this:

0000000000000001

0000000000000010

0000000000000100

0000000000001000

0000000000010000

etc...

I have two different computers and each has a PCI 6534 installed with exactly the same configuration accept the driver.  Computer 1 has PCI-6534 driver version 1.12.0f0 (circa 2006).  Computer 1 shows pattern above as expected.  Computer 2 has driver 2.0.0f0 (circa 2007).  Computer 2 shows pattern below:

0000000000000001

0000000000000001

0000000000000010

0000000000000010

0000000000000100

0000000000000100

0000000000001000

0000000000001000

0000000000010000

0000000000010000

So, this looks like computer 2 is getting the same data on the up and the down of one cycle of the clock.

I was just about to check the clock seen by 6534 on Computer 1 versus Computer 2 against the clock from the data generator to show the difference.  However, in doing so I have discovered that now Computer 2 is showing:

0000000000000001

0000000000000010

0000000000000100

0000000000001000

0000000000010000

I can't reproduce the problem even as I'm asking the question!

Any ideas?

Thanks!

[dansch]

Hi pshrew,

I am glad to hear that the program is now functioning properly. Have you seen the functionality change from what was expected anymore since it started working properly? Perhaps the clock rate was somehow set twice as high as needed and so it was taking each sample twice. This is really the best explanation that I can imagine for what was happening. One thing I am wondering about is the drivers that you mentioned (versions 1.12 and 2.0) for the 6534. I am slightly confused by which drivers you are referring to since this device uses the NI-DAQ/DAQmx driver and the driver versions do not match. In any case, please let me know if you start to see the problem occur again. Regards,

[pshrew]

Hey dansch,

It has reappeared on a random basis.  We use the Traditional NI-DAQ drivers so maybe that is why the versions of the driver installed on the two computers could be different?

Thinking it may be software related we have been restoring different disk images containing different versions of our software and it appeared to have re-occurred with an image that was known to have the problem.  Upon further investigation and to check our own sanity we were able to reproduce the problem with an image that previously did not reproduce the problem.  This is what led to the current breakthrough - that there may be a design flaw in the custom differential receiver board that is converting the double-ended signal to single-ended signal for the 6534.

The reason for this idea is because the Differential Receiver Interface (DRI) in the 'working' computer is an older vintage card built by a different vendor than the DRI that is installed in the 'malfunctioning' computer.  The DRI in the 'malfunctioning' computer is younger by about five years or so.

Obviously we'll be probing the clock line around the DRI today and comparing the chips use on the newer board to those used on the older, stable ones.

I'll keep this thread up-to-date until resolved.

Thanks,

-shrew

[pshrew · Accepted solution]

We have two different vintages of differential boards.  It turns out that the newer boards have a slightly different flavor of the 26LS32 chips than the older ones.  When we swapped out the chips on the newer board with those from the older we were able to resolve the problem.

So, with the non-functioning chips installed, if we turn the clock down reeeaal slow we can get multiple samples of the data as the noise on the differential line is enough that it takes over as clock.  If we turn it up to, say, 6MHz everything is fine.  This is because at that point the clock is running at a higher frequency than the noise and takes over clocking the card.

I still have yet to figure out what parameters of the new chips are really the root cause of the problem but it is working.

-shrew