Issue with real vs theoretical input - MCC1208FS

[TomEng]

Hello,

I am working with a device that is taking in two signals, a microphone and a proximity sensor.  For a point of reference, lets say the microphone is taking in a 60Hz pulse and the prox is taking in a 160Hz pulse of 5 volt spikes.  I am working off a setup someone else made previously, trying to improve it.  I basically want to have DASYLab figure out the Hz of each input, then be able to use that in a math equation, then plot a result from that.  This has to be done over and over again rapidly because I need to do a continuous average to get the desired answer (too much fluxuation otherwise).

Now to the problem: I took the system offline to do some tweaking, and used generated pulse signals to simulate the inputs.  I was able to get the program to work exactly the way I wanted to this way.  However, when I switch over to the real inputs with my MCC 1208FS, only the 60hz mic signal will be calculated correctly, and the other signal registers at .20E05 and the calculator part won't work at all (says mismatched block data or time info).  I am sampling at 20.0588khz and block size of 3000 something (I can get the exact number if needed, it is a multiple of 31 as required by the daq).  What differences between the generator and the real signal would cause issues?  The graphs of the data once put through a trigger look identical as far as I can tell.

Thanks,

Tom

[CJ_Butler__DASYLab_Pro]

Are you using Analog inputs or Analog and digital inputs?

Can you post your before and after worksheets here? (zip them).

The other thing that would be REALLY useful... run some raw data directly off the hardware inputs into a Write Data module, set for DASYLab format.

Zip that file and send. That will tell me a lot about the actual signal that you're seeing, including block size discrepancies.

[TomEng]

I am using 2 analog inputs.  I can't put the worksheets here as they would be proprietary to my company.  I will attempt to get a write data output and put it up however.  The mic is around 1.5volts with small spikes down at 60hz, and the prox is 0 volts with 5 volt spikes at 160 hz.  The mic is being put through some filters before that is being used.

Another problem I've had, and not sure if it's related, using the mccdrv_i.dll driver I have an issue with my raw signals getting "spiked" at 27 second intervals.  Annoying to say the least and I haven't figure it out yet.  Using the older driver it was ok but I don't think that will work for newer made sheets.

I just realized this isn't an NI related issue, but I've gotten so much useful info here about dasylab and the daq device that I thought someone would have some experience with it!  Thanks for the fast response CJ.

[CJ_Butler__DASYLab_Pro]

I won't be able to tell you why the mismatched data error is happening.

If they're both analog input, now you should look for the following:

- Any software generator (Switch, Slider, etc) must use the same timebase as the Analog Input. Open its properties, click on Options, and change the timebase from "Driver" to match the MCC USB-1208FS HW timebase.

- Any average module must be configured identically for each channel

What other functions are you using?

[TomEng]

The microphone goes through 2 digital filters to turn it into basically a sine wave.  Then that signal and the raw prox signal go into a trigger module; the mic triggers on rising, the prox between two voltage values (to basically get a pulse signal).  Both channels then go through their own relays to remove blocked data, then into a time base (in seconds from start), then a difference arithmetic module, then an inverse arithmetic module to get Hz out.  This worked with the theoretical input, but not with the real input.  I attached two ddl files, the first contains real data, the second theoretical data.

-Tom

[TomEng]

Just a note, I also tried using the pulse analysis module, which does display the Hz values correctly.  However, those values entered into the calculation returned an "ERR" in the digitial display box, and it also seemed to slow down the update speed.  With the relay and manual pulse lengh/inverse method I seem to end up with more data to work with, so I can smooth it out in an averaging block before I calculate with it.  I don't exactly understand how the pulse analysis works, but I'm assuming it needs a certain amount of pulses to make a determination?

-Tom

[TomEng]

I have done some more experimenting, with both the FFT module and the pulse analysis module.  With the FFT module, the frequency it finds seems to vary a little depending on what combination of sampling rate and block size I use, but it is stable (does not move over time at all w/ theoretical data).  I think the rate/block is my biggest issue right now, I'm not sure what I should be doing with this.  The pulse analysis block isn't too bad, but seems to jump around a lot even with perfect theoretical data.  Why does changing the sampling rate and block size affect the frequency results so much?  The device was set up previously to run 20.058.8 khz, and 8184 block size (multiple of 31 for the daq).  I am unsure of the significance of that rate or why it was chosen.

CJ, I used your compare FFT to pulse analysis example you posted in a prior thread, it was very helpful.  The 1000Hz/100 sample rate seems to give perfect FFT results as to the Hz value of my inputs.  But I can't choose numbers like that with the daq.

[TomEng]

I solved my original problem!  The issue was that while they seemed identical, the real input was not a pure pulse so it could not be processed the same way as the theoretical generated pulse.