Open Source "Lab instrument system" Idea

[Bloch]

Where have before been talk of a

Community Bench Meter and Open Source Multimeter


And that has been mentioned several things that makes it's impossible or at least why it will not happen.

When designing equipment for example a multimeter. It is normal to try meet everyone's needs but that is almost always impossible.

• Price
• function
• accuracy
• Size
• etc

And this will in a open source “forum” be a never ending discussion .
This is a proposal for usable open source diy lab equipment. "lab instrument system" / "bench instrument" Still working on a god name   

 
Instead of building a multi-function instrument. So, the system consists of simple modules.

• Volt meter.
• Ampere meter
• Ohm meter
• Digital power supply
• Digital input/output
• etc

Every module is divided in a front end and a output end.
The idea is that we don't care about the front end but have a very easy text protocol out of the module.
Every module can the be expanded with a

• logger cpu.
• Controls
• display

There can also be a "main" module to collect all modules to a big display and or a COM /  ETH / bluetooth etc. to controle it from a PC/MAC/Phone

[David_AVD]

I've been thinking of a similar thing for a while.  So far, I've been looking into the PC software side of things and was looking to use the SCPI protocol.  Unfortunately it's fallen to the back burner for now due to lack of hours in the day!

[FenderBender]

Would be a nice idea, though I don't know if it could really compete with any production model. I mean even autoranging might be a challenge, though off the top of my head I think I can figure out how to do it...

However, what something like this might offer is a good all around solution for the hobbyist or shallow-pocketed.

When you proposed the idea, it reminded me of the Tek 7xxx series that has a mainframe and then plug-in units.


photo by tekfan

If you were to sell it like that though, you'd need a custom enclosure of some sort.

Well who knows. Maybe it can happen.

[jucole]

Hi,  after reading through the open-source multimeter comments I got the impression the 'module' approach was quite popular.   So why not use perhaps an old flat screen monitor like the one Dave brought back from the dead in his video as a dedicated display for a multi-test tool - this is very rough etc but something along the lines of...



Afterwards I realised that a separate remote box unit with the inputs / buttons on it would work better.  just a thought anyway! ;-)

[FenderBender]

You'd have to figure out how to drive it. I guess you'd essentially need to have a PC. Maybe running Unix of some sort.

[gxti]

You can drive a VGA display using a microcontroller with some difficulty, but FPGAs are generally a better fit and can do digital formats as well. But I do think an OS (probably Linux) would be smart because more people will be comfortable contributing to it. You can also combine the features and run Linux on the FPGA :-) OSes are rather common on higher-end instruments, especially scopes.

[FenderBender]

Real big ambitions here guys. It might be more worth it just to use a small like 4" TFT and drive it from a MCU or FPGA. Or you could use a Rasberry pi.

[pickle9000]

The Maximite is an excellent example of how to drive a VGA monitor.

http://geoffg.net/maximite.html

...mike

[FenderBender]

What would be the cost of the total machine? Would this be a product to rival Agilent? Or would it be something small and accessible to hobbyists and the like?

[jucole]

To me such a project is not about trying to rival commercial projects; It's all about the learning process itself.  If you use a Rasberry pi or FPGA Linux you might as well just use a laptop.  If you want high specs - you might as well buy some solid used test gear from Ebay.

It doesn't have to be over-cooked as well; For example the display driver could be an fpga, some ram and a couple of resistors for a video-out sync to either a tv or monitor at 800 x 600 with 3 shades of black.  The capture module might be re-chargable battery powered, with bluetooth to send tiny update display packets to the display module. The display module would have a uC to manage the display layout.

The attraction for me is the "all-in-one",  the remote capture module and also you can make use of old displays.

[kripton2035]

Real big ambitions here guys. It might be more worth it just to use a small like 4" TFT and drive it from a MCU or FPGA. Or you could use a Rasberry pi.

+1 for the rasberry pi. ideal candidate for this job.
and far less quick obsolete than a laptop ...

[David_AVD]

+1 for the rasberry pi. ideal candidate for this job.
and far less quick obsolete than a laptop ...

Until the Pi is replaced with the next new model / best thing...

[rolycat]

+1 for the rasberry pi. ideal candidate for this job.
and far less quick obsolete than a laptop ...

Until the Pi is replaced with the next new model / best thing...

The Pi is cheap and extremely capable, has an accessible and well specified GPIO connector, offers built-in USB and Ethernet, and boasts a huge and rapidly growing user base.

Would 'the next new model' invalidate all of those advantages? I doubt it.

There seems to be a school of thought which believes that the popularity of the Raspberry Pi with newcomers to programming and/or electronics somehow makes it unworthy for serious consideration. 

[hlavac]

Open source hardware/software would be extremely beneficial for something that would replace multichannel oscilloscope, signal generator, spectrum analyzer, frequency counter etc in a single cheap, expansible universal instrument for a hobbyist.
In modern instruments the hardware is not really expensive,
it's the software options that cost arm and leg...

[Bloch]

