Open source data acquisition system. - Page 1
Forum section: electronics / general

author: kamilian
author_rank: Newbie
timestamp: January 27, 2012, 12:38:11 am
content: Hi Dave,Hopefully you had a good Australia Day in spite of the weather! I've been considering mentioning this for a little while, as much as I need help with the project I got the impression you'd be too busy to get involved. However, seeing as you've mentioned looking for other revenue streams elsewhere on these forums then you may be interested, so I'll put it out there and see what happens.Quick introMy background is engineering (mech/aero) in roles involving data acquisition and analysis. I've used a few (not many, but a few) acquisition systems and seen good and bad points in them, as well as other things I've seen along the way that I thought may be useful in such a system.The projectTo develop an open source data acquisition system incorporating what I'd picked up from previous experience. I wanted a minimum of 8 simultaneously sampled channels at various rates up to 48 kHz (for recording sound) with a minimum resolution of 16 bits. Of course 8 channels is for a single device with the possibility of having multiple devices providing as many channels as the available resources allow (bandwidth, etc). In doing so I had two main aims (the first I believe I've now achieved):To prove to myself that I could understand what was going on at more of a theoretical level.Complete the project and release it as open source.An overview of what I've doneInterfaced three development boards: a microcontroller, an FPGA, and a Delta-Sigma ADC.Designed digital filters using GNU/Octave.Developed software for the FPGA in VHDL to perform digital filtering.Created a simple package manager (it doesn't really manage, it just compiles source) to create a toolchain under GNU/Linux.Developed software for the microcontroller in C/assembly including a simple UDP/IP stack.Written a (very) basic console application to communicate with the microcontroller.Performed a quick calibration (to prove that functionality works, it's not a good calibration).Acquired some data at the various sampling rates.What still needs to be doneLots, probably!Topics you may be able to cover in blogs (I'm not sure if you've covered any already)Selection of ADC/FPGA/uC.Signal conditioning and anti-aliasing.Digital filtering and filter design using GNU/Octave.VHDL and implementing a digital filter in an FPGA.Toolchains and programming uC's.Networking, UDP/IP, etc.Board layout (analogue/digital).Calibration?I could go in to more detail but I'd prefer to do so in a less public fashion for now. I'm also located in Sydney which means it shouldn't be a problem to demonstrate what I've done and discuss things further if there's any interest!

author: Jimmy
author_rank: Regular Contributor
timestamp: January 27, 2012, 10:32:32 am
content: I am looking at doing a project that will do all that and serv it all up on its own web server with a budget of about $80I would be interested but I live in Brisbane so creating somewhere that we can calibrate ideas would be good.

author: Unknown
author_rank: Unknown
timestamp: January 27, 2012, 11:02:53 am
content: I think we are probably working on the different aspects of the same thing. My work revolves more around mechanical issues like form factors etc. I'd like to know more about your work but Dave's recent experience showed us that disclosing ideas prematurely might not work all that well. You might consider sending private messages if you like.

author: kamilian
author_rank: Newbie
timestamp: February 02, 2012, 10:24:00 am
content: Apologies for not replying earlier...I was originally going to contact Dave privately, then stumbled on to the suggestions thread and it got me thinking about what topics Dave could talk about in the videos. At the moment I have information revolving around digital filtering (including CIC decimation, Hogenauer 'bit' pruning theory, and FIR filtering), GNU/Octave scripts for designing the filters, and shell (sh/bash) scripts for creating input files for the FPGA assembler. I also have what I referred to as the 'package manager' which is a shell script and build files to create the toolchain, including openocd for programming. At least some of which I thought would make it easier to create blogs based on those topics!As HAL-42b brought up, it's very early days. In an ideal world I guess sharing ideas and trying to get it right to begin with would be the way to go. However, I think it would be best to have a full working prototype (even if it's a bit hackish) before sharing anything. My plan was to get what I would consider a beta version (for both hardware and software) so that I could create a project page with theory, instructions, and proper revision control for the various files. After that, even I have a number of ideas to improve it so no doubt plenty of other people would too!There's a couple of things I need to do to get to that point though...The first I'm working on is robust communication. I have some ideas to find a good compromise between performance/robustness but it would obviously be nice to talk to someone with more experience in network programming.The other is getting a single PCB with all the components on it, which is a bit more in depth and without an electronics background it's a bit out of my depth. I always knew if I got to where I am now I would need to talk to an electronics engineer (or possibly an expert going by the thread on people calling themselves engineers) about it. This also includes the signal conditioning, which I believe I have a unique concept for, at least I haven't worked with data acquisition systems doing the same thing. Maybe it's nothing special, but just maybe it's a good idea, and someone with more electronics knowledge would be better able to answer that question.

