"DIY instrumentation bus" (or DIB)

[prasimix]

I'm opening this topic to discuss the possibility of specifying a DIY instrumentation bus (or DIB in the text that follows) as a joint effort of many people who already built or think about building a test & measurement  (T&M) device, and possibly also found the modular approach as beneficial in the long run for themselves and DIYer/maker community.
One can find many projects that belong to T&M category, in this and many other forms: power supplies, electronic loads, signal generators, data loggers, multimeters and scopes, etc. While many of them are still at the idea level, some are successfully finished with many somewhere in between.

From what I understand, people started these projects for different reasons such as: to learn about electronic circuits and programming needed for digital control, to design a device according to their requirements and budget, to improve their maker skills (PCB design, hand soldering, testing and debugging, working with mechanical parts, etc.).
Many of these projects exist as isolated islands without the possibility for straightforward communication with other devices even if they are built by same author(s). Also, due to lack of modularity, it’s not possible to mix-and-match them with others.

Question is why should, for example, my power supply be in any way connected or share anything with something like an electronic load, data logger, signal generator, etc.? It shouldn’t if it’s not programmable/digitally controlled. But digital control building blocks (both hardware and software/firmware) have become affordable many years ago and it would be a shame not to take advantage of that. Therefore it will be interesting for the device to have centralized control, or if that is not the case, the control software (firmware) written for one device could be reusable with others to the greatest possible extent.

My impression is also that many DIY/maker project are “stuck” because of software. There's a long way from “hello world” application (whatever that means for particular device) to usable, reliable, intuitive, and future upgradeable (and portable) solution. It can be especially frustrating/disappointing if the whole project was initiated to fulfill author’s specific requirements and then in one moment become obvious that due to the lack of programming skills, time or hardware capability the project might not be completed.

Developing software for one device that could be used with minimum adoption on another device should be beneficial on the many levels for both sides: for the initial author of software who can learn about the specific requirements of many different types of devices/instruments that could lead to a more efficient and universal solution. On the other hand, people who are going to build a new device could count on software support from day one, support that addresses communications with the device to greater extent (locally or even remotely). If a completely new digital peripheral/controller is introduced, its support could be easier to implement and test/debug following the existing logic for already supported peripherals.

When such software comes with some kind of standardized way to interact with “outside” world then people who are interested in high level/layer of programming (e.g. presentation, data distribution, etc.) could join such an initiative without caring a lot about what is going on at the lower level (firmware and hardware).

Using the same software “suite” for different devices could be done on the two level:

• individual – each device is standalone and requires its own digital control circuitry or
• grouped – two or more devices share the same digital control whether they share the same housing or not (one enclosure per device).

We can assume that if someone is encouraged by the successful completion of one project they start to think about another one. Adding another one in the same housing to keep the often limited DIY/maker’s benchtop space free should make sense.

Finally, I’ll try to summarize this post in few bullets that should help understand what could be done.

Current situation:

• There are many DIY/maker projects at various levels of completeness/maturity
• No unified design can be identified in which various devices could be controlled using the same software “suite”, preferably form the single place (one controller-many devices)
• The lack of a modular design and “backplane” that can be used to mix-and-match different devices and grow a “benchtop lab” over the time by adding new instruments (modules)

Initial proposition:

• Devise a specification for digital control of various T&M devices
• Introduce modular design with “backplane” that carry DIB
• All parts of the design (hardware, software, mechanical, etc) should be published using a free and open source license

Pro’s:

• A software “suite” will be developed, that can be reused and shared between different project/initiatives
• multiple versions of controlling and controlled modules can be developed where people with different skills and aspirations can be more focused on one part and make it better
• Different groups of people could benefit: end-users, hardware and/or software developer, manufacturer who don’t have R&D capability but can make hardware parts widely available and more affordable

Con’s:

• Modular design puts some limits to electrical and mechanical design
• Inter-connectivity issues can be expected even if the same software and DIB is used

More details will follow in coming days. Of course, your feedback on what is already said is highly welcomed.

[filssavi]

I would strongly advices agaimst using such an outdated protocol as GPIB for external comunicazione either, not only It require special hardware, if you take Ethernet for example a lot of MCU have internal MAC, and there are some with internal PHY also, and also there are currently 0 PC with GPIB input requiring extra cards and/or dongles, in contrasto with Ethernet that comes in for free on all' desktop and most laptops