The VGA / HDMI / DVI "Controler" module is a great option.

But the priority must be to build good "Front End" modules first.

>>though I don't know if it could really compete with any production model<<
We cant compete on every things. Especial on price.


That we can do is make a


easy to build
easy expandable
good quality components/layout/schematic
And maybe most important is to make a good/fun modules. That from the noob to a "Dave" have need to have / build look in the eyes    


>>What would be the cost of the total machine? Would this be a product to rival Agilent? Or would it be something small and accessible to hobbyists and the like?<<


The nice thing about this is it open/free. Next you build that you want/need. That way you will learn how it works and will be posible to fix it if it dont work.


But if you work on a very important product or need some important measurement then i hope you buy the Agilent one. We will never get all the safety approvals / EMC on the modules.


So i can only see the modules as a Enthusiasts / school / learn thing.

[jucole]

The form factor of the modules could look something along the lines of one of these..



Then all you need is a "caddy" to plug them into.. 





(edit, i tweaked the picture in case of copyright issues.)

[Bloch]

Then all you need is a "caddy" to plug them into..

Well that is not off the shell box.... At least not cheap. Correct me if i am wrong.


In the bench thread Dave did mentioned http://www.polycase.com/zn2 I must say it is a nice box.

[jucole]

Then all you need is a "caddy" to plug them into..

Well that is not off the shell box.... At least not cheap. Correct me if i am wrong.


In the bench thread Dave did mentioned http://www.polycase.com/zn2 I must say it is a nice box.

+1  nice!

[poptones]

I bought tone of the pis. After looking over the docs I can't really say it's all that.

The GPIO is only a partial bit of what's available form the chip, and is not well documented. They don't even tell you how fast the lines can change state with any certainty. The network is just a usb dongle; the "camera" interface (that DOES allow high speed input) is proprietary, you're not going to be able to develop for it without ndas and binary blobs.

The pi should not be the basis of ANY "open hardware" system - it can't, because it's not open hardware. You'd be way better off picking an intel motherboard as the basis for an "open" system. HD3000/4000 video is fine for any application like this, and the drivers are fairly robust. You'll get way more computing power, low price, and a well documented and free software development platform.

[David_AVD]

I have a few items (power supply, multi-channel logic probe, colour bar generator) that I built as Eurocard modules a few years ago.  They plug into a frame.  Nice, but not super cheap.  You can get varying width modules as just card fronts or fully enclosed cases.

[gxti]

Agreed, Pi has no place in open-source hardware. Even ignoring the ideological issues, they might stop making it in a year, or change it enough that the OSHW stuff has to change, too. Plus it's nothing special -- there are Pi-like boards coming out already, some from reputable designers like Olimex that will probably stick around for a little while.

[senso]

Probably an Cortex M4 has the raw power to do an multimeter, a lab supply and to some extents a signal generator and logic analyzer.

[Bored@Work]

You are discussing irrelevant issues. These days computing power is readily available in all shapes and forms. Lack of computing power is not a risk for such a project and does not dictate other design decisions.

Enclosures are readily available, too. Although most in ugly shapes and forms. Still lack of an enclosure is not a risk for such a project. You can always go larger and uglier if needed.An enclosure dictates design decisions in the sense that it dictates size, shape, safety, etc. But you currently have not even a rough estimate about the required size, safety, etc.

Instead of wasting time with these trivial issues now, what about the showstoppers that will kill your project? E.g. where is your analog meter front-end? Ups. Are you waiting for a white night or a miracle? Good luck.

[Rerouter]

(focusing on bench type as i see that more feasable)

being how the interface is meant to be modular, perhpas look at it in a modular way, e.g. what type of interface would have to be used to get the most capability out of the least dollars, what voltages, signals and communication protocols are likely to be better fed from a single point than from each module, and the golden question how will it all connect?

e.g. this modular design will always have to have a power supply or atleast power source in it somewhere, and here the most common voltages can be sourced from, the currents involved would depend a little on what is to be tied off of the thing, but the point is what voltages, i myself am left thinking 3.3V, 5V, -5V, and possibly 12V for the possibility of a power supply output on the thing,

that in my mind covers all digital and near all analog design requirements, removing what would otherwise be regulators on each module, and leaves the possibility of specialty voltages to be generated from them

next would be signals, are there any signals such as 16Mhz, 100Khz or even 1Hz that would simplify the design of the possible modules in any significant fashion over having a seperate crystal per module?

and finally communication, would there be an I2C bus? would there be some SPI loop arrangement? high/low status lines or interrupts, and any secondary module to module only busses? and even the possibility of taking those busses and piggybacking into a second one? would the various busses rebroadcast or be seperate and how would that be decided? will level shifters be provided or even footprints that can be bridged, or straight signals?

and for the connections i feel like the tek series plugins should be a backplane based solution, with a common and cheap connector, for this would think a 0.1" SIL connector, but this can be furthur discussed, and also what spacing should be used, to allow larger things to use up 2-3-4-x wide slots,

