9802 in FPGA Mode

[DominicRoberton]

Hi All,

I am having some significant issues in recording data to the 9802 module using two 9074 cRIO controllers connected across a network.  I shall try and keep my post concise but will give you some background.

I am recording data across 96 strain channels and 8 accelerometer channels at a rate of 800 samples per second.  Currently there is one 9802 module with the data from the second 9074 module being sent across a network link, on the cRIO with the 9802 I am also recording GPS data and adding that to the data stream along with the recorded sample number for synchronisation purposes.  I have worked out that I am collecting about 334 Kbytes a second (Based on the data in the FPGA example being I16 format) .  This may be a problem, but I am not 100% sure how to drop the data rate down, ideally I'd convert everything to 8bit data but I don't know what the knock on effect of this would be, I don't have a huge amount of experience with this stuff.

Initially I tried a .tdms format, the data was very successfully written onto the SD cards (Kingston 2GB), however it was writing to slowly, therefore the memmory on the RT would run out and the system crash after collecting about 6 minutes of data.

Having read the various different posts I decided to go down the binary file format and try both the RT and FPGA options.  

The RT method causes the sytem to slow down significantly after a short period, before apparently locking then suddenly continuing as normal. (I have a control on the User1 and FPGA light which flashes with the programme - these start flashing eratically, then slowly, then theypause, before continuing as they should).  Having put a wave form chart showing the available memmory on the RT system I can see that the available memmory drops steadily until the system locks out, when it restarts the available memmory rises again to a much higher, but not the maximum value.  Unfortumately the system needs to be able to be left to run for a minimum of 10hours before erroring out so I am a bit worried by the system locking up.

The FPGA method seems to be the fastest to write, and certainly with this method the RT system never runs out of memmory, however the SD card never seems to write any data past the initial file setup...  In summary, the data is pulled from the 6 strain and 1 acceleration module into the RT system through a FIFO, combined with the GPS data and then put back into a FIFO having been flattened into a string and converted to a bite array.  This occurs every half second, or at least is programmed too.  If I probe the "Data" input in the FIFO Write I can see the data going in, unfortunately the FIFO read is in the FPGA, so I am a bit stuck as to how I can debug this end. 

I have attached some images, the "Data FIFO to FPGA SD Card" and "Data to FIFO-Write" refer to the FPGA file write issues.  The "RT Binary file" refers to the RT file write issues.  I will post up the file handler.vi in a second.

So in summary I have the following questions:

1.  What will the knock on effects be of dropping down the data type from a 32 bit single precision....  I am getting a bit confused with the whole byte/bit thing!

2.  I would imagine someone has managed to implement the FPGA write successfully, how!?

Cheers,

Dom

[DominicRoberton]

Here is the File handler vi

[DominicRoberton]

Also,

It's worth adding that I was trying to understand the different byte/bit data rate / SD card ratings whilst posting this so am a bit confused right now.

The SD cards I have appear to be rebadged Toshiba cards:  http://www.toshiba.com/taec/Catalog/Product.do;jsessionid=D03241009944C8943266B6197E0ADF4F?productid...

[DominicRoberton]

Bump

[Ashish_Naik_NIUK]

Hi Dom,

Thanks for using the NI Forums!

By changing the data type, we essentially change how much data information can be represented by this number.

Each datatype can be represented by 0 and 1s. For instance a 8 bit number will be represented by 8 0/1s. Whereas a 32 bit number can be represented by 32 0/1s.

If we take the example of an 8 bit number. This can be represented on a binary level as 00000000 = 0, and 11111111 = 255. Therefore by changing the precision to 8bit data, the largest number we can represent is 255.

The following links may help in the understanding of this

digsys-02: Bits, Buses, and Binary Numbers - http://decibel.ni.com/content/docs/DOC-5861

Computer Numbering Formats - http://en.wikipedia.org/wiki/Computer_numbering_formats

As for being able to get the writing up and running with the 9802. I would like to refer you to the built in examples for the 9802. These should be stored locally on your PC at C:\Program Files\National Instruments\LabVIEW 2010\examples\CompactRIO\Module Specific\NI 9802

Please let us know if this helps,

[DominicRoberton]

Hi Ashish,

Thanks for your reply.  I have had a look through the examples and have some other example code available to me, the problem I am trying to understand is how I can convert to a small number, ideally U8 for data storage, but still give me enough accuracy to be able to interpret the micros strain and acceleration of my system through post processing.

I need to be able to record for 10 hours over 107 channels at 800hz with 4GB of data storage....

[Ashish_Naik_NIUK]

Hi Dom,

Well this depends on what resolution you are going to need, and over what range you expect these values to come back at? Are the values always positive or may include negative values?

As a quick calculation for the rates you are discussing :-

28.8 MSamples per channel over 10 hours.
3.0816 GSamples over 107 channels over 10 hours

If we use a 8bit datatype (U8, or I8) - this will be approx 2.87 Gb (slightly smaller due to the 1024 conversions!)

If we use a 16bit datatype (U16 or I16) - this will be approx double the 8bit info and too much for your memory storage!

By using a 8bit datatype, the largest range of values we can represent is (2^8)-1 and therefore 255 values. Will this provide enough resolution for your data?

[DominicRoberton]

Hmmm....

Well, this is where I am a bit confused.  I am happy with an accuracy of around 1%, but I am not 100% sure what my range is likely to be, unfortunately I haven't been able to test the system in the extreme environments yet.

The calculations I have done suggest an expected strain range between 0.05% and 4%, however I really doubt that second figure, I wouldn't expect it to be anywhere near as high.  I honestly wouldn't expect anything over 1% before material failure.  I've just got off the phone with the guys who installed the gauges, and they normally use 16 bit resolution.  So I may start with that....

So I guess the next question is I16, U16 or a fixed point number?

[Ashish_Naik_NIUK]

Hi Dom,

I hope you are well. Thanks for your message. Let me see if I can explain myself further.

Unsigned data only allows us to display positive values. Signed data uses one of the bits to decide if the data is positive or negative, and therefore can represent both + and -.

Unsigned and signed only allow us to display whole numbers. Therefore we would need to do our own custom scaling when writing to file, and then the reverse when reading from file.

I have calculated the datastorage from the previous calculation in my above post of the 107 channels at 800Hz over 10 hours.

DataType	Minimum	Maximum	Delta	DataStorage
Unsigned8 (U8)	0	255	1	~2.87Gb
Signed8 (I8)	-128	127	1	~2.87Gb
Unsigned16 (U16)	0	65535	1	~5.8Gb
Signed16 (I16)	-32768	32767	1	~5.8Gb
Fixed Point	Variable	Variable	Variable	Variable

Fixed point allows us to decide ourselves how much information is being used to represent integer numbers or how many is being used to represent decimal information. Fixed Point also has some caveats with what conversions and analysis functions we can use on the FPGA.

[DominicRoberton]

Hi ashish,

Those numbers you have calculated are similar to those I calculated, so happy days there.

To make this a bit easier I am going to look into doing the conversion from mV to strain on the FPGA target rather than in the post processing so I have a better idea of what resolution I'll actually need.

Looks like I'll have to wait until I start getting some numbers in before I can really work out what the best format is going to be.  I have some more opportunities next week to get some data.

Cheers for your help,

Dom