[magetoo]

It's an interesting suggestion.  I've wondered why more people haven't seen what the Eurorack format has done for modular synthesizers and adopted something similar.

My own observation regarding software: If there is going to be portability of software, such that my power supply project can use the same software as yours, would require standardizing on a particular platform, be it a hardware platform like ARM or a software platform like Lua, Python, etc.  I don't think that is going to be easy.  Not to mention picking a license...

On the other hand, standardizing protocols for communication between modules could be reasonably simple.  I would hope that's going to be the central part of the proposal.  A physical format would be useful too.

[Kleinstein]

For GPIB you don't absolutely need that special hardware. It is only the output drivers - the logical control can be well handled by an µC. However the cables are rather expensive and large. So there is not that much advantage in using the old style cables.

The ethernet interface has the additional advantage of including electrical insulation, and it is quite fast too. However for a kind of bus / daisy-chain, it would take two ports or an external router.
The old coax style ethernet could cause quite some confusion with T&M equipment and modern PC don't have this any more.

USB might be interesting as it includes power - but an USB host is rather complicated.

For instruments on GPIB already have a kind of standard format, that many instruments use, but not all. No need to fix the µC - it is the data / command format that is fixed, not µC code.

[julian1]

At a higher level, SCPI, message format already exists,

https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments

The physical communications layer can be anything  which makes it flexible - eg, GPIB,  rs232, ethernet, or spi

[dino]

Hi guys,

Excellent idea!

Maybe we can borrow some ideas from the NI Compact RIO:

This device connects to the PC via ETH or USB, and the individual modules talk to the backplane via a DB connector (not sure whether it's a point to point or parallel bus).

Also there are a ton of computer bus backplanes (CompactPCI, VME), but these might be too complex/expensive for our use.

On the PC software side, maybe we could get Sigrok onboard, so there could be a complete opensource equivalent to commercial modular DAQ solutions.

[cdev]

Cost is important to many people, and so a project needs to look at cost as a good way of driving development. Focus on commodity off the shelf hardware as much as possible as building blocks.

SBCs excel at putting devices onto a home lan for less than an Ethernet card cost a few years ago. The AVR /"Arduino" has become so available wherever thats found lots of things become cheap.. Wherever these super cheap super rich ecosystems can be used to do something, use them. Since thats the main drawback of proprietary systems - that a DIY ecoststem doesnt have the burden of needing to support, reverse it and support areas where open hardware exists..

Watch out for feature creep and avoid proprietary devices and "standards" that aren't public. There are so many walled gardens, for a non-closed hardware communications platform to be successful it needs to avoid them all, or it becomes unaffordable.

An open model means there is no need to sell specific hardware, making it really mostly about letting lots of hardware communicate with one another using a minimal amount of additional hardware, ideally commodity off the shelf SBCs and devices which have become successful in the market and are starting to look fairly standardized.

[magetoo]

As long as we're throwing out ideas...

I'm imagining a series of modules that perform one function each, such as power supplies, signal generators, meters, etc.  They should be as simple as possible, and a system would have a control module for anything more complex than reporting a single reading or setting a parameter.


Physical format: Eurorack.  (a 3U subassembly)  No backplane.  Standardize power and communications on IDC connectors/pinheaders.

Inter-module communication: RS-232 bus at standard baud rates, maybe at TTL levels - available on every micro.  Modules could then also be used as stand alone instruments when connected to a computer.  Slow, but I can't think of anything I would want to DIY that needs to transfer lots of data.

Not everything has to go via this bus, I could imagine patching modules together via front panel connections for time-critical trigger signals, for example.

Controller module based on a Raspberry Pi or similar; talks to modules via serial, talks to workstation computer via Ethernet or whatever else is convenient.  Would run control software to do more complex operations, which would be written in Lua/Python or something else that is easy to hack.  Could also have a display.

Workstation interface: Not part of the specification, leave this for the open source community.

[Richard Crowley]

I love the concept, but I don't understand why we can't just start creating hackable interfaces for existing schemes like:

• Virtual Instrument Software Architecture (VISA) --
  https://en.wikipedia.org/wiki/Virtual_Instrument_Software_Architecture
• Standard Commands for Programmable Instruments (SCPIP) --
  https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments
• High Speed LAN Instrument Protocol (HiSLIP) --
  https://en.wikipedia.org/wiki/High_Speed_LAN_Instrument_Protocol

Aren't these all open source?
Is there some good reason to cobble together yet another interface?
Using an existing interface could provide interoperability with commercial products.

[jancumps]

I love the concept, but I don't understand why we can't just start creating hackable interfaces for existing schemes like:

• Virtual Instrument Software Architecture (VISA) --
  https://en.wikipedia.org/wiki/Virtual_Instrument_Software_Architecture
• Standard Commands for Programmable Instruments (SCPIP) --
  https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments
• High Speed LAN Instrument Protocol (HiSLIP) --
  https://en.wikipedia.org/wiki/High_Speed_LAN_Instrument_Protocol

Aren't these all open source?
Is there some good reason to cobble together yet another interface?
Using an existing interface could provide interoperability with commercial products.

For SCPI, there's a very nice open source C library available. I've used it on an ARM R and a BeagleBone. Fits on the UNO's ATMega too.

[prasimix]

Thanks everyone for inputs. Some of you already shares some of my thoughts and what I discussed with void_error.
I’d like to address immediately few issues that could improve discussion and simplify gathering of needed information that will be used in drafting DIB specification.

• Please be as specific as possible when you are mentioning building blocks that you find interesting. For example instead of “SBC”, please let us know what specific model(s) you have in mind, or instead of “very nice open source C library” please name it, specify link and if you like your experience with it. You can also list it in a Pro’s & Con’s manner that people get better understanding of key advantages but also disadvantages.
• It seems that we are agree that natural environment for such initiative is open source. Please think about licensing. Why? Because it can remove a lots of further frustrations when things starts to happen. It seems that open source software license is more mature and better understand what cannot be said for open source hardware. Due to that people used inappropriate licensing such as CC (Creative Commons) that are not intended for hardware design. I’d like to suggest the following:  for software GPL v3 or MIT, for hardware TAPR 1.0 and for documents and drawings we can use CC-BY-SA 4.0. Additionally I’d like to suggest that you are using into consideration for software part the Collective Code Construction Contract (C4)
   which regulate both code licensing and ownership. About possible benefits of C4 for any open source initiative please read this article from its author (Hintjens).
• We should start using central repository such as GitHub in early stage for simple reason because it offer version control and issue tracking. If structured well it can help us to manage different aspects of the DIB (i.e. electrical and mechanical specifications and drawings, building blocks, list of ongoing projects, etc.) more efficiently.
• Use and propose free and/or open source tools that can be used for shaping all parts of the initiative. Some of you already made such suggestion (i.e. SCPI, VISA, Arduino, etc.) Please keep posting it and try to provide more info about it as mentioned before. My idea is to make a repository of such tools that anybody interested in DIB can easily find them and start evaluate/use them.

[cdev]

Okay, the following is just my impression and I am an amateur who likely knows less than most of the people here.. so the following is with that caveat. My interest is I want people without access to expensive college or industry labs to be able to do science, for almost nothing. Not professionally, for fun and to remain sane, for personal satisfaction..

By SBC I mean "single board computer" and I guess I am implying 32/64 bit, linux capable SBCs like Raspberry Pi. Many other SBCs exist but often because they are closed source,  things like graphics drivers limit their upgrade-ability. There they may become limited to what the manufacturer releases. The RPI is far better than most in that respect. Since RPIs are reliably cheap and likely will remain so for the forseeable future if there is a standard among SBCs being used for FOSS projects that is likely it. Most software that can compile under gcc etc can work on any hardware platform where it can be compiled. The less hardware-specific software is the better.  (All?) desktop computers lack the GPIOs of Raspberry Pi wedding them to substantially more expensive add-in cards. The Raspberry Pi's GPIOs seem to lend themselves to cheap solutions for hardware access.

[julian1]

linux capable SBCs like Raspberry Pi. Many other SBCs exist but often because they are closed source,

The Pi story is actually pretty mixed so far as FOSS is concerned. From the debian wiki, https://wiki.debian.org/RaspberryPi

- A binary blob used by the GPU must be present on the SD card for the system to boot.
- While some hardware documentation has been released the documentation is sorely lacking.
- While schematics are available the board design is closed and the main processor is not available for purchase by the general public.

[void_error]

As long as we're throwing out ideas...

I'm imagining a series of modules that perform one function each, such as power supplies, signal generators, meters, etc.  They should be as simple as possible, and a system would have a control module for anything more complex than reporting a single reading or setting a parameter.

Physical format: Eurorack.  (a 3U subassembly)  No backplane.  Standardize power and communications on IDC connectors/pinheaders.

I'm actually working on something like that, just standardizing all my (work-in-progress) modules to use a simplified version of what prasimix has in mind, with power delivered via keyed pin headers and communications via IDC ribbon cables. Not designed with an Eurorack format in mind though but it might be adaptable.

[ajb]

I think trying to get a bunch of people to come together on any kind of mechanical form factor or complicated bus interface standard is going to be worse than herding cats.  Different types of instruments simply have too wide a range of mechanical and thermal requirements, and anything more mechanically complicated than a card form factor is going to run into issues of either cost or access to fabrication equipment for anyone who wants to build a compliant instrument. 

But if someone wants to kickstart an inexpensive, modular, plug-together housing system with panels that can easily be removed for machining or replaced with PCB panels, I'm all for that 

For the bus interface, you run into issues of getting everyone to agree on a set of features, voltage levels, transfer rates, etc.  You're going to have some people who want 5V TTL signalling for ease of hardware design, and others who want two dozen LVDS channels for maximum throughput, and good luck getting everyone to agree.  Something simple that preferably builds on existing protocols has the best chance of success, as long as there are clear advantages over using something that already exists.  For anything with Ethernet, there are a few good protocol options.  For a single, one-off instrument, I think you just use SCPI via USB/UART.  I think there's probably room for a simple, inexpensive bus interface that allows a bunch of instruments to be linked together and synchronized (synchronization is where USB/UART interfaces really fall down).  Here's my suggestion for a simple, easily-standardizable hardware interface:

Physical:
- 8P8C connectors, Cat5 cabling
- two 8P8C connectors per slave device for daisy chaining, one connector per bus on master devices

Electrical:
- RS 485 signalling on all signal pairs
- Pair 1: Primary serial UART
- Pair 2: Secondary serial UART
- Pair 3: Sync/Trigger
- Pair 4: Gnd (RS485 reference) and +5V@200mA supplied from the master system

The power supply is included to power the RS485 side of an isolated interface for those devices that require isolation (saves a potentially noisy isolated DC-DC or an expensive isolated transceiver), and possibly operating power for low-power slave devices.

Protocol:
- All devices shall be capable of communicating on either the primary or secondary UART link, but need not be capable of communicating on both simultaneously.
- All devices shall be capable of receiving a sync/trigger signal on the sync/trigger line, and may optionally be capable of driving the sync/trigger line.
- The master will periodically poll the bus and discovery of new slave devices takes place on the primary link via some mechanism I haven't thought about yet.  Probably binary search-based.
- The primary and secondary links may operate at different baud rates as befit the capabilities of the various slave devices or the needs of the overall system.
- All transactions start with a break signal from the master.  The break signal shall be exactly the length of two character periods to allow newly-joined slave devices to identify the current baud rate of the bus.
- At any point the master may command a slave device to switch all communication to the secondary link, or may direct a slave to response on the secondary link to a query issued on the primary link.  The master may also command a slave device to stream data continuously on the secondary line until directed to stop.
- A bus transaction begins with the master issuing a break signal followed by a brief idle period.  The first two bytes of the transaction packet constitute the address and subaddress.  Subaddressing is optional, but may be useful for something like a GPIB converter that may connect this bus to another bus with multiple instruments.
- The third byte of the packet is the format code.  A format code of 0 indicates that a bus management command follows.  A format code of 1 indicates that an SCPI-format command follows.  All other format code values are reserved.
- After the format code, the data portion of the message follows.  After the data portion, a 16-bit CRC is appended.

Obviously a lot of details to be fleshed out, but I think that sort of setup gives a good balance of ease of implementation, robustness, and flexibility, and since it requires SCPI as the default command interface there's less for people to disagree about.  Of course I'm sure everyone else will have their own ideas which are obviously much better than mine and here's why...

[magetoo]

I'm actually working on something like that, just standardizing all my (work-in-progress) modules to use a simplified version of what prasimix has in mind, with power delivered via keyed pin headers and communications via IDC ribbon cables. Not designed with an Eurorack format in mind though but it might be adaptable.

That sounds great.  It seems there are a few people who have already had the same idea separately, and I'm glad someone is actually doing it.

For the bus interface, you run into issues of getting everyone to agree on a set of features, voltage levels, transfer rates, etc.  You're going to have some people who want 5V TTL signalling for ease of hardware design, and others who want two dozen LVDS channels for maximum throughput, and good luck getting everyone to agree.

What sort of thing do you have in mind that would need lots of bandwidth?  The only thing I can think of is things like scopes or logic analyzers and I don't see many hobbyists building either, but maybe I'm missing something.

Edit: I like your ideas, very reasonable and the only thing that seems odd is the dedicated sync/trigger line.  That's something I'd imagine you'd want to have on the front panel instead, so that you could hook up other equipment you already have, and so you could change things around quickly without reaching for a computer keyboard.

[prasimix]

What sort of thing do you have in mind that would need lots of bandwidth?  The only thing I can think of is things like scopes or logic analyzers and I don't see many hobbyists building either, but maybe I'm missing something.

We don't need to be limited only to simple instruments, and your examples are just to the point. Think about the following scenario: anything that is build around agreed specification could be in one moment of time offered as a group buy, crowdfunding and hopefully thru one or more "cloners" who found it economically viable to start production in larger series. Therefore more advanced user can lead with more complex designs and capitalize from it in the first run. Beginners don't need to assembly nor dig into the details but can benefit from community support since everything is open sourced.

Edit: I like your ideas, very reasonable and the only thing that seems odd is the dedicated sync/trigger line.  That's something I'd imagine you'd want to have on the front panel instead, so that you could hook up other equipment you already have, and so you could change things around quickly without reaching for a computer keyboard.

Dedicated sync/trigger lines is a must when more advanced instruments is deployed. That save wiring and time to propagate signals and make measurements more accurate.

[prasimix]

Thanks ajb for mentioning lots of important points. I’ll continue then with cats herding and we’ll see if there is any chance to do that (possibly during the process we realized that no cats are in question ).

The electromechanical part of the specification can be seen as a lowest common denominator. I’m aware that many of us have different opinions, favors based on direct experience or simply belief. That’s fine and please take into account that what follows is just another suggestion and if we’d like to push this topic forward a proposal that is favored by majority of participant should have an advantage. Proposal that follows take into account the following facts:

• DIY/maker community is very diverse and that diversity is caused by many factors like people’s age, available spare time, finance, venue/legal requirements, knowledge level, etc.
• Bus means connectivity between two or more units, but that’s also possible that particular unit is deployed as standalone. When more units exists they can share the same housing (“mainframe”) or can be housed in more shared or standalone/single unit housing.
• Digital control could be centralized, present on each module/unit or mixed
• Specialized instrumentation bus and interfaces, already exists on the market.

”Mainframe”/chassis with backplane
Specialized instrumentation bus like VXI already exists and we can learn from it that is possible to pack any type of instruments on the card/module and that many modules can co-exist in the same mainframe. I believe that mainframe concept offers electrical, mechanical, thermal (assisted with forced air cooling) capability that can easily fulfill DIY needs. Also it’s space-saver, that many can found important.
Modules can be fixed/connected inside mainframe only mechanically when additionally wiring has to be provided to establish communication. Another solution is to introduce backplane, a series of connectors that improve mechanical strength and provide electrical connection. I think that backplane is way to go. Since this is a DIY, backplane shouldn’t need more then 2-layer PCB what also put some requirement to connectors that we can use.
The mainframe itself should be as simple as possible that one can make it using simple profiles (L and/or rectangle) and metal plates that can be easily cut to size. The max. width of such mainframe shouldn't be wider then 19". If we selected VXI’s 30.5 mm (1.2") as a width of single module we could go with up to 13 modules. Of course, if necessary, modules could be wider in increments of 30.5 mm (i.e. 61, 91.5 mm, etc.) and can use multiple connectors for mechanical strength and more control lines.
Now we comes to more trickier part that is modules height and insertion direction. I found visually very attractive height of 2U. It looks very compact. But most standards is based on 3U height. Module height is directly connected with “insertion” direction/orientation. Think about PC slots: insertion direction is vertical since a backplane, that is PC motherboard, is mounted horizontally. Thanks to that you can insert PC cards of various height and length as far as you do not exceed set limits. Actually you can mix and match various cards on the same PC. As far as I know this is not a case with industrial rack systems where backplane is mounted horizontally on the rear panel that is vertical. They are started with 3U height, and could be 6U and even 9U and length (depth) could vary but it's not possible to mix modules of different length because all of them has to be fixed on front side.
Note: please correct me if mentioned directions are misleading and has to be swapped.

So, if we choose vertical insertion we have more freedom to create boards with different height. Even if we don't have agreement about standard height (i.e. 2U or 3U) one can still make "low-profile" cards and insert it in mainframe that is set to 3U – you just need to mount it with 3U front panel.

Insertion orientation also set limits for bus connector(s). If horizontal backplane is selected then we have more room to positioning one or more connectors. I made one drawing in Eagle (you can also find .dxf export in attachment) to illustrate how that can be if horizontal backplane is used.
Main "disadvantage" is that you can not easily stack more boxes. But for DIYers that shouldn't be a problem. There is few of them who have a rack full of equipment (and indeed packed with "cooling fan sections" which noise could be unbearable .
Talking about cooling with horizontal backplane we have complete rear side available for cooling fans. That is not a case with vertical backplanes. You have to add an extra 1U on top or bottom of the mainframe. Therefore min. height became 4U (very bulky if you asked me)!



Module's front panels are fixed with L or rectangle profile on bottom plate that also carry backplane, and with other screw is fixed to L or rectangle profile that is mounted on top cover plate. Therefore if you'd like to remove any of modules you have to remove top plate first. Looks unpractical on first, but you don't need to have top plate during testing phase and when everything is completed you can fix it with screws to the rest of the mainframe.

Backplane connector(s)



Electrically we can work with two cheap and reliable connectors such like DIN 41612 Type 2C: female 09232486824 (backplane side) and male 09231486921 (PCB side). Three type of signaling should be available:

• Power is used for input and, if necessary, output power distribution. Some lines has to share multiple pins to allows total current of min. 5 A. That high current lines could be used to couple power outputs internally. As input power we can define "DC bus" like +48 Vdc and each module could derive all bias supplies from that voltage. Additionally we can specify voltage levels that can be much easier adopt to particular module power requirements, e.g. 3.3 V, +/-5 V, +/-15 V, etc.
• Analog is mainly small signal lines that can be used for internal wiring of signals that is not digitized because it's not critical or it's too fast/expensive for digitizing.
• Digital should be collection of various chip selects, triggering, sync/clocks and similar signals. I think that digital buses should be solely serial: multiple UART, I2C, SPI and CAN.

One "slot" (module position) should have special purpose: it has to be dedicated to CPU module. When full 19" wide backplane is used it should be placed in the middle. On shorter backplane (half or even quarter of 19") it can be located on one end.