what i am getting at is before we try and make it into a product perhaps we should work out the mechanisms to build upon, such as what will be provided to try and spur some community involvement with possible modules, and solutions, as i myself wouldnt mind remaking a few things for a good system

[jucole]

I'm really tempted to have a go myself because I'd learn quite a bit, also it would be a lesson for others on how NOT to design test gear! ;-)

(edit - a quick visual of the stacker box approach)

[FenderBender]

Not sure if I'm too fond of the stacking enclosures..

Think National Instruments. That might even be easier than getting actual enclosures for each. Building the module onto a "card" instead of giving it it's own box might actually be easier. How you do the backplane and interfacing is up to you. I don't know much about interfacing but I'm sure you could figure out how to do it correctly. If you see in this National Instruments...instrument, you have one big module which pretty much just looks like a PC motherboard I/O and then the rest are interfaced with some sort of busses to that board...presumbably.




Again, what is the intended audience of this product? What price would it start at? If you are thinking $1k+, then maybe I should go away, but what kind of person would be expected to buy this?

[David_AVD]

Here's a portion of my eurocard frame and modules:

[Rerouter]

David would those be held in my the screws at the top or only friction? and overcome by tugging on the tab down the bottom? if so a similar design could probably be mimicked by using blank expansion card slots and folding back the guide tab at the bottom and removing the top securing part, to give a compact 1x wide slot design, though i am struggling to find a source of them with mounting holes provided :?

still would love to hear some feedback on what specifics should we start off this design aimin for :/

[David_AVD]

The units pictured are standard 3U eurorack card fronts and modules.  There are a few different manufacturers.  The frame is the biggest expense.  The card fronts are relatively cheap.

Each card front / module is held in with 2 or 4 screws (depends on the width).

[Bloch]

The units pictured are standard 3U eurorack card fronts and modules.  There are a few different manufacturers.  The frame is the biggest expense.  The card fronts are relatively cheap.

Each card front / module is held in with 2 or 4 screws (depends on the width).

It it this ?

http://uk.farnell.com/schroff/24563-132/subrack-3u-235mm-84hp/dp/1370392
http://uk.farnell.com/rittal/3653040/module-3u-160mm-14hp/dp/1198884


Will a so expensive case be worth it ?

[senso]

Those Eurorack card fronts really seem nice, but I cant seem anyone selling them, only DJ/audio related things that go on Euroracks. 

[Bloch]

Then all you need is a "caddy" to plug them into.. 

  http://sine.ni.com/nips/cds/view/p/lang/da/nid/202664


that is about 6000 dollars !! just for the case.....

[shebu18]

I like the idea with the black boxes stacked. The bottom one is the PSU and communiction and the other one are the extensions with extension pins in th bottom and the female counter part on top covered by a rubber thing for dust protection. If you want to add a module you have just to take the rubber thing out and plug the module in.


The real problem is, like someone sad, the communication between the modules. What offers the best speed vs pin count vs noise vs reliability?
RS-485 looks interesting. 32receivers and 32 senders, 10Mbit/s speed. In this instrument system you have one receiver and more senders. 12V would be maybe good for canceling noise out.


LE: Comparison of 8 serial data protocols http://www.maximintegrated.com/app-notes/index.mvp/id/3438
Enclosure good for some projects http://www.ebay.de/itm/Desktop-Instrumentation-Project-Enclosure-Box-Case-Plastic-/150870440462?pt=UK_BOI_Electrical_Components_Supplies_ET&var=&hash=item2320943a0e
board interconnectivity: http://ro.farnell.com/multicomp/2001s-20g-420-01/socket-0-5mm-5-5-5mm-20way/dp/1661180
http://ro.farnell.com/multicomp/2000p-20g-270-01/header-0-5mm-3-5-5-5mm-20way/dp/1661169


