Open Source "Lab instrument system" Idea

[sub]

looking back to some of the earlier discussion on possible housing and mounting options, as a rough guideline, why not make use of what already accommodates for most of our connectors, even if not a professional case in the early implementations, i'm referring to PC expansion slot covers, its a simple layout for the blanks with only 1 bend, 2 filed or cut grooves at the top and 2 slanted edges at the bottom, just manipulating the direction of usage slightly,

I suspect that any design involving metalwork is probably going to be too difficult to get right reliably.  My inclination is towards a laser-cuttable design, even if it means some cabling, since there are too many people like me who are ill-tooled and mechanically inept.

[Rerouter]

now with a good nights sleep and more forethought i realise that it should be kept with the metal bending out of the case to preserve the mounting flanges , however i was getting at it being a simple design, it does not necessarily need to be metal, though it would help with any foreseeable emi and reliable grounding issues, it could be acrylic wood, etc, its just a shape that ticks the boxes we need, a way to decide some aspect of this thing, so we can work towards the final thing,

as opposed to swinging back and forth on all the display options, as in reality the display is just an interface and software, we need a working backend before we can worry about the front,

[sub]

as opposed to swinging back and forth on all the display options, as in reality the display is just an interface and software, we need a working backend before we can worry about the front,

In reality I think both are necessary.  I have half of a DDS signal generator prototyped, though still need to decide how I will go about adding proper gain control, design a decent power supply, and decide upon an anti-aliasing filter.  For the moment I am just controlling it via the PC using SCPI and a Qt interface.  A link was posted earlier in the thread to the software side.  The hardware is an AD9835 with an LM6181 current-feedback amp in a unity-gain configuration.  I'm really only 10% of the way there, though, if that.

[mrflibble]

as opposed to swinging back and forth on all the display options, as in reality the display is just an interface and software, we need a working backend before we can worry about the front,

In reality I think both are necessary.

Both valid points. The way I see it, you do indeed need both. However IMO you really really should get some hardware in place, otherwise you risk just another open sauce Item XYZ thread going nowhere.

For the display, don't reinvent the wheel. Sod driving a tft from fpga or whatever. Yeah sure it's a fun exercise. And then you have to implement the gui. Oopsie! So either you flush a man year+ into just being able to show pretty pixels, or oooh I don't know use this things called pc/laptop/tablet that already has the OS + gui + dev environment, etc etc available. Seems an easy choice to me.

And yes, before some clever monkey comes up with that, there are exceptions to the above that don't take a man year. But personally I've been over that and as such I don't care for that part of the discussion. There's only so much time in the day.

My point here is, make things as easy as possible for yourself. That way you actually have a chance to get things done. Just get something that works. After that you can always do incremental improvements. Besides, if you have something that works, then you have a better chance of other people joining in.

I have half of a DDS signal generator prototyped, though still need to decide how I will go about adding proper gain control, design a decent power supply, and decide upon an anti-aliasing filter.  For the moment I am just controlling it via the PC using SCPI and a Qt interface.  A link was posted earlier in the thread to the software side.  The hardware is an AD9835 with an LM6181 current-feedback amp in a unity-gain configuration.  I'm really only 10% of the way there, though, if that.

Hey, that sounds surprisingly familiar! I have (less than) half of same. I use a AD9834, and as it happens I also use Qt for the gui. No fancy SCPI interface though. Just a quick and dirty binary protocol. Basically because this was a bit of an experiment with several things I wanted to try. The AD9834 spi interface is hooked up to an fpga dev board (nexys2), which in turn is connected to the pc via usb. And to keep things simple on the fpga side I used a binary protocol. Read: easy to implement FSM.

So from the Qt + libusb interface I can do pointy clickey to control the dds. I also made a quick & dirty perl + libusb script to control it from cmd line.

Anyways, back on the SCPI topic. Using that as a standard seems like a good idea. It doesn't even have to be the bestest(est) standard out there. As long as it is reasonable, you can use it is a bit of common ground. Human readable scripts are easier to share & expand upon than binary blobs.

