cRIO with NI 9237 Bridge Module in Scan Interface and Anti-Aliasing

[AndyClegg]

Hello,

I have question about using an NI 9237 Bridge Module with CRIO and its operation in Scan Interface mode. The manual talks about the data rate for the module, and a parameter (n) that can be set to adjust this (down to a minimum of 1613 Hz) which in turn scales the module's built in anti-aliasing filters. It appears (but not explicilty stated) that this data rate setting is only available in FPGA Programming mode.

Our application currently works in Scan Interface mode, so my question is what is the module's "data rate" (and hence anti-aliasing filters) when in Scan Interface mode ? And, if we have the scan period set to 10msec (100 Hz), is there any software anti-aliasiing filtering provided automatically by the scan interface itself related to the scan period ? Or is any additional anti-aliasing something we have to build in ourselves ? I have looked at the provided example using Scan Interface and there isn't anything additional.

I do understand about aliasing, just need clarification on what happens for this specific module in Scan Interface mode.

Thanks,

Andy

[markwhiteley]

Hello Andy,

You are correct in assuming that this data rate setting is only available in FPGA programming mode (there are two separate configuration modes for the FPGA mode and the Scan Interface) even though it's not that clear in the manual.

The modules "data rate" is determined by the scan period which typically is never lower than 1 ms and so the rate at which your data would update across all modules would be 1kHz (as mentioned here). It seems that from the data sheet as you have probably seen that the aliasing available to your signal is then = 0.45 x "data rate", giving you an alias-free bandwidth of 450Hz. There is not to my knowledge any software anti-aliasing filtering provided automatically by the scan interface itself that relates to the scan period. However, providing additional filtering is something you can do programatically using the filter functions available to you in the Signal Processing palette in LabVIEW.

I hope that has helped to answer your question!

[AndyClegg]

Mark - thanks for the prompt and useful reply.

Just to confirm - since the data rate is derived from the scan period, how does that work with the minium data rate of 1613 samples/sec, which from reading the manual seems to be fixed within the module ? Hence why I was wondering about additional software anti-aliasing filters when sampling slower than this. Our scan period is 10msec (100 samples/sec), so I am unsure if the anti-aliasing filters cut-off will be at 0.45x1613 = 725Hz or 0.45x100 = 45Hz. Or, are you saying that this module should not be used with a scan period of anything slower than 1msec, to ensure the anti-aliasing filter (725Hz) is inside the sampling frequency (1000Hz) ?

Regards,

Andy

[markwhiteley · Accepted solution]

Hi Andy,

I had to have a quick sleep on this overnight to get my facts straight, hope the delay wasn't too long!

The minimum data that is listed at 1613 samples/sec is due to a forumla that uses the internal time base that is pretty well explained on on the 20th page of the manual.  The scan period does not affect the data rate, or in turn the anti-aliasing filter. My previous post was wrong in this sense, apologies!

This page helps to explain scan mode quite well too, but the best way to explain it is that even though the frequency of the module may be set at 1613 samples/sec or higher, the compactRIO will only collect 1000 of those samples a second, or in your case if you are using a loop rate of 10ms, 100 of those 1613 samples. The anti-aliasing cut off will be based off 1613 x 0.45 as you pointed out and so will be at 725Hz (not based off the loop rate as I wrongly mentioned)

In this case with these modules it's probably a good idea to not use a scan period slower than 1 msec for that reason that you have pointed out - if you are worried about oversampling you can always decimate you readings in software afterwards to take every 1 in 10 readings (this page explains how to do it with an eerily similar situation!)

[AndyClegg]

Mark - I appreciate your helpfulness.

If we keep the scan period at 10msec, then we could see some aliasing. The impact of this isn't known since we haven't really got a clear understanding of the frequency content of the signal - it would be negligible for some types of signal due to low noise, but as this is a load cell for a force control loop it may be significant hence my concern to properly understand what is going on. It would seem that our best/simplest solution is to just move to a scan period of 1msec, such that the module's built in anti aliasing filters can do their job on the sampled signal, and just decimate the samples used within the control loop.

Thanks,

Andy

[AndyClegg]

Mark - just a quick point to confirm. Since the scan period is not linked to the module's internal data rate - does the data rate (and hence anti-aliasing filters) automatically get fixed to 1613S/s (i.e. the lowest value) when used in scan interface mode ? Thanks,