fixing could be done by magnets(i don't know if they interfere with the electronics)

[FenderBender]

Well perhaps you could find cheaper ones. Maybe they make something similar in ABS or something?

[David_AVD]

With Eurocard racks, the frame is the most expensive part, but you only need one.  The enclosed modules are also fairly expensive, but the plain card fronts are much cheaper.

The card fronts simply bolt on to the front of the circuit board.  I have designed a few products that used Eurocard frames.  Some used 160mm depth cards, some used 220mm depth cards.

You can use a backplane and DIN41612 connectors on the back of each card so they just plug in.  I have done that for most of the Eurocard framed units I've built.

The left picture below is the one that goes on the card and the right one goes on the backplane.  They are about $3 - $4 each retail, much less in quantity.

 

I don't know if people are interested in going this way, but I thought I'd explain what the system is like anyway.

[crispus]

I think the major obstacle in a DMM project is the analogue part.
For me, the rest are details.

First thing I thing is schematics. For schematic (especial the analogue part) you don't need case, display, communication, etc...

Dare someone to start (at least analogue part)?

[robrenz]

As in life, conception is the exciting fun part. Then the unending hard work begins.

[gxti]

The problem with eurocard is the PCBs all need to be pretty large, which rules out inexpensive professional PCB fabrication. But there's little point arguing about chassis or PCBs or stacking or video or anything if nobody has any real vision about what's being built, otherwise this thread is just a place for people to trot out their little ideas that, if all implemented, would result in a hulking, bloated monstrosity. Even something as simple as a lab power supply can easily spiral out of control unless you set out at the beginning with an idea and stick to it. If you want to build it, build it! Otherwise nothing will happen...

[ptricks]

I am doing a project now that will comprise a logic analyzer with protocol analaysis, DSO oscilloscope, multimeter, transistor hfe , capacitor, inductance, frequency meter, and function generator, that will connect directly to a monitor and has a keypad and rotary encoders for an interface.

The board I am using is by embeddedarm.com. It has an ARM9 processor , MAXII CPLD, and a CycloneII FPGA, ethernet interfaces, and a vga port driven off of part of the FPGA, the vga has its own dedicated memory. The cost was right and I am not looking to do anything high end, more hobbyist type specs. The board is designed to very high specs for temperature and stress and I have really been impressed with the support the company offers. They provide full open linux source to everything from bootloading from an SD card to the VGA code for the display.  It also has a pc104 interface connector as well as pinouts for lcd, spi, and digital IO and it runs off 5VDC @ 1A.  The company even includes examples on how to interface 1 wire devices, SPI and I2c from within linux.

I got the board used for about $75

http://www.embeddedarm.com/products/board-detail.php?product=TS-7300



My goal is to do most of the work inside the cpld and fpga and have as little support parts as possible.  The cool thing about this board is they have developed a driver for the embedded linux run by the ARM cpu that allows me to push a new design to the fpga on the fly without external tools. So I don't have to have everything fit in the FPGA , I can load a specific module as it is needed, allowing the use of the entire FPGA for each function if necessary.

If I had the funds I would go with one of their newer boards , complete with SATA ports and a ton of ram for an embedded board with open design.
http://www.embeddedarm.com/products/board-detail.php?product=TS-7800

[Praxis]

I bought tone of the pis. After looking over the docs I can't really say it's all that.

The GPIO is only a partial bit of what's available form the chip, and is not well documented. They don't even tell you how fast the lines can change state with any certainty. The network is just a usb dongle; the "camera" interface (that DOES allow high speed input) is proprietary, you're not going to be able to develop for it without ndas and binary blobs.

Repeat after me ... the Pi is not a microcontroller, it's a linux box.  That said, it's a very cheap linux box that does HDMI.  The place of a Pi in something like this is as a user interface, simply handling the display (and perhaps user input) of data, in addition to doing data analysis and logging.  It just sucks info from the MCU and processes it and displays it.  Also, it doesn't have to be shit-hot, it just has to be good enough for the job.

The pi should not be the basis of ANY "open hardware" system - it can't, because it's not open hardware. You'd be way better off picking an intel motherboard as the basis for an "open" system. HD3000/4000 video is fine for any application like this, and the drivers are fairly robust. You'll get way more computing power, low price, and a well documented and free software development platform.

Sometimes I wonder if the Open Hardware movement is shooting itself in the foot by not being able to compromise -- you propose a solution that's going to wind up as well more than twice the price just as a premium for ideological purity, when it's frankly the least important part of the system.

Sure, parts of the RasPi aren't open.  On the other hand, no one's talking about using the NDA'd parts of the RasPi hardware or software for this.  Anything written for the RasPi that relies as minimally as possible on hardware-specific bits should be readily portable to any other similar mini linux computer.  (Sure, the low-level RasPi graphics stuff is NDA'd.  Who cares?  Unless you're a driver designer or demoscene freak you never come that close to the video hardware for it to matter.)  Perhaps considering the display (as partially closed hardware) as being seperate from the acquisition hardware would satisfy purists?  Then it's really an open hardware (the acquisition bits) and open software (the display and interpretation bits) project. 

[Marco]

Why not simply use the arduino shield method of interconnecting boards? Pin headers are only rated for 100 insertion cycles, but meh. I was actually looking if there were any cheap LCR shields and was surprised there is very little like this.

If I had the perseverance to tackle a system like this I'd start with the Freescale KL25 board (the only one of the ~10$ uC boards with a 16 bit ADC AFAIK) add a bluetooth module and make an android app for UI. Design a standard sized enclosure for 3D printing with gaps for the pin headers which can be customized for whatever connectors the shield needs and then start with a single shield for an auto-ranging V/A/LCR meter (is going to be pretty cheap,since the ADC/DAC are on the Freedom board the shield only needs attenuation, buffering and protection).

Assuming the circuit board for the shield is sold without too much markup,  cheap access to a 3D printer and ownership of an android phone/tablet with bluetooth this could get someone a useful and expandable measurement platform for 30$ in parts with assembly required.

That's the only way you are going to get some mindshare ... low cost.

[sub]

In my mind, low cost and ease of development can be achieved if one is willing to choose sufficiently simple connectors and spread their circuitry over as many instruments as possible.  The Arduino would make a good starting point, as it provides the USB to serial interface as well as some power.  The presence of ADC pins would mean that there is a digitiser available, even if it is nothing special.

I have started working on a SCPI parser, so that we can make existing software that can talk to the instruments easily.  The standard has the facility for multiple virtual instruments, so it would make a good start for this type of system.

[sub]

I have built a prototype of the SCPI parser, which I have placed online at https://github.com/LachlanGunn/oic (MIT licence).

It is a bit of a mess, using great amounts of dynamically allocated memory and leaking it like a sieve.  However, if nothing else it gives me something to work with as I build something for an embedded platform (Arduino to start with).  Once this is done I will provide a multimeter-like interface to the ADC (just as a demonstration), and an interface to control an AD9835.

The analogue bandwidth of the micro's ADC isn't high enough to make this into a dodgy VNA, so if I decide to go down that path I will probably start by building a digitiser.  This might be a good step towards making something useful.

After making things work satisfactorily on the Arduino, I would like to get it working on the PIC32 via Microchip's USB-to-serial library.  This would bring us a bit closer to being able to plonk down a chip or a module on the board or in a chassis that would handle all of the PC interface requirements.  Eventually I would like to use USBTMC instead of resorting to USB-to-serial, but that will take some time to develop.

For those interested, I have placed my plans for development into README.md in the repository listed above.

[MysteryBunny]

If you want to make an OSHW oscilloscope you should consider these boards... They are more expensive than a $20 one because of the PCB itself... ( I'm working on a 386 processor in Verilog/VHDL, and then a cross-assembler FPGA to convert x86 to ARM... So I wouldn't even start this project yet, so this is an interesting idea I thought of for the future)...

This is MUCH MUCH faster than the raspberry pi which the clock speed of the pi is very deceiving... This is also COMPLETELY OPEN SOURCE: http://beagleboard.org/bone

The BeagleBone uses a TI AM3358 ARM Cortex-A8-based microprocessor. Announced on Oct 31, 2011, the main processor is available for as little as $5, uses a 0.8mm ball-grid array and standard DDR2 memory, making this board easier to clone than other BeagleBoard designs.

I also have some M/F jumper wire going to my DE-0 so I have programmable logic as well. 3.3v compatible and cheap...

http://www.altera.com/education/univ/materials/boards/de0-nano/unv-de0-nano-board.html

This is like the Xilinx Spartan-6 series but cheaper... This particular model is 22k LUT-4 I believe and the FPGA itself is around $10-20 ( maybe less now ) ... That's quite a lot of gates. I never started this project in 2004 because back then you only had maybe 6-10k LUT ( For reference a lookup table is sram cells I believe + 4-6 MUX or multiplexers... You can emulate basically anything, the hard-IP block DSP is also fairly good )...

I think if you were to make an OSHW oscilloscope you could get it into the $50-100 range in total with a custom PCB. The real work is just making the ADC front end since you might need to blow around $20-50 of prototype money selecting one with the right sample rate while keeping the cost low... That sounds like a joke but you could easily do it to those who are critical... If you have the I/O with serdes/transceivers in PLL arrays I'm sure a 400-700mhz A8 is enough ( not to mention it blows the doors off of the pi in processing power and I/O )... Once again this is only prototype cost to DESIGN an oscilloscope kit ( with another kit )... You're easily going to have to make a separate board since you don't know what voltage/current scenario you're going to get out of your front end even buying these two things... I think it's an interesting idea though... Then you can just feed it back to either the beaglebone or FPGA board... Analog devices also makes a $150 board that has a spartan 6 + blackshark on it @ 600mhz+ ...Which those are both budget lines that can be scaled up or down depending on needs. All you'd need as the hobbyist to solder BGA would be a cheap IR... OR even just the ATTEN hot air, reballing stencil, gel, etc... That sounds extremely fussy and risky, but I think if people had the technique down ( I've seen a lot of attempts to teach it on this site so I think it's the best place to talk about it) it wouldn't be that risky to try at least since the investment wouldn't be that high ( once the community has a premade PCB and the parts are standard for the kit )... The only real investment is getting together a kit based on these parts. But we'd have to prototype the system first, and THEN build an OSHW board specifically for test gear...

All the processing power is easy to get and an LCD display isn't that surprising to add... Even an 800x600 display is laughable for a cyclone IV FPGA since it can handle an overlay too... I'm not sure about the cost of that though... It would be fine even with monochrome I think. But once again it could be MODULAR and hardware-agnostic with risers... MUCH MUCH better than the weak amtel in the arduino, and it's a huge improvement over the pi... But the raspberry pi is also a $35 kit and it's ultra low cost. Beaglebone is around $90 but the processor itself is only $5... These particular FPGA and microcontroller are perfect I think for a test piece. I saw examples on the texas instrument site showing how to design your own washing machine ( commercially ) and everything with block diagrams... Which basically is a cry for help saying it's so cheap and fast it can be, and should be tried in anything almost... Xilinx has low-cost platforms, but they start out at $150 usually through digilent design, or they have no features like easy-access GPIO... I have also looked at analog devices blackshark boards ( which surprisingly is only $50 or so for one, but they only work with the BEmicro board, which also doesn't have the 40+ GPIO pins like the DE-0 by terasic )...

