06-13-2012 09:08 AM
Hey, I'm trying to impliment a manchester signal decoder with an NI PCIe-6320 card using the DAQmx API in C / C++.
Currently I have code that sets up a Digital Input Channel set to sample data on rising/falling edges, but I'm really only interested in the state change (or lack of change) that occures in the 60-120 microsecond window after a previous state change event.
Is there anyway to set DAQmxCfgChangeDetection timing to a minimimum trigger interval?
If not, how would I go about pausing a task for an interval mesured in microseconds?
Is there anyway to impliment a mask on signal input?
06-15-2012 10:37 AM - edited 06-15-2012 10:41 AM
Hello MrSky,
have you tried to work with the property node ' Start : Digital Edge : Digital Filter : Timebase : Source Property ' ?
06-15-2012 12:54 PM
Greetings macncheese.
I'm afraid I have to confese my ignorance on what a property node even is. So, no. I haven't. At least not intentionaly.
I original started with the 'ReadDig-Chan-ChangeDetectionEvent' ASCII-C example and built up from there.
My current kludge uses the windows QueryPerformanceCounter/QueryPerformanceFrequency functions in the call back function from a rising edge events to measure pulse timing. With a bit of logic combining the delay, the last data value, and lots of error checking I'm left with code that reports decoded 24-bit word with 96% accuracy. That 4% error rate and stack of hidden rejects still bothers me, so if you can tell me what this Property Node is I'm listening.
06-15-2012 01:21 PM
MrSky,
First, I'll start by saying that I'm not very familiar with Manchester signal decoding. From the small amount of reading I did, it would appear as though you need to distinguish the relative length of pulses to be able to determine the logic level of the next bit in your bitstream. Change detection does not provide any timing information about the line(s) which is changing. You can set up a digital filter to filter out pulses that do not meet a minimum length, but then these transitions would be missing from your data set all together and would not allow you to reconstruct your bit stream.
I think a better alternative might be to use a counter on the 6320 to do semi-period measurement on your signal. From the X Series User Manual, "In semi-period measurements, the counter measures a semi-period on its Gate input signal after the counter is armed. A semi-period is the time between any two consecutive edges on the Gate input." With this information, I believe that it would be possible to reconstruct the digital bitstream.
If you must use the digital lines on the device, I think you could use hardware timing to 'oversample' the signal in question, then post process the data to determine when edges occurred. If you are interested in timing on the scale of 60-120 uS, I would think that you could sample the digital signal at 100 kHz (10 uS resolution), then process this data to find the timing of digital transitions on the signal. Once you have this, I would think that you would be able to reconstruct the digital bitstream.
Like I mentioned, I haven't tried doing this before so I hope that I'm not off base in my understanding of Manchester decoding. However, I think either of the approaches I mentioned should allow you to retrieve the relative timing of consecutive edges on your signal.
Hope that helps,
Dan