Open Source DAQ protocol and reference hardware - Page 1
Forum section: electronics / general

author: djacobow
author_rank: Super Contributor
timestamp: May 12, 2014, 09:25:19 pm
content: The thread on an open source DMM as well as my own desire to have certain types of instruments that should cost much less than they do, has gotten me thinking of embarking on an ambitious project: creating an open-source data acquisition framework along with some reference starting hardware.I'm curious if anybody would want to- dissuade me- get involved- provide adviceHere's my vision:- establish a simple mainframe connector and protocol that would provide- data xfer (maybe USB3?)- triggering and other synchronization (both directions)- a few useful clocks (10 MHz, etc)- device ID- bipolar analog supplies (maybe +/- 30V, +/- 15V, +5V)- on top of that, a software library that- can manage the hardware protocol above- can enumerate devices,- provides data structures for aggregating and aligning data from multiple "cards"- provides primitives for trigger, drain, real-time capture, etc.From the physical hardware perspective, we'd start out with two devices:A) a mainframe "motherboard" sporting a reasonable processor capable of running Linux or whatever, and providing several copies of the hardware interface specified above, maybe four. Also would have the basic IO we expect from computers: ethernet, maybe video, USB, etcB) an "example" DAQ module that would speak the protocol above and maybe provide voltage measurement in a few rangesTo make it all feasible, design for a total bandwidth per card of, say 250 ksps (16b samples) and a total bandwidth for the motherboard of 1 Msps if capturing from all four simultaneously.If this turned out interesting, people might be inspired to build other DAQ boards that fit the protocol.From this infrastructure, we could move into a world where people can build whatever they want, for maybe not too much money: power analyzers, LAs, protocol analyzers, etc. Basically, an open source NI-like ecosystem.Everything would be OSH/W.-- dave j

author: Bored@Work
author_rank: Super Contributor
timestamp: May 12, 2014, 09:43:54 pm
content: Quote from: djacobow on May 12, 2014, 09:25:19 pmYou mean like Comedi?Or like openDAQ?Or like openSCADA?Or RELACS?Or DAQFlex?

author: djacobow
author_rank: Super Contributor
timestamp: May 12, 2014, 10:07:34 pm
content: Quote from: Bored@Work on May 12, 2014, 09:43:54 pmMaybe like DAQFlex, but, no not generally like the others. Comedi might be a good way to build drivers for my imagined instrument, but the others do not seem like they could support the high-precision simultaneous capture I was imagining. Perhaps they could through post-processing if the devices could all time-stamp *very* accurately.But your list does give me plenty of pause to consider that there are many similar efforts out there, most seeming not fully cooked, which is probably where mine would end up, too.

author: theatrus
author_rank: Frequent Contributor
timestamp: May 24, 2014, 04:20:01 pm
content: Being able to ship products with the open standard is what will cement a winner. Everything else is just electrons

author: RobertCristofer
author_rank: Newbie
timestamp: July 16, 2014, 09:17:38 am
content: I think that OpenSCADA can support the high-precision simultaneous capture. Because I read about similar creating an open-source data acquisition framework and they use OpenSCADA for their project

author: mrflibble
author_rank: Super Contributor
timestamp: July 16, 2014, 04:13:32 pm
content: Quote from: djacobow on May 12, 2014, 10:07:34 pmYou could always go over the options on that list, pick the one that matches your vision the most, and contribute to that in the direction of your end goal. That will increase the likelihood of less-cooked efforts.Besides, what's wrong with SCPI & LXI and whatnot? Just grab the programming manual of agilent instrument equivalent of what you are trying to build, and implement that instruction set. If you do that properly it should save you some time on the driver side too. And also increase chances of it being adopted by other people.

author: djacobow
author_rank: Super Contributor
timestamp: July 16, 2014, 05:25:46 pm
content: Quote from: mrflibble on July 16, 2014, 04:13:32 pmWell, there are some things that cannot be software-abstracted in order to create a "unified" instrument.For example, if you want to create an AC power analyzer, you need voltage and current measurements that are correlated in time down to the sample. If you want to create low-rent ATE equipment, you need a pattern generator and logic analyzer that are clocked identically. If you want to create your own mixed signal measurement beast, you want shared triggers.With judicial use of external clocks and shared trigger and sync cables, you can do a lot of this with existing off the shelf equipment -- though to be fair I don't know of any equipment maker making strict promises about the latency between input trigger events and actual trigggering and output trigger events, so it is tricky to put together this kind of hybrid instrument without some trial and error.Also, real name-brand equipment is expensive and hard to hack. :-)

author: mrflibble
author_rank: Super Contributor
timestamp: July 16, 2014, 05:58:51 pm
content: Quote from: djacobow on July 16, 2014, 05:25:46 pmSo use IEEE 1588 for your synchronization. In a way that looks suspiciously much like the way LXI does it.QuoteBut incredibly cheap to download TFM and R it. It's not as if you are trying to solve an unsolved problem with the above case. Why reinvent the wheel when there's a perfectly acceptable wheel (hell, four of them!) already fitted to the bandwagon, all ready for you to jump on.I realize that it's not sexy to implementother people'sideas ... but every so often it's the way to go. Especially if your project idea has"new standard for"in it.

author: djacobow
author_rank: Super Contributor
timestamp: July 16, 2014, 06:09:58 pm
content: Quote from: mrflibble on July 16, 2014, 05:58:51 pmI see your point. I have not done enough research here. I was not aware that LXI+IEEE1588 could synchronize to sub 1us.

author: charlespax
author_rank: Regular Contributor
timestamp: August 26, 2014, 02:25:53 am
content: Quote from: djacobow on May 12, 2014, 09:25:19 pmDave, what advantages to you see a modular hardware system having over discrete measurement devices? I can see how time correlation of different types of readings would be nice to have. What use case examples are you thinking of?