Anyways, I hope that offers some insight...

This is a rather tricky thing to find on google: http://www.analog.com/en/evaluation/sdp-bemicro/eb.html

The SDP platform starts at $50 and goes up to around $175 I think? But this isn't easy to find on the analog devices website... Look at the H1 series...
 http://www.analog.com/en/system-demonstration-platform/evaluation/index.html

The only problem with the $50 one is getting the connector to mate with your board. The cost of the nicer ones is for I/O, bigger PCB, and then the final one you're paying for the FPGA too... http://www.analog.com/en/system-demonstration-platform/controller-boards/evaluation/EVAL-SDP-H1/eb.html ...They are almost a waste though compared to the beaglebone I think...

[Hobgoblin612]

I think a project like this needs to start with a standard bus and case design and work from there. One of the hardest things is going to be the user interface. An old 17" LCD monitor would work great as the screen. But the input is a lot harder. For some things like logic analysers a keyboard and mouse work fine but for a scope or function gen you need buttons and knobs. It is not an easy project because different test gear has different requirements for case size, power, interface, bandwidth to the main controller and so on. Any case system chosen or designed would need to have multiple compatible sizes and probably a metal or shielded version. Also keep in mind that if you incorporate a DMM or logic analyser it won't be isolated (unless you isolate all the data and power). In my experience open source projects generally need to be tightly managed or the user interface gets out of control.