So barring any better alternatives presenting themselves, I think I'll grab the SCPI idea for my next DIY T&M thingy.

Oh yeah, forgot to mention. The Qt interface also runs on my android tablet. ^_^ Still plenty of usability issues, but it was a first try to see if this sort of approach was feasible. So the same code works on android + linux + windoze. And for the rest I don't care. Ahem, I mean, based on current requirements the rest is placed out of scope.

Now that I think about it, I might as well do a proper board for this. I'm currently practicing my altium skills anyway, so this is a good excuse to take this one out of the dead bug stage. And then hook it up to an stm324 discovery + add a little scpi parser. LM6181 already added to mouser shopping cart for the next purchase round.

How do you have the LM6181 hooked up to the dds? Figure 1 from the datasheet, or any clever modifications based on experience?

Rant prevention protocol activated. Pressing [Post] now. *beep* *boop*

[Anquietas]

So, what you are basically planning to DIY is something along the lines of National Instrument's PXI?

http://www.ni.com/modularinstruments/


Edit: Whops, skipped the second page. It's been said already. Okay.

[mrflibble]

So, what you are basically planning to DIY is something along the lines of National Instrument's PXI?

Not sure who you are addressing this to, but in any event ... personally I am not planning any such thing. If only because PXI is horrible overkill for anything I plan to do within the realm of DIY lab instrument stuff.

Besides, while industrial and rugged and blah is nice, I think that if you need something that requires that much bandwidth you may want to stick with regular PCIe. PCIe connectors are no doubt cheaper than PXI Express, due to the PC market volume. Plus discarded mobo's are a nice cheap source. And for PCIe there's IP that comes with the regular boring ISE license, that can be used on spartan-6. For PXI express I have no idea...

Besides, for the dds mentioned I'll just use a PMOD connector. I already use that as a standard more or less for this type of low bandwidth thing.

And no doubt PXI has some clever solutions for clock distribution and such. But unless it's really clever and can be adopted in a cheap enough fashion, for my own stuff I think I'll just stick with sma/smb/mcx + point to point connection. Not as nice as  with the professional solution, but what the hell, this is DIY. As long as the signal quality is good I don't care too much that it takes a bit longer to wire up. Besides, it does make prototyping a bit easier.

So just taking the DDS as example, I plan to use a pmod connector (already doing that on the dead bugged protoype). And I also plan to use SMA for clock input, which will be an improvement upon the currently used clock input over the same pmod connector. Right now I use the horribly jittery clock straight from the fpga pll as dds clock source because that was convenient at the time.

[Rerouter]

while i dont mind the idea of pci connectors, (self aligning on insertion, etc) i dont think the signalling system should be adopted.. as while it helps us along with bandwidth, it has far too many lines used for the job. i still feel SPI or UART (with possible I2C for some very low speed bus) should be used for the heavy lifting, as they are very easy to create interfaces for, and just about any micro can handle it,

though on the spi side of it, as slaves have a select pin, when the device is not selected, can you dramatically up the clocking rate, i'm thinking something along the lines of polling devices based on there update rate, and if you could say know the voltmeter plugin can only handle 1Mbps, and only provides 860 bytes per second, then slam it down at its maximum speed or shunt it to the low speed bus?, up next might be a high channel logic block, say 32 inputs, the block itself can handle 45Mbps but has a few tens of kilobytes to transfer every second, so raise the clock speed only while that device is selected and power it in?  i have to admit at this point i have only really made use of uart and i2c,

i'm more worried that a monster pci controller may scare off to many, as there device has to interface with it,

[Bloch]

To get a user interface and case up and running fast and "cheap".


Why not use a PC


That gives a lot of things for "free"

• Cheap monitor
• Standard slots with power / mounting for the PCB´s
• (back) Standard steel brackets for inputs.
• (fronts) Standard brackets for inputs/knobs/leds.

And no need to use the "hard to use" pci bus
There are Usb/com/ltp ports already.


