"CO Pulse" clock division

[bhpowell]

First of all, a huge thank you to Kevin for all of this investigation.  You put a lot of time into this forum, and I'm sure I'm not the only one to benefit from your knowledge.

I continue to push this through NI.  I have a few ways I can poke on NI to make sure this doesn't get ignored, so hopefully we'll get an explanation soon.

I'm back from my travels, and hope to do some more testing.  I _thought_ that I was seeing different results with 2/2 vs 4/4, but it sounds like you were getting a 25MHz clock with either setting.  I think I was seeing 25 and 12.5.  If it's really 25 and 25, then I need to come up with different logic.  I need a 2:1 ratio more than I need a faster clock.  (In other words, I really want 50MHz and 25MHz, but can potentially live with 25MHz and 12.5MHz.  My app simply won't work if it's X MHz and X MHz; it needs to be X MHz and X/2 MHz.)

Another worry I have is how to future-proof my code.  If this is something fixable in software, I can't imagine NI will just "fix" the 2 tick scenario to make it go 50MHz, since that might break existing code.  Or maybe they will!  If nothing else, I'll just document that upgrades to NI-DAQmx could potentially cause problems with timing.

[bhpowell]

I went back and ran some of my tests.

This is LV 2019 with the corresponding DAQmx, and a 6614 board with a 100MHz timebase.

I'm only using "Pulse" output mode.

I am clearly seeing a 2x difference between 2 ticks low, 2 ticks high, and 4 ticks low, 4 ticks high.

The former has a 40ns (25MHz) rising edge to rising edge, the latter has an 80ns (12.5MHz) rising edge to rising edge.

In some ways, that's good news, because I need the 2x difference for my application.

It doesn't explain the numbers you are seeing, Kevin, but maybe that's a difference between the 6614 board I am using, and your boards.

It's also not 50MHz (20ns rising edge to rising edge), which is a problem for me.

Next, I tried 2/2 followed by 3/3.

The latter signal has a 60ns rising edge to rising edge.

That number lines up with my other measurements, but still half of what I expect.

[Kevin_Price]

Curious -- *all* your observations are consistent with the counter operating only in "toggle" mode rather than pulse mode.  In every case the 100 MHz timebase is divided by the *SUM* of high ticks and low ticks.

My X-series device *seemed* to obey pulse mode as long as both high and low ticks were >=3, but with 2 Ticks for high and low it would silently behave like toggle mode instead.

In the case where I configured 2 High, 3 Low (or maybe vice versa? or maybe both ways? I didn't explore this with a high degree of scrutiny), there was some indication of pulsing at a variable rate - either after 3 Ticks or after 5 Ticks.  I didn't have a scope, I just used a modified example to do an unbuffered on-demand frequency measurement of the output counter.  The measurement flickered back and forth between 33.3 MHz and 20 MHz, suggesting a varying output that might have alternated (?) between 3 Tick pulse mode and 5 Tick toggle mode.  I may have to check this out again with a buffered semiperiod measurement to see what the heck's going on.

Meanwhile, my M-series device (and the even older device with E-series era counters) worked correctly, always obeying my choice of pulse or toggle mode for any # ticks >= 2.

-Kevin P

[bhpowell]

Not much of an update, but here are some things that have happened...

* I tried installing Windows 10 and LabVIEW/DAQmx 2019 on my old system with 6602's.  I was hoping that the software I wrote for the 6614's would work with the 6602's and I'd get the faster clock rate.  Unfortunately, this didn't work.  For the 6614's, I'm using the ChangeDetectionEvent.  (This approach: https://forums.ni.com/t5/Example-Code/Implement-FSK-with-X-Series-and-DAQmx/ta-p/3503175?profile.lan... )

Unfortunately, it looks like the 6602's don't support the ChangeDetectionEvent.

While I know that Traditional NI-DAQ can make the 6602's do FSK, I am doubtful that I can do it in DAQmx.

I also ran into another timing mode incompatibility with the 6602.  Frankly, fighting with this part of DAQmx is exhausting.

* In the meantime, NI spent a few weeks finding a 6614 board to test with, so they might be able to confirm this week that I'm out of luck making the 6614 go faster.  They mentioned that their tech support staff and the test system with the 6614's are on different continents.  I guess one or the other are hard to come by.  I offered to drive my systems the few miles up to NIC, but I was told this was impossible for them to handle.

[Kevin_Price]

I did a little more fiddling about and found that the problem with 2-Tick intervals and pulse mode *seemed* to go away when I divided down a slower clock rather than the default 100 MHz internal clock.

I tried generating a clock with another counter at both 1 kHz and 1 MHz and then specified my "divide-down" counter to use that output signal as its timebase.  With the slower timebase, the X-series device behaved as it should -- the periods were 1/2 as long in pulse mode as in toggle mode.   When I reverted back to specifying "OnboardClock" as the timebase, the periods were the same in both pulse and toggle modes.  When I went to 3 Ticks high and low, periods were again 1/2 as long in pulse mode as in toggle mode.  The wrong behavior seems to show up only when there are 2 Tick intervals while using the internal master timebase.   (I didn't happen to try the internal derived timebases of 20 MHz or 100 kHz.  Should have, but didn't.)

Period and semiperiod measurements continued to give varying results when I tried 2 Ticks high, 3 low (or vice versa).

-Kevin P

[bhpowell]

Interesting. Thanks for continuing the investigation.

I know that NI R&D continues to look into this, but I've gotten no update in several days.

By the way, I'm using the "/Dev1/100MHzTimebase" as the source.  I can't remember the details, but I was having trouble when using "OnboardClock".  (Maybe a routing issue; I don't remember.)

[bhpowell]

So, mea culpa, I didn't explore the pulse vs. toggle behavior thoroughly enough before today.  I should have followed up on some of the advice Kevin gave earlier in this thread. 

After 70+ days in NI Tech Support, they came back with "use pulse output mode", but also,

"our developer team did not design the 6614 with this functionality in mind, and therefore, we cannot guarantee the signal integrity."

So the good news is that I'm able (at least on the one 6614 counter I tested) get a 50MHz clock at 2 ticks high and 2 ticks low, and it properly divides down at 4 ticks high/low or 8 ticks high/low (which are the three scenarios I need in my application).

I misunderstood and thought the pulses would be generated only once for each set of ticks high and low, but they are actually generated for both the high set and the low set.  This incorrect expectation was why I didn't go down the path Kevin did.  I should have figured that out with Kevin's examples, but I think I was thrown off by the failures he ran into with certain hardware.

I'm not sure how to interpret NI's caveat about signal integrity.  Perhaps, "we don't test this, so your mileage may vary".  And perhaps somewhere in there is an explanation for why some of Kevin's tests yielded unexpected results.