Just my 2^c worth.

Timothy.

[sub]

My inclination was to use one of those sub-$100 tablets for the display, since you get buttons there too.  It is potentially a bit irritating (I use occasionally an Agilent 9000-series with a touchscreen, and hitting the right button can be difficult), but probably the most space-efficient way to get a useful interface.  This would mean writing an Android USB driver if one were to use USBTMC, but you can't have everything.

[Hobgoblin612]

Im not so sure about the tablet idea.

• The bandwidth into the tablet is a problem since most of them just have a USB interface
• I'm not sure how much use the touch-screen is in this application because mostly you need precise pointing like a mouse or actual physical knobs
• the rest of the instrument is not going to be really portable so why does the display need to be
• you can pick up a 17in 1024x768 LCD on eBay for about $25 if you can't find one just lying around

[sub]

While the device may not be portable it still takes up bench space, moreso because you now need your chassis to accommodate front panels for every instrument in addition to a 17in display.  For some applications USB bandwidth could be a limiting factor, but it seems that Android supports USB 2.0, so it might still be fine---I'll try it on my mobile when I eventually get some FTDI chips.

I agree that one would probably need to go down the route you suggest for graphically intensive things, but for a signal generator, function generator, power supply, etc. the requirements are not that high.

[Rerouter]

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,

flip it around so it curves back in towards your pcb, have either a screwed on flap at the bottom pin the grooved part or some clip arrangement, and have either another screw or a pin arrangement molded out of a single piece of plastic and pushed up with a spring for a lock in for the top hole (trying to cater for both people with tools and people without)

most of the modules, such as a volt meter, ammeter 4 wire ohm meter etc, could easily fit on a single blank, even very high density logic analyzer cards could be made with plenty of space left for additional processing like decode on them if required, and the required front piece can be stolen out of old pc cases, (always plenty around)

that leaves us with what card length, and is not an easy question, on one hand you have very cheap 5x5cm boards, but on the other it should probably cater to larger higher complexity boards, say a 5x10 or 10x10, personally i would say the 100mm long should be the standard, as double or triple wide blanks would not be that hard to make, though fitting into the casing may take better supporting the pc mounting side, and removing the middle strip supports :/

thoughts?

[jucole]

I think a project like this needs to start with a standard bus and case design and work from there. One of the hardest things is going to be the user interface. An old 17" LCD monitor would work great as the screen. But the input is a lot harder. For some things like logic analysers a keyboard and mouse work fine but for a scope or function gen you need buttons and knobs...

.. In my experience open source projects generally need to be tightly managed or the user interface gets out of control.

Some good points in there!