This way there will be no laser cutting or plastic molding. Or special case from one manufacturer.

[Rerouter]

a pc is rarely a good alternative, its better that the modules be mounted in something you would use in a lab, while yes the option of sending the data out to a pc as a display module is no issue, the actual mounting for the pieces probably should not be, just borrow off components you can rip out of them, as there are plenty scrapped each month across the world,

its not a bad idea, just probably far from ideal, but not to be discarded, if we can all agree on what size and mounting system the modules should use, then it should not matter if you throw it in the back of a pc case, a lab back-plane or a small 1-3 module battery powered carry case,

next up would be power for the modules, which voltage(s) should we agree on as a way to power them, its almost a given 5V should be one of them, for people aiming at usb or interfacing with logic chips, but should anything else be done? say a 3.3V rail so the modules don't have to convert it on there own to reduce redundancy?

[mrflibble]

i'm more worried that a monster pci controller may scare off to many, as there device has to interface with it,

That is more or less how I see it as well. Besides, better start with something simple and get it working. That way you can get that whole community thing going. Otherwise it stays in the realm of nice ideas and polite invitations for the other guy to start first.

SPI really is good enough for quite a lot of things. The big mistake (hah! as if... one of the big mistakes) I see with many of these non-starting projects is they try and solve too many things at once. Just pick something that has your interest and just do it. Sod the rest. Why? Because you are going to be the one doing all the inital work anyways, so might as well be honest about that fact and pick something you care about. That way you will be motivated enough to actually finish it, and possibly get the ball rolling.

Design by committee + waiting for the other guy just doesn't work. Listen to other people, yes. Ignore 90%, yes.

Anyways, regarding SCPI parsers ... does anyone have a good code base that is MCU friendly? So far I have on my SCPI parser stuff to check list:
- sub's parser
- https://github.com/j123b567/scpi-parser
- http://www.jpacsoft.com/parser_free_demo.htm ... mostly for inspiration

If it turns out everything is crap, the plan is to:
1 - do an exceedingly lame "parser" based on strcmp + accepting lack of rigid error checking
2 - use 1) for quite some time, then get annoyed enough with the limitations and proceed to ...
3 - do a proper lex + yacc version
4 - profit!

Anyways, I hope I can stay at entry 0), which is where the current state of the art in free scpi parsers is not crap, and as such I'll just use that. Every now and then writing a parser is amusing enough, but it is not in my top 3 of fun things to do.

[mrflibble]

To get a user interface and case up and running fast and "cheap".

Why not use a PC

Why not indeed? So, presentation layer solved. Onwards to the real problem.  What real problem you say? The analog front end, that one. Get to it, chop  chop!

a pc is rarely a good alternative, its better that the modules be mounted in something you would use in a lab, while yes the option of sending the data out to a pc as a display module is no issue, the actual mounting for the pieces probably should not be, just borrow off components you can rip out of them, as there are plenty scrapped each month across the world,

Well, he did say "user interface", not just "interface" which may be taken as electrical interface as well. I am all for using the PC/whatever (see previous post) as user interface.

And yes you want some sort of enclosure. Personally I would advice to adopt a stance of "I don't care too much". Just do what is convenient for you in terms of form factor. Just try to agree on some sort of electrical standard. If you decide to plonk it in a cardboard box, that's your business.

[sub]

i'm more worried that a monster pci controller may scare off to many, as there device has to interface with it,

That is more or less how I see it as well. Besides, better start with something simple and get it working. That way you can get that whole community thing going. Otherwise it stays in the realm of nice ideas and polite invitations for the other guy to start first.

SPI really is good enough for quite a lot of things. The big mistake (hah! as if... one of the big mistakes) I see with many of these non-starting projects is they try and solve too many things at once. Just pick something that has your interest and just do it. Sod the rest. Why? Because you are going to be the one doing all the inital work anyways, so might as well be honest about that fact and pick something you care about. That way you will be motivated enough to actually finish it, and possibly get the ball rolling.