author: Unknown
author_rank: Unknown
timestamp: February 02, 2012, 12:47:05 pm
content: Quote from: kamilian on February 02, 2012, 10:24:00 amIts only that Dave's opening up of his project led to unexpected amount of unpleasant comments generally along the lines of "you are using wrong electrons, my electrons are the only correct electrons". There were a few useful comments but it was not worth all that trouble. Maybe it was because the entry threshold for a power supply is quite low. With more complicated projects the outcome may be different, who knows.Quote- USB is the most widely used one over short distances, not particularly robust.- Ethernet is popular and cheap. Real-time data may be problematic though.- Rs488 is reasonably robust if a bit old and bulky- SpaceWire can be very robust, has many speed levels, has redundancy, handles realtime data, the specification is open but there are curiously few implementations outside of aerospace industry, maybe cost is a factor.

author: Unknown
author_rank: Unknown
timestamp: February 02, 2012, 08:44:09 pm
content: Quote from: HAL-42b on February 02, 2012, 12:47:05 pmThat's what you get when announcing it to the world to a few thousand (?) Youtube subscribers. With that kind of audience, you can expect a lot ofbikeshedding. Plenty of community design projects seem to be able to do without the unpleasent comments, but they also have much less exposure than Dave.Quote from: HAL-42b on February 02, 2012, 12:47:05 pmIs USB much better for real time? Average latency for uncongested Ethernet can be down to < 1 ms or so. I seem to remember that USB only does one frame every millisecond or so, though USB high speed may be better.Quote from: HAL-42b on February 02, 2012, 12:47:05 pmRS-488? IEEE-488? I wouldn't recommend implementing this in a new design, except for a one-off if you have all the interfaces and cables available. The dedicated IEEE-488 transceivers are no longer commonly available, and I don't think there are standard IEEE-488 stacks for common platforms. Is there an open-source Arduino or PIC IEEE-488 lib? Or an implementation for an FPGA? It's quite reliable, and latency (especially worst case latency) will probably be much better than with consumer-oriented protocols like USB and Ethernet.Quote from: HAL-42b on February 02, 2012, 12:47:05 pmNever heard of it, but I'm not in the aerospace industry. There are probably plenty of high-performance, niche interfaces out there. I would try to stick to something mainstream, especially if you want a wider audience to use it. At some point it has to communicate with a PC, and that either involves building another piece of hardware to translate it to something common like USB, or an expensive piece of commercial hardware.This basically limits it to USB and Ethernet in my opinion. USB is probably easier to implement, although Ethernet MAC/MIIs and TCP/IP stacks are also readily available. Not sure about throughput. For Ethernet, I would move most of the intelligence to the PC, and use a basic UDP/IP or TCP/IP protocol between PC and DAQ. With Ethernet, 1000baseT is standard in the PC world, but I'm not sure how easy this is to implement in an FPGA/uC. If performance is critical and you're using a big FPGA, PCI-express might also be an option, no idea how hard to implement this is. It's probably hard to debug due to the high clock rates involved. It will probably make the PCB much more expensive to produce.What would be the important parameter, latency? Throughput? Guaranteed latency? USB and Ethernet will probably suck for the latter, but should be able to achieve decent throughput and OK average latency.By the way, I think you should use holes, not electrons.