Logically and electrically we should define mandatory (MAIN) and auxiliary (AUX) bus and try to be smart while allocating different functions to both of them. We can borrow some ideas from specifications such as VXI.
I’m aware the mandatory/auxiliary concept is an open call for trouble and incompatibility. Maybe it’s better to put that another way: BASIC and e.g. FAST/LEVEL2/ENHANCED. In that way two different type of modules should co-exist within the same mainframe with quite different power and signaling needs. For example simple instruments such as power supply or electronic load will use power and basic signaling of BASIC connector while digital oscilloscope will use fast signaling, triggering that is offered on the FAST connector.
Also on the BASIC connector we can define simpler way of communicate between Slot #0 (CPU module) and rest of the mainframe. I think that void_error could offer here an appealing proposal that use minimum number of control lines. That in the first place could lower pins requirements on the MCU side.

"Out of box" communication or communication with outside world
Communication outside mainframe/chassis can exists on different level:

• DIB chassis to DIB chassis,
• DIB chassis to DIB module,
• DIB chassis to propiatery/closed instrument(s) and
• DIB module to DIB module

Case #1
Pro’s: Your “lab” can grow beyond limitation of single chassis. Also if smaller/shorter backplane is initially selected and housed, you can continue to grow without throwing anything away.
Con’s: We need to specify inter-chassis communication, and define where connection point has to be located. I presume that should be the CPU module. Good candidates on lower layer are what you already proposed: Ethernet and serial (MAC, RS-485). I think that bridges such as USB-to-SPI could be a good and cheap candidate.

