USB-6255 Digital Change Detect missing events

[waltm1]

I am using the digital change event to capture SPI data.    Specifically, i am creating a change event on the CLOCK high and SC high.  This should results in 33 change events, and 33 samples.  What is happening is that i am missing a change event, and the data returned will be 32 samples, instead of 33.

I am using a ESP32 to send SPI data.  I also routed the change event signal to one of the PFI pins to monitor it.  Whenever the data is returned missing a event, i have the my scope buffered and i review the data.  The clock is not missing, nor is the change event missing.

Subsequently, I replaced the ESP32 SPI signal with the Daq generating the data itself. I recreated the SPI CLOCK and CS with digital data, and physically routed that to the two pins im using for change event.  It did not take long to get an event that was missing, so i am pretty confident this issue is not me.

The SPI CLOCK is at 400 khz which seems as if it in the realm of capabilities for the device to see the changes (2.5uSecs between edges).  I measure the changed event pulse and it is approximately 200 nanoseconds. I was sending SPI data at a slow one second interval.

The change event in the event structure only fires after the 32 clocks and the change select have been generated (33 samples normal).   I have my Digital Read set up with the "-1" read all available.   I find it a bit odd that an event is not generated for "Each" change. While i realize that LabView would probably not be able to keep up, i feel that the data must be buffered somehow, generating one change event for all 33 samples.

When sending data from the ESP32, i would send a sequential number.  When i read the data back from the samples missing the events, i could see what bit was missing in the data stream and oddly it seemed to be the 24th bit each time!

My only guess is that the change event is firing but somehow not getting recognized internally?  There must be some buffer that is waiting for X change events to happen before sending the data to LabView.  

I did read about being able to change transfer modes between DMA, Event and Programmed IO.  Perhaps the wrong mode is selected?

Any help?

[Kevin_Price]

I don't know SPI protocol to know the expected timing between CLOCK and SC signals, but will assume for the time being that your SC rising edge does NOT coincide (or very nearly coincide) with any CLOCK rising edge?    I can see that they wouldn't if you loopback your 2 DO output lines back to your 2 DI input lines.  

I don't have a definitive answer for you, but there's a few places I'd focus first:

1.  reliance on the software change detection event.  I would expect this event rate to be more limited than the hardware change detection rate (which itself is limited to ~5 MHz, as you've seen from the ~200 nanosec pulse).

    I probably wouldn't bother with registering for the software change detection event b/c I wouldn't assume I could trust it to be consistent and reliable when the hardware events are in the 100's of kHz or more.

2. use of -1 for # samples to read.  The first time you receive a software event, you'll retrieve whatever # of samples happen to be available in the task buffer at that moment.  But then your data integrity checks seem to depend on an assumption that you'll have all of them.

   If the software events *were* able to keep up, you'd only get 1 sample on the first event, then fail the integrity checks and exit.

3. implied software loop rate is very high.  Either 1/400kHz or 33/400kHz.  Either way software reads probably can't keep up at that rate.

My recommendation: drop the event structure and set your read loop to retrieve 33000 samples per iteration.   This gives you 1000 cycles worth of data while keeping your read loop rate around the generally well-accepted rule of thumb of 10 Hz.    Then let's see if the *hardware* change detection capture circuitry is getting you the data you expect once we get the software events out of the way.

-Kevin P

[waltm1]

I guess i needed to add a few more tidbits.  

First, this project is being written in python.  I have this same scenario not working in python and i duplicated the code in Labview to try and find the issue.  In python, I setup a change event and it returns data in a callback.  

At first, when i coded this setup in LabView, i did not use the software event structure, and instead replaced it with a loop as you suggested.  With the number of samples set as 33 or -1, the loop caught everything with no issues! I thought the "software event structure" in Labview was required to be used. I thought perhaps when i ramped up the speed of the messages from 1 a second to as fast as possible, that the event structure was necessary, as it is shown in most every example. When i added it, it developed the same issue as python.  

I went back to python and removed the "register_signal_event" which effectively removed the callback, and instead read data in my main loop.  This worked.  It seems that polling will work fine, as the hardware change event effectively filters out the data that i needs.

Consequently, i create a ticket with NI and the tech support rep was able to duplicate on his M Series.  However, the same code on the X series does NOT miss edges.

I do not know enough about the internal working, but it seems the transfer mechanism from the daq is the culprit.  

[Kevin_Price]

I don't think it's the "transfer mechanism" exactly.  As you found, all the data transfers fine as long as you bypass reliance on software-based DAQmx events that fire off Python callbacks or LabVIEW event structure cases.

At the device hardware level, the change detection circuitry will detect a change, capture a sample, and create a hardware change detection event inside the device.  This internal hardware change detect event pulse *can* be used as a sample clock by other tasks.  However, as you've seen, the hardware change detect pulse is limited to <= ~5 MHz even when the digital change detection task can perform sampling at a slightly higher rate (some devices support 10 MHz).  So that can occasionally be a bit of an issue.

    Anyway, the sample goes to the device's onboard FIFO to get in line for transfer up to the task buffer.   DMA controllers get involved and I can't speak to any details about that.  The DAQmx driver will be monitoring the task buffer and either notice or be notified (again, dunno DMA details) about data transfers and use this information to create software-based DAQmx events.  The rate at which software events can be generated will have some limitation too, I'd guess about 2 orders of magnitude slower than the hardware event pulse, give or take.

My further guess is that the software-based events probably could work out if you registered for something like "every N samples acquired into buffer" where N would nominally represent a 50-100 msec time period.

-Kevin P