[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

[mrflibble]

*grin* I was almost expecting this kind of reply. I can see the future, because I keep making the same mistakes. And sometimes even other people repeat my mistakes.

Transport is trivial. It's the visualization & ease of applying math & updating that is the thing IMO.

Sooo, do an fft in an easy manner with rrdtool? Yes yes, I know it can be done, been there done that (well, not fft, but the not-so-trivial math). Averaging + error bars? Histograms with binning that doesn't suck?

The thing is, (I think) I know what you roughly can do with the snmp + rrdtool and I see zero benefit over boring old industry standard methods. And there are drawbacks, such as not being able to integrate with tools that actually deal with the problem domain. On the upside you can integrate with all manner of infra-management tools. Not that this will get you anything tangible in a good time spent vs features obtained way, but what the hell!

That said, if all you want is read out a voltage every minute, store it, and do a simple plot then sure it'll work.

Anyways, if you see a benefit or just think it's fun, go for it. 

[linux-works]

I'm not looking to do anything complicated other than setup gear and data log.  I think that will do most of what I would want at the capture phase.

math - that would all happen post-capture, no?  analysis and whatever - I see that as a post-process.  capture is just data logging of raw values and time.  no?

I realize this won't directly plugin to the existing tools in this domain.  that's not my goal.  I'm avoiding some of the existing scpi management tools since they are non-free and I want to give a fully free way to talk to test gear in a simple and lightweight way.

[Bored@Work]

I want to give a fully free way to talk to test gear in a simple and lightweight way.

But SNMP is not simple. Yes, I know what the S in SNMP stands for. But it it is really only in relation to other network management protocols.

[mrflibble]

math - that would all happen post-capture, no?  analysis and whatever - I see that as a post-process.  capture is just data logging of raw values and time.  no?

I realize this won't directly plugin to the existing tools in this domain.  that's not my goal.  I'm avoiding some of the existing scpi management tools since they are non-free and I want to give a fully free way to talk to test gear in a simple and lightweight way.

Well, there are more mature free infra-management tools than there are free mature T&M tools, that's for sure. 

And yeah, math would be post-capture. And inter-capture. And pre-capture. As in control your instruments based on real time measurements and such. Rrdtool and friends are not really built for that. So open loop data logging, sure. Anything even remotely closed loop, not so much.

[linux-works]

I want to give a fully free way to talk to test gear in a simple and lightweight way.

But SNMP is not simple. Yes, I know what the S in SNMP stands for. But it it is really only in relation to other network management protocols.

hey, its a new idea and I'm going to give it a try.  I'm not saying that its going to be a new fad or anything but snmp is a perfectly fine remote control protocol; and to me, scpi is still just another tree-based command language and so mapping scpi to snmp won't be that hard and I don't think it will be that hard to use, either.  snmp is easily scriptable and as long as you have ip connectivity, snmpwalk and snmpset should work just fine.

the other comment about not being closed-loop; I'm not sure how much that will matter to me.  if I happen upon that situation, I'll see how best to deal with it, but I'm more thinking about doing a batch setup of gear, starting a 'run', collecting data and then closing down the run.  for that, I'm pretty sure this paradigm will work out well enough.

the net-snmp cli tools would be a first way to control things.  something like:

% snmpset -v2c -c private 192.168.1.1 KEITHLEY2500::trigger.count.1 = 1
% snmpset -v2c -c private 192.168.1.1 KEITHLEY2500::sample.count.1 = 5
% snmpset -v2c -c private 192.168.1.1 KEITHLEY2500::genCmd.1 = "init; *opc?"
% data = $(snmpget -v2c -c public 192.168.1.1 KEITHLEY2500::response.1)
% echo $data

etc.

in this case, I'm talking to instance 1 of the keithley.  I'd first do a walk of the equipment 'slot table' to find out what gear I have and what their instance id's are.  here, I found it was '1' (I only have one of these boxes on the network).  then I use the instance ID to point to which box the cmds are directed at.  do set's to change things and get's to fetch things.

if I want to get fancy, I could even have an snmp trap come out when an experiment is done so I don't have to poll for a status variable.

just some initial thoughts.  I know its quite a different take on remote control, but I'm going to work thru it and see if its something that can actually be useful or if its just a tech demo.

[Bored@Work]

Good luck in writing your own MIB in pseudo-ASN.1. Good luck in implementing the basic SNMP protocol, several of the standard MIBs and then your own MIB.

[mrflibble]

the net-snmp cli tools would be a first way to control things.  something like:

% snmpset -v2c -c private 192.168.1.1 KEITHLEY2500::trigger.count.1 = 1
% snmpset -v2c -c private 192.168.1.1 KEITHLEY2500::sample.count.1 = 5
% snmpset -v2c -c private 192.168.1.1 KEITHLEY2500::genCmd.1 = "init; *opc?"
% data = $(snmpget -v2c -c public 192.168.1.1 KEITHLEY2500::response.1)
% echo $data

etc.

For your chosen SNMP path that's as good a way to start as any. If you find your shell scripts get a bit convoluted after a while you could move to your script language of choice. I know the Net::SNMP perl module is quite usable (apt get install libnet-snmp-perl). For python you could do apt get install python-pysnmp4-apps and check that one out. Quick check shows it to be a viable candidate but haven't used it myself.

[linux-works]

Good luck in writing your own MIB in pseudo-ASN.1. Good luck in implementing the basic SNMP protocol, several of the standard MIBs and then your own MIB.

not sure if you are being sarcastic or not.

fwiw, I have over 25 years of snmp developer experience, so I do think I can pull this off...

I don't have to implement the snmp protocol.  the net-snmp stack works just fine and you can turn a mib file into c code without too much trouble.  once I have a basic engine implemented, the rest is just 'software wiring' to connect leaf nodes to callbacks.

the standard mibs are not useful here; I don't care (in this context) about ip counters or ethernet counters, etc.  the system group, the snmp group (what a master agent always contains) and then vendor mib plugins for each kind of equipment that I have.

I should probably not take up any more space in THIS thread.  once I get a basic POC, I'll post the code and let people play with it, if they so choose.  please wait until you see this before throwing more stones, ok?

[linux-works]

the net-snmp cli tools would be a first way to control things.  something like:

% snmpset -v2c -c private 192.168.1.1 KEITHLEY2500::trigger.count.1 = 1
% snmpset -v2c -c private 192.168.1.1 KEITHLEY2500::sample.count.1 = 5
% snmpset -v2c -c private 192.168.1.1 KEITHLEY2500::genCmd.1 = "init; *opc?"
% data = $(snmpget -v2c -c public 192.168.1.1 KEITHLEY2500::response.1)
% echo $data

etc.

For your chosen SNMP path that's as good a way to start as any. If you find your shell scripts get a bit convoluted after a while you could move to your script language of choice. I know the Net::SNMP perl module is quite usable (apt get install libnet-snmp-perl). For python you could do apt get install python-pysnmp4-apps and check that one out. Quick check shows it to be a viable candidate but haven't used it myself.

how you call snmp is not as important to me.  sure, there are perl binding, python bindings, c bindings.  this is all manager stuff and its not my main interest.

what I care about is more on the agent side.  the server side, if you will.  that will be written in c since net-snmp is a C implementation and C is my best/preferred language.  the platform will be anything linux: from raspi to beaglebone to itx box.  it should not matter; the code will run on any linux system.

[mrflibble]

how you call snmp is not as important to me.  sure, there are perl binding, python bindings, c bindings.  this is all manager stuff and its not my main interest.

Hence the "If you find your shell scripts get a bit convoluted after a while you could move to your script language of choice". Anyways, have fun.

[jwm]

As for a case, how about one of these? CD Duplicator case

Cheap and comes with a power supply and integrated fans for cooling. For a backpane you could just use ribbon cable with multiple IDC connectors, like pre SATA HDD's were connected.

You can even bump up to 7 or even 9 bays easily as you add modules.

[Rerouter]

As for a case, how about one of these? CD Duplicator case

Cheap and comes with a power supply and integrated fans for cooling. For a backpane you could just use ribbon cable with multiple IDC connectors, like pre SATA HDD's were connected.

You can even bump up to 7 or even 9 bays easily as you add modules.

I Really like this idea,

[Felicitus]

There's already such a thing called c't Lab (from a popular german computer magazine). Unfortunately, most of the documentation is in german, but using google translate shouldn't be too hard. And if you have troubles, ask me, I can translate.

Their wiki can be found on http://www.thoralt.de/wiki/index.php/Hauptseite and the project site is on http://www.heise.de/ct/projekte/machmit/ctlab/wiki. It's pretty much complete and I know quite some germans who have built it.

[Bloch]

There's already such a thing called c't Lab (from a popular german computer magazine). Unfortunately, most of the documentation is in german, but using google translate shouldn't be too hard. And if you have troubles, ask me, I can translate.

But is it truly open source ?

I do understand that the software is

But that about the hardware ?

Will you translate this a bit better than google is :-) Thanks !

