Quote:
Originally posted by moyalt
HELLO HUNTER,
Firsti wanne thank you for your caring and help.
My samples of data base are samples that have to enter the database file every time , i'll explain :
The datalogger system I'm connected to is a control system of gas turbine motor , the datalogger systm show the inputs coming from the sensors of the gas turbine in real time , but the sampling rate of my program (which is max by the way) is 70 inputs (sensors) for half a second - in 1 second i sample this 70 sensors twice.
this database file has to keep all the sampling for future analyzing - graphs... the database has to include this next fields : exact time , date , sensor name , sensor value .
if you could help me i will be more than greatfull.
TOMER.
OK, First off, Gas Turbines fascinate me. I have done some engine testing (Two Cycle Model Air Plane Engines) First let's look carefully at your data structures, and let's spend a bunch of time thinking before we begin saving tons of raw data. You should probably forget the idea of a database in favor of a sequential read/write file system. You should probably consider using the actual file record number as a clock reference, and you should probably think carefully about how to minimze each record's file size. Here are my thoughts: If you are running 24 hours a day seven days a week then you are going to need massive storage capability, but I am going to assume that you are limiting your trials to fixed periods, even if they are a day or two in length. If you reserve the first n bytes of a random access file as a "Header" and your data alway begins at say byte 1024 or 2048 and in the header you have the exact time that the trial began as well as any other parameters that you need to save with it, and you sample data at exactly 70 samples per second then any given sample's relative time to the header's time is a function of its relative position in the file. (This is the exact way .WAV files are constructed, except they have two channels and 44,100 samples per second). Secondly you need to determine the smallest possible resolution that will correctly convey your sample. ie will a byte do it, or do you need an integer or larger value? If you are measuring RPM and the normal operating RPM range is 40,000 to 70,000 then do you need to measure values below 40,000 or above 70,000? If not then you can subtract 40,000 from your actual value and use an integer to represent your data value...If you want to compress your data value even more then you can determine the maximum acelleration/decelleration of your turbine and then record the beginning RPM in the header and then only record ds/dt, probably a byte in the preceeding example. The down side to these types of compression is the amount of work that you need to do to create a front-end, the upside is that you can compress tons of data into a very small memory map without loss of resolution. A great example would be MP3 Files VS WAV files. 