Case #2
Pro’s: Some modules especially complex and/or sensitive one could be detached from the rest of the system.
Con’s: Higher level of complexity, require own power supply, MCU and additional resources such as “local console” (i.e. LCD display, TFT display, encoders/keypads, etc.)

Case #3
Pro’s: Communication with legacy instruments can be established. A good candidate for interface are GPIB/IEEE-488 and serial (RS-232 or RS-485), but also Ethernet and USB for newer models.
Con’s: Additional complexity/cost related to GPIB (not a case for other interfaces)

Case #4
This is to my understanding that some of you already proposed.
Pro’s: High level of independence,
Con’s: See case #2

[magetoo]

It seems that we are agree that natural environment for such initiative is open source. Please think about licensing. Why? Because it can remove a lots of further frustrations when things starts to happen.

I hope people will settle on a small, simple license (BSD/MIT/ISC) rather than a huge legal document (GPL) here.  We're talking about fairly small pieces of code that will run on the modules, code that is useless without the hardware that goes with it.  Having something that is more nailed down isn't going to stop the clones on Ebay, but it might cause some friction when borrowing code.

[magetoo]

We don't need to be limited only to simple instruments, and your examples are just to the point.

I think we are going to be limited to simple instruments, as long as this is a "DIY" standard.  It seems like you have given this some serious thought, but looking at your next post the general direction looks more industrial to me, and less hobbyist.  I would consider buying instruments made for such a standard, but not building them.

