Open Source DAQ protocol and reference hardware

[djacobow]

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 advice

Here'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, etc

B) an "example" DAQ module that would speak the protocol above and maybe provide voltage measurement in a few ranges

To 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

[Bored@Work]

creating an open-source data acquisition framework

You mean like Comedi?
Or like openDAQ?
Or like openSCADA?
Or RELACS?
Or DAQFlex?

[djacobow]

You mean like Comedi?
Or like openDAQ?
Or like openSCADA?
Or RELACS?
Or DAQFlex?

Maybe 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.

[theatrus]

Being able to ship products with the open standard is what will cement a winner. Everything else is just electrons

[RobertCristofer]

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

[mrflibble]

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.

You 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.

[djacobow]

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.

Well, 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. :-)

[mrflibble]

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.

Well, 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.

So use IEEE 1588 for your synchronization. In a way that looks suspiciously much like the way LXI does it.

Also, real name-brand equipment is expensive and hard to hack. :-)

But 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 implement other people's ideas ... but every so often it's the way to go. Especially if your project idea has "new standard for" in it.

[djacobow]

But 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 see your point. I have not done enough research here. I was not aware that LXI+IEEE1588 could synchronize to sub 1us.

[charlespax]

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.

Dave, 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?