-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2005-11-24 at 13:18 -0000, JUAN ERNESTO FLORES BELTRAN wrote:
You still haven't said what sampling speed you need, but unless it is slow, you will need to save somewhere else first (as fast as posible), and then move to the database as a post process.
Sampling speed will be as slow as possible because of this is a project for the university...not a product for anyone so speed is subject to the designer programming skills and available resources: adquisition data card specifications, programming language, etc...
It is rather the other way round: you know what speed you require, then define what hardware/software requirements you need to meet it. Supposing you are to measure some sort of experimental data, like engine speed/accel: then somewhere about ten samples per second is enough. If you are measuring oven temperatures, then one per second or per minute. If atmospheric weather, one per quarter/hour, say. If you want to measure an audio amplifier response, I'd be happy with a million samples per second. It depends on what you need! You will find that sampling and storing data for a dozen channels at 10..100 K-s/s, non stop, quite taxing. That is withing the capabilities of a standard daq card. And related to that is the precision needed... 12bit is typical in industry, 16 bits is more expensive, 8 cheaper (and for home use, really). 12 bits is roughly equivalent to what a 3 1/2 digit multimeter gives.
just to get an idea...what limit is considered "too fast" to save somewhere else before saving into the database??
¡Test it! It will not be real time, in any case. Real time means that the response time is guaranteed to be below certain value, by the way, that's the most important characteristic. You can not use a database like that and give that guarantee. You can, however, simulate a test run, send data to a database at a fixed continuous rate for some time, and measure unexpected delays. You will have to define how exactly are you going to save the data, what format: one sample per register or a thousand, or the whole experiment in one register.
and what technical reasons would force me to do this in case sampling speed increases where neccesary?? is this subject to any mysql or postgresql managing/storaging data limitations??
I'm no expert in databases! X-) But they are certainly not designed for a continuous data flow storage, non delay, non stop.
Any link, tutorial or manual to get inmersed into real time data handling?? would be helpfull!!
I don't have any... I had to learn it on my own. What I did, roughly said, was to program the ISA card (that's what we used) to measured the channels and call an IRQ, at a fixed rate. An IRQ handler routine would save the data (a word) in memory or save to a file, raw. This could be an independent resident program (that was in Dos). Another routine, in the foreground, would read the data, filter it, process, display, perhaps even react to it, whatever. The card manufacturer supplied several code samples, from simple polling routines to irq or dma read. Later they supplied a driver that did all the dirty work, I only needed to call up the setup functions. I usually worked with Advantech cards, rather common here and not expensive (except for a hobbyist), meaning about 10 times less than National's. There are many more manufacturers, you will have to search around, depending on your requirements and purse. National people were usually helpful, they could give you sound advice using their software and hardware depending on your needs: not cheap, of course. Don't forget when looking around what kind of software and sourcecode samples they include, it makes a very big difference. And that that code was tested in Linux! ;-) I'm not sure how I'd do it in Linux, but I'd like to have a device driver that would copy data to a file or stream at a fixed rate. Probably it exists already. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDhl1ktTMYHG2NR9URAhQpAKCT8/t+vKiTt/nNpRReKo3N3/YRHACfRR8j nvk51LHpbH2FHO/4CKfvEu4= =MdL7 -----END PGP SIGNATURE-----