[prasimix]

I'd like to highlight my first sentence from introductory post. This is an open call to people who already made or consider making T&M devices. Designing and building something represents quite different challenge then browsing around in a search for existing solution that fulfill one's needs and desires. That also means that they could count on different results and level of satisfaction and frustration. My starting point was that I want a fully programmable power supply and naively starts to build one two years ago. Can I buy an existing solution? Of course I can, but reviews from this forum's host, Dave, and few others just encourage me further in my intention to try to make something by myself.

It's in the same time funny and sad to see what engineers departments did or missed to do possibly due to the lack of time, resources, experiences or support from marketing department. That is not a case only with newcomers from China. A good exercise could be to browse thru multiple SCPI programming guide for the same type of instrument (e.g. power supply) produced by the same manufacturer (that change its name three times until now). It seems to me like internal war between different divisions or serious lack of communication. That cannot be easily explained with different "platform" (CPU type, capability, etc.) since SCPI is platform independent. I can imagine how extra work (=higher price) that generate both for the technical support and end user despite of middleware intended to mask such diversity. I can spare lots of time and money by simply buying available device and curse every time when something for me obvious on the "higher" level = firmware/software/UI is not implemented.

I started this discussion with simple presumption that is not possible at all that I'm the only one on this planet that think this way. I'm also aware that announcing any specification limits our freedom to some extent, and DIY/maker group enjoy freedom of doing something to the maximum possible extent (to what is already manufactured and what is defined by known law of existing science). But I cannot stop thinking of possible benefit for all of us if we can count on designs/modules that is not necessary just much cheaper then commercial solutions but offer on the first place an example that something is doable within DIY and it is open source. On the long run even traditional manufactures could learn something or get a message what people prefer and try to include that in their quite complex corporate processes. But my intention is not to give a lesson to anyone. I fill a great joy that I have currently on my benchtop something that I can tweak in one or other way infinitely and also that some people who found my project interesting and completed it fill equal joy.