Design by committee + waiting for the other guy just doesn't work. Listen to other people, yes. Ignore 90%, yes.

Anyways, regarding SCPI parsers ... does anyone have a good code base that is MCU friendly? So far I have on my SCPI parser stuff to check list:
- sub's parser
- https://github.com/j123b567/scpi-parser
- http://www.jpacsoft.com/parser_free_demo.htm ... mostly for inspiration

Mine is rubbish, but I do have it running on an Arduino board, so it at least works to some extent.  That second one looks good, thanks for linking it.  I'll definitely be trying it as a replacement for my own.

How do you have the LM6181 hooked up to the dds? Figure 1 from the datasheet, or any clever modifications based on experience?

It's really just a unity-gain buffer with a bit of filtering at the input.  I have attached a schematic.  The feedback resistor has since been reduced to 1k.

[mrflibble]

Thanks! Regarding filtering ... I assume you do any extra filtering with a different type of opamp? Anyways, I intend to do just a simple low pass filter before the line driver, pretty much like your first circuit. And possibly with a < 1k feedback resistor. Just curious ... what made you chance from the 2k2 to 1k resistor?

[sub]

Thanks! Regarding filtering ... I assume you do any extra filtering with a different type of opamp? Anyways, I intend to do just a simple low pass filter before the line driver, pretty much like your first circuit. And possibly with a < 1k feedback resistor. Just curious ... what made you chance from the 2k2 to 1k resistor?

I'll probably use a similar op-amp; the app notes that I've seen suggest that Sallen-Key lowpass works perfectly well with current-feedback amplifiers, so might as well keep the high bandwidth.  Particularly so if I later decide to switch to the 9951 or such.

Lower resistors should be faster which, truth be told, is probably not what we want here anyway, so I might fiddle with switching it back.  The resistor was chosen to be the smallest that I had to hand which would guarantee stability. I might further reduce it to 820 ohms as specified in the datasheet.

[jucole]

I've completely moved away from my existing thoughts of what the lab instrument should look like and came up with this.  The specs. won't be impressive, but the feature list will be!   Most of the data will be pushed and controlled by a PC and I'll probably make the specs up as I go along.  There will be a system board and one for each feature; so I can upgrade a board as I learn more. 

I know it's very big project but that's the way I like it;  no pain;  no gain! ;-)

[mrflibble]

It certainly looks pretty! My concept art for a diy instruments always looks like a cardboard box.

[shims506]

I'm not sure if this was discussed before but if the main processing is done by the computer why not incorporate the rest in the computer. What i mean is the 5.25in drive bays are typically empty in most computers and they can be real estate for all your inputs. Makes the instrument clean and flush with the computer and you could also have an option to do that extension if you don't like your computer close by. Ill post up some of my concept drawings later on.

[mrflibble]

There's been dicussion on that yes. IMO you get it half right. The 5 1/4" form factor is nice, which is why I'll use either a spare usb drive enclosure OR a sata enclosure. Personally I wouldn't put it in the (desktop) PC itself, but hey it's DIY. If it works for you go for it.

[jucole]

I'm not sure if this was discussed before but if the main processing is done by the computer why not incorporate the rest in the computer. What i mean is the 5.25in drive bays are typically empty in most computers and they can be real estate for all your inputs. Makes the instrument clean and flush with the computer and you could also have an option to do that extension if you don't like your computer close by.

I couldn't really get on with something like that; the scope knobs are a must for me to tweak time and divs etc.
sorry I misread your post ;-)

[linux-works]

I haven't read thru the whole thread yet, but I'm going to be working on something along these lines.

my take on it: use existing high quality gear (hp, tek, fluke, keithley, etc) and control it via rs232/scpi.  I don't like the price of gpib controllers and the hassle it brings, but if you accept the limit of having all gear be scpi/rs232 then you can leverage all the good work the vendors have done on their ascii mgmt interfaces and just bind it all together with some pc glue.