"Auch kommerzielle Eigenentwicklungen aufgrund der veröffentlichten Schaltungen und Grundlagen sind zulässig, allerdings keinesfalls eine 1:1-Nachfertigung der Platinen, die dem Urheberrecht des Autors und des heise Zeitschriften Verlags unterliegen; hier ist eine eigene Erfindungshöhe der Neuentwicklung Voraussetzung."

[Marco]

They are saying you have to layout the PCB from scratch if you want to use it commercially with your own PCBs.

Basically the firmware sources are attribution only licensed and the PCB layout sources are attribution non commercial licensed (they are just being honest in recognizing that copyright can't cover circuit topology, so a completely new layout renders their copyright irrelevant).

[Bloch]

(they are just being honest in recognizing that copyright can't cover circuit topology, so a completely new layout renders their copyright irrelevant).

So a big differences between 

pls dont copy it |  pls do copy it

[uwezi]

I mean even autoranging might be a challenge, though off the top of my head I think I can figure out how to do it...

Who wants autoranging anyway? 

[mrflibble]

what I care about is more on the agent side.  the server side, if you will.  that will be written in c since net-snmp is a C implementation and C is my best/preferred language.  the platform will be anything linux: from raspi to beaglebone to itx box.  it should not matter; the code will run on any linux system.

Any progress on this?

[linux-works]

I got side-tracked to a few other projects (lots of re-capping and refurbing of used gear I recently bought) but I do still plan to work on this and post the prototype C code (and MIBs, lol) that I end up with.