To summarize, all what I propose in my posts is just an idea, and I'll be glad to find another few souls that resonate in a similar fashion and we'll see what that can bring to us and community in the future.

[ajb]

I really like the idea of having an open-source mainframe style instrumentation architecture, but I really don't foresee it taking off as a decentralized, ad-hoc pseudo-standard as you've laid it out.  In order for a backplane system to be successful it must:

- Have a defined way of managing interconnect resources and resolving conflicts (ie, I2C address collisions, allocation of cross-connect channels). 
- Assure that modules do not interfere with each other--the massive switching converter on someone's DIY power supply module shouldn't be allowed to introduce a bunch of noise that will interfere with someone else's precision voltmeter module, for example.
- Have a defined way of managing power budget.
- Have maximum bandwidth, line loading, and voltage level characteristics defined for all bus connections.
- Once you've defined all of the requirements above (and many more), in order to achieve reliable interoperation you must ensure that all developed modules comply with those requirements.

The more complicated the interface is, the less interest there's going to be in developing modules for it, and the harder it's going to be to ensure that those modules are compliant.

Regarding the 'CPU card', I'm wary of this idea.  Maybe if it's a raspberry pi, but this is another area where the software support must be developed and behaviors defined...it's also an additional cost and amount of effort that may not be necessary if the instruments can simply be connected to an existing lab PC instead.