I like a networked solution and I also like small fanless pcs, so my first take will be to have a linux system like the rasp pi or beaglebone and let that talk over usb/serial to the test gear.  the next problem is to abstract that and give a network interface (over IP) so that you can remotely control and 'manage' the gear.  I have a background in SNMP and for grins, I'm thinking of using that for setup and data collection of the test gear.  I'm not sure anyone has ever done that before but I'm game to try

the user interface does not actually interest me; that's a problem to be solved later once the gear is manageable over the network.  first to get the usb/serial streams 'discoverable' and provide some MIB plugins so that you can snmpwalk the tree of discovered/connected gear and eventually do snmp SETs them to control them.

[mrflibble]

I'm no guru, but have enough snmp experience to have the following opinion: SNMP is not the best match ever for test gear.
Sure, you can homebrew something, but why bother? Picking an industry standard intended for the problem domain and implementing that seems like a better way to spend time. If for no other reason than that you can use existing software etc to build on. Going to use nagios to manage your snmp enabled measurement gear? Yeah, good luck with that. <insert_time_here> *flusssshhhh*

Case in point, the last few electronic doodles I've been doing on chibios + scpi. Accept command from serial port and ethernet, then send them (through mailbox) to another thread that is responsible for parsing the scpi commands and executing the decoded commands.

That said, if you think you have a good idea where SNMP enables all sorts of easy solutions go for it. Worst case scenario, you'll learn something.

[linux-works]

I'm going to just see what kind of usability I can get over snmp.  not saying its the BEST idea, but its kind of novel, you have to admit.

one thing I'm thinking might be cool is that NMS systems usually can poll and graph things pretty well.  if I can simulate a 'data feed' of a voltmeter, say, and have the NMS poll for time/value pairs (after a capture to a buffer, of course!), you could get a 'free' graphing and user interface.

scpi is tree based and snmp mibs are also tree based, so the mapping won't be too ugly.

aside from snmp, I'd like to have a telnet or ascii bridge iterface so that you could console into the beaglebone and then send normal scpi commands to various virtual ports.  maybe I'll use the terminal server idea of having a base port and then offsets that you can telnet to for each of the boxes that are connected.

[linux-works]

btw, I'm not sure I'd start with nagios.  in fact, I have not found that many good opensource NMS systems out there.  the last one I used was xymon (old name, hobbit) and while its not native snmp, its a pretty thin framework and I was able to add my own net-snmp based poller and trap receiver to it.

at least it has a decent enough rrdtool feature.  for data logging, rrdtool is a good and easy way to start off.

[mrflibble]

I'm not sure if I would start with nagios either, it's just the first one that sprang to mind. What do you think you'll get out of rrdtool that you cannot get out of any random API du jour that is a bit more suitable for real time plotting? Want something reasonably easy to develop? Use python with one of the many ways to plot things, depending on your tastes. Want a robust & fast gui? Use Qt + qwt. Want something even lazier with pretty graphs and proper statistics? Use R. Want webserver statistics? Use rrdtool.

That said, if all you want is logging and not too much math on your measurements, rrdtool should work fine. But I know how this works, I spot a certain amount of "make the tool fit" going on. That is usually not cured by a random dude on the internet trying to explain the drawbacks. What that takes is flushing a few days of your own time into it and finding out for yourself. So happy coding! 

[linux-works]

what I've done is do a dual data sink; one 'tee' goes to rrdtool and one goes to mysql, so that I can play with the data all I want.  the rrdtool stuff is because you have a lot of already existing visualizers and managers for rrd files.  its also great for long term data logging.

note that the SNMP stuff is not going to be the only way in to this network of test gear.  I'm thinking of an hourglass model where there are many devices at the bottom and many UIs at the top.  the skinny middle is the common abstraction that everything else plugs into.  SNMP is a top plugin, while any diffs in transport (serial characteristics, protocol nuances, etc) for each of the test gear instances would be bottom layer plugins.

I'm going to give it a try.  if it fails, well, maybe at least it can be an apr-1 RFC