author: kamilian
author_rank: Newbie
timestamp: February 04, 2012, 12:23:30 pm
content: Quote from: HAL-42b on February 02, 2012, 12:47:05 pmAh, I've seen a few posts in other threads regarding unpleasant comments, but haven't actually seen the comments themselves. If it's more complicated it could also make things worse, more things for people to comment on...Anyway, it's still here if he'd like to consider a new project and I think there's a number of video blogs that could be a result of it. Some or all of the topics I mentioned in the OP could be subdivided to provide quite a few videos even before you get in to revision updates, bug fixes, and new features down the track! If not then this thread may be better off in the project forum, although it's probably a bit to early in the project for that one.Quote from: HAL-42b on February 02, 2012, 12:47:05 pmI apologise, I was a bit ambiguous in my post although it was interesting to read about SpaceWire!I've already chosen to go with Ethernet, one of the systems I've used before was Ethernet based and I thought it would be a good, proven technology with a number of benefits. For example, it shouldn't be difficult to get long cable for longer runs or even buy the parts and crimp tool to make cables of a specific length, which would be better than USB. It has readily available hardware and most computers these days would probably have a network adapter already, which is better than SpaceWire and RS-488.What I mean by "robust communication" was that I've chosen to go with UDP rather than TCP as I didn't know if the overhead of TCP would be acceptable, and could hopefully achieve functionality similar to TCP (taking in to consideration there's a finite buffer, so if a datagram doesn't arrive and can't be re-delivered then too much is being asked of the system).Quote from: alm on February 02, 2012, 08:44:09 pmAnd I've already limited it to EthernetI've mentioned some advantages, including cable lengths which is a big one over USB (I think). From memory you need boosters/repeaters or something similar at greater than 10m, and for another system we used Ethernet cables much longer than 10m!More importantly, however, the microcontroller I selected only has full speed (12 Mbps) USB which isn't fast enough, 100 Mbps Ethernet is!Anyway, the most important parameter is data integrity, my aim was not to get absolute real-time communication. By that I mean that sending datagrams at 48 kHz seems excessive for the system, and increases the required bandwidth significantly due to overheads. For example (with 8 channels), sending 1 sample at 48 kHz you'd be looking at more than 3 times the data than sending the maximum 45 samples at 1067 Hz (about 5.2 MB/sec vs 1.6 MB/sec). My plan was to have the microcontroller determine the best datagram size depending on sample rates (if all channels are a low sample rate then it would best to send datagrams as fast as possible but not exceeding the maximum of 1067 Hz). Hopefully that makes sense, it considers 10/100base-T Ethernet and an MTU of 1500 bytes which is enough for one device (and then some).So far I've written my own basic UDP/IP stack to get the most out of the DMA controller (within the microcontroller), I found lwIP didn't seem to play too well with it. I've gone with IPv6 as I'm expecting it's adoption will improve over time and it makes some things a bit easier (link-local addressing, neighbour solicitation/advertisement, no IP checksum, etc.). Overall it's going well, I need to fix some small things such as network endianness for some of the data sent back and forth (it should all be network endian except the actual data, I'd like to be able to change between little and big endian to suit the controlling machine's endianness). However, as I mentioned I need to sort out a decent method for robust data transfer over UDP, ideally it should always arrive, but if the system is too slow then it should fail gracefully and never think everything's okay when it isn't!At the moment my plan (some of which is just what I already have, but I'll try and explain in enough detail) is to have an array of static datagrams in the microcontroller's memory. These are prepared before any data is acquired (headers filled in as much as possible), and then filled with data and sent while acquiring data. They'll have an index indicating which datagram they are in the array, as well as a sufficiently large sequence number. Having a similar array of buffers on the controlling PC means it can store the datagram in the appropriate buffer, and if the sequence number is wrong, re-request the correct datagram. Hopefully that way it only needs to request datagrams that didn't arrive. If any device n the network can't handle the request (the sequence number doesn't exist anymore meaning the datagram has been over-written), then the system can't handle acquiring that much data and it tells the controlling PC to stop.

author: Bloch
author_rank: Unknown
timestamp: February 04, 2012, 01:56:37 pm
content: Quote from: kamilian on February 04, 2012, 12:23:30 pmIf the need for real-time communication will change then take a look at EtherCAT.Overviewhttp://www.ethercat.org/en/technology.htmlHow hard it is to program with a microcontroller i don't knowBut it is one of the best communications "protocols" i used at work. And it is "open/Free"

author: Unknown
author_rank: Unknown
timestamp: February 04, 2012, 04:06:47 pm
content: IPv6 should be fine, almost any modern OS supports is out of the box, and many will configure at least link local addresses by default.I would be hesitant trying to build my own (semi)-reliable transport over UDP. Many implementations attempting this, like NFS, suck compared to TCP. It does not sound like you're maxing out the bandwidth, so across local networks you shouldn't have any performance issues. The bottleneck will most likely be limited by your embedded device, since modern networking hardware can get very close to wire speed. By designing for high latency/packet loss, you may be trying a problem that does not exist. I would try TCP first and see if this performs well enough. If packet loss / out of order arrival turns out to be an issue, you might look into SCTP or protocols designed for audio/video streaming. The advantage of using standard protocols is that debugging and testing is much easier. Most of the problems these protocols are trying to solve involve transport across a high-latency, unreliable and possibly congested Internet, however.

author: Unknown
author_rank: Unknown
timestamp: February 04, 2012, 08:30:25 pm
content: kamilian,as you are already settled on Ethernet I'd like to ask what were the good and bad points of the existing systems that you mentioned in your first post. There are communication protocols working over Ethernet that are specifically geared towards data acquisition.Precision Time Protocol (PTP) is one that you'd probably want to implement as is.Quotehttp://en.wikipedia.org/wiki/Precision_Time_Protocolhere is the full standard:http://www.isdcr.gov.vn/IEEE%20PTP1588v2-2008.pdfAnother interesting one is LXIhttp://en.wikipedia.org/wiki/LAN_eXtensions_for_InstrumentationThis one does exactly what you want to do, however I should warn you in advance, its use in open source projects is an uncharted territory likely to turn into a legal quagmire. There are two major lies postulated about LXI, the first is that it is a standard, the second is that it is open, LXI is neither of these. It is not a standard but an industry specification hoping one day to become a standard, however 60% of the spec is full of marketing blurb, even the LXI name is copyrighted so go figure."Open" on the other hand, in the lingo of the marketing types with goatees means that you are allowed to see what you are buying. It has absolutely nothing to do with the notion of open source hardware. You are required to pay money in order to enter the club and still more money to get your product certified.The best way, if you ask me, is to study the LXI documentation, learn the standards it is based on and adopt these while disregarding or circumventing the marketing blurb.

author: ejeffrey
author_rank: Super Contributor
timestamp: February 05, 2012, 09:33:27 am
content: Quote from: alm on February 04, 2012, 04:06:47 pmI would second this. Modern TCP implementations are excellent, almost certainly better than you will do with UDP with a home-rolled reliability layer on top. TCP has good performance on a LAN with reasonable scaling to long distance links. UDP performance may look good under 'laboratory' conditions where you don't have any contention and only a tiny number of dropped / delayed packets. As soon as you run in a real environment things become a lot dicier.Also, don't make the mistake (many ethernet instrument makers do) of thinking your device only has to be usable on a LAN. While 95% of the time that is true, it should be possible to use it over the internet. Some instruments do stupid things like disabling the default gateway with no documented way to turn it back on!

author: kamilian
author_rank: Newbie
timestamp: February 07, 2012, 12:01:24 pm
content: Quote from: Bloch on February 04, 2012, 01:56:37 pmThat's an interesting protocol. At one point I was wondering about using Ethernet frames without any TCP/UDP/IP headers as it wasn't a necessity with what I wanted. I'm guessing without an IP address it would make sending across the internet impossible, but I'll talk about that later as someone else mentioned it.Thanks!Quote from: HAL-42b on February 04, 2012, 08:30:25 pmGood question, now you're trying my memory!The first system I used was about 10 years ago from National Instruments using LabVIEW and I think a NI-DAQ PCMCIA card. I would suggest an obvious downside with that is the PCMCIA interface as I have no idea how you could use that with recent hardware. I'm not saying it can't be done, but something like Ethernet is pretty much standard on any new laptop/PC/Mac/etc. and I think it'll be here for a while yet.The most recent system I used was while I was working in a wind tunnel over in the UK. If you do a Google search for "mistral site:cosworth.com" (without the quotes) there's some information about some of the products we used. It was a wind tunnel designed to have a full scale F1 car in the test section which should give you some idea about the size. We had the IJB's (you should get a result in Google for an IJB10, we used the IJB7 I think, just a few less slots for cards) in various places, connected by Ethernet to various switches, with some cable lengths probably 20 or so metres. Anyway, when they work as advertised (I believe they were getting on top of issues around when I resigned, so they may be spot on now) they do a good job. They probably implement IEEE-1588 as they have no common clock, just the Ethernet connection for timing. The biggest issue would be the 200 Hz sample rate. It's fine for a wind tunnel, but obviously you can't record sound with that!Generally, most of the issues I saw revolved around signal conditioning which I'd prefer not to go in to just yet.If you get a chance, give that Google search a try, you may find some of the info interesting in relation to the work you mentioned earlier (hopefully!).Quote from: HAL-42b on February 04, 2012, 08:30:25 pmI looked in to that shortly after I got the microcontroller! The one I selected (LM3S9B92) doesn't have hardware IEEE-1588, while a similar one (LM3S9B96) does. However, I didn't convince myself it was accurate enough (I realise the claim is sub-microsecond accuracy), but my main concern was possible restrictions on hardware and/or topology. For example, it would be possible for a setup to have a number of switches and some devices to be more switches from the controlling computer. I noticed there's IEEE-1588 aware hardware, but even if that made it work it would put restrictions on what hardware could be used. Additionally, I thought if wireless bridges were used it might make a PTP implementation less accurate. For starters I thought it would be best to have all devices run off a single clock, although it would be worth using the LM3S9B96 with hardware IEEE-1588 in case it could be implemented down the track. It'd be ideal to have completely wireless devices (only requiring a local power supply and connection to sensors, etc.) communicating with the controlling computer.Quote from: alm on February 04, 2012, 04:06:47 pmQuote from: ejeffrey on February 05, 2012, 09:33:27 amI like the idea of implementing TCP at some point as it would be nice to have telnet capability for statistics, etc. When I looked at various sources (Wikipedia, lwIP source, etc.) it seemed that TCP isn't really designed for streaming data. Sure, it sends data reliably across networks and the internet, but it's more a case of sending static rather than dynamic data (i.e. a file rather than a stream of data). At least, that's the impression I got, I could be wrong on that one!I did look at various protocols, including SCTP and RUDP, however, I thought it might be possible to come up with a method that was a bit simpler, even though it'd be specific to this application.As much as I'd like to be able to, it might be a bit of an ask to send data sampled at 48 kHz across the internet! At the moment I have 16 static buffers with enough for 45 samples each (as it's a 1500 byte Ethernet payload) on the microcontroller, which corresponds to about 15 ms of data. If the controlling computer needs data to be re-transmitted then the buffer on the microcontroller would have been overwritten if it takes more than 15 ms from when that data was sent for the request to arrive. It might not be the same thing, but I get 30 ms just to the first hop after the modem/router from my PC.It might be possible, but I'm thinking it would need more RAM and more buffers to handle longer round trip times?

author: amspire
author_rank: Super Contributor
timestamp: February 07, 2012, 01:09:48 pm
content: UDP is faster then TCP, and it can be just as reliable. OpenVPN is a great example of a rock solid UPD communication.The only issue about UDP is it is up to the application to manage integrity, not the interface to manage integrity. Quite often, if packets are being lost, then with UPD the application can decide which lost packets it doesn't need. Also an application using UDP is able to maintain the streaming even when packets are going missing, whereas TCP will slow right down when packets are lost.The truth is that within a local network, the loss of packets should be extremely close to zero, and over the Internet, a 1% packet loss is considered really bad. As long as the application can tolerate the very occasional missing package, UPD is great if you need speed, and a consistent streaming of data.UDP is very vulnerable to spoofing attacks, so if security is a concern, the UDP based application has to check that the sender's IP address in the incoming packets is actually coming from the machine with that IP address.Richard

author: ejeffrey
author_rank: Super Contributor
timestamp: February 07, 2012, 01:45:40 pm
content: Quote from: kamilian on February 07, 2012, 12:01:24 pmIt isn't really designed for streaming, but it can do so rather effectively. UDP is only really good if you can tolerate a lost or out of order packet. For instance, some although not all streaming protocols use UDP and just display glitches or dropouts if a packet is delayed or lost. This is OK for live video, but unacceptable in almost all instrumentation system.QuoteProbably more trouble than they are worth, although SCTP is interesting in that it allows multiple streams to be multiplexed over a single connection. You don't get the universal support you have with TCP or UDP, so I wouldn't bother.QuoteYes.Quote from: amspireOpenVPN uses UDP because it expect TCP to be run on top of it, which provides its own reliability layer. They don't use TCP not because it is intrinsically slow, but because implementing nested retransmit/congestion control implementations on top of each other interact badly. OpenVPN does not actually provide any reliability guarantee at all (at least for data packets) -- it relies on the overlaying TCP implementation (if one exists) to do that. If you run a UDP based application across an OpenVPN link you will definitely get dropped packets.I will say it again. Modern TCP implementations are very, very good. They can utilize close to the maximum link bandwidth, and they run as well as possible across congested / degraded links. If you need in-order, reliable delivery of data you should absolutely start with TCP. The chances that a home-rolled protocol to implement reliable in-order delivery over UDP will outperform under sort of normal LAN environments is very small.In any case, the OPs requirements are modest. There is no problem streaming 48 kS/s over a LAN via TCP.

author: BobC
author_rank: Unknown
timestamp: April 12, 2012, 03:26:06 am
content: Just stumbled across this thread, and seeing that I have an extra $0.02 in my pocket, here goes.The first step in any DAS (Data Acquisition System) design is to have a few specific use-cases in mind to limit the solution space. We don't want to guild the bikeshed!While Open Source software has a zero cost of replication, hardware most certainly does not! Any Open Source DAS should have a primary goal of making dirt-cheap hardware do wonderful things.If you are going to have an 8-sensor or 16-sensor system, using Ethernet for the sensor interconnection medium is silly. The software would be free, but the hardware might as well be Unobtanium.What is the cheapest interconnect medium for digital data? Since we'd like our sensors to be able to have significant cable lengths, and we'd like our long cables to also be cheap cables, it would seem a slow-ish protocol is indicated, preferably one that can be piggy-backed over the power line. While Ethernet can do this via PPoE, that would substantially increase the system cost. I2C, RS-485/432/232, and CAN are all able to combine delivery of power with transport of data, and all are fairly inexpensive, since each can be implemented using 2 or 3 wires (if you squint a bit).To minimize communication hardware costs, we should choose a protocol that is directly handled by dirt-cheap microcontrollers and a single power supply, which limits the choices to I2C, CAN, and TTL-level serial.How do we get the data to a PC? USB wins here, since a large number of microcontrollers also come with this interface, and it can also be used to power the entire DAS, providing the immense benefit of eliminating the need for a separate power supply.An amazing number of sensors are available with I2C interfaces. For example, a temperature or pressure sensor could easily be implemented by directly soldering the US$2 I2C sensor chip to the end of the cable. It is hard to make a less expensive remote sensor than that!Since we're going to have USB around anyway, what else can we do with it? For analog signals, there are 16-bit stereo USB audio input dongles available for under US$10. That's only US$5 per channel, though you may need to remove an input capacitor to be able to measure DC voltages. With a few resistors, a cheap microphone or piezo speaker can become a good quality vibration sensor.While precision USB thermocouple dongles are available for US$20, I'd use one only when needing to measure high temperatures (such as in a DIY reflow oven). There are cheap microcontrollers that can directly interface to thermocouples, so that may be a better and cheaper way to go.What does our inexpensive DAS look like so far? We have a USB microcontroller serving as an I2C hub, with strings of inexpensive digital sensors hanging off it. We have some stereo input dongles for analog signal measurement, and perhaps a thermocouple dongle or two. That's a ton of measurement capability for a minimal investment.But what to do with the data? It's all coming in at different times, with different sample rates, and different acquisition delays! Here's where we deal with one major source of FUD in DAS design: There is seldom ANY need for precise timing! In fact, I'll go further, into pure heresy: Precise timing is actually a NEGATIVE characteristic of any medium- to low-price DAS!First, it is important to understand that what is important is seldom an individual data item in isolation, but instead what's important is the relationship between the data being taken: Between successive samples for a single item, and between simultaneous samples for multiple items. The time of any particular sample does not matter at all so long as we can successfully derive the relationships we are interested in.What I do is this: I acquire my data across all sensors in 1-second blocks, and apply timestamps only at the block level. This has many advantages compared to trying to sample, timestamp and record data on a per-sample basis. The primary benefit is that it PREVENTS you from looking at the data as individual samples, and encourages the use of statistical analysis.First, any of a number of resampling techniques can be applied to "persuade" all the data to a common sampling interval. Then broad correlations can be used to detect and remove fixed delays between data streams (though sometimes you will have to put them back in later, such as when measuring thermal diffusion).With data blocks being gathered only at 1-second intervals, the need for real-time software goes away: Python is perfectly able to manage the data flows, and can even do massive amounts of simultaneous analysis, especially if you are careful to stay deep within the Numpy and statistics libraries, and/or use PyPy to get some wicked-fast code execution.About the only factor needed to make such "sloppy" acquisition work extremely well is to have deep enough buffers on each data stream, so nothing needs to be done more than once each second.

author: Unknown
author_rank: Unknown
timestamp: April 12, 2012, 08:30:50 am
content: Timing is useful when you want to control stuff, otherwise I agree with what you said.A cheap and simple acquisition system would probably satisfy 90% of all usage cases. Also it is the only approach within the capabilities of the community.

author: BobC
author_rank: Unknown
timestamp: April 14, 2012, 07:31:57 pm
content: Using a DAS as part of a control system loop is seldom a good idea! At best, you may be able to add a logging capability to an embedded control system, but that doesn't make it a terribly good DAS. Combining both goals into a single system can make the union meet neither goal well, unless substantial additional engineering resources are dedicated to optimizing competing features.It is also useful to employ a DAS to monitor an embedded control system: Keeping them separate has many benefits, the most important being both functional and data independence. Having a reliable, flexible, low-cost DAS at hand will greatly simplify embedded control system analysis, design, implementation, monitoring and troubleshooting.