The bottom line is, the more complicated this is to implement the less participation you're going to get.  The more options and loopholes and behaviors are left undefined, the less interoperability you will get.  If you want any chance of this succeeding:

- Fully define the behavior of devices on the bus.
- Minimize the hardware requirements for instrument devices so that defining requirements (and then implementing them) isn't an insurmountable amount of work. 
- Provide portable, easy-to-customize libraries for the interface.
- Provide working reference designs for a few basic devices.

If you really want to stick with a backplane/mainframe system, I don't see that being successful until someone designs and makes available for sale a complete mainframe system and several instrument modules that work out of the box (which means doing everything in the list above first!) and doesn't cost an arm and a leg.  Unfortunately I think the cost aspect is what really makes the mainframe idea a non-starter.  Low volume means it's going to be expensive to manufacture even before you try to recoup the engineering time to do all of the hardware and software development, and no one's going to want to spend $500 on an empty mainframe that they now have to spend hundreds of hours and hundreds of dollars developing hardware to plug into it.

Again, I really like the mainframe idea in principle, I just don't see it being successful as a framework for DIY instruments.  I think maybe it makes more sense to consolidate around an existing interface with maybe a thin wrapping that adds one or two really useful features that requires minimal hardware and can be used to link multiple instruments directly to a PC.  Build up some nice open source libraries for it and a few reference designs, then focus on developing a nice software suite to run it, and make sure it's easy for people to integrate their own instruments into the software.  Maybe require compliance with SCPI standard instruments, and have a nice profile builder tool for custom instruments.

[JPortici]

I've toyed with this idea for a while. what i would use: a "modified" canbus
canbus because besides bandwidth there is priority of information, everybody can talk to the bus when they have to and everybody can listen for the information they find useful, also there is no real master-slave so any device can talk to anybody

"modified" in the sense that i'd like to add a small number of async lines AKA triggers and such but i'm not sure if it will be doable

[PointyOintment]

I've toyed with this idea for a while. what i would use: a "modified" canbus
canbus because besides bandwidth there is priority of information, everybody can talk to the bus when they have to and everybody can listen for the information they find useful, also there is no real master-slave so any device can talk to anybody

"modified" in the sense that i'd like to add a small number of async lines AKA triggers and such but i'm not sure if it will be doable

How about MQTT?

[alex.forencich]

Every time I see one of these discussions, this comes to mind:



Why do we need a new standard?  There are already a lot of perfectly workable standards out there.  Frankly, it is exceptionally annoying when people roll their own communications protocols instead of using an existing standard.  There are lots of instruments out there that cobble together some proprietary protocol instead of either showing up as a USB serial port or implementing USBTMC.  It's infuriating.  For general purpose instrument control, implement USBTMC for USB connections and VXI-11 for Ethernet connections.  Or just use a simple serial port.  Then use SCPI for simple, easy to script text-based control.  There is no point in doing anything else unless you need a crazy amount of bandwidth. 

Now, for developing a custom backplane...I would highly recommend finding a way to leverage these existing protocols as much as possible.  For example, build a USB hub or Ethernet switch into the backplane and then use USBTMC or VXI-11.  That way you can leverage existing proprietary and open source drivers.  If you need serious bandwidth, then use something like PCI express.