Author Topic: "DIY instrumentation bus" (or DIB)  (Read 41691 times)

0 Members and 1 Guest are viewing this topic.

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
"DIY instrumentation bus" (or DIB)
« on: December 17, 2016, 04:32:15 pm »
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.

Offline filssavi

  • Frequent Contributor
  • **
  • Posts: 433
Re: "DIY instrumentation bus" (or DIB)
« Reply #1 on: December 17, 2016, 07:19:37 pm »
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
 

Offline magetoo

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: se
Re: "DIY instrumentation bus" (or DIB)
« Reply #2 on: December 17, 2016, 07:28:13 pm »
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.
 

Online Kleinstein

  • Super Contributor
  • ***
  • Posts: 14072
  • Country: de
Re: "DIY instrumentation bus" (or DIB)
« Reply #3 on: December 17, 2016, 07:41:28 pm »
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.
 

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 721
  • Country: au
Re: "DIY instrumentation bus" (or DIB)
« Reply #4 on: December 17, 2016, 07:42:21 pm »
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
 
The following users thanked this post: jbb

Offline dino

  • Contributor
  • Posts: 31
  • Country: cs
    • Hackaday profile
Re: "DIY instrumentation bus" (or DIB)
« Reply #5 on: December 17, 2016, 08:15:09 pm »
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.
 

Offline cdev

  • Super Contributor
  • ***
  • !
  • Posts: 7350
  • Country: 00
Re: "DIY instrumentation bus" (or DIB)
« Reply #6 on: December 17, 2016, 09:25:18 pm »
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.
« Last Edit: December 17, 2016, 09:56:43 pm by cdev »
"What the large print giveth, the small print taketh away."
 
The following users thanked this post: jolshefsky

Offline magetoo

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: se
Re: "DIY instrumentation bus" (or DIB)
« Reply #7 on: December 17, 2016, 09:57:36 pm »
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.
 

Offline Richard Crowley

  • Super Contributor
  • ***
  • Posts: 4317
  • Country: us
  • KJ7YLK
Re: "DIY instrumentation bus" (or DIB)
« Reply #8 on: December 17, 2016, 10:11:51 pm »
I love the concept, but I don't understand why we can't just start creating hackable interfaces for existing schemes like:


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.

« Last Edit: December 17, 2016, 10:14:03 pm by Richard Crowley »
 
The following users thanked this post: jbb

Offline jancumps

  • Supporter
  • ****
  • Posts: 1272
  • Country: be
  • New Low
Re: "DIY instrumentation bus" (or DIB)
« Reply #9 on: December 17, 2016, 10:38:37 pm »
I love the concept, but I don't understand why we can't just start creating hackable interfaces for existing schemes like:


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.
 

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #10 on: December 17, 2016, 11:29:44 pm »
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.

Offline cdev

  • Super Contributor
  • ***
  • !
  • Posts: 7350
  • Country: 00
Re: "DIY instrumentation bus" (or DIB)
« Reply #11 on: December 18, 2016, 12:12:16 am »
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.
"What the large print giveth, the small print taketh away."
 

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 721
  • Country: au
Re: "DIY instrumentation bus" (or DIB)
« Reply #12 on: December 18, 2016, 12:46:39 am »
Quote
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.
 

Offline void_error

  • Frequent Contributor
  • **
  • Posts: 673
  • Country: ro
  • I can transistor...
Re: "DIY instrumentation bus" (or DIB)
« Reply #13 on: December 18, 2016, 01:24:03 am »
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.
Trust me, I'm NOT an engineer.
 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 2582
  • Country: us
Re: "DIY instrumentation bus" (or DIB)
« Reply #14 on: December 18, 2016, 06:07:51 am »
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... ;)
« Last Edit: December 18, 2016, 06:13:54 am by ajb »
 
The following users thanked this post: jolshefsky, PointyOintment, Richard Crowley

Offline magetoo

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: se
Re: "DIY instrumentation bus" (or DIB)
« Reply #15 on: December 18, 2016, 10:43:37 am »
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.
« Last Edit: December 18, 2016, 10:51:02 am by magetoo »
 

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #16 on: December 18, 2016, 11:05:55 am »
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.

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #17 on: December 18, 2016, 11:07:54 am »
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

Offline magetoo

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: se
Re: "DIY instrumentation bus" (or DIB)
« Reply #18 on: December 18, 2016, 11:13:42 am »
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.
 
The following users thanked this post: garnix

Offline magetoo

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: se
Re: "DIY instrumentation bus" (or DIB)
« Reply #19 on: December 18, 2016, 11:23:30 am »
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.
 
The following users thanked this post: jolshefsky

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #20 on: December 18, 2016, 01:08:51 pm »
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.
« Last Edit: December 18, 2016, 01:18:47 pm by prasimix »
 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 2582
  • Country: us
Re: "DIY instrumentation bus" (or DIB)
« Reply #21 on: December 18, 2016, 05:16:36 pm »
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.
 
The following users thanked this post: PointyOintment

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: "DIY instrumentation bus" (or DIB)
« Reply #22 on: December 18, 2016, 06:32:46 pm »
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
 

Offline PointyOintment

  • Frequent Contributor
  • **
  • Posts: 327
  • Country: ca
  • ↑ I scanned my face
Re: "DIY instrumentation bus" (or DIB)
« Reply #23 on: December 19, 2016, 03:32:08 am »
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?
I refuse to use AD's LTspice or any other "free" software whose license agreement prohibits benchmarking it (which implies it's really bad) or publicly disclosing the existence of the agreement. Fortunately, I haven't agreed to that one, and those terms are public already.
 

Offline alex.forencich

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: us
    • Alex Forencich
Re: "DIY instrumentation bus" (or DIB)
« Reply #24 on: December 19, 2016, 06:54:59 am »
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. 
Python-based instrument control: Python IVI, Python VXI-11, Python USBTMC
 
The following users thanked this post: Richard Crowley, jbb, 2N3055

Offline mubes

  • Regular Contributor
  • *
  • Posts: 237
  • Country: gb
  • Do Not Boil
Re: "DIY instrumentation bus" (or DIB)
« Reply #25 on: December 19, 2016, 10:33:16 am »
Folks,

Sory I'm slightly late to this party, but has anyone considered Automotive Ethernet? http://www.opensig.org/ or https://en.wikipedia.org/wiki/OPEN_Alliance_SIG.  I don't know so very much about it, but it seems to have multidrop capability and supports different classes of transport.  Any open instrumentation bus is going to need to be capable of doing that if its going to be generally applicable.

Regards

DAVE
 

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #26 on: December 19, 2016, 11:44:12 am »
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. 
Thanks for another batch of valuable inputs. Not really understand what decentralized means. Thanks also for label "pseudo" that is a reminder that it does not come from establishment. But unlike establishment I'm not ready to start another "religious war" to defend my position but want to hear an learn from you guys. So, lets move on...

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).
That’s right, but I didn’t even came to this point. I’m aware for possible issues with mentioned I2C. Situation with e.g. SPI could be a little bit better but still it’s possible that two modules allocates the same CS signal. Hopefully we can borrow something from VXI and similar specifications: on the backplane level they don’t have anything more then multiple CS signals. Therefore some kind of CS on the module level must be present (jumpers, or something else). Your input are welcome.

- 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.
Here we can also follow VXI practice: they are recommending shielding on the module level for sensitive circuits. That mean that whole module can be shielded or part of the PCB can carry shielding.

- Have a defined way of managing power budget.
- Have maximum bandwidth, line loading, and voltage level characteristics defined for all bus connections.
Ok, that should be clearly stated in specification. Also e.g. max. capacitance on the each input power line has to be specified.

- 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.
Don’t see a way how to insure idiot-proof solution. Did anyone succeed with that so far? It’s possible to some extent to make some testing into firmware/libraries, but even that cannot ensure a lot. Ok, “corporate specification” usually offer or even demand some certification procedures. I think that in our case the voice of community would be the best judge does one should include certain design/module into the lab or not.

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.
Exactly! That is true on all levels starting from backplane or other way of electromechanical module interconnection. That’s why 15th specification is proposed that could serve DIYers/makers better then VXI or some other :).

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.
For the sake of specification simplicity (what we already addressed above) I think that DIB should be CPU/MCU agnostic. It could be any ready-to-go board such as Raspi, Ardiuno, Beaglebone, Launchpad, etc. Obviously such boards require some kind of “piggyback” on the hypothetical “CPU Slot #0” what is not necessary so bad, because on the same board/module one can put some additional circuity that is not available on the selected board itself (e.g. more memory, RTC, Ethernet, etc.).

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.
I’m agree and can provide in the foreseeable future at least one working reference design: a multi-channel power supply with local (TFT touch-screen) and remote control (SCPI over USB and Ethernet).

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.
Thanks for mentioning this and round figure of $500. I heard in some other discussions a similar figure (€500) here in Europe. My stance is if entry level mainframe cost more then €80 then something is wrong. Lets say that entry level is 4-slot mainframe. I’ll continue with “horizontal” backplane introduced in my latest post but it also can be a “vertical” on like in we’d like to use Eurocard or similar form factor. The backplane could looks like this:



The cost even in qty of 2 using European manufacturer (not Chinese one) is €30 per backplane (2-layer, 35u Cu, no silk screen):



On top of that we’ll need 8 connectors (about €14) and visit to local hardware store that carry steel or Alu plates (e.g. 1.5-2 mm thick) and L-profiles. I believe that can be get for not more then additional €20. Of course you have to cut on size plates to get up to 4 front panels, and rest of the chassis. But that is a “business as usual” for DIYer/marker, isn’t it? And, yes some hardware stores also offers for a little bit more already perforated plates that can be used for e.g. top side for better cooling.

8-slot backplane doesn’t cost much more: according to the same manufacturer calculator it is about €40:





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.

I’d like to join any initiative that could save benchtop space, money and time. I don’t have neither interest, time nor knowledge to build up a whole lab. Hopefully this topic will not die even before it starts to present that is possible to bridge the gap between DIY and commercial world in an efficient way.

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #27 on: January 21, 2018, 04:39:33 pm »
After long time I came back to this topic that is still living in my mind. I'd like to continue it but this time with another component that should shape future DIB progress, and that is control or MCU board.
I was started my journey in placing on my benchtop equipments that is tailored in line with my wishes using Arduino as a control board. Despite the fact that my first device, a bench power supply, is rather trivial in sense of needed processing power it became obvious pretty soon that is not a case if you'd like to make it fully programmable and going beyond 7-segment LED or 2x16 LCD display as primary user interface. Therefore the PSU ended up controlled with 32-bit ARM based Arduino Due board that is actually not a real representative of Arduino world and Arduino team itself gave up long time from its production and with just dozen new software commits in previous year in its GitHub it can be said that is pretty dead (not to mention that even in its active phase many things were not supported as in case of AVR MCUs).
A next step in using more capable solution could be to choose between few very potent candidates, where e.g. STM32 with their Discovery evaluation boards looks like excellent choice. But, again when I start thinking about a little bit more demanding tasks where e.g. multi-Mbps of data have to be transfered and processed and that some of processes should we done in parallel for more acceptable end result then it's easy to came up into position to take into account SoC and FPGA to assist MCU.
FPGA is a different world, that is still waiting that both my colleague (software developer) and I discover, and nobody of us are eager to do that any time soon. So, one possibility is to try to use SoC or cheap SBC like Beaglebone, RasPi (or similar fruit variants like BananaPi, OrangePi, itc.) to take care about "hi-level" taks such as host communication, display control, media/USB control, etc. But, even with RTOS in one part of the solution it's questionable how some time critical operation can be handled, i.e. without measurable execution "jitter". But, there is another candidate that is still pretty exotic (i.e. "risky") and well known between digital audiophiles: XMOS multicore MCUs. It looks like something between MCU and FPGA, that can be programmed in C or XC that comes with extended set of commands for handling tasks in parallel. Parallel is the keyword for this MCU family, something that make it closer to FPGA then ordinary MCU. Although it really lack some basic features of top-grade MCU, processing power and possibility to process more tasks in parallel with resolution below 10 ns (!) make it really interesting for me. Additionally, even if number of resources on single MCU is not enough, you can easily make a true grid with e.g. 2, 4, 16 MCU that compiler could easily access. Also possibility to works with different version of firmwares and update firmware from single place (if more then on MCU reside on single or multiple boards) promise easier maintenance.
A list of features is amazing, but I'll continue to talk about things that could be placed anywhere from questionable to possible show stoppers:
  • xCORE MCUs comes from single fabless company XMOS. They have a great experience with parallel processing and was involved with things like Transputers from 80's.
  • Limited number of suppliers, three in total: Digikey, Farnell, Future, no my favorite TME :(
  • Unit price and bulk price is not small but neither too high if it can deliver what is advertised
  • One cannot expect a great community for something this is still exotic, but they have forum (xcore.com). My current experience with it is quite different from this forum or some others: it can be descried as "slow" with very small number of active members and many observers. I'm still wondering how to receive an "official" or reputable answers to my questions and doubts
  • No flash (memory) even if flash is there! That really confused me on the beginning but, I start to live with it and as previously mentioned that could make firmware uploading task very flexible and easy. In short, MCU comes in two flavors with and without flash memory (has F letter in the name, e.g. XEF216 instead of XE216). But, flash cannot be reached directly and must be loaded into working/internal RAM!
  • Limited and segmented available RAM: xCORE comes with max. 256KB of RAM per tile (one tile carry up to 8 logical cores). That's all! If 512KB is advertised that is in reality 2 x 256KB, and cores from one tile cannot access RAM from another one. When you take into account previous "flash feature" then it seems that one could be very careful about what to put into firmware. Just for comparison, top-class MCUs comes with up to 4MB of flash memory (per core) and I do believe that is not just a pure luxury but a real world necessity.
  • Most of activities on official web site, GitHub and forum (app. notes, libraries, discussion that include XMOS team, etc.) seems that are dated a few years ago. Therefore one could expect a lot of missing link and information that is related to EOL (or soon to be) products. That can be understand to some extent - company crew had more time on the beginning for support and presentation of what they are offering.
Anyway, despite all that I decided to make a try with xCORE MCUs simply because I can (still) afford such luxury :). It could be at the end a complete failure or something that cannot be easily labeled with "just another xyz MCU based (and equally limited!) solution"! I have no illusion that it could replace usage of FPGA, but it definitely should over-perform MCU on many fronts. One of them is "boring" debugging. Its free and open source IDE (xTIMEcomposer based on Eclipse) offers non-intrusive debugging in real-time. Crazy stuff, all what you need is a xTAG debugger (decently priced) connected (if board has XSYS 20-pin IDC connector). An introduction in so-called xScope can be seen in the following video:



I was thinking how to start with XMOS evaluation. They started few years about with startKIT board that is now obsolete and replaced with eXporerKIT that comes with xCORE-200 (2nd generation) MCU. There are many others that can be expanded with sliceCARD modules. Mentioned eXporerKIT alone is not cheap by evaluation board standards (106 GBP), but include 15 GBP xTAG debugger, Gigabit Ethernet and USB 2.0 port. What is really missing is something that can be found on sliceCARD: LCD controller and SDRAM needed for frame buffering. For that one should go with even more expensive board, and I need everything multiplied by 2. At the end if we decided to continue working with it, I need do make my own PCB as part of DIB project. Therefore I decided to make my own evaluation board following schematics of existing boards and do that for the very first time on the 4-layer PCB.
What I made so far is from today available on the Github here, and I'll try to explain my intentions and design in more posts that follows (before I continue to start talking about DIB again).

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
DIB pin mappings proposal
« Reply #28 on: February 10, 2018, 04:11:40 pm »
Here is the first proposal of pin mappings for backplane that I'd like to use to connect more modules within a single chassis.

The foundation of everything is a digital control based on the principle of a single processor (master) module that would take care of more peripheral (slave) modules. Although a good specification should be "architectural agnostic" this one is, as you will see, inspired or suggestive of using a XMOS parallel processing MCU, but that does not mean it could not be usable with any other MCU family.

Power lines
3.3 V is used as the main power supply for peripheral modules. It is also backed up with  +3.3VAUX and Vbat outputs that should be used for standby mode. The additional power supplies are +5V, +12V and -12V. In addition, several pins for GND are provided. There is currently no PE (Protective Earth) that may need to be added to avoid providing additional wiring out of the modules if necessary. A possible advantage of using the separate wire is higher current rating as perhaps better/easier arrangement of the star structure.
The power supply section can be placed on the processor module itself or brought from the outside.

System signals
It is envisaged to bring a "master clock" signal of 100 MHz to all peripheral modules. Because of the speed, it might be mandatory to be provided over differential lines. For this reason, I predicted two pins for it: MASTER_CLK+ and MASTER_CLK-. It should not be confused with the SPI clock signal, since it is provided through SCLK1 to SCLK7 pins.
#RESET is the next important system signal generated by a reset generator/power supervisor on processor module #0.
Optional, or maybe better to put them as mandatory from the beginning, are five signals for JTAG debugging (TDI, TDO, TCK, TMS, #TRST).

Communication between modules
The basic communication between processor and peripheral modules is SPI where for each module a separate SPI channel is dedicated to enable parallel operation, assuming that the CPU/MCU is capable of doing something like this, as in case of the mentioned XMOS xCORE. If other MCU is to be used then it will be necessary on the processor module to merge multiple SPI channels to what the MCU (at least on the physical level or pins) offers separately. Plenty of MCUs have several SPI channels, the other thing is that there is still just one processor core that have to deal sequentially and not in parallel with the connected peripherals.
SPI channels have three signals SCLK, MOSI and MISO. The question remains what about CS (Chip Select) which is also needed if we have more than one SPI device on the same SPI channel. For this purpose, pins #CS1 to #CS7 are foreseen. Now, this would mean that it is possible to have only one SPI device per module. However, with simple trick it become possible to address x peripherals. We have to deploy a SIPO register such as '595 for addressing up to 8 peripherals, of more if they are daisy-chained (16, 24, etc). Of course, the greater the number of SPI peripherals on the module, the access time could be slower. However, since the '595 has access speed that largely exceed the usual SPI speeds, it would in this way greatly or wholly neutralize the delay of such addressing. E.g. if the SPI device with max. speed of 4 MHz is used, and there are up to 8 of them, if the '595 is accessed with more than 30 MHz first, and then proceeds with SPI communication at 4 MHz, the end result should be the same as if '595 is not present at all. Furthermore, I assumed that we could have a very fast SPI devices on the first two slots (closest to the MCU!) and want them to access with, say 20 MHz. In that case, the '595 signaling could also go over 100 MHz. For this reason it is envisaged that CS1 and CS2 can be differential, so we have #CS1 Diff+, #CS1 Diff-, CS2 Diff+ and #CS2 Diff-.

Additionally, for slower functions, I2C can be used, which is shared between all peripheral modules (slot #1 to #7).

Finally, if using xCORE, they allow multiple MCUs to be interconnected for e.g. more processing power and I/O lines. This means that main processor resources are no longer necessary resides on slot #0 only, but may be on other slots, too. For such a connection, a 2-wire xCONNECT bus is used, which is slower than a 5-wire variant but consumes fewer pins on both MCUs and connectors (4 instead of 10, or 8 instead of 20 if differential). xCONNECT would be theoretically (and probably practically as advertised by XMOS) used for fast serial communication that should be at least 10 times faster than the usual SPI.
The processor module has an xCONNECT channel that can be used to connect to the remaining modules, but also to connect to another chassis that will have its own processor module and associated peripheral modules.

Triggers and analogue switches
For the purpose of synchronizing activities between multiple peripheral modules, trigger inputs and outputs are used. Star topology is implemented, i.e. all inputs and outputs are terminated at one end on the processor module. The MCU is therefore in charge of waiting for the trigger (on inputs) and sending the trigger to one or more modules. In the case of a xCORE MCU with a predictable resolution of less than 10 ns, a precise synchronization of multiple modules can be expected.

In addition, I took from the VXI specification the use of cross-point switching that allows the redirection of (analog) signals from x to y module. Depending on the speed required, there are chips that do this for decent price in range from 45 (MT8808) to 300 MHz (ADG2188).

______________________________________________________

Below (and in attached PDF) is shown the pin mappings of the #0 connector that has 96 pins (3x32) and other 48-pin (3x16) connectors/slots. The connector suggestion is at the bottom of the text.

As usual, your comments and suggestions are very welcome :).





Offline awallin

  • Frequent Contributor
  • **
  • Posts: 694
Re: "DIY instrumentation bus" (or DIB)
« Reply #29 on: February 10, 2018, 05:36:22 pm »
Looking at your drawing there are two connectors on a 114 mm high board, that's 57mm or less of the moduble PCB towards the 'front-panel' if I understand correctly.
For something like a PID-controller you want multiple coax-connectors on the front panel (set-point, sensor in, actuator out, monitor out, etc).
For example normal 90-deg BNC connectors are ~16mm wide and can be spaced ~16mm apart, so there would be room for only 3 BNC's on a 57mm edge.

Did you consider 100mm high 'eurocard' cards that would also fit a standard 3U rack/subrack format?

Given the EEZ naming of your bus - are the EEZ powersupply parts in the bus format?   ::)
 

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #30 on: February 10, 2018, 10:03:38 pm »
Almost all of the previous drawings are now obsolete. I'm going to make another backplane proposal and dimensions related to the chassis/subrack that can carry a) up to 4 (MCU + 3 modules) or b) up 8 modules that is max. for one chassis. Yes, 3U height is planned and min. width for "slave" modules will be a little bit larger: 7 HP (35.56 mm) or 8 HP (40.64 mm). Width of MCU module could be larger to carry e.g. 3.5" or 4.3" TFT display + other stuff (encoders, trigger I/Os, etc.). Therefore 100 mm high card is planned but not necessarily in any of "Eurocard" formats or at least I'm not going to put DIN connector on the rear but on the bottom (like cards in a PC).

I'd like to make power supply module as first example that use this bus. But this time such module will carry end-to-end functionality, i.e. AC/DC SMPS pre-regulation and linear post-regulation. Therefore 3rd party AC/DC adapter (currently it is Mean Well) and DC-DC SMPS pre-regulator should go out of the picture.


Offline jbb

  • Super Contributor
  • ***
  • Posts: 1128
  • Country: nz
Re: "DIY instrumentation bus" (or DIB)
« Reply #31 on: February 11, 2018, 02:44:45 am »
    I like the thought of an accessible, (largely) open-source instrument spec, and I'm glad to see someone having a go. I believe that the engineering school at EPFL (Lausanne, Switzerland) did something with ARM host processor and USB rack backplane, but can't seem to find any info on it (maybe died of neglect when critical students finished their PhDs).

    Here are some thoughts:
    • I expect DIYers like DIYing. So it's important that people feel that they get some benefit from the spec rather than just building whatever.
    • People will be tempted to skip 'difficult' or 'annoying' bits of the spec. There may need to be an 'official' test scheme to say that yes, such-and-such is sufficiently compatible (note: this could be a self-test and the developer fills in a report card. No need to spend mega-bucks at a lab.). Writing such test procedures is, unfortunately, difficult and time-consuming.
    • Sorting out a connection or racking system is really important.  If it's a racking system, the not-at-all simple act of saying 'here are the card dimensions, here's a comprehensive parts list, you can buy them from vendors X Y and Z' is critical.  There are probably some good Aliexpress options, but someone needs to research, acquire and check out some samples.
    • Great example projects would be important as a springboard for widespread adoption.

    On the electronics/communications side, I think that:
    • Having some kind of card ID system (e.g. using I2C) with well-defined data structures is a good idea.  That way the master can either a) use the right driver or b) complain.  Could also store calibration info.
    • Facilities for isolation should be available (e.g. 5V/12V DC supply sufficient to run isolator systems) and easy for module designers to use.
    • Low bandwidth modules (e.g. DC power supply) don't need much bandwidth, so they should be able to use a cheap connection. (We don't want to pay for an FPGA in a basic DC supply...)
    • Medium/high bandwidth modules (e.g. analog capture or DAC) need more bandwidth (and probably clock + trigger distribution), so they will need a more capable connection (and there people might be willing to pay for an FPGA).
    • The module designer should be able to choose what goes into their module, so the comms should be fairly generic and vendor-independent.

    I would suggest a tiered comms system, where the designer picks the appropriate level:
    • Card ID (e.g. I2C or SPI bus) + basic low speed comms
    • Clock and trigger distribution
    • High bandwidth

I'd like to make power supply module as first example that use this bus. But this time such module will carry end-to-end functionality, i.e. AC/DC SMPS pre-regulation and linear post-regulation. Therefore 3rd party AC/DC adapter (currently it is Mean Well) and DC-DC SMPS pre-regulator should go out of the picture.

Err, I love power electronics, but I'd be a bit nervous about promoting built-it-yourself power supplies with large quantities of 380V DC inside (after PFC stage).  If you look through my post history I'm the often saying 'safety safety safety!' to people, 'cause I don't want anyone to get killed. Maybe part of the spec should include an 'external' type connection so the scary power stuff can be put in a separate enclosure?
 
The following users thanked this post: prasimix

Offline jbb

  • Super Contributor
  • ***
  • Posts: 1128
  • Country: nz
Re: "DIY instrumentation bus" (or DIB)
« Reply #32 on: February 11, 2018, 02:47:58 am »
Also, I'd like to be involved :-)
 

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #33 on: February 11, 2018, 08:49:12 am »
      I like the thought of an accessible, (largely) open-source instrument spec, and I'm glad to see someone having a go. I believe that the engineering school at EPFL (Lausanne, Switzerland) did something with ARM host processor and USB rack backplane, but can't seem to find any info on it (maybe died of neglect when critical students finished their PhDs).

    If you talk about Easy ? it is still around.

    Here are some thoughts:
    • I expect DIYers like DIYing. So it's important that people feel that they get some benefit from the spec rather than just building whatever.
    • People will be tempted to skip 'difficult' or 'annoying' bits of the spec. There may need to be an 'official' test scheme to say that yes, such-and-such is sufficiently compatible (note: this could be a self-test and the developer fills in a report card. No need to spend mega-bucks at a lab.). Writing such test procedures is, unfortunately, difficult and time-consuming.

    You're right. I believe that a sort of test procedures will come out of our development and be published as all other stuff.

    • Sorting out a connection or racking system is really important.  If it's a racking system, the not-at-all simple act of saying 'here are the card dimensions, here's a comprehensive parts list, you can buy them from vendors X Y and Z' is critical.  There are probably some good Aliexpress options, but someone needs to research, acquire and check out some samples.
    • Great example projects would be important as a springboard for widespread adoption.

    I spent some (but possibly not enough) time to find out what kind of connectors are available with good price/performance. It seems that DIN 41612 are very attractive with price around 2 USD, good pin density and mechanical strength. All your suggestions are highly welcomed.

    On the electronics/communications side, I think that:
    • Having some kind of card ID system (e.g. using I2C) with well-defined data structures is a good idea.  That way the master can either a) use the right driver or b) complain.  Could also store calibration info.

    Ok, I can see here two approach: a very simple reading out 8-bit register that has hard wired ID number (e.g. up to 254 devices, if 00 and FF are reserved/forbidden) and another with on-board cheap EEPROM (started today about 0.25 USD) where ID number and some other data (like calibration that you mentioned below) can be stored. Issue with later is how to program it conveniently for the first time.

    • Facilities for isolation should be available (e.g. 5V/12V DC supply sufficient to run isolator systems) and easy for module designers to use.

    I think that specified power lines can remain and we can introduce another one e.g. 12, 15 or 24 V that can be used for supplying module isolated power stage.

    • Low bandwidth modules (e.g. DC power supply) don't need much bandwidth, so they should be able to use a cheap connection. (We don't want to pay for an FPGA in a basic DC supply...)
    • Medium/high bandwidth modules (e.g. analog capture or DAC) need more bandwidth (and probably clock + trigger distribution), so they will need a more capable connection (and there people might be willing to pay for an FPGA).
    • The module designer should be able to choose what goes into their module, so the comms should be fairly generic and vendor-independent.

    At the beginning I was thinking about "mandatory" and "auxiliary" connectors. Now, I tried to put as much as possible on mandatory/primary connector to cover work with different modules/functionalities. For extra ("FPGA-class") stuff maybe we should introduce over the time another connector what is actually viable to do when backplane/connectors are placed at the chassis bottom not rear side.

    I would suggest a tiered comms system, where the designer picks the appropriate level:
    • Card ID (e.g. I2C or SPI bus) + basic low speed comms
    • Clock and trigger distribution
    • High bandwidth

    Yes, something like that.

    I'd like to make power supply module as first example that use this bus. But this time such module will carry end-to-end functionality, i.e. AC/DC SMPS pre-regulation and linear post-regulation. Therefore 3rd party AC/DC adapter (currently it is Mean Well) and DC-DC SMPS pre-regulator should go out of the picture.

    Err, I love power electronics, but I'd be a bit nervous about promoting built-it-yourself power supplies with large quantities of 380V DC inside (after PFC stage).  If you look through my post history I'm the often saying 'safety safety safety!' to people, 'cause I don't want anyone to get killed. Maybe part of the spec should include an 'external' type connection so the scary power stuff can be put in a separate enclosure?

    I'm not going to promote anything in that area that is not heavily tested on my side and didn't review from someone that is an expert in the field just because of safety: my safety in the first place and then safety of anyone alse. That was the reason why EEZ H24005 power supply comes with Mean Well AC/DC adapters. If I succeed in making a robust and safe AC/DC section, great, I'll share it with others, otherwise I'll keep my mouth shut :).

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #34 on: February 11, 2018, 08:50:26 am »
    Also, I'd like to be involved :-)

    Actually you already are, keep posting your comments and suggestions  :-+.

    Offline awallin

    • Frequent Contributor
    • **
    • Posts: 694
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #35 on: February 11, 2018, 10:06:33 am »
    If you talk about Easy ? it is still around.

    this one might be worth a look also:
    https://openhpsdr.org/atlas.php
     
    The following users thanked this post: Richard Crowley, prasimix

    Offline void_error

    • Frequent Contributor
    • **
    • Posts: 673
    • Country: ro
    • I can transistor...
    Re: DIB pin mappings proposal
    « Reply #36 on: February 11, 2018, 02:32:06 pm »
    Communication between modules
    The basic communication between processor and peripheral modules is SPI where for each module a separate SPI channel is dedicated to enable parallel operation, assuming that the CPU/MCU is capable of doing something like this, as in case of the mentioned XMOS xCORE. If other MCU is to be used then it will be necessary on the processor module to merge multiple SPI channels to what the MCU (at least on the physical level or pins) offers separately. Plenty of MCUs have several SPI channels, the other thing is that there is still just one processor core that have to deal sequentially and not in parallel with the connected peripherals.
    SPI channels have three signals SCLK, MOSI and MISO. The question remains what about CS (Chip Select) which is also needed if we have more than one SPI device on the same SPI channel. For this purpose, pins #CS1 to #CS7 are foreseen. Now, this would mean that it is possible to have only one SPI device per module. However, with simple trick it become possible to address x peripherals. We have to deploy a SIPO register such as '595 for addressing up to 8 peripherals, of more if they are daisy-chained (16, 24, etc). Of course, the greater the number of SPI peripherals on the module, the access time could be slower. However, since the '595 has access speed that largely exceed the usual SPI speeds, it would in this way greatly or wholly neutralize the delay of such addressing. E.g. if the SPI device with max. speed of 4 MHz is used, and there are up to 8 of them, if the '595 is accessed with more than 30 MHz first, and then proceeds with SPI communication at 4 MHz, the end result should be the same as if '595 is not present at all. Furthermore, I assumed that we could have a very fast SPI devices on the first two slots (closest to the MCU!) and want them to access with, say 20 MHz. In that case, the '595 signaling could also go over 100 MHz. For this reason it is envisaged that CS1 and CS2 can be differential, so we have #CS1 Diff+, #CS1 Diff-, CS2 Diff+ and #CS2 Diff-.

    Do you mean something like this? By using line decoders you can even ditch the 595s since you're looking at 7 #CS pins anyway since there shouldn't be more than one Chip Select line pulled low on the bus at any given time anyway. Also, why the odd number (7), no pun intended? In the schematic section below I found it a lot simpler to use a 3-to-8 decoder instead of another 595 and it also comes with inverted outputs. It's all down to how many SPI devices you'll have on the bus.
    Trust me, I'm NOT an engineer.
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #37 on: February 11, 2018, 02:44:41 pm »
    Maybe using CS (Chip select) label is confusing. It's module (or card) select in the first place. Therefore only one CS line reach each of 7 modules, and if you have more then one SPI device on one module you have to "decode" their chip selects. A star-topology is used (1-to-many) to connect MCU with each module, and due to that peripheral modules needs smaller connector then processor module. In case of xCORE you can simultaneously (in parallel) communicate with all seven boards via dedicated SPI channels at once!

    Why number seven? Because it's 8 minus 1 (processor board on slot #0) :).

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #38 on: February 11, 2018, 07:45:06 pm »
    I spent some (but possibly not enough) time to find out what kind of connectors are available with good price/performance. It seems that DIN 41612 are very attractive with price around 2 USD, good pin density and mechanical strength. All your suggestions are highly welcomed.
    Yeah, connectors are hard. Do they have some pins which are a bit longer than others and engage early?

    Ok, I can see here two approach: a very simple reading out 8-bit register that has hard wired ID number (e.g. up to 254 devices, if 00 and FF are reserved/forbidden) and another with on-board cheap EEPROM (started today about 0.25 USD) where ID number and some other data (like calibration that you mentioned below) can be stored. Issue with later is how to program it conveniently for the first time.
    I was thinking some of the connector pins could be used to encode the backplane slot #, and feed them to address lines on the I2C EEPROM.  The EEPROM can be programmed by plugging it into the backplane and using some 'special' master commands (maybe with a removable jumper for write-protection.  Reference design material should include the appropriate (low cost but reliable) EEPROM, addressing scheme, scripts (Python?) for generating configuration descriptor etc.

    I think that specified power lines can remain and we can introduce another one e.g. 12, 15 or 24 V that can be used for supplying module isolated power stage.
    Yes, that's probably good.  Final voltage TBA. I would suggest a separate power ground return as well to keep power return currents out of the signalling.

    At the beginning I was thinking about "mandatory" and "auxiliary" connectors. Now, I tried to put as much as possible on mandatory/primary connector to cover work with different modules/functionalities. For extra ("FPGA-class") stuff maybe we should introduce over the time another connector what is actually viable to do when backplane/connectors are placed at the chassis bottom not rear side.
    Mandatory + auxiliary (or 'Core' + 'Expansion' or whatever) is a good concept.  Some people looking at this will be highly cost sensitive.

    Also, I suggest starting with the Mandatory part, because you will likely at some point say 'this isn't quite right, I need to make some big changes.'  That will probably break some compatibility, and is one of the costs of good engineering. You have to be willing to do a big revision to capture lessons learnt, or you end up with the Arduino pin header offsets.

    Arduino probably should have said, 'oh, this is a mistake, we'll change the spec to make sense and redo a few shield designs,' but instead they kept going and now all Arduinos have a funny pin spacing.  When people make items like this, the specification is flawed.

    Maybe using CS (Chip select) label is confusing. It's module (or card) select in the first place. Therefore only one CS line reach each of 7 modules, and if you have more then one SPI device on one module you have to "decode" their chip selects. A star-topology is used (1-to-many) to connect MCU with each module, and due to that peripheral modules needs smaller connector then processor module. In case of xCORE you can simultaneously (in parallel) communicate with all seven boards via dedicated SPI channels at once!

    Why number seven? Because it's 8 minus 1 (processor board on slot #0) :).

    Maybe the master should spit out 7 Module Select signals (one per module) (or even 7 separate SPI busses) and a few Chip Select signals (maybe 4??, could be shared across all modules). That way some simple cards (e.g. relay output channel / basic ADC / basic DAC) could be built with SPI chips and no micro.

    Or maybe a cheap & cheerful bunch-of-UARTs would be the solution? That way developers wouldn't have to make SPI slave firmware, which can be a bit tricky. (But then you would almost always need a micro.)
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #39 on: February 12, 2018, 10:15:14 am »
    Yeah, connectors are hard. Do they have some pins which are a bit longer than others and engage early?

    Not ones that I have/suggested. What do you have in mind a hot-swap capability?

    I was thinking some of the connector pins could be used to encode the backplane slot #, and feed them to address lines on the I2C EEPROM.  The EEPROM can be programmed by plugging it into the backplane and using some 'special' master commands (maybe with a removable jumper for write-protection.  Reference design material should include the appropriate (low cost but reliable) EEPROM, addressing scheme, scripts (Python?) for generating configuration descriptor etc.

    That sounds good.

    I would suggest a separate power ground return as well to keep power return currents out of the signalling.

    Ok, make sense but I didn't find so far such separation in other specifications (i.e. VXI). Maybe they compensate that with few dozen of evenly placed GND pins?

    Mandatory + auxiliary (or 'Core' + 'Expansion' or whatever) is a good concept.  Some people looking at this will be highly cost sensitive.

    Also, I suggest starting with the Mandatory part, because you will likely at some point say 'this isn't quite right, I need to make some big changes.'  That will probably break some compatibility, and is one of the costs of good engineering. You have to be willing to do a big revision to capture lessons learnt, or you end up with the Arduino pin header offsets.

    Arduino probably should have said, 'oh, this is a mistake, we'll change the spec to make sense and redo a few shield designs,' but instead they kept going and now all Arduinos have a funny pin spacing.  When people make items like this, the specification is flawed.

    I believe that mandatory/core specification and connector has to be wisely defined that we don't have a need to change anything there in the future. Further modifications and enhancements should be done by introducing "Expansion/AUX" connector. There is a good chance that we do not come even closer to Arduino situation :).

    Maybe using CS (Chip select) label is confusing. It's module (or card) select in the first place. Therefore only one CS line reach each of 7 modules, and if you have more then one SPI device on one module you have to "decode" their chip selects. A star-topology is used (1-to-many) to connect MCU with each module, and due to that peripheral modules needs smaller connector then processor module. In case of xCORE you can simultaneously (in parallel) communicate with all seven boards via dedicated SPI channels at once!

    Why number seven? Because it's 8 minus 1 (processor board on slot #0) :).

    Maybe the master should spit out 7 Module Select signals (one per module) (or even 7 separate SPI busses) and a few Chip Select signals (maybe 4??, could be shared across all modules). That way some simple cards (e.g. relay output channel / basic ADC / basic DAC) could be built with SPI chips and no micro.

    Or maybe a cheap & cheerful bunch-of-UARTs would be the solution? That way developers wouldn't have to make SPI slave firmware, which can be a bit tricky. (But then you would almost always need a micro.)

    I draw a simple schematic that should help you to visualize proposed pinouts (only three peripheral modules are shown for the sake of simplicity):



    You can see above that signaling that comes to each modules is almost completely dedicated to that module, i.e. a star-topology is proposed driven by idea that on the processor module (#0) a multicore CPU/MCU can be employed for parallel processing. That could be XMOS xCORE, Parallax Propeller, a bunch of single-core MCUs or multi-core CPU/SoC. If multi-core/parallel processing resources are not available, designer has to merge on the processor module SPI buses into one or more (depending of MCU/CPU/SoC pinout). There is few shared signals only (i.e. RESET, MASTER_CLOCK, I2C, and non-isolated power lines). Finally only two buses are daisy-chained and not mandatory: JTAG and xCONNECT (or that could be something else if xCORE is not used).

    I don't see a way how to efficiently share more CS lines between more modules. Please keep in mind that some of modules should be completely isolated (e.g. power supply, electronic load, etc.) that sharing could make even more difficult (if possible at all).
    With current proposal, if signaling isolation is needed for min. functionality one have to implement only one 4-in/2-out digital isolator (or even 4-in/1-out if IRQ is not needed), and has to derive powering from proposed "hi-voltage" source that could be +24 V (or TBA).




    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #40 on: February 12, 2018, 07:41:30 pm »
    Do they [connectors] have some pins which are a bit longer than others and engage early?

    Not ones that I have/suggested. What do you have in mind a hot-swap capability?

    Good reply! I hadn't really been thinking of hot swap, so there's not much point.  (Maybe a look at options with early mating connectors are in order so that those pins can be ground from the get go and the door to hot swap isn't closed.)

    I was thinking some of the connector pins could be used to encode the backplane slot #, and feed them to address lines on the I2C EEPROM.  ...

    That sounds good.

    You'll need to reserve a couple of pins for card address, then.

    I would suggest a separate power ground return as well to keep power return currents out of the signalling.

    Ok, make sense but I didn't find so far such separation in other specifications (i.e. VXI). Maybe they compensate that with few dozen of evenly placed GND pins?

    Perhaps overkill then - just dedicate some connector pins for power return and use a single big ground plane on the backplane?  (I was thinking that the totals may go up to some amps).

    The reason for having lots of ground pins is usually signal integrity.  In fact, I think that your proposed pinouts may need more ground pins.  What kind of data rates do you expect on the SPI, and how fast do you expect to drive the STAR system (i.e. will you use high speed buffers)?

    I believe that mandatory/core specification and connector has to be wisely defined that we don't have a need to change anything there in the future. Further modifications and enhancements should be done by introducing "Expansion/AUX" connector. There is a good chance that we do not come even closer to Arduino situation :).

    Obviously you'll try to get everything right the first time, but the simple act of sticking 'Version 0.1, Provisional' on all the reference material leaves the option open to make a big change if something serious becomes apparent.

    (Possible AUX connector: DIN41612 power connection)

    I draw a simple schematic that should help you to visualize proposed pinouts ... signaling ... is almost completely dedicated to that module, i.e. a star-topology is proposed.

    The star-based architecture (with some MUXing on the master) could be very effective. Some care will be required to manage signal integrity (I'm thinking about stubs and reflections and multiplexers...)

    Do you think that the XCONNECT and JTAG connections are a good idea?  I've got four concerns:
    • XCONNECT is for XCORE only, and a lot of module implementers will use something else (AVR ... PIC ... FIGHT!)
    • How often will an end user use JTAG to connect to a module?  I would think that this is more for module developers, who presumably can just put their own JTAG header on the module and connect to it directly.
    • Some JTAG devices (MSP430 I think, and others...) don't play well when daisy-chained for anything other than boundary scan duties.  So the JTAG may mysteriously stop working when some other module is swapped.
    [/li][/list]A JTAG diasy chain would require completing links, i.e. dummy modules, to complete the connection.[/li]
    [/list]

    I don't see a way how to efficiently share more CS lines between more modules.

    It's not easy, no.  There are limits on pin count, after all.  However, I would like to pose the following question: if I have two SPI chips on a module (e.g. an ADC and a relay driver), how do I address them?

    Please keep in mind that some of modules should be completely isolated (e.g. power supply, electronic load, etc.) that sharing could make even more difficult (if possible at all).
    With current proposal, if signaling isolation is needed for min. functionality one have to implement only one 4-in/2-out digital isolator (or even 4-in/1-out if IRQ is not needed), and has to derive powering from proposed "hi-voltage" source that could be +24 V (or TBA).

    Yeah, isolation makes things more difficult.  From experience, I can say that sometimes you just have to drop a whole lot of channels.  Alternatively, you can deploy something like a UART (1 in / 1 out) but that has challenges too, especially with timing.

    Once again (and I can see you're doing it carefully), it's important that the module designer gets choices about what features they use and how much they pay.
     

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #41 on: February 13, 2018, 08:04:56 am »
    I've been thinking about this more (please let me know if it gets annoying)...

    Star topology
    • I like the concept, because it means that module designers don't have to muck about with weird and wonderful comms stuff, time slots etc.
    • It does use up a few pins on the master
    • In order to allow for a hypothetical 'cheap' master, it should be possible to connect all the SPI buses on the master card to a smaller number of SPI masters. So modules should release the MISO line when they aren't selected.
    • Given there are SPI connections to each module, maybe the module ID system should be an SPI EEPROM?  That way I2C lines and slot address pins aren't required. (This would involve adding a couple of addressing lines to each module.) Modules with a microcontroller could even emulate the SPI EEPROM if someone is desperate to save some cents.

    Synchronisation
    Is a great idea.
    • I saw a 100MHz clock distribution pencilled in - were you thinking this should come from the master only, or should it allow for the choice a more accurate timing module?
    • Isn't the usual clock distribution frequency of choice 10 MHz?  A lot of cheap micros can't handle 100 MHz.
    • A synch signal which strobes at a lower rate is also very helpful.
    • The synch signal could be sourced from the master clock (fixed period strobe), or maybe it could be a bidirectional pin, allowing a (suitably configured) slave to trigger everything.

    Triggers and higher speed signalling
    • I think a lot of applications won't need hardware triggering or high speed communications. Maybe these should be an optional part of the spec?
    • If the STAR bus is designed for high speed signalling, maybe it could be dual function: either advanced triggering or high speed comms (imaging 100 MHz DDR: 200 Mbit/s is quite a lot of bandwidth...)


     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #42 on: February 13, 2018, 10:26:04 am »
    Hi jbb, of course that your posts are not annoying at all, please keep posting. I also believe that more people are going to join us soon to have better idea how useful is what we are talking about. I'll start with another schematic to clarify "chip select" demux/decoding for multiple SPI device on the same module. In example below I also added min. digital isolator what should be added if module has to be isolated/"floating" what will be for sure a case for my first module (power supply):



    A SPI EEPROM is also added, that can be used for storing info about module/card ID and some other useful data (settings, calibration data, working hours, last state, etc.). That is in line with what you already realized that instead of I2C a SPI EEPROM could be more convenient. That is especially a case if isolation is needed when we can spare one isolator (for I2C).
    As you can see in this configuration only one Card/chip select (CS#N) is needed for each module regardless of number of deployed SPI devices. To keep access time constant with adding/addressing more on-board devices you have to increase the SCLK frequency for sending data (MISO to SER) to SIPO register.
    Of course, firmware has to take care of sending data that include only one 0 (e.g. 0111 1111 to select EEPROM, 1011 1111 to select CS1, etc.). A more "firmware bug-proof" solution could be to deploy 1-to-8 demux or sequencer instead of '595 (something like '138 but with only "CLK" input). I didn't spent any time to find one, and I'm not sure that cheap one exists either, so your input is welcome here.

    Grounding
    Currently we have 11 GND on #0 connector and 4 on peripherals. GND pins are "strategically" placed close to SPI channels and some other places. Don't know if that is enough, but situation with peripheral connectors with only 4 GND pins is possibly not good. That can be improved with using two currently unassigned pins (B5, B6) and with removing JTAG and/or xCONNECT from "mandatory" connector specification.

    SPI bus speed
    The max. SPI bus really depends of what we are going to exchange between #0 and other modules. I think that we need sooner or later to identify few use case that can help us to set a boundaries. I'm not going to mention in this post any use case because they need more prominent place/presentation (that could be a separate doc file available for review).

    AUX connector
    (Possible AUX connector: DIN41612 power connection)
    Do you have anything in particular, since DIN41612 include dozen of power connector?

    xCONNECT and JTAG
    Your comments about such signaling are right and I can agree that they are not deserve to occupy pins on the primary/mandatory connector. That is true especially for JTAG (I've borrowed it from the PCI Express, but that is a quite different type of beast). By removing them we have more pins for GND and possibly some other stuff (e.g. promoting some signaling to differential due to expected higher bandwidth, etc.).

    Synchronization, triggers, hi-speed signaling, UART...
    I saw a 100MHz clock distribution pencilled in - were you thinking this should come from the master only, or should it allow for the choice a more accurate timing module?
    Isn't the usual clock distribution frequency of choice 10 MHz?  A lot of cheap micros can't handle 100 MHz.

    That is a good point. Even VXI has both 100 and 10 MHz clocks. In our case 10 MHz sounds more reasonable. Therefore I'm going to make that change. 100 MHz could find its place later on the AUX connector.

    A synch signal which strobes at a lower rate is also very helpful.
    The synch signal could be sourced from the master clock (fixed period strobe), or maybe it could be a bidirectional pin, allowing a (suitably configured) slave to trigger everything.

    I'm not sure how to provide bidirectional master clock, but for slave triggering STRGIN#N and also STARX#N, STARY#N cross-switch matrix could be used.

    Yeah, isolation makes things more difficult.  From experience, I can say that sometimes you just have to drop a whole lot of channels. Alternatively, you can deploy something like a UART (1 in / 1 out) but that has challenges too, especially with timing.

    UART imply using a MCU on peripheral module too. In my view that shouldn't be a case/requirement. Basic configuration should imply using CPU/MCU on the module #0 (i.e. master) only. Also if we are going to assign to pins per module that will increase demand for pins on #0 too (up to 2 x 7 pins!). I presume here that no shared UART topology is possible. Eventually, we can offer existing MOSI#N, MISO#N to be used for UART communication with selected modules, but in that case we cannot use SPI EEPROM as default mean of module identification :(.


    I hope that everything is addressed from your latest two posts. Please let me know if something require more elaboration.

    Offline cat87

    • Regular Contributor
    • *
    • Posts: 230
    • Country: nl
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #43 on: February 13, 2018, 11:20:31 am »
        Now, this thread is a nice surprise. I'm planning on making my own modular case which will take 100 x 160mm  cards, connected with the DIN4162 connectors. Because I don't want to have digital lines in my backplane, because they're a pain to route properly, I planned on having the SPI or I2C or what have you communications interface coming out from the front of the module. Kinds half-assed, but doable.
     
    But now, looking at this thread, I think I might give the backplane a once-over and try to incorporate some comm.  interfaces.


    Thanks guys

    Oh, and I've got the frame of the case almost complete. I'll be picking up some card  guides tomorrow and maybe post some pics of the case one of these days.
    « Last Edit: February 13, 2018, 11:22:06 am by cat87 »
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #44 on: February 13, 2018, 11:46:12 am »
    One little question, is there are reason for 3.3VAUX to be 3.3V? Using 5V there would allow for direct use of ATX power supply (at least to bootstrap it, as they have 5 volt standby voltage), at least for testing as providing  +3.3, +5V, +12V and  -12V is at least 2 bench power supplies worth of power rails and that's a bit of a pain for testing.
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #45 on: February 13, 2018, 12:06:14 pm »
    One little question, is there are reason for 3.3VAUX to be 3.3V? Using 5V there would allow for direct use of ATX power supply (at least to bootstrap it, as they have 5 volt standby voltage), at least for testing as providing  +3.3, +5V, +12V and  -12V is at least 2 bench power supplies worth of power rails and that's a bit of a pain for testing.

    No it's not. I was guided here with the idea that nowadays +3.3 V is pretty standard and choose it as a main power. Consequently AUX has the same voltage. But, your remark about ATX is valuable. Also since 5 V is easier (and less noisier) to step-down then other way around we can change AUX to be 5 V.

    Offline jeremy

    • Super Contributor
    • ***
    • Posts: 1079
    • Country: au
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #46 on: February 13, 2018, 01:22:30 pm »
    I have an Agilent smu with a backplane connector, and the pinout is basically just power, USB and trigger/sync.

    I throw my vote in with the earlier SCPI/vxi11 folks. Why reinvent the wheel  :-// works fine for keysight/tek/etc

    Just to add my 2c  ;)
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #47 on: February 13, 2018, 01:38:04 pm »
    The main reason for such (modular) approach is to save, reuse and use, to the greatest extent what is already done or spent (in time and money). My stance is that is exactly the quite opposite from hardcore consumerism (fulled by debt "money") which is a main mantra for so-called "sustainable development" (that is in fact sustainable domination!) and publicly listed corporations as that what you're mentioned cannot afford a luxury to ignore that. That is a default/"winners" game, and it's presented so far as the best what humanity can get (and buy!) and consequently deserve. A "litmus test" for such worldview among other is mentioning of open source ;). It's usually trigger a bunch of rationalizations (and attacks).
    « Last Edit: February 13, 2018, 01:41:12 pm by prasimix »
     

    Offline jeremy

    • Super Contributor
    • ***
    • Posts: 1079
    • Country: au
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #48 on: February 13, 2018, 02:03:17 pm »
    Right, but scpi/vxi11 is free, and USB/Ethernet chips are extremely cheap and widely available. I don’t think keysight uses these protocols because they are trying to lock you in, the opposite actually. My current “backplane” on my desk is just a 7 port USB hub, and it works great for connecting PSUs, multimeters, oscilloscopes, motion controllers, etc. The only issue is that cabling is a mess. I write python code to control them all, and I certainly spend the most time reading the manuals to understand all of the functionality available rather than fiddling with driver installs.

    Keysight even sells a big fancy USB hub mainframe: https://www.keysight.com/en/pc-1890327/usb-mainframes-controllers?nid=-33269.0&cc=AU&lc=eng. You can use the modules inside the mainframe, or outside using just a USB cable.
     
    The following users thanked this post: Kean, prasimix

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #49 on: February 13, 2018, 02:10:50 pm »
    Ok, but USB as a "backplane"/bus imply a sort of "intelligence" (CPU/MCU/SoC) on both side. Yes, USB-to-SPI/I2C bridges exists and that was one of my earlier considerations but I gave up from it. A nice detail on mentioned Keysight solution is, if I understood picture correctly, a possibility to use the same module as part of the rack or as stand-alone (possibly USB powered) solution. That's something that I had in mind, too.

    EDIT: I forgot to comment SCPI: that should be a "basic requirement" and my first project support SCPI pretty well, too.
    « Last Edit: February 13, 2018, 02:13:33 pm by prasimix »
     

    Offline jeremy

    • Super Contributor
    • ***
    • Posts: 1079
    • Country: au
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #50 on: February 13, 2018, 02:37:54 pm »
    It’s true that you would need a micro on both ends. An arduino pro micro can be had for US$3 on aliexpres (I use them like crazy at that price!), or a wiznet chip for <$10 to do the Ethernet part. Something like a raspberry Pi could sit on the other end, or you just plug it in to your PC. This is the approach taken by NI with their PXI chassis; you can either put in a CPU card (essentially just an embedded PC), or instead use that slot to connect it to a desktop PC where it runs over PCIe.

    The NI virtual bench, which seems similar to what you are trying to do, minus the modular part, also uses USB/Ethernet and even recommends python. (Ignore the part about the crime against humanity aka labview ;) )

    I’ve done a fair amount of test equipment automation, and I have actually never needed two instruments to communicate peer to peer except for trigger/sync; they all talk to some PC software which coordinates them. So I’m not sure why you would want to avoid a central controller?  :-//
     

    Offline Mr. Scram

    • Super Contributor
    • ***
    • Posts: 9810
    • Country: 00
    • Display aficionado
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #51 on: February 13, 2018, 02:40:27 pm »
    I would also recommend using SCPI or another existing solution to base your design on. Yet another standard isn't going to help things. I love that can plug in all my SCPI devices and talk to it over USB, the serial port or whatever I like.
     
    The following users thanked this post: prasimix

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #52 on: February 13, 2018, 02:44:29 pm »
    I’ve done a fair amount of test equipment automation, and I have actually never needed two instruments to communicate peer to peer except for trigger/sync; they all talk to some PC software which coordinates them. So I’m not sure why you would want to avoid a central controller?  :-//

    Oh, quite contrary, I'd like to have central controller but possibly built-in my chassis with backplane (slot #0) that could work with or without connected PC. It's sort of DVD/Media player vs. PC-only solution: the former usually provide faster/easier startup and maintenance while later gives more freedom and choice but also demands more skills and attention.

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #53 on: February 13, 2018, 02:49:10 pm »
    I would also recommend using SCPI or another existing solution to base your design on. Yet another standard isn't going to help things. I love that can plug in all my SCPI devices and talk to it over USB, the serial port or whatever I like.

    Yes, on software/firmware SCPI is a no-brainer to me. What I'm trying to do here is to downscale "beefy" PXI/VXI hardware part of the story. Therefore all your suggestions and comments are welcome.

    Offline jeremy

    • Super Contributor
    • ***
    • Posts: 1079
    • Country: au
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #54 on: February 13, 2018, 02:57:26 pm »
    Oh, quite contrary, I'd like to have central controller but possibly built-in my chassis with backplane (slot #0) that could work with or without connected PC.

    Yes, this is essentially the MXI option: https://www.ni.com/pxi/mxiexpress/

    You just take the embedded controller card out of slot #0 and put in a “dummy” which feeds the important signals out to the PC. If you must have both at once (and don’t want to use something as simple as a mechanical switch to jump between the two), I suppose you also could use a device which has both USB slave and host like the beaglebone black, but then you have to mess around with forwarding data and such.
     
    The following users thanked this post: prasimix

    Offline David Hess

    • Super Contributor
    • ***
    • Posts: 16545
    • Country: us
    • DavidH
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #55 on: February 13, 2018, 03:00:41 pm »
    On the hardware side, I am not interested unless the instrument bus provides galvanic isolation.  There are lots of instrument buses which do not have this so why would I need another one?  While isolation can be provided inside the instrument, this is also a performance and safety issue.

    Ethernet between instruments allows for the possibility of using standard ethernet switches and bridges and even operation over the internet.  That it includes galvanic isolation on both ends, is inexpensive to implement, and has a relatively high data rate is icing on the cake.

    What I have done in the past is to use optically isolated asynchronous serial like the old MIDI bus and for the lowest cost designs I think this is the best way.

    Provisions should be made for a galvanically isolated out of band trigger signal.  I am not sure how best to do this on the hardware side.
     
    The following users thanked this post: prasimix

    Offline jeremy

    • Super Contributor
    • ***
    • Posts: 1079
    • Country: au
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #56 on: February 13, 2018, 03:03:34 pm »
    On the hardware side, I am not interested unless the instrument bus provides galvanic isolation.  There are lots of instrument buses which do not have this so why would I need another one?  While isolation can be provided inside the instrument, this is also a performance and safety issue.

    Ethernet between instruments allows for the possibility of using standard ethernet switches and bridges and even operation over the internet.  That it includes galvanic isolation on both ends, is inexpensive to implement, and has a relatively high data rate is icing on the cake.

    What I have done in the past is to use optically isolated asynchronous serial like the old MIDI bus and for the lowest cost designs I think this is the best way.

    Provisions should be made for a galvanically isolated out of band trigger signal.  I am not sure how best to do this on the hardware side.

    But you would also need an isolated power supply for each slot, wouldn’t you?
     

    Offline David Hess

    • Super Contributor
    • ***
    • Posts: 16545
    • Country: us
    • DavidH
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #57 on: February 13, 2018, 03:20:46 pm »
    On the hardware side, I am not interested unless the instrument bus provides galvanic isolation.  There are lots of instrument buses which do not have this so why would I need another one?  While isolation can be provided inside the instrument, this is also a performance and safety issue.

    Ethernet between instruments allows for the possibility of using standard ethernet switches and bridges and even operation over the internet.  That it includes galvanic isolation on both ends, is inexpensive to implement, and has a relatively high data rate is icing on the cake.

    What I have done in the past is to use optically isolated asynchronous serial like the old MIDI bus and for the lowest cost designs I think this is the best way.

    Provisions should be made for a galvanically isolated out of band trigger signal.  I am not sure how best to do this on the hardware side.

    But you would also need an isolated power supply for each slot, wouldn’t you?

    That is how the old Tektronix TM500/TM5000 series of modular test instruments works.  Each instrument has a pair of isolated 25VAC transformer secondaries and an NPN/PNP pair of isolated power transistors available to it from the mainframe.

    For a lower cost and more flexible solution, separate instruments with just the *isolated* instrumentation bus connection are more suitable.  And if the instrument bus is isolated, it becomes irrelevant if each instrument uses an isolated power supply unless the user requires it.  For instance I might have a pile of small instruments which run off of 12 volt DC power but in this case, galvanic isolation of the instrument bus is doubly important to prevent ground loops and safety issues if the power ground fails.  I have seen PC motherboards and some laptops killed by this when using RS-232.

     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #58 on: February 13, 2018, 03:22:11 pm »


    On the hardware side, I am not interested unless the instrument bus provides galvanic isolation.  There are lots of instrument buses which do not have this so why would I need another one?  While isolation can be provided inside the instrument, this is also a performance and safety issue.

    Ethernet between instruments allows for the possibility of using standard ethernet switches and bridges and even operation over the internet.  That it includes galvanic isolation on both ends, is inexpensive to implement, and has a relatively high data rate is icing on the cake.

    What I have done in the past is to use optically isolated asynchronous serial like the old MIDI bus and for the lowest cost designs I think this is the best way.

    Provisions should be made for a galvanically isolated out of band trigger signal.  I am not sure how best to do this on the hardware side.

    Ethernet sounds good, it's well established, but by default require "intelligent" peripheral module. I'm not per se against adding MCU on that side, but that rise a concern about multiple MCU firmware updating. That can be annoying for many people, and we can count here with very live and dynamic environment when firmware can be updated more frequently then in proprietary/closed/patented system where firmware upload is quite often connected with additional cost.

    As you can see in post #43 bus isolation is mentioned but to isolate a whole bus will need more the single Silabs isolator (that it btw excellent for fair price comparing with some competitive devices). In that case Ethernet is clearly a winner and I didn't heard yet of anything else that could provide isolation and high bandwidth.

    But you would also need an isolated power supply for each slot, wouldn’t you?

    Yes, that's why we discussed about introducing another DC bus voltage (possibly 24 if 48 is too high) that can be used for on-board DC-DC conversion.

    Offline Gribo

    • Frequent Contributor
    • **
    • Posts: 629
    • Country: ca
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #59 on: February 13, 2018, 03:50:24 pm »
    What about PXI/MXI? From all this discussion here, I have a feeling that you are trying to reinvent the wheel. Instead of this, how about designing open source reference designs for PXI?
    I am available for freelance work.
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #60 on: February 13, 2018, 04:09:09 pm »
    What about PXI/MXI? From all this discussion here, I have a feeling that you are trying to reinvent the wheel. Instead of this, how about designing open source reference designs for PXI?

    No, I'd like to make a thing simpler and fill the huge gap between professional multi thousands $$$ solution and DIY creations where even two instruments/devices from same author for various reason cannot be easily inter-connected and controlled :).

    I presume that you took a look on PXI specification: just parallel data and address buses make them expensive and unattractive. Just connectors for such backplane could cost few hundreds. I'd rather follow some standard with serial bus like PCI Express, but it's also overkill my many means (if nothing else their connectors are cheap and even PCB alone is used at the one end, and there you can find a great expansion mechanism based on lanes).

    Offline David Hess

    • Super Contributor
    • ***
    • Posts: 16545
    • Country: us
    • DavidH
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #61 on: February 13, 2018, 04:21:29 pm »
    Ethernet sounds good, it's well established, but by default require "intelligent" peripheral module. I'm not per se against adding MCU on that side, but that rise a concern about multiple MCU firmware updating. That can be annoying for many people, and we can count here with very live and dynamic environment when firmware can be updated more frequently then in proprietary/closed/patented system where firmware upload is quite often connected with additional cost.

    Ethernet is definitely complicated on the MAC side requiring a processor of some type and programming.

    What about designing a universal open hardware and software ethernet to USART bridge which supports SPI, I2C, and asynchronous serial on the USART side?  Then the user device just needs to deal with some sort of serial connection which is likely a built in capability and SPI and asynchronous serial can be pretty fast although not normally 100 Mbit/second fast.

    Would this meet the requirements of SCPI over Ethernet?

    Something similar could be done for USB with isolation provided on the USB or USART side of the bridge but I think Ethernet would be better because USB lacks the ease of networking.  Having an instrument which I can plug into any Ethernet port within say the broadcast domain and just have work really appeals to me.

    Quote
    In that case Ethernet is clearly a winner and I didn't heard yet of anything else that could provide isolation and high bandwidth.

    USB up to 12 Mbits/second is easy to isolate but I suspect more expensive than Ethernet at 100 Mbits/sec and it loses the easy to use networking capability of Ethernet.

    Quote
    But you would also need an isolated power supply for each slot, wouldn’t you?

    Yes, that's why we discussed about introducing another DC bus voltage (possibly 24 if 48 is too high) that can be used for on-board DC-DC conversion.

    One of the solutions I have seen used is to provide a regulated high frequency, 20 kHz or higher anyway, high power square wave drive which the separate instruments can use to provide multiple isolated power rails via a simple inverter transformer and diode rectification.  This can be surprisingly low noise and provides a high power factor if a square wave is used.

    If the lowest noise is required, then controlling the slew rate of the square wave edges can be done or sinewave drive can be used with a loss of power factor which is likely irrelevant.


     
    The following users thanked this post: prasimix

    Offline David Hess

    • Super Contributor
    • ***
    • Posts: 16545
    • Country: us
    • DavidH
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #62 on: February 13, 2018, 04:32:17 pm »
    What about PXI/MXI? From all this discussion here, I have a feeling that you are trying to reinvent the wheel. Instead of this, how about designing open source reference designs for PXI?

    These standards exemplify everything that I do not want.  If they were acceptable to me, then I could use GPIB and GPIB is not acceptable to me.
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #63 on: February 13, 2018, 05:01:47 pm »
    Ethernet sounds good, it's well established, but by default require "intelligent" peripheral module. I'm not per se against adding MCU on that side, but that rise a concern about multiple MCU firmware updating. That can be annoying for many people, and we can count here with very live and dynamic environment when firmware can be updated more frequently then in proprietary/closed/patented system where firmware upload is quite often connected with additional cost.

    Ethernet is definitely complicated on the MAC side requiring a processor of some type and programming.

    What about designing a universal open hardware and software ethernet to USART bridge which supports SPI, I2C, and asynchronous serial on the USART side?  Then the user device just needs to deal with some sort of serial connection which is likely a built in capability and SPI and asynchronous serial can be pretty fast although not normally 100 Mbit/second fast.

    Would this meet the requirements of SCPI over Ethernet?

    Something similar could be done for USB with isolation provided on the USB or USART side of the bridge but I think Ethernet would be better because USB lacks the ease of networking.  Having an instrument which I can plug into any Ethernet port within say the broadcast domain and just have work really appeals to me.

    Huh, a sort of Ethernet-to-SPI (master) bridge as single-chip solution could be really nice. Eventually some cheap MCU+Ethernet PHY controller with firmware that is uploaded once and don't need further attention. Although I'm not sure if cheap MCU and Ethernet speed communication could coexist together :).

    I'm thinking here that actually for speed of up to 100 Mbit/s (and isolated), probably a low cost/low count BOM solution could be again xCORE entry level MCU that has built-in SerDes and could work internally with amazing speed (and without jitter), can be inter-connected using their xCONNECT and then we can use affordable Silabs isolators that offer 100 Mbit/s bandwidth. In this case we'll need one MCU per module, but their complier and firmware uploading and bootstrap mechanism offer that everything could be done from single point. But, that makes a whole thing vendor-specific what is not so attractive. Additionally if no daisy-chaining is acceptable (and I really don't like it since failure of one module could jeopardize a whole system), a two xCONNECT links is needed what asks for more isolators. Phew, that is not good.

    Quote
    In that case Ethernet is clearly a winner and I didn't heard yet of anything else that could provide isolation and high bandwidth.

    USB up to 12 Mbits/second is easy to isolate but I suspect more expensive than Ethernet at 100 Mbits/sec and it loses the easy to use networking capability of Ethernet.

    Yes, it's easy to isolate but it's still costly (around 2.5-3x the price of a 6-line Silabs isolator :)) and USB 2.0 is still out of question since only one hardly-sourced isolator exists AFAIK. 

    But you would also need an isolated power supply for each slot, wouldn’t you?

    Yes, that's why we discussed about introducing another DC bus voltage (possibly 24 if 48 is too high) that can be used for on-board DC-DC conversion.

    One of the solutions I have seen used is to provide a regulated high frequency, 20 kHz or higher anyway, high power square wave drive which the separate instruments can use to provide multiple isolated power rails via a simple inverter transformer and diode rectification.  This can be surprisingly low noise and provides a high power factor if a square wave is used.

    If the lowest noise is required, then controlling the slew rate of the square wave edges can be done or sinewave drive can be used with a loss of power factor which is likely irrelevant.

    That sounds like a great idea and could lower the overall complexity and cost especially if we succeed to find some ready-made small transformers that can be used on all isolated modules, e.g. with single secondary for +3.3 V or +5 V, dual secondary for +/-12 V only, or triple/quadruple secondary for all of them.

    Offline C

    • Super Contributor
    • ***
    • Posts: 1346
    • Country: us
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #64 on: February 13, 2018, 05:53:51 pm »
    The problem is cheap leads to poor.

    serial , spi, i2c are all built with a master in control, at some point a master can not do the job.
    In addition serial adds huge encode/decode problem which slows speed and increases program complications.

    If you want to spread control such that overload of one is harder then there are two current systems ethernet and can. With both being packet based less encode/decode problem.

    Cheap leads to stupid when just a little increase in cost gives you CAN at cost of hardware driver($1). Proper microcontroller selection gives firmware program/update over CAN.
     
    Look at world, how many real time control systems are CAN based and how many are Ethernet based.

    CAN does some things that are harder do do on Ethernet, priority small packets. Think of interrupts over network with little delay due to small packet size. Think of software functions where many different parts of hardware are evolved.

    You build test equipment out of simple modules. Too simple/dumb increases costs and problems. While a AVR can control a power supply, by using an ARM base you can cheaply have ARM scope & awg added again at little cost.

    Think of simple word changes
    David Hess, suggests a regulated high frequency.
    Go a step further and you have a Motor Drive acting like a high frequency supply. This could have noise feedback used to adjust wave shape.

    At some point the ability to hot-plug will be wanted.

    Differential signals to remove ground loops and improve signals. Adding differential to something that exists can be hard/costly, done at start could be cheap & simple.

    There is no one size fits all. Best to have many choices that can build to greater things.

    Think
      Ethernet is better at bulk and poorer at real-time.
      CAN is better at real-time and poorer at bulk.
    To get better real-time then CAN you need separate signals.
    To get better Bulk you need more point to point but could use a shared buss like SATA & SAS.



     

    Offline David Hess

    • Super Contributor
    • ***
    • Posts: 16545
    • Country: us
    • DavidH
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #65 on: February 13, 2018, 07:27:14 pm »
    That sounds like a great idea and could lower the overall complexity and cost especially if we succeed to find some ready-made small transformers that can be used on all isolated modules, e.g. with single secondary for +3.3 V or +5 V, dual secondary for +/-12 V only, or triple/quadruple secondary for all of them.

    Off the shelf isolation and gate drive transformers are suitable but will not provide the correct winding ratios to produce exact output voltages unless the primary side voltage is selected specifically for them.  This is not a problem if a secondary side switching regulator is included.  High frequency operation of the inverter transformer makes for a good power density and easy ripple filtering.
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #66 on: February 14, 2018, 08:35:29 am »
    That sounds like a great idea and could lower the overall complexity and cost especially if we succeed to find some ready-made small transformers that can be used on all isolated modules, e.g. with single secondary for +3.3 V or +5 V, dual secondary for +/-12 V only, or triple/quadruple secondary for all of them.

    Off the shelf isolation and gate drive transformers are suitable but will not provide the correct winding ratios to produce exact output voltages unless the primary side voltage is selected specifically for them.  This is not a problem if a secondary side switching regulator is included.  High frequency operation of the inverter transformer makes for a good power density and easy ripple filtering.

    Gate transformers makes sense to some extend, if more power is needed designer can search for something bigger. But, there is another possible issue with providing switched/pulsed power that can be used for step-down (with or without further regulation): what SMPS topology to use that tolerate connection of various inductive loads (on-board isolation transformers)?

    Additionally, if this approach is going to be selected I'd like to step-down in the first phase mains voltage (115/230 Vac, with or without PFC) to e.g. 24 V unrectified with let say one mandatory "load" to close NFB loop. I'm to sure how variable number of connected transformers could affect stability.

    I also find a schematic of mentioned Tek mainframe (3-slot in this case), it seems to me that they were using mains transformer with multiple isolated secondaries (two per module) instead of hi-freq switching output that can be used on module:


    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #67 on: February 14, 2018, 09:03:27 am »
    The problem is cheap leads to poor.

    Right, and I'm not interesting into cutting a cost at all cost and trying to stay in "jelly bean component" zone. As I already mentioned, my stance is that a huge gap exists between professional and DIY/hobbyist solution and today with global suppliers with multi-million parts stock and overnight delivery if you wish, we are not limited to what we have somewhere on the shelf. Additionally, if some stuff ends up to be pricey I believe that accompanying open-source software/firmware will make a complete solution still very attractive/desirable.

    serial , spi, i2c are all built with a master in control, at some point a master can not do the job.

    Yes, and in one moment you need more master to do the proper job: that's why xCORE and Propeller MCUs with parallel processing looks quite appealing to me. It's not like bringing more single-core MCU together, since that approach require a special attention to synchronize tasks. I think that multi-core MCU is a proper building block for point-to-point or star topology that already exists in my proposal.

    In addition serial adds huge encode/decode problem which slows speed and increases program complications.

    If you want to spread control such that overload of one is harder then there are two current systems ethernet and can. With both being packet based less encode/decode problem.

    Cheap leads to stupid when just a little increase in cost gives you CAN at cost of hardware driver($1). Proper microcontroller selection gives firmware program/update over CAN.
     
    Look at world, how many real time control systems are CAN based and how many are Ethernet based.

    CAN does some things that are harder do do on Ethernet, priority small packets. Think of interrupts over network with little delay due to small packet size. Think of software functions where many different parts of hardware are evolved.

    You build test equipment out of simple modules. Too simple/dumb increases costs and problems. While a AVR can control a power supply, by using an ARM base you can cheaply have ARM scope & awg added again at little cost.

    I didn't consider CAN yet due to limited speed, but I'll take another look and check what is possible with it.

    Think of simple word changes
    David Hess, suggests a regulated high frequency.
    Go a step further and you have a Motor Drive acting like a high frequency supply. This could have noise feedback used to adjust wave shape.

    Hm, motor drive could be a solution, but not sure if it can be used for "preparing" mains voltage, too (see my previous post).

    At some point the ability to hot-plug will be wanted.

    Differential signals to remove ground loops and improve signals. Adding differential to something that exists can be hard/costly, done at start could be cheap & simple.

    There is no one size fits all. Best to have many choices that can build to greater things.

    Think
      Ethernet is better at bulk and poorer at real-time.
      CAN is better at real-time and poorer at bulk.
    To get better real-time then CAN you need separate signals.
    To get better Bulk you need more point to point but could use a shared buss like SATA & SAS.

    I presume that hot swapping could be implemented quite successfully in the future even without specially designed connector, but differential signaling is quite different story, and if not included in the first specification it will require adding an additional connector.


    Offline C

    • Super Contributor
    • ***
    • Posts: 1346
    • Country: us
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #68 on: February 14, 2018, 10:59:38 am »
    Yes, and in one moment you need more master to do the proper job: that's why xCORE and Propeller MCUs with parallel processing looks quite appealing to me. It's not like bringing more single-core MCU together, since that approach require a special attention to synchronize tasks. I think that multi-core MCU is a proper building block for point-to-point or star topology that already exists in my proposal.
    I see this as a waste of time and a limit/fail just waiting to happen.
    First this is not main stream so no main stream support.
    Look at ARM
    At the low cheap end you have parts that have a CAN interface. In place of one MPU, many could be cheaply used. At the high end you have ARM & FPGA, This lets a designer not locked in to ONE or MASTER to solve a problem/task with many. Needs idea of many at the start and simple hardware/software to make many easy. Big problem here is changing how designers look at a problem. Distributed control is just that Distributed.   

    I didn't consider CAN yet due to limited speed, but I'll take another look and check what is possible with it.
    You are also missing other parts. You can have many CAN buses and have much less encode/decode if used properly. Need to remember that a computer is binary and should work in binary not a human version of binary.

    I presume that hot swapping could be implemented quite successfully in the future even without specially designed connector, but differential signaling is quite different story, and if not included in the first specification it will require adding an additional connector.

    Short answer is NO
    Do you see many hot-swap pci around? Was not designed in at start.
    Even with SATA,SAS where hot-swap is designed in to drives, you have controlers that do not support hot-swap.
    Suggest you read up on how it is done.
    « Last Edit: February 14, 2018, 01:56:28 pm by C »
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #69 on: February 14, 2018, 11:44:50 am »


    On the hardware side, I am not interested unless the instrument bus provides galvanic isolation.  There are lots of instrument buses which do not have this so why would I need another one?  While isolation can be provided inside the instrument, this is also a performance and safety issue.

    Ethernet between instruments allows for the possibility of using standard ethernet switches and bridges and even operation over the internet.  That it includes galvanic isolation on both ends, is inexpensive to implement, and has a relatively high data rate is icing on the cake.

    What I have done in the past is to use optically isolated asynchronous serial like the old MIDI bus and for the lowest cost designs I think this is the best way.

    Provisions should be made for a galvanically isolated out of band trigger signal.  I am not sure how best to do this on the hardware side.

    Ethernet sounds good, it's well established, but by default require "intelligent" peripheral module. I'm not per se against adding MCU on that side, but that rise a concern about multiple MCU firmware updating. That can be annoying for many people, and we can count here with very live and dynamic environment when firmware can be updated more frequently then in proprietary/closed/patented system where firmware upload is quite often connected with additional cost.

    Maybe hybrid approach ? Chassis controller (basically whatever lands in slot 0) connects to modules via serial and exposes them via LAN. It would be trivial on Linux (via some cheapo ARM board) to run it and even do one-ip-per-slot so each device in chassis could be talked with separately.

    Then have controller talk with modules via SCPI over serial, or even directly over USB.
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #70 on: February 14, 2018, 12:23:01 pm »
    We can name it hybrid approach too, but currently the main concern is what to lay down on the chassis backplane with enough flexibility and speed and can be easily isolated. Later requirement makes USB a bad candidate but that can be addressed with applying isolation indirectly i.e. not on the USB lines but on the other side of USB interface chip (e.g. UART, SPI, etc.).

    Offline C

    • Super Contributor
    • ***
    • Posts: 1346
    • Country: us
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #71 on: February 14, 2018, 02:47:27 pm »
    We can name it hybrid approach too, but currently the main concern is what to lay down on the chassis backplane with enough flexibility and speed and can be easily isolated. Later requirement makes USB a bad candidate but that can be addressed with applying isolation indirectly i.e. not on the USB lines but on the other side of USB interface chip (e.g. UART, SPI, etc.).

    Currently I see no benefits to using a chassis backplane and a lot of problems and costs.
    Something with nothing to offer is just that noting.
     
     

    Offline David Hess

    • Super Contributor
    • ***
    • Posts: 16545
    • Country: us
    • DavidH
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #72 on: February 14, 2018, 03:32:02 pm »
    Gate transformers makes sense to some extend, if more power is needed designer can search for something bigger. But, there is another possible issue with providing switched/pulsed power that can be used for step-down (with or without further regulation): what SMPS topology to use that tolerate connection of various inductive loads (on-board isolation transformers)?

    Transformer loads are primarily their secondary loads transformed by the turns ratio; the inductive magnetizing current of the transformer itself is only a minor component.  So the typical rectifier and capacitor input filter on the secondary still looks like a rectifier and capacitor input filter on the primary and some extra series resistance but with a different ratio of voltage to current unless the transformer windings have a 1:1 ratio.

    Generating the differential square wave is trivial with an H-bridge driven by pair of square waves 180 degrees out of phase and non-overlapping.  Some switching regulator controllers can generate this waveform directly when their feedback connection is broken like the TL594 which Tektronix used to do this in their 2225 oscilloscope power supply.  Their 24xx series of analog oscilloscopes shows another way using flip-flops and gates.  Jim Williams published some application notes showing other ways to do this.

    Quote
    Additionally, if this approach is going to be selected I'd like to step-down in the first phase mains voltage (115/230 Vac, with or without PFC) to e.g. 24 V unrectified with let say one mandatory "load" to close NFB loop. I'm to sure how variable number of connected transformers could affect stability.

    If the primary side is regulated, then many loads can get by without regulation on the secondary side simplifying things so a low, say 24 to 48 volts, but regulated primary side voltage makes perfect sense and that is how Tektronix commonly did it.

    Quote
    I also find a schematic of mentioned Tek mainframe (3-slot in this case), it seems to me that they were using mains transformer with multiple isolated secondaries (two per module) instead of hi-freq switching output that can be used on module:

    I just used the TM500/TM5000 mainframes as an example where fully isolated transformer secondaries were provided to each slot.  I suggested using a much higher frequency to improve power density and make filtering easier but only because the needed transformers are readily available at least for low power loads.

    Incidentally, Vicor makes isolated fixed ratio power modules which implement all of the above in one module effectively acting like unregulated DC to DC converters.
     
    The following users thanked this post: prasimix

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #73 on: February 14, 2018, 03:33:39 pm »
    I was thinking about it a bit and I thought of an idea.

    Isolation on chassis level would be complex and not needed by everyone (for example for my use cases just having whole chassis be ground-lifted, but still sharing ground would be enough)

    Isolation on module level just makes every module much more complex to deal with (especially when/if USB would be involved)

    So just... have 2 chassis designs, one which has all of the bells and whistles required to isolate the module like separate isolated power for each module and isolated data/control lines.

    And the other without it, just simple shared power. Could probably be basically same PCB design, just with some 0 ohm resistors fitted on isolation-less version

    As for busses, I think there are basically 2 requirements to cover, low (measuring voltages/frequency)/mid speed measurements (scanning a bunch of input channels), and high data rate that is usually sampled (logic analyzer/Oscilloscope) or streamed (SDR), with most of devices being in the first category. So ~500kbit (assuming 5k measurements/sec * 10 bytes per measurement) vs tens/hundreds

    Therefore I wonder if it would be worth it to have 2 busses, low (say serial so modules itself can just talk via SCPI over serial), and high-data rate, with latter one being optional. So minimal implementation would be just micro with serial interface but that would still allow putting some more beefy modules in.

    We can name it hybrid approach too, but currently the main concern is what to lay down on the chassis backplane with enough flexibility and speed and can be easily isolated. Later requirement makes USB a bad candidate but that can be addressed with applying isolation indirectly i.e. not on the USB lines but on the other side of USB interface chip (e.g. UART, SPI, etc.).

    Currently I see no benefits to using a chassis backplane and a lot of problems and costs.
    Something with nothing to offer is just that noting.

    Then, considering whole thread is about having some kind of chassis or backplane, it is probably not for you.

    But in theory it would be simple to just have 1 socket "DIB to USB" adapter (as it is just power + whatever bus it uses to talk) where you can plug any module in.

     
    The following users thanked this post: prasimix

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #74 on: February 14, 2018, 04:35:57 pm »
    Thanks a lot for more inputs. It seems that many of us can agree that a graded/staged or multi-level spec makes a lot of sense. Regarding the isolation we don't necessary need to think about extremes like all modules have to be isolated or none of them are isolated. At least modules with sourcing/sinking capability (power supply, el. load) especially when more then one exists in the same chassis asks for isolation. That still don't dictate that rest of the modules need isolation. Therefore I think that non-isolated power lines (i.e. +3.3, +5, +/-12 V) should remain with additional "pulsed" input of e.g. 24 Vpp that can be used to drive on-board isolation transformer with rectifying/filtering and eventually regulation to achieve needed voltage. Additionally we could provide another/separate path for 24 Vdc i.e. which is already regulated and can be used for powering industry-standard 24 V or as input for on-board push-pull converter if designer is not willing to implement generation of pulsed source as @David Hess proposed.

    I'd like to highlight once again that what I have in mind is not just a "blind" chassis but one with "user console" on the front panel: a concept of "standalone DVD player" i.e. power it and play, with min. hassle that can arise when establishing communication with PC (wired or wireless), loading software, etc. That could be of great help when you need to frequently move your "instrumentation set" back and forth, when frequent interaction is expected, etc. Depending of user habits and demands that could be a primary and not just a backup user interface. Such feature is not mandatory, it should be a feature of processor board #0, but from other side will affect min. mechanical dimensions since any combination of e.g. TFT display, encoders, switches and I/O connectors asks for wider #0 slot space (currently its set to max. 8 HP or ~40 mm). From other side, since display is slim, that leave enough room inside the chassis to place e.g. AC distribution/filtering, AC/DC section, bigger backup battery and/or DC input if needed, etc.

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #75 on: February 14, 2018, 05:22:21 pm »
    I'd think that is a good time to initiate discussion about a few typical use case/module functionality that should help us to better shape demands on the hardware/backplane level. I believe that we don't need more then three examples that belongs to e.g.:

    a) entry level,
    b) mid-level and
    c) high-level.

    Please take into account that my ambition here is not to compete with professional/commercial solutions, but to find an acceptable balance between often very basic DIY/hobbyist and entry-level or accidentally mid-range commercial devices (depends which brand is in question :)). What I'm going to propose I'd like to build in a foreseeable future and could serve as proof-of-concept (to avoid reference design title):

    a) Multiple digital I/O with and without isolation and low-power/signaling switching matrix (e.g. 4 x 4)
    b) 4-quadrant programmable power module, with triggering/sync, and low-bandwidth function generation/AWG and
    c) Data acquisition module, e.g. min. 20 MHz bandwidth, min. 100 Msamples/s (8- to 12-bit), single or multiple channels (multiplexed or simultaneous), eventually with single/dual high speed DAC for function generator/AWG or basic "network analyzer" (Bode chart plotting) with min. 10 MHz output (8- to 12-bit).

    Your candidates are highly welcomed, together with comments to what is suggested above.


     

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #76 on: February 14, 2018, 11:41:41 pm »
    I’ve kept thinking (yes, it’s been hard for me :-) ) about a few issues here.

    How does the following sound?
    • Quite dumb backplane with master slot and N slave slots.
    • Isolation to be done in module to keep backplane simple.
    • Hot swap is probably not required - it adds a lot of complexity. I think prasimix’s sketches show a bottom plane (rather than a back plane) which would complicate the mechanics anyway. I still like the thought of using early mating ground pins to reduce the risk of ESD damage.
    • Use of M-LVDS, which is a mulidrop differential standard explicitly designed for backplanes. Bandwidth of 100 MHz (200 Mb/s) is achievable.

    Core bus
    • A single shared SPI bus for module ID and dumb cards (e.g. basic digital IO) that don’t need a micro (thanks prasimix).
    • One dedicated UART per module (Could easily run at 10 MHz / 16 = 625 kb/s).
      (I suggest UART rather then separate SPI because it’s a bit fiddly to write an SPI slave).
    • 10 MHz clock distribution over M-LVDS. Clock source is master (default) or timing slave module.
    • Synch pulse (maybe 50ns pulse @ 10 kHz?) over M-LVDS. Source is master or timing slave module.
    • Bidirectional trigger line over M-LVDS.

    Standard power bus
    • Plenty of 5 / 12 V power for master
    • Moderate amount of power @ 3.3 /  5 V for unisolated side of modules.
    • Medium freq AC bus (10s of kHz?) for isolation transformers on modules (thanks David Hess)

    Extended bus
    • Several (8, 12, 16?) lanes of M-LVDS.
    • A small menu of standard options, e.g. trigger, single/dual/quad SPI data (SDR and DDR), 8b/10b packet (DC levelled, can go through coupling transformer or fibre optic), custom use-at-your-own-risk.
     

    Offline Richard Crowley

    • Super Contributor
    • ***
    • Posts: 4317
    • Country: us
    • KJ7YLK
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #77 on: February 14, 2018, 11:43:47 pm »
    The Gigabit Ethernet technology seems pretty good as a command/control/data bus.
    It can handle very fast speeds, bi-directional, between multiple nodes on the bus.
    And it is galvanically isolated (transformer-coupled). (Or optically coupled with some standardized bus configuration)
    At least for the OSI (Open Systems Interconnect) Layer 1 (Physical).
    The hardware is dirt-cheap and standardized even for Gigabit speed.

    And there are open source software solutions for the other six layers.
    Depending on which level(s) would make sense for the project.

    1. Physical layer  - bit level - electrical/optical and voltages, connectors, pinouts, etc.)
    2. Data link layer  - frame level - IEEE 802 defines Medium Access Control (MAC) and Logical Link Control (LLC)
    3. Network layer - packet level - datagram addressing, routing and traffic control
    4. Transport layer - Segment (TCP) or Datagram (UDP) level - segmentation, acknowledgement and multiplexing
    5. Session layer - data level - session management
    6. Presentation layer - data level - translation between network comms and the actual "application"
    7. Application layer - data level - high-level API

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

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #78 on: February 15, 2018, 03:56:35 am »
    Sounds interesting. Shame there are no micros (afaik, just looked thru some Cortexes and not much more) supporting differential signaling out of the box, but then transceiver woudn't be needed just to receive trigger/clock signal.

    The Gigabit Ethernet technology seems pretty good as a command/control/data bus.
    It can handle very fast speeds, bi-directional, between multiple nodes on the bus.

    gigabit ethernet is not multidrop, it is point-to-point only.

    Which means that either:

    • master module of say 8 slot chassis would have to have 8x7 = 56 lanes connected to it
    • backplane itself would have to have ethernet switch in it - ain't that expensive but significantly complicate the backplane compared to "dumb bus" solution

    It also makes "dumb but fast" modules like fast ADC/DAC harder to make, as instead of "just" bus arbitration you'd need to implement MAC/ARP/DHCP/IP at the very least and probably at least UDP (as going anywhere below that just makes it pain in arse to interact from PC) and probably just straight LXi support.

    But on the other side, it would make "master" module side "just a rPI" and using it a breeze as you'd basically use module like any other ethernet-equipped test equipment.
     

    Offline Richard Crowley

    • Super Contributor
    • ***
    • Posts: 4317
    • Country: us
    • KJ7YLK
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #79 on: February 15, 2018, 06:15:10 am »
    gigabit ethernet is not multidrop, it is point-to-point only.
    That assumes you are using all the levels of 802.3 "Ethernet" protocol.
    I am suggesting that you CAN implement multidrop and/or whatever else is needed by establishing new protocols for the upper layers.
     

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #80 on: February 15, 2018, 09:39:06 am »
    Going back a few posts, prasimix asked about example modules. Here’s some thoughts which might help us clarify requirements.

    Basic modules
    Slow digital IO
    Slow analog IO (multimeter style or power meter)
    UART breakout
    Basic PSU / load

    Medium modules
    Pulse / PWM generators
    Medium speed IO
    Waveform generation
    Short duration waveform capture

    Advanced modules
    Real time signal processing (requires low, consistent latency)
    Wide / fast analog capture

    On the isolated power front, I think that a separate forum thread might be more appropriate?

    Edit: constrain things -> clarify requirements.
    Edit: forgot 'forum thread'
    « Last Edit: February 15, 2018, 07:03:02 pm by jbb »
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #81 on: February 15, 2018, 06:39:04 pm »
    Might be useful to have more than one trigger in "core config". Like 2 would be useful if you wanted to do "start recording at X condition, stop at Y".

    Or "start recording at trigger 1, start power supply at trigger 2"

    Or use second one as "panic button", make it stop all power supplies and hook it to temperature sensor attached to battery and to voltage sensor that triggers if battery goes above 4.22V, for testing battery chargers.

    Also, option to tie one of digital I/O pins to trigger might be pretty neat
    As for examples:

    • External trigger IO -  receive triggers, generate them and send them to chassis/external output with different delays, say "send trigger to ext out then 100ns later to the chassis
    • Thermocouple module  - few typical profiles + some flash to load your own profile + option to just work like millivoltmeter because why waste ADC only on temperature :)
    • "Arduino" - bare minimum to run an arduino-compatible bootloader on AVR or better, some Cortex


    That sounds like royal pain in arse for everyone involved honestly
    gigabit ethernet is not multidrop, it is point-to-point only.
    That assumes you are using all the levels of 802.3 "Ethernet" protocol.
    I am suggesting that you CAN implement multidrop and/or whatever else is needed by establishing new protocols for the upper layers.

    Using a standard just to throw away most of it seems like royal pain in arse for everyone involved. You're basically throwing most of advantages of having ethernet while compensating for none of it disadvantages.

    Also "multidrop" is function of layer 1, layers above it have nothing to do with it. So you can't just take ethernet chip and "implement multidrop"

    100Mbit ethernet *can* actually do it (via passive hubs), but 1Gbit can't .
     

    Offline David Hess

    • Super Contributor
    • ***
    • Posts: 16545
    • Country: us
    • DavidH
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #82 on: February 15, 2018, 11:28:33 pm »
    Using a standard just to throw away most of it seems like royal pain in arse for everyone involved. You're basically throwing most of advantages of having ethernet while compensating for none of it disadvantages.

    I agree.  One of the appeals of Ethernet is cheap expansion hardware allowing me to plug an instrument in anywhere the LAN reaches which can be a considerable distance.  For an instrumentation bus which will live inside of a single chassis, most of this capability is superfluous.

    Quote
    Also "multidrop" is function of layer 1, layers above it have nothing to do with it. So you can't just take ethernet chip and "implement multidrop"

    100Mbit ethernet *can* actually do it (via passive hubs), but 1Gbit can't .

    I considered mentioning this.  I even keep a 10/100 ethernet hub for special applications where it will work better than a switch.

    It has been a while since I looked at this and someone can correct me if I am wrong but 10Mbit and 100Mbit Ethernet on twisted pair use one pair for transmit and one for receive so the hub function is more than just bridging the signals; it selects and repeats one transmitted signal to all of the receivers so it is more than just a passive function.  Switches do actual store and forwarding.

    I always wondered if 100 Mbit Ethernet could be adapted to operate with carrier-sense multiple access with collision detection on a shared media like 10 Mbit Ethernet can but I never saw this implemented.  I have a pretty good idea how it could be done while using a standard 100 Mbit Ethernet physical layer interface.
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #83 on: February 16, 2018, 02:47:56 am »

    I considered mentioning this.  I even keep a 10/100 ethernet hub for special applications where it will work better than a switch.

    It has been a while since I looked at this and someone can correct me if I am wrong but 10Mbit and 100Mbit Ethernet on twisted pair use one pair for transmit and one for receive so the hub function is more than just bridging the signals; it selects and repeats one transmitted signal to all of the receivers so it is more than just a passive function.  Switches do actual store and forwarding.

    Yes. That allows for few neat tricks like passively tapping traffic on 100Mbit ethernet, or having fully passive hubs (at cost of signal degradation and possibly dropping speed to 10Mbit thanks to that).

    As for switches we actually went full circle and some enterprise switches are cut-thru (they read only enough to get the header then immediately start sending before receiving whole packet) and only switch to store-and-forward if outgoing port for a packet is congested. That is done to cut few extra us (or rather ns in case of 10Gbit+) off latency

    Quote
    I always wondered if 100 Mbit Ethernet could be adapted to operate with carrier-sense multiple access with collision detection on a shared media like 10 Mbit Ethernet can but I never saw this implemented.  I have a pretty good idea how it could be done while using a standard 100 Mbit Ethernet physical layer interface.
    I'm guessing that with prices falling it just didn't make sense to bother with it. Especially considering universal hatred for 10base2 shared by basically any old networking guy I ever talked to
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #84 on: February 16, 2018, 08:03:21 am »
    Thanks all once again for valuable inputs. I'd try over the weekend to compile all what is said in new proposal draft and publish it for your review.

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #85 on: February 17, 2018, 11:29:01 am »
    PCBs of XMOS evaluation board mentioned in #28 just arrived from ALLPCB (I managed to order it before Chinese holidays). They sent me 10 pcs (it seems that is minimum value despite the fact that 5 can be selected during ordering process) and I don't expect to need more then 3. Therefore if someone found this circuit usable in one or other part (since you don't need to populate everything) feel free to contact me and I'll send one PCB (for the price of shipping cost, that should be about 8 EUR in the EU). You can find schematic on the GitHub here, or complete pre-release here.
    Due to yesterday's unfortunate event I'll not be able to start assembling my boards soon.


    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #86 on: February 18, 2018, 03:29:07 pm »
    I'm working on new pin mappings trying to include some of your thoughts and saying that is quite challenging is simply understatement. Before posting another proposal, and waste your time reviewing it, I'd like to know what you can say about the following:

    1. If differential transmission line is used, I presume there is no need to have GND next to line+/- pins. But, if that is not a case, and we we have multiple SPI channels as in first proposal (see in post #29 Slot#0, pins C5 thru C32) and presume that isolation is going to be deployed, do we really need that 7 GND pins used as "separation"? Such "better grounding" is actually only valid on the Slot #0 side since we have here star topology. I'd like to spare that pins since introduction of more LVDS lines ask for many additional pins.

    2. Are you aware of any mechanism/wiring that can be implemented when same signal line(s) can be used as single-ended OR differential? In that case a part of module identification info stored in EEPROM could contain info about module capability / speed requirement. When such signal lines are not shared (i.e. multidrop) then lo-speed module could be connected with single-ended signal. In extreme case a whole chassis could be lo-speed or on other side hi-speed.

    3. Does it make sense to spare some pins (primarily on the hi-speed LVDS signals) by introducing Isochronous self-clocking signaling?

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #87 on: February 18, 2018, 07:03:07 pm »
    Sorry about the 'scope; what a pain.

    I'm working on new pin mappings trying to include some of your thoughts and saying that is quite challenging is simply understatement.

    Good plan.  Sorry about the flood of mutually-conflicting ideas.
    I do have one proposed simplification about Ethernet (which has cropped up a bit here); if people want an Ethernet-based instrument system, they should consider an open source EtherCAT slave for low cost micros.

    1. If differential transmission line is used, I presume there is no need to have GND next to line+/- pins.
    I'm not sure - this is a signal integrity matter.  While 1 ground pin per LVDS lane would be nice, it will indeed chew through 96 pins really fast. Do we have any signal integrity people in the house?? Note that when the next question comes into play, the concern becomes stronger...

    If using point to point (standard) LVDS I suspect it might be possible to reduce the number of grounds a bit.  If using M-LVDS (Multipoint LVDS), I would recommend against it because a) the signal integrity issues are more complicated and b) there just wouldn't be as many lanes chewing up pins.

    2. Are you aware of any mechanism/wiring that can be implemented when same signal line(s) can be used as single-ended OR differential?
    That's an interesting idea.  I know FPGAs can do it, and I guess that some carefully-deployed driver chips could do it too.  There might be some crosstalk issues through the backplane (not a signal integrity expert...)?

    3. Does it make sense to spare some pins (primarily on the hi-speed LVDS signals) by introducing Isochronous self-clocking signaling?
    I would be nervous about that.  The catch with this sort of thing is that you either a) need some analogue systems to do PLL-type things to generate the receive clock in each module or b) need to over-sample digitally (limits max baud rate) and then manage bit slips etc.  A synchronous reference clock makes it much easier to receive things, and also helps with overall system jitter when fast triggers are involved.

    It goes a bit against the 'dumb backplane' idea, but it would be possible to put a fanout buffer on the backplane. Multipoint LVDS (M-LVDS) offers multi-drop, and so would be good for this clock distribution task.  However, it looks like standard LVDS (while needing the fanout buffer) can pass through an Ethernet transformer for isolation.  M-LVDS almost certainly can't...
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #88 on: February 19, 2018, 09:16:06 am »
    I agree that backplane should stay passive, therefore no fan-outs and similar thing should reside on it.

    I'm still not sure that differential transmission lines require GND pin in close proximity for "return path". Other thing is that GND plane is needed beneath lines to set correct impedance.

    Regarding (re)using diff. lines as single-ended I'm still searching for more information. It's simple to imagine that some chassis will be populated with lo-speed modules only without all overhead related to LVDS drivers and isolations (e.g. mentioned Ethernet transformers). Maybe in that situation unused line can be used for return GND. If that is a case, the question is do we need some kind of "hard-coded" protection (e.g. connector key pin) to prohibit inserting module with LVDS drivers into chassis with modules that use diff. lines as single-ended.

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #89 on: February 19, 2018, 11:30:35 am »
    Maybe just have additional connector for hi-speed differential ? Then low-speed module would just... not mount it.

    One option for relatively fast and low pinout bus would be just USB2.0, just 2 pins for >400MBits of bandwidth, that is also very easy to interact with directly from micro.



     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #90 on: February 19, 2018, 11:49:31 am »
    One option for relatively fast and low pinout bus would be just USB2.0, just 2 pins for >400MBits of bandwidth, that is also very easy to interact with directly from micro.

    But a sort of USB hub or switch is then needed to be implemented on the processor module (#0) or on the backplane, or not?

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #91 on: February 19, 2018, 08:52:03 pm »
    Yes it would, however there are pretty much commodity. Disadvantage is quite a bit of overhead when coding for it (altho there is plenty of ready-made code to support) and possible issues with bus contention (as you can't really control how usb hub handles traffic)
     

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #92 on: February 19, 2018, 09:02:42 pm »
    Just FYI, isolating LVDS with a transformer requires the use of DC-level coding eg 8b/10b (which is commonly used). Unfortunately that will likely require SERDES chips or FPGAs (could use ICE40s).

    It’s possible to get quite good software triggering, especially if a good clock is distributed.
     

    Offline Vtile

    • Super Contributor
    • ***
    • Posts: 1144
    • Country: fi
    • Ingineer
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #93 on: February 19, 2018, 09:05:03 pm »
    I didn't read this through, but I hope there have been though of:

    - Power consumption, should be compatible with low power battery equipment.
    - Separation, Should be galvanically isolated.
    - Complexity, should fit in a minimum of memory and be build with ease.
    - Cost, Should use simple parts and techniques
    - Measurable, medium speed.


    IE. Interesting protocol SW/HW were HP-IL
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #94 on: February 19, 2018, 09:42:49 pm »
    Yes it would, however there are pretty much commodity. Disadvantage is quite a bit of overhead when coding for it (altho there is plenty of ready-made code to support) and possible issues with bus contention (as you can't really control how usb hub handles traffic)

    Great, and we are again in situation that asks for MCU on all modules (master/control and slaves/peripherals) or at least a kind of USB-to-somethingelse bridge on peripheral modules.

    Just FYI, isolating LVDS with a transformer requires the use of DC-level coding eg 8b/10b (which is commonly used). Unfortunately that will likely require SERDES chips or FPGAs (could use ICE40s).

    It’s possible to get quite good software triggering, especially if a good clock is distributed.

    He, he, and guess which MCU (not FPGA) has serious built-in SERDES functionality: XMOS again ;)


    I didn't read this through, but I hope there have been though of:

    - Power consumption, should be compatible with low power battery equipment.
    - Separation, Should be galvanically isolated.
    - Complexity, should fit in a minimum of memory and be build with ease.
    - Cost, Should use simple parts and techniques
    - Measurable, medium speed.

    Power consumption is currently not discussed, nor specific pins or functionality is assigned for power management (so far only +5VAUX as stand-by power is listed).

    Isolation is indeed addressed, and it's a must for some instruments.

    Min. memory yes, as far as it's 256KB or more (talking from existing experience). Avoiding QFN, BGA and similar packages can make building simpler (no stencil, oven, etc.).

    Cost and BOM (i.e. parts count) is important and that why we are discussing here what underlaying HW protocols/buses to use as "basic/cheap" and "advanced/expensive".

    Medium speed yes, if that mean something in-between 10 and 200 Mbps.

    IE. Interesting protocol SW/HW were HP-IL

    Yes, it was, let rest it in peace :)

    Offline Vtile

    • Super Contributor
    • ***
    • Posts: 1144
    • Country: fi
    • Ingineer
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #95 on: February 19, 2018, 10:18:44 pm »
    How you measure something like 200mbps without 2k5+ eur/dollar instrument?? Sounds pretty far from diy.
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #96 on: February 19, 2018, 10:53:12 pm »
    Yes, one thing is measuring (or sampling) something 200 million times per second, and another one is to have a bus that is capable of transferring with such speed. If you take a look at e.g. LVDS you can see that 100/200 Mbps drivers are available for decent price.

    Even if we come to measuring at least 100 MSps is achievable without spending multi Kdollars. Currently we are not discussing any instrument capabilities in details, but yes, a few use cases should be useful in shaping a whole thing as I suggested that in #76. To get a better picture I'd like to suggest you to spend a little more time to read thru all what is already proposed and discussed. You'll see among other stuff that topic is highly antagonistic: it easily gather two groups of "believers" and "non-believers" in just-another-standard as it can be baptized :). But, let's be realistic, I'm not the one who can alone set any standard (by any standard!), I just want to make development of my future toys more manageable and reusable. Getting feedback from community is highly appreciated (and proven to be very fruitful if talking from previous experience). Finally, if DIY in topic title looks misleading, I can tell you that is not, because everything what I was designed so far belongs to DIY or in other words, I believe that if I succeed to make some stuff then many others definitely could do the same thing (even better).


    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #97 on: February 20, 2018, 07:37:14 am »
    Yes it would, however there are pretty much commodity. Disadvantage is quite a bit of overhead when coding for it (altho there is plenty of ready-made code to support) and possible issues with bus contention (as you can't really control how usb hub handles traffic)

    Great, and we are again in situation that asks for MCU on all modules (master/control and slaves/peripherals) or at least a kind of USB-to-somethingelse bridge on peripheral modules.


    I meant USB as an option for mid-hi-speed, not as requirement for every module. Extracting data is also easier, as it is "literally any rPi-like board with USB and some basic coding" vs "probably an FPGA with a bunch of LVDS channels and few RAM chips"

    Besides, I don't really see a problem in including $1 micro on each one considering even connector is few times more expensive than that. It would probably be even possible to program it in-chassis for micros that have serial bootloader in ROM

    Just FYI, isolating LVDS with a transformer requires the use of DC-level coding eg 8b/10b (which is commonly used). Unfortunately that will likely require SERDES chips or FPGAs (could use ICE40s).

    It’s possible to get quite good software triggering, especially if a good clock is distributed.

    He, he, and guess which MCU (not FPGA) has serious built-in SERDES functionality: XMOS again ;)
    Without builtin 8/10b that's still some work to make it work and still requires driver; but it also does have USB ;)
     

    Offline Vtile

    • Super Contributor
    • ***
    • Posts: 1144
    • Country: fi
    • Ingineer
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #98 on: February 20, 2018, 08:50:30 am »
    No I did mean that if this is something that is supposed to be done at home or small outsourced batches. Then how you can troubleshoot the electrical side of the things without expensive instruments out of the most hobbyists reach.. Ie verifying that the edges aren't ringing and that sort of measurements.

    Heck I can't even troubleshoot 100Mbps ethernet in my current job, since it is cheaper just to swap parts compared to expensive equipment needed. Gain compared to 'vintage bus' not much at all tbh.
    « Last Edit: February 20, 2018, 08:54:39 am by Vtile »
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #99 on: February 20, 2018, 12:37:47 pm »
    Hobbyist with 50MHz scope wont be able to debug 100Mbit LVDS very well either so pretty much any high-speed option would be hard for most hobbyists to debug
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #100 on: February 20, 2018, 01:28:54 pm »
    Hobbyist with 50MHz scope wont be able to debug 100Mbit LVDS very well either so pretty much any high-speed option would be hard for most hobbyists to debug

    Right. I don't understand where's point to invent next bus. Hi-speed LVDS for hobbyists is straight road to failure because you can't hope to receive wide acceptance, there will be not that many hobbyists who will develop their modules for obscure "standard" coming from eevblog forum.

    Why don't simply use USB? HUB ic's are cheap as sand, microcontrollers with USB peripherals as well. USB would allow stand-alone use and development of modules as well. Win win win solution. IMHO.
    « Last Edit: February 20, 2018, 01:32:56 pm by ogden »
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #101 on: February 20, 2018, 01:44:37 pm »
    Thanks to all recent posts. I got the message, in the meantime if some of USB-proponents find a nice way how to isolate USB bus that is faster then full speed (i.e. USB 2.0 or later) please let us know.

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #102 on: February 20, 2018, 02:03:14 pm »
    Thanks to all recent posts. I got the message, in the meantime if some of USB-proponents find a nice way how to isolate USB bus that is faster then full speed (i.e. USB 2.0 or later) please let us know.

    If isolation at communication end of the module is *requirement*, then obviously Ethernet is next thing in the list. Some would like to use just single module w/o backplane (with lo-cost adapter board) and using USB/Ethernet/both is elegant way to allow it. Not to mention much higher chances of acceptance compared to proprietary LVDS BUS "standard out of nowhere". USB for lo-speed modules and Ethernet - for hi-speed. I would put USB on the backplane and Ethernet socket on the front panel of the hi-speed modules. This could require Ethernet switch module, and obviously external wiring but why not? After all it's DIY which supposedly is "low cost" as well, right? Also I would put isolators on backplane so there could be two versions of backplane - isolated and low-cost nonisolated.

     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #103 on: February 20, 2018, 02:09:34 pm »
    If isolation at communication end of the module is *requirement*

    Yes it is, already mentioned few times and that is for practical reasons because I don't know how to control from single place multiple e.g. floating power supply or el. load modules without introducing isolation.

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #104 on: February 20, 2018, 02:14:09 pm »
    If isolation at communication end of the module is *requirement*

    I don't know how to control from single place multiple e.g. floating power supply or el. load modules without introducing isolation.

    Well, look at the existing bench instruments then :) They all have non-isolated comms & control with floating measurement part.

    [edit] If some module will require buttons, rotary encoders and so on - do you really want them to be connected to point of measurement? - I don't.
    « Last Edit: February 20, 2018, 02:15:43 pm by ogden »
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #105 on: February 21, 2018, 02:18:59 pm »
    Multimeters sure, but scopes and sig gens generally have gnd tied to ground. So it is definitely not "all"

    Thanks to all recent posts. I got the message, in the meantime if some of USB-proponents find a nice way how to isolate USB bus that is faster then full speed (i.e. USB 2.0 or later) please let us know.
    Probably easiest way would be isolating other side (between micro and ADC, ~100-150Mbit isolators are pretty cheap). Chips doing isolation at 480Mbit do seem to exist http://www.prweb.com/releases/2015/10/prweb12995871.htm just not buyable at hobbyist quantity

    Thanks to all recent posts. I got the message, in the meantime if some of USB-proponents find a nice way how to isolate USB bus that is faster then full speed (i.e. USB 2.0 or later) please let us know.

    If isolation at communication end of the module is *requirement*, then obviously Ethernet is next thing in the list. Some would like to use just single module w/o backplane (with lo-cost adapter board) and using USB/Ethernet/both is elegant way to allow it. Not to mention much higher chances of acceptance compared to proprietary LVDS BUS "standard out of nowhere". USB for lo-speed modules and Ethernet - for hi-speed. I would put USB on the backplane and Ethernet socket on the front panel of the hi-speed modules. This could require Ethernet switch module, and obviously external wiring but why not? After all it's DIY which supposedly is "low cost" as well, right? Also I would put isolators on backplane so there could be two versions of backplane - isolated and low-cost nonisolated.

    Sure ethernet is one option but if you have ethernet then... why the fuck even bother with anything else ? Just have a box with ethernet and power connector and nothing else.
    Like only thing you really gain is maybe sharing clock/trigger (and if you just need us resolution, just send a broadcast packet)

    Like, really, you have Gbit of transfer rate (and ethernet goes way above that if you really need to), well supported standards and if you really hate connecting more than one cable to the box, PoE can supply from ~12 to 50W
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #106 on: February 21, 2018, 04:02:58 pm »
    Multimeters sure, but scopes and sig gens generally have gnd tied to ground. So it is definitely not "all"

    Good point to think about :)

    Quote
    Like, really, you have Gbit of transfer rate (and ethernet goes way above that if you really need to), well supported standards and if you really hate connecting more than one cable to the box, PoE can supply from ~12 to 50W

    Ethernet will increase complexity and price of low speed modules that can happily run SCPI over USB. Everybody most likely can find free USB ports on their computer right now, but will struggle finding Ethernet switch ports around.
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #107 on: February 21, 2018, 05:39:44 pm »
    Multimeters sure, but scopes and sig gens generally have gnd tied to ground. So it is definitely not "all"

    Good point to think about :)

    Quote
    Like, really, you have Gbit of transfer rate (and ethernet goes way above that if you really need to), well supported standards and if you really hate connecting more than one cable to the box, PoE can supply from ~12 to 50W

    Ethernet will increase complexity and price of low speed modules that can happily run SCPI over USB. Everybody most likely can find free USB ports on their computer right now, but will struggle finding Ethernet switch ports around.


    Sure, I know, just that my point was that once you have ethernet you don't really need remaining signals and requiring chassis becomes a drawback, as you can't just separate the module and use it somewhere else easily.

    But I guess exactly same thing can be said about USB, maybe expect speed. It is relatively cheap to get 10Gbit NIC and 1Gbit switch that has 10Gbit upstream port, while in case of USB it is one upstream port shared between all nodes.

    And now I'm considering how hybrid approach would work, like having low-speed-only (well, single digit of Msps, not hundreds) chassis that just shares devices inside with outside using ethernet and high speed stuff delegated to standalone modules with ethernet (with maybe some tiny connector with clock/sync to the chassis)

     

    Offline welterde

    • Contributor
    • Posts: 19
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #108 on: March 06, 2018, 05:36:58 am »
    I would prefer to avoid complex protocols such as Ethernet or USB, since I was hoping to use this to build many rather simple modules and combining those to do what I want (divide and conquer), instead of building one module that does everything I want (then why really bother with DIB again?).

    My proposal would be to have a shared SPI bus for slow control with 3 per-module chip-select signals.
    One CS signal would be used for an SPI EEPROM that contains information about the module and the other 7 possible combinations can be used for other SPI devices on the module (similar to what has been suggested before).
    One can easily generate the actual CS signals with an 3-to-8 decoder IC - or directly use the three lines if it's less than four devices.
    This would cover most simple modules that have no large data bandwidth requirements (like power supplies, slow DAQ, etc.).
    And there are more or less easy to use SPI to I2C/UART/1wire/.. chips if one doesn't want to deal with SPI directly or wants to hook something else up.

    And for slightly higher bandwidth applications one could use an per-module LVDS SPI bus, which is still easy enough to implement on the modules (one <3€ LVDS transceiver IC).
    Or is that overkill for an SPI bus that's maybe 50cm in length running at maybe 60Mhz (or however far people want to push it)?

    Adding various power supplies, master clocks and some trigger signals pretty much fills up the 48 pins for the modules already.
    Even higer bandwidths, analog busses, etc. I would put on a (optional) second connector (or use cables between modules).
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #109 on: March 06, 2018, 08:24:47 am »
    SPI vs serial is an interesting case in itself.

    On one side SPI allows card itself to be very simple and don't even have a micro, and generally be faster than UART, also easier to daisy chain and drive few chips without need for additional switching. On other, to program it you pretty much have to exactly know beforehand what are you communicating with. Which means either:

    * enter it by hand in controller, and re-enter every time you move something around
    * have an additional bus with EEPROM that IDs the board. And at that point, if you have programmable device then why not just put micro there ?
    * have additional SPI chip on bus that only purpose is to send a bunch of ID bytes

    In case of serial you can *basically* just implement some basic protocol or even just SCPI directly (and get benefits of using pre-made software to control it) but:

    * you pretty much require one micro per module
    * speeds are generally lower
    * master card needs either a bunch of UARTs or some multiplexing

     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #110 on: March 06, 2018, 11:44:01 am »
    SPI vs serial is an interesting case in itself.

    On one side SPI allows card itself to be very simple and don't even have a micro

    "Does not need micro" is danger territory. This means that there is no hardware abstraction - control software must know what kind of IC's are on the card and how they shall be driven, what are properties of the card. What's worse - where do you put all the (gain/offset/e.t.c.) calibration data? On the controller or on the board? If on the board then additional EEPROM needed which basically costs as much as micro, not to mention that EEPROM needs to be somehow communicated to. If someone wants to design own power supply, he must develop part of controller sofware as well! Come on! - It's 21st century. Today everything that runs on electricity, have micro.

    I would add RS485 or RS422 to the list:

    + common bus, does not need mux
    + still async serial
    + speeds are not that slow, you can reach even 10Mbit - obviously if UART peripheral of MCU supports such :)
    + signal integrity much better than CMOS signals (SPI or UART)
    + longer runs possible. you can control whole 19" rack full of cards through single bus
    - needs bus driver and micro with UART
    « Last Edit: March 06, 2018, 11:49:39 am by ogden »
     

    Offline welterde

    • Contributor
    • Posts: 19
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #111 on: March 06, 2018, 05:00:34 pm »
    You will need an EEPROM or microcontroller on each module anyway for the module to identify itself towards the controller (which I also mentioned in my proposal).
    EEPROM vs. micro is not really about cost, but about simplicity.
    And if you want serial communication with the module, adding a SPI-to-UART chip is easy enough.
    You are of course right that RS485 or so would be able to run at a higher speed, but is that really needed for the slow control bus?

    As for the HAL.. I would put that into the controller instead of the module - at least for simple modules.
    Sure - a power supply might expose a higher level protocol, but I really don't want to write boilerplate code just so I can control a few DACs (and nothing else) on a module.
    And unless we want to specify a (complex) common protocol for all modules to use, we'll end up with different protocols for each module anyway.
    At which point the controller needs per-module-type logic again..
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #112 on: March 06, 2018, 09:59:54 pm »
    Sure - a power supply might expose a higher level protocol, but I really don't want to write boilerplate code just so I can control a few DACs (and nothing else) on a module.

    Right. Good power supply needs just few DACs to be controlled. No readouts of in/out current/voltage needed, LEDs that indicate PSU stale like CV/CC and so on, are not needed as well. Right. Only simple module I can imagine is relay card, yet it most likely needs not only relay control, but some indication as well.

    Whatever... do as you want. Just my two cents.
     

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #113 on: March 06, 2018, 10:47:45 pm »
    I think Prasimix is proposing I2C for module ID (and calibration etc.) plus a cunning pre-addressing trick for the SPI lines to support multiple slave devices per board.

    They have also said that they want star connections where reasonable to reduce bus contention and also allow some modules to go faster than others. This makes sense to me because it means higher data rate modules (e.g. data acquistion) shouldn’t get choked by something with a slow SPI clock.

    It should be reasonable to use SPI devices direct or SPI to UART converters or even slave SPI ports on micro controllers.
     

    Offline welterde

    • Contributor
    • Posts: 19
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #114 on: March 06, 2018, 11:57:23 pm »
    Sure - a power supply might expose a higher level protocol, but I really don't want to write boilerplate code just so I can control a few DACs (and nothing else) on a module.

    Right. Good power supply needs just few DACs to be controlled. No readouts of in/out current/voltage needed, LEDs that indicate PSU stale like CV/CC and so on, are not needed as well. Right. Only simple module I can imagine is relay card, yet it most likely needs not only relay control, but some indication as well.

    Whatever... do as you want. Just my two cents.

    I have a few modules in mind to construct a CCD controller that will each be very simple.
    And I am not arguing that a complete power supply *should* be built up just with a few SPI devices, but if people want to do that why not? You don't have to use those modules if you don't want to... Nothing prevents you from implementing a higher level protocol on top of SPI or SPI-UART..

    For example for the DC bias module I really do want to just have two SPI DAC's (and a bunch of fixed opamps, etc.), since for example readback, etc. will happen on another module.
    I don't really see the point of adding another micro there, which does nothing other than wrapping the DAC commands in a slightly different protocol.

    I think Prasimix is proposing I2C for module ID (and calibration etc.) plus a cunning pre-addressing trick for the SPI lines to support multiple slave devices per board.

    I was first thinking about just using three pins on the module connector to encode the module slot ID towards the I2C EEPROM as well, but then I thought that instead of using three pins  to encode an I2C address I could use three pins (and 7*3 pins on the cpu-connector; or shift register on the backplane) to encode 8 SPI devices one of which just happens to be the SPI EEPROM.

    But if we can get multiple I2C devices per board that would also work for me.

    They have also said that they want star connections where reasonable to reduce bus contention and also allow some modules to go faster than others. This makes sense to me because it means higher data rate modules (e.g. data acquistion) shouldn’t get choked by something with a slow SPI clock.

    Hence my suggestion to have a per-module LVDS SPI bus separate from the slow shared SPI bus (still not sure if using LVDS is really neccessary).
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #115 on: March 07, 2018, 10:22:43 am »
    And I am not arguing that a complete power supply *should* be built up just with a few SPI devices, but if people want to do that why not?

    How many SPI select lines will you dedicate for each slot? Two? Four? That number cannot be "fluid". Then there comes SPI data/clk line load problem - because you shall design whole thing for worst possible case - when every resource of the chassis is used. It means either SPI mux or multiple SPI masters.

    Quote
    You don't have to use those modules if you don't want to... Nothing prevents you from implementing a higher level protocol on top of SPI or SPI-UART..

    Me? I will not use any modules or your chassis :)  Why? - Because when building own module like power supply, I need skills to build electronics of module and also need skills to code control software. Basically I have to do everything. Your chassis seemingly have no added value then. Then why I need your chassis? :-DD

    [edit] - Just because you defined backplane electrical signalling?  - I can do it myself as well. Note that BUS is more than just socket pinout definition and some kind of data transfer interface choice. Also - successful and widely accepted modular system is more than just backplane bus.

    Quote
    Hence my suggestion to have a per-module LVDS SPI bus separate from the slow shared SPI bus (still not sure if using LVDS is really neccessary).

    Sure. LVDS SPI. Complexity will be very appealing for 3rd party module designers.  :-DD
    « Last Edit: March 07, 2018, 12:25:38 pm by ogden »
     

    Offline welterde

    • Contributor
    • Posts: 19
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #116 on: March 07, 2018, 01:27:20 pm »
    And I am not arguing that a complete power supply *should* be built up just with a few SPI devices, but if people want to do that why not?

    How many SPI select lines will you dedicate for each slot? Two? Four? That number cannot be "fluid". Then there comes SPI data/clk line load problem - because you shall design whole thing for worst possible case - when every resource of the chassis is used. It means either SPI mux or multiple SPI masters.

    Well my suggestion was to use 3, since <=7 devices sounds quite reasonable for small modules.

    The alternative suggestion was to have 1 and using a sort of addressing logic over SPI to address a potentially much larger number of SPI devices if I understood correctly.
    And also have a shared I2C bus instead of a shared SPI bus.

    Quote
    You don't have to use those modules if you don't want to... Nothing prevents you from implementing a higher level protocol on top of SPI or SPI-UART..

    Me? I will not use any modules or your chassis :)  Why? - Because when building own module like power supply, I need skills to build electronics of module and also need skills to code control software. Basically I have to do everything. Your chassis seemingly have no added value then. Then why I need your chassis? :-DD

    Didn't you argue you for having a HAL above the module layer earlier..? Wouldn't that mean that *any* chassis would be useless to you?

    What would a chassis have to bring to the table to be useful for you?

    For me power and some easy slow-control bus would already be quite useful. Anything else I need (~30 trigger signals, analog routing, fast LVDS connections) is probably outside the scope of this project and best handled with some extra cables between modules..
    « Last Edit: March 07, 2018, 02:01:56 pm by welterde »
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #117 on: March 07, 2018, 09:27:42 pm »
    Didn't you argue you for having a HAL above the module layer earlier..? Wouldn't that mean that *any* chassis would be useless to you?

    It's you who suggested that card creator can create HAL himself over SPI bus, suggesting that DIB is nothing more than just physical and electrical definition of backplane. Bus is more than that. W/o higher level API and good software indeed it is more or less useless.

    I did not say anything about HAL, I said - you have to abstract hardware. Control software shall not directly write into ADC or DAC registers. No matter - such function lives in the HAL layer of controller or not. It shall control voltage of power supply, not DAC counts. Module itself shall apply all the compensation and calibration. Those who write control software shall be freed from reading ADC or DAC chip datasheets and those who are good doing electronics, shall be freed from coding anything else than MCU they know.

    Quote
    What would a chassis have to bring to the table to be useful for you?

    Chassis appealing to me could be cost-optimized Keysight U2781A. Definitely with low-speed USB-less card support we are talking here for a while. It shall have quick & easy learning curve for those creating new/own cards. Like Arduino of instrumentation :) Chassis alone will not work, it shall be whole ecosystem of affordable, easy DIY instrumentation.

    Reference hw/sw design of few typical cards shall be available, as well as "card SDK". Would be supercool if AVR or even Arduino-based cards are shown as examples. I would like stm32-series, but do not insist on that. No need to create very complex instrumentation API. It's enough to create communication API for instruments. Host communications could be very simplified like sendvariable(char *name, double value); senddataarray(char *name, double *pdata, int size). Receive functions - just typical function callbacks, registered by variable name. Obviously card can have other (optional) modes of communication such as SCPI.

    Quote
    Anything else I need (~30 trigger signals, analog routing, fast LVDS connections) is probably outside the scope of this project

    What about extension bus for hi-end features? Cards are wide enough. You can put Two connectors on advanced cards, one on standard version cards.
     

    Offline welterde

    • Contributor
    • Posts: 19
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #118 on: March 08, 2018, 02:34:41 am »
    It's you who suggested that card creator can create HAL himself over SPI bus, suggesting that DIB is nothing more than just physical and electrical definition of backplane. Bus is more than that. W/o higher level API and good software indeed it is more or less useless.

    I did not say anything about HAL, I said - you have to abstract hardware. Control software shall not directly write into ADC or DAC registers. No matter - such function lives in the HAL layer of controller or not. It shall control voltage of power supply, not DAC counts. Module itself shall apply all the compensation and calibration. Those who write control software shall be freed from reading ADC or DAC chip datasheets and those who are good doing electronics, shall be freed from coding anything else than MCU they know.

    Ah.. I misunderstood you then. When I read control software I thought you meant the software controlling the internals of the power supply not something that might control multiple power supplies, etc.

    So something like VME, where you read/write a bunch of addresses to control the modules would be fine I guess?

    Quote
    Anything else I need (~30 trigger signals, analog routing, fast LVDS connections) is probably outside the scope of this project

    What about extension bus for hi-end features? Cards are wide enough. You can put Two connectors on advanced cards, one on standard version cards.

    Yes, this has been proposed before. But I don't really think it's useful for what I have in mind. For more general purpose stuff I am all for it.

     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #119 on: March 08, 2018, 07:36:56 am »
    My proposal would be to have a shared SPI bus for slow control with 3 per-module chip-select signals.
    One CS signal would be used for an SPI EEPROM that contains information about the module and the other 7 possible combinations can be used for other SPI devices on the module (similar to what has been suggested before).
    One can easily generate the actual CS signals with an 3-to-8 decoder IC - or directly use the three lines if it's less than four devices.

    No more then one CS signal is needed if you are using '595 (see post #43) that can be clocked much faster then SPI (to compensate 8 clocks needed to shift data for target CS). "Module info" EEPROM could be one of SPI devices (e.g. #0).

    Quote
    Hence my suggestion to have a per-module LVDS SPI bus separate from the slow shared SPI bus (still not sure if using LVDS is really neccessary).

    Sure. LVDS SPI. Complexity will be very appealing for 3rd party module designers.  :-DD

    Please let me know how "LVDS SPI" is different then "RS485 SPI" that you proposed? Both require line drivers, but in both case it's completely irrelevant what type of higher layer signaling (i.e. SPI) is used for communication. Do you want to say that LVDS presume more challenging PCB routing?


    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #120 on: March 08, 2018, 10:06:01 am »
    No more then one CS signal is needed if you are using '595 (see post #43) that can be clocked much faster then SPI (to compensate 8 clocks needed to shift data for target CS). "Module info" EEPROM could be one of SPI devices (e.g. #0).

    Oh, I see. Additional SIPO register for chip selects, then EEPROM for module info, unusual SPI clocking. All this mess for what? To me it seems like MCU-phobia rather than rational & farsighted design.

    Please let me know how "LVDS SPI" is different then "RS485 SPI" that you proposed?

    For a record I did not propose RS485 SPI:

    I would add RS485 or RS422 to the list:
    + common bus, does not need mux
    + still async serial

    Most commonly used and known LVDS topology is point-to-point. RS485 including it's transceivers is multidrop by design. That's the difference.

    IMHO problem of multidrop LVDS SPI is slave SOMI output. Only way I imagine LVDS SPI is: point-point lines for each SOMI->MISO connection which are mux'ed on the master side. That obviously I consider as much more complex than rs485 which have both transmit and receive as multidrop topology.
    « Last Edit: March 08, 2018, 11:30:54 am by ogden »
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #121 on: March 08, 2018, 10:25:02 am »
    So something like VME, where you read/write a bunch of addresses to control the modules would be fine I guess?

    Kind of. Considering that I don't even know what VME is ;) Not addresses but named variables. During init master enumerates module capabilities including list of the variables that can be written and/or polled. Variable can be either single value or number of values in array, various common data types shall be supported as well (double/float/int8/int16/int32/string).
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #122 on: March 08, 2018, 11:27:43 am »
    No more then one CS signal is needed if you are using '595 (see post #43) that can be clocked much faster then SPI (to compensate 8 clocks needed to shift data for target CS). "Module info" EEPROM could be one of SPI devices (e.g. #0).

    Oh, I see. Additional SIPO register for chip selects, then EEPROM for module info, unusual SPI clocking. All this mess for what? To me it seems like MCU-phobia rather than rational & farsighted design.

    Not really, such irrational design is based on an attempt to provide support for at least 6 peripheral modules while on the MCU/CPU/Master/#0 module only 96-pin connector is utilized (as basic/mandatory connector). You can try an exercise for yourself and see how fast you will run out of available pins.
    If you can recommend connector with higher pin count that does not cost a fortune and is easily to obtain, please let me know.

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #123 on: March 08, 2018, 11:39:54 am »
    If you can recommend connector with higher pin count that does not cost a fortune and is easily to obtain, please let me know.

    Thank you, I will not. I would simply put MCU on the module to not have pin count problem.
     

    Offline void_error

    • Frequent Contributor
    • **
    • Posts: 673
    • Country: ro
    • I can transistor...
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #124 on: March 08, 2018, 12:05:33 pm »
    If you can recommend connector with higher pin count that does not cost a fortune and is easily to obtain, please let me know.

    Thank you, I will not. I would simply put MCU on the module to not have pin count problem.

    Hmm... does that mean that every module will have a different MCU from a different manufacturer depending on the designer's preferences or enforce the use of a particular MCU architecture across all the modules? I don't think everyone will agree with any of those.

    Also, for modules such as bench power supplies you still need dedicated DACs & ADCs if you want anything higher than ~16-bit and a MCU would be a waste of space and money unless you want to implement some kind of PID loop like for an electronic load's constant resistance mode. In other words, if high sampling rate and/or complex calculations are not required I think there's no point in adding a MCU which is going to spend most of its time waiting for the 'read ADC timer' to overflow or get some request to send data...
    Trust me, I'm NOT an engineer.
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #125 on: March 08, 2018, 12:18:24 pm »
    Hmm... does that mean that every module will have a different MCU from a different manufacturer depending on the designer's preferences or enforce the use of a particular MCU architecture across all the modules? I don't think everyone will agree with any of those.

    Give me a break... So your solution is to use "standardized SIPO register and EEPROM"?  :-DD

    Every "manufacturer" will use same ADC and DAC. Right.

    Quote
    Also, for modules such as bench power supplies you still need dedicated DACs & ADCs if you want anything higher than ~16-bit and a MCU would be a waste of space and money unless you want to implement some kind of PID loop like for an electronic load's constant resistance mode.

    :palm:

    MCU would handle offset, calibration and hardware abstraction so every supply in "your instrumentation standard" is controlled same way and it's voltage and current readout is done same way. In your proposal every "manufacturer" can save 2 dollars (huge savings!!!) on MCU and place any kind and number of ADCs and DACs on power suplies, then put some shift registers for LEDs and so on - to make compatibility between various supplies a total mess.

    Your joke "MCU would be a waste of space and money" saved my day.  :-DD
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #126 on: March 08, 2018, 12:23:16 pm »
      Well, burning 2 pins for serial and just sending configuration via it makes more sense than burning 8 pins just for chip selects.

      Have a mandatory serial bus  for

      • Configuration
      • Identification
      • Writing/reading configuration registers - say if only reason you need SPI is to set few config registers then just write it on serial and let micro handle it
      • Low speed measurement

      And then just use saved pins for whatever else is needed

      Hell, I can imagine a case where you could have few shared pins and then
      • Tell module A "send ADC data on bus 0"
      • Tell module B "send ADC data on bus 1"
      • Tell module C "receive data on bus 0,1, send your output to bus 2
      • Tell module D "receive data on bus and output it via ADC"
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #127 on: March 08, 2018, 12:57:08 pm »
    If you can recommend connector with higher pin count that does not cost a fortune and is easily to obtain, please let me know.

    Thank you, I will not. I would simply put MCU on the module to not have pin count problem.

    Hmm... does that mean that every module will have a different MCU from a different manufacturer depending on the designer's preferences or enforce the use of a particular MCU architecture across all the modules? I don't think everyone will agree with any of those.

    https://jaycarlson.net/microcontrollers/

    Every SINGLE $1 micro has an UART and SPI (altho to be fair in some cases they share same piece of hardware). Most also have I2C (altho I'm not sure how many can work as slave)

    So you can pretty much take almost any micro and use it, if it was just a serial bus.

    Quote
    Also, for modules such as bench power supplies you still need dedicated DACs & ADCs if you want anything higher than ~16-bit and a MCU would be a waste of space and money unless you want to implement some kind of PID loop like for an electronic load's constant resistance mode. In other words, if high sampling rate and/or complex calculations are not required I think there's no point in adding a MCU which is going to spend most of its time waiting for the 'read ADC timer' to overflow or get some request to send data...

    Okay. Let's say it is just a power supply.

    You'd probably still NOT want to drive it directly via SPI because then you'd have to handle all calibration on the controller side and also store all calibration data on controller side. Or add another eeprom somewhere.

    And you would want to have calibration because getting higher % shunt resistor is cheaper than having some high precision one just to save $1 on a micro.

    And you probably would still want to have a readout of current/voltage.

    So at the very minimum you'd have to write to 2 DACs and read from 2 ADCs + 2-4 (depending wheter those would be separate or dual adc/dacs) CS.

    That's a minimum. You probably also want

    • Actual power on/off (with output disconnect) signal instead of "set DACs to 0 and hope for best"
    • Info to controller whether it is in CC/CV mode
    • Probably a temperature sensor output so it can alert operator why power supply stopped providing required power
    • Any other alert it could generate

    And the moment you change ADC/DACs, your controller needs to change its code.

    Compare it to "just send what voltage/amperage I want over serial and receive any measurement, and let module's micro deal with it".

    Then you can have generic model of "this is a power supply, it accepts this and that command" (and same with ADC/DAC/digital I/O at least at serial-level speed) and anything will work without much/any change in code
     

    Offline void_error

    • Frequent Contributor
    • **
    • Posts: 673
    • Country: ro
    • I can transistor...
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #128 on: March 08, 2018, 01:39:13 pm »
    Hmm... does that mean that every module will have a different MCU from a different manufacturer depending on the designer's preferences or enforce the use of a particular MCU architecture across all the modules? I don't think everyone will agree with any of those.

    Give me a break... So your solution is to use "standardized SIPO register and EEPROM"?  :-DD

    Every "manufacturer" will use same ADC and DAC. Right.
    Let me dumb it down for you:

    Bob, Jim and Matt all want to build their own module on the instrumentation bus.
    Bob uses a micro from ST on his module, Jim uses a micro from NXP on his module and Matt uses a TI micro on his.

    Bob wants to also build the modules that Matt designed, and also the one that Jim designed. He wants to add some features to Jim's firmware and some other features to Matt's firmware but he only has an ST-Link so he can only debug code running on STMs.

    Do you see any issues here?
    Quote
    Also, for modules such as bench power supplies you still need dedicated DACs & ADCs if you want anything higher than ~16-bit and a MCU would be a waste of space and money unless you want to implement some kind of PID loop like for an electronic load's constant resistance mode.

    :palm:

    MCU would handle offset, calibration and hardware abstraction so every supply in "your instrumentation standard" is controlled same way and it's voltage and current readout is done same way. In your proposal every "manufacturer" can save 2 dollars (huge savings!!!) on MCU and place any kind and number of ADCs and DACs on power suplies, then put some shift registers for LEDs and so on - to make compatibility between various supplies a total mess.

    Your joke "MCU would be a waste of space and money" saved my day.  :-DD
    'manufacturer'... see above.

    https://jaycarlson.net/microcontrollers/

    Every SINGLE $1 micro has an UART and SPI (altho to be fair in some cases they share same piece of hardware). Most also have I2C (altho I'm not sure how many can work as slave)

    So you can pretty much take almost any micro and use it, if it was just a serial bus.

    I know that. See my statement above, featuring Bob, Jim and Matt.

     :palm:

    Do you people actually read what you reply to?

    Anyway, I'm out, It's seems I'm not one of those hobbyists with 30+ years of experience in the field and a lot of money and free time. Have fun.
    Trust me, I'm NOT an engineer.
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #129 on: March 08, 2018, 01:56:38 pm »
    Let me dumb it down for you:

    Bob, Jim and Matt all want to build their own module on the instrumentation bus.
    Bob uses a micro from ST on his module, Jim uses a micro from NXP on his module and Matt uses a TI micro on his.

    Bob wants to also build the modules that Matt designed, and also the one that Jim designed. He wants to add some features to Jim's firmware and some other features to Matt's firmware but he only has an ST-Link so he can only debug code running on STMs.

    Do you see any issues here?

    Yes. Your argument have serious "issue": in controller-less design nobody you mention can even build anything because they know only their micros. None of them knows how to code controller software :D

    Actually if you believe that what you "dumbed down" for me is serious argument- that  microcontroller on the module is bad thing because there are so many microcontrollers - I have no more comments. Basically we can end our discussion here right now and I am starting to regret my time I invested in this thread.
     

    Offline welterde

    • Contributor
    • Posts: 19
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #130 on: March 08, 2018, 02:22:39 pm »
    So something like VME, where you read/write a bunch of addresses to control the modules would be fine I guess?

    Kind of. Considering that I don't even know what VME is ;) Not addresses but named variables. During init master enumerates module capabilities including list of the variables that can be written and/or polled. Variable can be either single value or number of values in array, various common data types shall be supported as well (double/float/int8/int16/int32/string).

    VME is probably the most popular chassis system (in science) by far.
    It was essentially just the (data&address, etc.) busses from the Motorola 68000 put on a backplane (and evolved from there).

    And what you are proposing has the downside that it's more difficult to implement in say an FPGA (unlike just some memory-mapped stuff).
    But could always implement an address space to variable mapping system on top, which would abstract the lower details away.

    No more then one CS signal is needed if you are using '595 (see post #43) that can be clocked much faster then SPI (to compensate 8 clocks needed to shift data for target CS). "Module info" EEPROM could be one of SPI devices (e.g. #0).

    Ah, yes. That would also work.
    What do you think about using LVDS for the per-module SPI busses?
    Not trying to be stubborn about this idea, I just want to figure out if running an single-ended SPI bus quite quickly might be pushing it for the last few modules furthest away from the CPU module?
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #131 on: March 08, 2018, 02:41:06 pm »
    And what you are proposing has the downside that it's more difficult to implement in say an FPGA (unlike just some memory-mapped stuff).
    But could always implement an address space to variable mapping system on top, which would abstract the lower details away.

    Indeed processing variables by name compared to memory locations is more difficult. Yes, it can be memory-mapped stuff as well. Agreed. Just additional memory mapping descriptor file for each module needed. That shall not be any problem as long as module type and version matching (to descriptor file) is well-implemented.
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #132 on: March 08, 2018, 02:53:13 pm »
    No more then one CS signal is needed if you are using '595 (see post #43) that can be clocked much faster then SPI (to compensate 8 clocks needed to shift data for target CS). "Module info" EEPROM could be one of SPI devices (e.g. #0).

    Ah, yes. That would also work.
    What do you think about using LVDS for the per-module SPI busses?
    Not trying to be stubborn about this idea, I just want to figure out if running an single-ended SPI bus quite quickly might be pushing it for the last few modules furthest away from the CPU module?

    Yes, LVDS point-to-point (star) SPI and M-LVDS (or multi-point) for clocks, triggers and sync are in my latest working draft (sketched with massive help from @jbb) that hopefully I'll publish soon for your review. I presume that is also in line with what @ogden mentioned about LVDS, with addition of multi-point (shared between modules, and assigned "on the fly") signals.

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #133 on: March 09, 2018, 09:21:37 am »
    Hmm... does that mean that every module will have a different MCU from a different manufacturer depending on the designer's preferences or enforce the use of a particular MCU architecture across all the modules? I don't think everyone will agree with any of those.

    Give me a break... So your solution is to use "standardized SIPO register and EEPROM"?  :-DD

    Every "manufacturer" will use same ADC and DAC. Right.
    Let me dumb it down for you:

    Bob, Jim and Matt all want to build their own module on the instrumentation bus.
    Bob uses a micro from ST on his module, Jim uses a micro from NXP on his module and Matt uses a TI micro on his.

    Bob wants to also build the modules that Matt designed, and also the one that Jim designed. He wants to add some features to Jim's firmware and some other features to Matt's firmware but he only has an ST-Link so he can only debug code running on STMs.

    Do you see any issues here?

    Put a serial bootloader on each, trigger it via one line from bus ("set program, then send reset signal to enter bootloader"), done. Really, couldn't you figure out that  ?

    Hell, a bunch of micros come with the serial bootloader baked in.

    Or you can just provide JTAG connector.

    Skipping micro just means that Bob, instead of opening someone's else source code and changing 3 lines, now have to get close and personal with every SPI chip used on on other boards

     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #134 on: March 09, 2018, 09:51:05 am »
    Skipping micro just means that Bob, instead of opening someone's else source code and changing 3 lines, now have to get close and personal with every SPI chip used on on other boards

    This I believe depends of how well firmware layers are defined. If one has to include support for its SPI devices he/she has to be in position to add that without mingling with code that is addressing devices on other modules.
    My current stance regarding single MCU vs. multiple (per-module) MCU approach is that former could lower the complexity for entry level solutions, and should simplify development, debugging and maintenance (e.g. single instead of multiple firmware updates). Later offer better boundaries and sharing of responsibility when multiple "manufacturers" comes into picture. In that case each of them is responsible to provide hardware and firmware that should comply with specification how to communicate with local console (i.e. TFT display + encoders + switches + trigger I/Os, etc.) and outside world (PC application that has e.g. SCPI controller functionality).

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #135 on: March 09, 2018, 10:30:00 am »
    This I believe depends of how well firmware layers are defined.

    Yes, exactly! In MCU-less architecture firmware layers are blurred all over the system - from card to hi-level controller. It's oposite to well-defined firmware layers/boundaries.

    Quote
    If one has to include support for its SPI devices he/she has to be in position to add that without mingling with code that is addressing devices on other modules.

    Funny that you and other proponents of MCU-lesss modules completely ignore argument that "he/she has to be in position to add code to controller part". Electronics engineer who knows just how to program PIC/AVR/whatever microcontroller he is building all his hobby stuff on, is unable to create module because he have to learn "big systems", supposedly Linux (?) programming".

    Quote
    My current stance regarding single MCU vs. multiple (per-module) MCU approach is that former could lower the complexity for entry level solutions

    Low complexity, entry level solutions of automated instrumentation chassis? What's that? :D

    Guys, open your minds!

    [edit] You are overcomplicating things all over the place yet you say that MCU will add complexity. It does not makes sense. MCU with well-defined host communications boundary will ease everything, not complicate!
    « Last Edit: March 09, 2018, 10:38:37 am by ogden »
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #136 on: March 09, 2018, 11:37:45 am »
    Ok, lets put it in this way: if firmware layering is properly done, i.e. that for beginning lower hardware is abstracted from higher "presentation" layer then no difference should be if all code is executed on one place (i.e. MCU board) or many others. Then it become simply a matter of designer choice. Actually some computing intensive modules will ask for dedicated MCU and more (FPGA, etc.). Module "manufacturer" has to propose lower hardware layer ("driver") for new module alone (using e.g. reference module driver as reference) or with EEZ assistance and/or community.

    My previous project (EEZ H24005) already included to the high extent separation (layering) between let's call it "main loop" and underlaying devices (ADC, DAC, I/O expander, etc.) and comes with comprehensive SCPI command set support. I'll continue to go into that direction. My "initial" idea about central processing module and different peripheral modules was based on XMOS MCU that sounds pretty powerful to concurrently drive multiple modules (especially programmable power supplies), but even in that (exotic) scenario, a multi-layer firmware is presumed as basic requirement therefore per-module MCU engagement is possible.

    In summary, I don't like idea that multiple MCU setup is mandatory (nor impossible!), and I'm taking software/firmware part of the whole solution very seriously (that is I believe visible from EEZ H24005 project) and hopefully we could make in few iterations a meaningful specification that could make other designers a whole job easier and that they can count over the time with attractive (open source) software components that will be presented as part of this adventure.
     
    The following users thanked this post: megajocke

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #137 on: March 09, 2018, 02:42:35 pm »
    I'm taking software/firmware part of the whole solution very seriously (that is I believe visible from EEZ H24005 project)

    Your supply project is well-planned and well-done indeed. Thou it is not quite correct to compare that supply to instrumentation chassis. Supply is single & whole device, chassis is set of many devices controlled by single controller. You possibly see card of instrumentation as just FR4 PCB with single SPI ADC on it, I don't.

    Did you ever made list of all possible kinds of cards? I would like to see which you think does not need MCU, would like to see what are those cards and how many they are compared to total number of cards.

    Quote
    In summary, I don't like idea that multiple MCU setup is mandatory (nor impossible!)

    Ok MCU's are possible. Phew. :D  Is there any chance for cards that have just single AVR MCU and LDO on them?
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #138 on: March 09, 2018, 02:56:54 pm »
    I'm taking software/firmware part of the whole solution very seriously (that is I believe visible from EEZ H24005 project)

    Your supply project is well-planned and well-done indeed. Thou it is not quite correct to compare that supply to instrumentation chassis. Supply is single & whole device, chassis is set of many devices controlled by single controller. You possibly see card of instrumentation as just FR4 PCB with single SPI ADC on it, I don't.

    Did you ever made list of all possible kinds of cards? I would like to see which you think does not need MCU, would like to see what are those cards and how many they are compared to total number of cards.

    I cannot imagine a single card without MCU placed somewhere if I want to benefit from digitally controlled/programmed devices (locally or remotely). I started with idea that all MCU resources could reside on single place, but that is not mandatory (just as MCU per-module shouldn't be), it could simplify design, but also has real limitations.
    I see this "instrumentation" chassis as next step from single instrument to multitude of them added in modular fashion (the EEZ H24005 is also modular to one extent, but do not provide flexibility of chassis that we are discussing here).

    Quote
    In summary, I don't like idea that multiple MCU setup is mandatory (nor impossible!)

    Ok MCU's are possible. Phew. :D  Is there any chance for cards that have just single AVR MCU and LDO on them?

    Apparently even better: it can be MCU only, if LDO/power comes via backplane from external power module or e.g. "MCU" (slot #0) card :)

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #139 on: March 09, 2018, 04:30:46 pm »
    I see this "instrumentation" chassis as next step from single instrument to multitude of them added in modular fashion (the EEZ H24005 is also modular to one extent, but do not provide flexibility of chassis that we are discussing here).

    Your approach will lead to cards that are not useable without chassis and master controller.

    Example: If somebody will create low cost (< 50$?) card I badly want, let's say programmable 4-quadrant supply with programmable waveforms and it will be based on "save 2$ on MCU" approach, I will be pushed to buy whole chassis and controller which is significant additional expenses! BUT I need just that one 4-quadrant supply! I want to connect it to my PC through USB or UART-USB, run control software on my PC and that's it.
     
    The following users thanked this post: prasimix

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #140 on: March 09, 2018, 04:41:21 pm »
    I see this "instrumentation" chassis as next step from single instrument to multitude of them added in modular fashion (the EEZ H24005 is also modular to one extent, but do not provide flexibility of chassis that we are discussing here).

    Your approach will lead to cards that are not useable without chassis and master controller.

    Example: If somebody will create low cost (< 50$?) card I badly want, let's say programmable 4-quadrant supply with programmable waveforms and it will be based on "save 2$ on MCU" approach, I will be pushed to buy whole chassis and controller which is significant additional expenses! BUT I need just that one 4-quadrant supply! I want to connect it to my PC through USB or UART-USB, run control software on my PC and that's it.

    Hm, maybe your example is not so representative, or maybe it is, but I'd like to learn about 4-qudrant programmable power unit under < 50 USD :). But ok, let's pretend that something like that is doable (please excuse me for my ignorance). What if I made anticipated mistake and for people like you make a "piggyback" PCB with MCU, small OLED, encoder and USB that can be then housed together into standalone (possibly off-the-shelf) enclosure? Please note that adding just MCU probably will not be enough for many others, some more stuff is needed to have a decently usable unit, or not?

    Offline technix

    • Super Contributor
    • ***
    • Posts: 3507
    • Country: cn
    • From Shanghai With Love
      • My Untitled Blog
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #141 on: March 09, 2018, 05:15:53 pm »
    Actually I am in the process of rewriting firmwares to my own DIY instrumentations so everything is standardized. I don't really have a DIB in mind, just some method of transporting data over different channels. I even have devices capable of multiple modes of communication - for example my climate sensor clock supports both Wi-Fi and USB. For something like a DIB, there are four requirements to the system:
    • Some mechanism to address the devices,
    • Some mechanism to discover the devices,
    • Some mechanism to identify the devices, and
    • Some standard language all devices should speak.

    Currently I have two established transports and is in need for definition of a few more use cases:
    • USB HID transport: addressed by host port number, discovered through USB enumeration, identified through USB descriptors and speaks standard HID packets. The HID Report Descriptor is already a full featured high level protocol descriptor language, and I will use that here directly.
    • TCP/IP transport: addressed by IP address, discovered and identified through DNS-SD (Bonjour,) speaks HTTPS. Anything that normally carry TCP/IP uses this transport. This transport is actually designed with Apple iPhone support in mind. I am thinking about borrowing USB HID Report Descriptor but not so sure now.
    • I2C transport: I need help. Maybe implement Microsoft's I2C HID standard, and speak USB HID again?
    • RS232 transport: Uhhh...
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #142 on: March 09, 2018, 06:07:01 pm »
    What if I made anticipated mistake and for people like you make a "piggyback" PCB with MCU, small OLED, encoder and USB that can be then housed together into standalone (possibly off-the-shelf) enclosure?

    Yes, you can try to do such mistake. I do not see any need for display/buttons/encoders. It's automated instrumentation. Just adapter to supply power & connect card to host PC using USB and run controller software on the (preferably windows) PC. Did you check Agilent chassis I mentioned in my post?
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #143 on: March 09, 2018, 06:08:26 pm »
    Did you check Agilent chassis I mentioned in my post?

    Yes, I did. Thanks for that.

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #144 on: March 10, 2018, 12:06:22 am »
    Ok, lets put it in this way: if firmware layering is properly done, i.e. that for beginning lower hardware is abstracted from higher "presentation" layer then no difference should be if all code is executed on one place (i.e. MCU board) or many others. Then it become simply a matter of designer choice.

    I've been thinking a lot about this over the last few days.  On the one hand, I like the idea of leaving lots of flexibiilty to the module designer.  On the other hand, forcing the module designer to use a separate micro means that the module driver code must be separated from the master and use a defined interface, which is a good thing in my book.  We also know that designing any module will require some programming, whether it be in the master or in the module.

    I'm now doing a thought experiment on 'simple' cards which might be reasonable candidates for no-MCU implementation:
    • Basic Digital Input No MCU needed. MCU could be useful for time stamping inputs if desired.
    • Relay Driver Could do with simple outputs.  But I would like to have a defined state in the event of a backplane communications failure, which is easier to do with an MCU than logic.
    • Relay MUX card  This card is likely to use latching relays* which require set/reset drive and should have cycle counters. Again, easier to do with an MCU.
    • Power supply / Electronic Load / Function Generator I would really like an MCU to handle a) calibration b) any mode switching and c) graceful shutdown in the event of a backplane communications failure.
    • Multimeter / Power Meter I would like an MCU to do calibration and manage input MUXing.
    • Data acquisition card Could be done without MCU

    So I'm seeing that a good number of cards should have an MCU.    So my current thinking is that Ogden is right; it's reasonable to require all the modules to have an MCU.  If using an MCU in each module, UART comms make sense. They could start at a well-supported baud rate (e.g. good old-fashioned 9600 baud) to exchange identity information and then negotiate for higher speeds (10 MHz / 16 = 625 kbaud for an MCU, >100 Mbaud for an FPGA!).
     
    I would suggest that the backplane keep using LVDS to support those higher data rates.  I would like to keep 2 (maybe 4?) extra LVDS lanes on hand for some slots to support applications where big data transfer is required.  Using a clock distribution system (which we definitely want to have), LVDS can go up to 1000 Mbit/s or so without using crazy expensive FPGAs.  (600 Mbit/s LVDS isolators are available from Analog Devices.)  4x LVDS lanes @ 600 Mbit/s each = 2.4 Gbit/s!

    A basic 'connect this DIB module to my computer' interface could be a power supply, UART port and basic enclosure.

    * Latching type relays are recommended for low current sealed signal relays to reduce self-heating.  Self-heating can apparently lead to migration of compounds inside the sealed contact compartment and cause sticking or high contact resistance.  Self-heating can also cause thermocouple effects.
     

    Offline void_error

    • Frequent Contributor
    • **
    • Posts: 673
    • Country: ro
    • I can transistor...
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #145 on: March 10, 2018, 09:03:41 am »
    Put a serial bootloader on each, trigger it via one line from bus ("set program, then send reset signal to enter bootloader"), done. Really, couldn't you figure out that  ?

    Hell, a bunch of micros come with the serial bootloader baked in.

    Or you can just provide JTAG connector.

    Skipping micro just means that Bob, instead of opening someone's else source code and changing 3 lines, now have to get close and personal with every SPI chip used on on other boards

    My apologies for being stupid, I won't post on this forum anymore because it seems if I throw an opinion or idea out fingers are being pointed at me. Also, What's a JTAG? Or a bootloader? Where do you buy one? Sarcasm over.
    Trust me, I'm NOT an engineer.
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #146 on: March 10, 2018, 09:14:53 am »
    I'd like to learn about 4-qudrant programmable power unit under < 50 USD :)

    Of course initially it was meant as provocative joke. Then I started to think about it and stumbled on this discussion. Pay attention to http://www.linear.com/solutions/4288 mentioned in the thread. IMHO <50$ in BOM components (including MCU) is possible.
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #147 on: March 10, 2018, 09:19:31 am »
    I'd like to learn about 4-qudrant programmable power unit under < 50 USD :)

    Of course initially it was meant as provocative joke. Then I started to think about it and stumbled on this discussion. Pay attention to http://www.linear.com/solutions/4288 mentioned in the thread. IMHO <50$ in BOM components (including MCU) is possible.
    Yes, I'm aware of LT1970. If used alone < 50 USD BOM is probably possible, but if we added output booster stage, two pre-regulator, ADC/DAC/MCU for programming then BOM will be a slightly higher :). Anyway, thanks for link to mentioned discussion.

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #148 on: March 10, 2018, 09:43:11 am »
    I won't post on this forum anymore because it seems if I throw an opinion or idea out fingers are being pointed at me.

    Really? You did say "Let me dumb it down for you" implying that I need such style/kind of explanation - which is insult, not idea. You did throw a rock and now complain that you are receiving some back?
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #149 on: March 10, 2018, 10:19:44 am »
    I'm aware of LT1970. If used alone < 50 USD BOM is probably possible, but if we added output booster stage, two pre-regulator, ADC/DAC/MCU for programming then BOM will be a slightly higher :)

    Wow, you said this one will need MCU! I am thrilled :)

    If you specify it for >=150W then you obviously can't squeeze into 50$. Low power PSU will not need anything else but what's in appnote. Output stage mosfet costs 1$/1pc each, LT1970 around 10$, AMC7891 (10bit 4xDAC 8xADC)- around 5$. Whole stm32f103 (USB MCU) "blue pill" board = 2.2$ :D The rest is just jelly bean components and some electrolyte.
     

    Offline void_error

    • Frequent Contributor
    • **
    • Posts: 673
    • Country: ro
    • I can transistor...
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #150 on: March 10, 2018, 11:12:06 am »
    @prasimix & everyone else: Sorry for flooding this thread with useless posts...
    @ogden: Please review your post before making accusations.
    Hmm... does that mean that every module will have a different MCU from a different manufacturer depending on the designer's preferences or enforce the use of a particular MCU architecture across all the modules? I don't think everyone will agree with any of those.

    Give me a break... So your solution is to use "standardized SIPO register and EEPROM"?  :-DD

    Every "manufacturer" will use same ADC and DAC. Right.

    Quote
    Also, for modules such as bench power supplies you still need dedicated DACs & ADCs if you want anything higher than ~16-bit and a MCU would be a waste of space and money unless you want to implement some kind of PID loop like for an electronic load's constant resistance mode.

    :palm:

    MCU would handle offset, calibration and hardware abstraction so every supply in "your instrumentation standard" is controlled same way and it's voltage and current readout is done same way. In your proposal every "manufacturer" can save 2 dollars (huge savings!!!) on MCU and place any kind and number of ADCs and DACs on power suplies, then put some shift registers for LEDs and so on - to make compatibility between various supplies a total mess.

    Your joke "MCU would be a waste of space and money" saved my day.  :-DD
    Trust me, I'm NOT an engineer.
     
    The following users thanked this post: ogden

    Offline khs

    • Regular Contributor
    • *
    • Posts: 130
    • Country: de
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #151 on: March 10, 2018, 09:09:41 pm »
    Hmm... does that mean that every module will have a different MCU from a different manufacturer depending on the designer's preferences or enforce the use of a particular MCU architecture across all the modules? I don't think everyone will agree with any of those.

    Give me a break... So your solution is to use "standardized SIPO register and EEPROM"?  :-DD

    Every "manufacturer" will use same ADC and DAC. Right.

    Hmm..

    I would reserve the first 16 bytes of the first (optional) SPI EEPROM to store a GUID to identify the 'manufacturer'.

    Not more, not less.

    After the GUID additional information can be stored - depending on the requirements of the board.
     

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #152 on: March 10, 2018, 10:08:52 pm »
    Data structures for the ID information would be an issue, yes.

    At a bare minimum: manufacturer, model, serial #, HW version, FW version.

    Then communications settings (type, speed, use of external trigger bus etc.). And maybe calibration data.

    As you can see, it gets quite complicated.
     

    Offline technix

    • Super Contributor
    • ***
    • Posts: 3507
    • Country: cn
    • From Shanghai With Love
      • My Untitled Blog
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #153 on: March 10, 2018, 10:47:42 pm »
    For the ID information it might be a good idea to design some kind of interface description language that can be parsed by the host to extract information about the interface type, protocol, format, unit of measurement and calibration curve.

    The interface type, protocol and format description language can take inspiration from the USB HID Report Descriptor language, since it already describes fields and formats in a bit by bit fashion.

    The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

    The calibration curve describes the relationship between raw data and the measured value in that unit using a polynomial approximation, expressed using the coefficients of increasing order in 16-bit IEEE 754 half precision floating point numbers.
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #154 on: March 12, 2018, 03:28:39 pm »
    The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

    Considering that most units would just... fit as 4 bytes of ascii characters or less, that seems like needless complication. Just (standarized) textual representation of unit would be enough. Would also be more flexible

     

    Offline Blinkenlights

    • Contributor
    • Posts: 19
    • Country: au
      • Work examples
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #155 on: March 12, 2018, 10:49:10 pm »
    @Technix: Your "unit of measurement" statement is worth following up - do you have any more information?  Can you point me towards a specification that uses this approach, or a prior implementation, or - if your own concept - could you put a little more description behind it?

    The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.
     

    Offline technix

    • Super Contributor
    • ***
    • Posts: 3507
    • Country: cn
    • From Shanghai With Love
      • My Untitled Blog
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #156 on: March 13, 2018, 07:57:32 am »
    The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

    Considering that most units would just... fit as 4 bytes of ascii characters or less, that seems like needless complication. Just (standarized) textual representation of unit would be enough. Would also be more flexible
    Try describe the unit of Newtonian constant of gravity... That is 0x3fe00000 here. Also this produces a uniformly lengthed representation of all units regardless of its textual representation and is easy to manipulate in code.
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #157 on: March 13, 2018, 01:37:39 pm »
    The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

    Considering that most units would just... fit as 4 bytes of ascii characters or less, that seems like needless complication. Just (standarized) textual representation of unit would be enough. Would also be more flexible
    Try describe the unit of Newtonian constant of gravity... That is 0x3fe00000 here. Also this produces a uniformly lengthed representation of all units regardless of its textual representation and is easy to manipulate in code.
    I'm not a physicist so pardon my ignorance but... G? I don't know what you exactly mean by "unit of Newtonian constant of gravity.", do you mean constant itself?

    Aside from that, is that some kind of standard of representing units ? Are there libs for it ? Because writing "if unit == "V"' is a pretty low barrier to entry compared to "here are those magical numbers that mean Volt, just trust me on it"

     

    Offline technix

    • Super Contributor
    • ***
    • Posts: 3507
    • Country: cn
    • From Shanghai With Love
      • My Untitled Blog
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #158 on: March 13, 2018, 02:28:41 pm »
    The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

    Considering that most units would just... fit as 4 bytes of ascii characters or less, that seems like needless complication. Just (standarized) textual representation of unit would be enough. Would also be more flexible
    Try describe the unit of Newtonian constant of gravity... That is 0x3fe00000 here. Also this produces a uniformly lengthed representation of all units regardless of its textual representation and is easy to manipulate in code.
    I'm not a physicist so pardon my ignorance but... G? I don't know what you exactly mean by "unit of Newtonian constant of gravity.", do you mean constant itself?

    Aside from that, is that some kind of standard of representing units ? Are there libs for it ? Because writing "if unit == "V"' is a pretty low barrier to entry compared to "here are those magical numbers that mean Volt, just trust me on it"
    Yes, that constant G. It has a unit. Try describe that in a FourCC.

    Indeed you can say that if (unit == UNIT_VOLTAGE) is low barrier. However when you need to track a lot of different measurements with different units, you can get lost very fast. This representation of units is intended to provide a fixed length and easy manipulation regardless of the complexity of the unit, allowing for a uniform representation of values.
     

    Online Kleinstein

    • Super Contributor
    • ***
    • Posts: 14072
    • Country: de
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #159 on: March 13, 2018, 04:05:41 pm »
    The idea of bringing the units back to the basic Si units is a logic idea.  The Si connected units are usually just a combination of powers of the 7  basic units. In most cases a power up to 4 should be enough, so that one can also cover cases where a square root appears. However this already limits the the power to a +4 to -3.5 range, if only 4 bits are used.  So there might be a few odd SI units that do not fit the pattern. The square roots are rare, but they sometimes come up, like in spectral noise voltage often given as nV/Sqrt(Hz). One night get around this most of the time by having a extra Bit to have the square root on the whole unit.

    Another complication is that even the same combination of basic SI units might represent a different unit. For example torque is measured in Nm while energy is measured in Joule, with 1 J = 1 N * 1 m, but one should not use Joule for a torque and Nm for an energy is kind of misleading.  A similar problem appears with the Hz, that is reserved to be used for the frequency of a periodic process. So one should not use Hz for something like a count rate or the circular frequency or rate of angular change.

    Not all units are directly SI derived. A prominent example are the logarithmic parts like dB with all the different reference levels. Color metric is another example not covered by SI.
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #160 on: March 13, 2018, 04:52:06 pm »
    The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

    Considering that most units would just... fit as 4 bytes of ascii characters or less, that seems like needless complication. Just (standarized) textual representation of unit would be enough. Would also be more flexible
    Try describe the unit of Newtonian constant of gravity... That is 0x3fe00000 here. Also this produces a uniformly lengthed representation of all units regardless of its textual representation and is easy to manipulate in code.
    I'm not a physicist so pardon my ignorance but... G? I don't know what you exactly mean by "unit of Newtonian constant of gravity.", do you mean constant itself?

    Aside from that, is that some kind of standard of representing units ? Are there libs for it ? Because writing "if unit == "V"' is a pretty low barrier to entry compared to "here are those magical numbers that mean Volt, just trust me on it"
    Yes, that constant G. It has a unit. Try describe that in a FourCC.
    As I already said, I do not know that unit so I can't even try to do it. But I imagine there would be edge cases requiring more than 4 characters.
    I don't think it really is a  big problem, If I wanted to have binary protocol I'd just use TLV (type,length,value)-type encoding for fields (or just go lazy way and use Protobuf) instead of trying to keep everything same length.

    Quote
    Indeed you can say that if (unit == UNIT_VOLTAGE) is low barrier. However when you need to track a lot of different measurements with different units, you can get lost very fast. This representation of units is intended to provide a fixed length and easy manipulation regardless of the complexity of the unit, allowing for a uniform representation of values.
    Well there is always a chance someone mistypes and instead of just using "A" they use "mA", or even "ma".

    But on other side you can represent units that are not SI without having internally convert it before sending (and probably also converting it back before displaying, if you are measuring kcal for example you probably do not want result in joules).

    I think you also skipped a few units, because I think representing angular speed is impossible too

    And there are units that can just not be converted, at least not easily representable in 4 bytes

    Like take humidity for example. The absolute unit is grams of water vapor per cubic meter volume of air.  The relative unit is usually represented as %, which for unit type is too vague.

    In your proposed representation AFAIK it is impossible to write any of them.

    In text representation it is still really awkward but possible (like Rhum/Ahum or RH/AH ).

    Of course, there is another way, just a big list of ID -> unit type, but while that does not allow any wiggle room for mistakes and takes least space, it is awkward to manage when everyone have to have same list of magic numbers

    Same with other measurements like pH.
     

    Offline technix

    • Super Contributor
    • ***
    • Posts: 3507
    • Country: cn
    • From Shanghai With Love
      • My Untitled Blog
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #161 on: March 13, 2018, 08:14:06 pm »
    Quote
    Indeed you can say that if (unit == UNIT_VOLTAGE) is low barrier. However when you need to track a lot of different measurements with different units, you can get lost very fast. This representation of units is intended to provide a fixed length and easy manipulation regardless of the complexity of the unit, allowing for a uniform representation of values.
    Well there is always a chance someone mistypes and instead of just using "A" they use "mA", or even "ma".
    There is one and only one unit for each measurement, so only the input parsing front end have to deal with the mistypes.
    But on other side you can represent units that are not SI without having internally convert it before sending (and probably also converting it back before displaying, if you are measuring kcal for example you probably do not want result in joules).
    I do intend to rely on internal data conversions. In most cases since SI is a metric system floating point numbers work perfectly.
    I think you also skipped a few units, because I think representing angular speed is impossible too
    Give me an example of a unit not representable as either dimensionless or a combination of the seven SI base units. Angular speed is expressed as rotational frequency in hertz.

    This is an example of the related units exclusion principle: for physical quantities that have a one to one correspondence, only the one with the simplest SI base unit expansion of the set is defined, and every other quantity is represented by converting to the defined one. In this case angular speed is 2 * pi * frequency establishing a linear one to one correspondence, and since frequency (in hertz = 1/s) is simpler than angular speed (in rad/s) frequency is defined and angular speed is represented using frequency.
    And there are units that can just not be converted, at least not easily representable in 4 bytes
    Again, give me an example of a unit not representable as either dimensionless or a combination of the seven SI base units.
    Like take humidity for example. The absolute unit is grams of water vapor per cubic meter volume of air.  The relative unit is usually represented as %, which for unit type is too vague.
    Absolute humidity is a mass per volume concentration. Relative unit is dimensionless (pressure over pressure). Percentage just means a dimensionless number.
    In your proposed representation AFAIK it is impossible to write any of them.
    I just did.
    In text representation it is still really awkward but possible (like Rhum/Ahum or RH/AH ).
    It is possible although it takes a bit of thinking, keeping the related unit exclusion rule in mind.
    Of course, there is another way, just a big list of ID -> unit type, but while that does not allow any wiggle room for mistakes and takes least space, it is awkward to manage when everyone have to have same list of magic numbers
    You can treat it this way. Being logically allocated, at least those ID's are easy to understand. Still keep in mind that this unit representation allows you to manipulate it using an algorithm, instead of relying on either parsing the text or non-structured identifiers (requiring a new software revision when BIPM folks came up with a new name for a unit.)
    Same with other measurements like pH.
    pH is another case of related units exclusion principle: it is the negative logarithm of the molar concentration of hydrogen (or hydronium) ions. The logarithm actually messed the units representation up, so it is treated as more complex than molar concentration. Thus, pH is expressed in term of molar concentration.
     
    The following users thanked this post: Blinkenlights

    Offline Blinkenlights

    • Contributor
    • Posts: 19
    • Country: au
      • Work examples
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #162 on: March 14, 2018, 01:33:42 am »
    While keen to find to find the best ID system for a product such as this, I am reminded that such systems are frequently ignored. Many years ago I worked with a quite brilliant, methodical engineer who informed me that the company guesstimated the maximum current for its PCI cards at design time, and wrote it into the ID settings PROM. I had a minor double take, considering the respect I had for this mans prior work. But perhaps I just had to add pragmatic to list of abilities - is someone paying them to do a second (albeit quick) round of engineering evaluation to gather final production engineering parameters and write them into the ID settings? No. Are they a commercial company? Yes. Does the value written into the ID settings make the product less functional? Not really, because compliance was not widespread.

    My take on this: Highly ethical or "perfectionist" (I do not use that label myself) individuals/companies will do the right thing by all the ID fields. Others may not. The most useful thing would be a system which the worst of us cannot ignore - something simple like Country of Manufacture, Manufacturer, Model name, Date of manufacture (or at least the year) and ideally revision level, and ideally serial number.  There may be several Manufacturers with the same name - but country law usually means just one with each name in a country.  This probably gives enough info for a clever software module in the host to be able to track down and workaround some horrible short coming in a common shipped PCB - perhaps only present on boards made before 2018 (etc). 

    That is going to make your whole ID system worthwhile - even if SI units are not included - or even if they are. Make the bar to entry quite low.
     

    Offline xani

    • Frequent Contributor
    • **
    • Posts: 400
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #163 on: March 14, 2018, 10:40:33 am »
    In text representation it is still really awkward but possible (like Rhum/Ahum or RH/AH ).
    It is possible although it takes a bit of thinking, keeping the related unit exclusion rule in mind.
    In 4 bytes ? I'd think that after converting to base SI units you'd run out of space for some of the more complex ones...

    And that's not the point, I want a system that gets me values and then I do stuff with it, if code to decode "what the hell is that value in normal units" is longer and more complex than rest of the code... well most would probably just write few lines that do "if that magic number is there, multiply by X to get the result in useful units" and call it a day

    Of course, there is another way, just a big list of ID -> unit type, but while that does not allow any wiggle room for mistakes and takes least space, it is awkward to manage when everyone have to have same list of magic numbers
    You can treat it this way. Being logically allocated, at least those ID's are easy to understand. Still keep in mind that this unit representation allows you to manipulate it using an algorithm, instead of relying on either parsing the text or non-structured identifiers (requiring a new software revision when BIPM folks came up with a new name for a unit.)
    You could just use you idea as a base for generating IDs.

    But I think that "just a list" of base units + maybe exponent if for some reason using very small or very big numbers is undesirable (I can imagine the case when someone wants to use cheapo 8 bit micro and just use integer math for measurements) would be good enough.
     

    Offline technix

    • Super Contributor
    • ***
    • Posts: 3507
    • Country: cn
    • From Shanghai With Love
      • My Untitled Blog
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #164 on: March 15, 2018, 05:36:32 pm »
    In text representation it is still really awkward but possible (like Rhum/Ahum or RH/AH ).
    It is possible although it takes a bit of thinking, keeping the related unit exclusion rule in mind.
    In 4 bytes ? I'd think that after converting to base SI units you'd run out of space for some of the more complex ones...
    I am only storing the exponents of the 7 base units, each using a 4-bit signed integer. The last nibble is used for distincting between different units with the same dimension. Here is why this uses exactly 4 bytes for all units.
    And that's not the point, I want a system that gets me values and then I do stuff with it, if code to decode "what the hell is that value in normal units" is longer and more complex than rest of the code... well most would probably just write few lines that do "if that magic number is there, multiply by X to get the result in useful units" and call it a day
    Conversion between units is almost always applying one polynomial to the number. It would be surprising to me if you need more than one line of code for this (except when using assembler.)
    Of course, there is another way, just a big list of ID -> unit type, but while that does not allow any wiggle room for mistakes and takes least space, it is awkward to manage when everyone have to have same list of magic numbers
    You can treat it this way. Being logically allocated, at least those ID's are easy to understand. Still keep in mind that this unit representation allows you to manipulate it using an algorithm, instead of relying on either parsing the text or non-structured identifiers (requiring a new software revision when BIPM folks came up with a new name for a unit.)
    You could just use you idea as a base for generating IDs.

    But I think that "just a list" of base units + maybe exponent if for some reason using very small or very big numbers is undesirable (I can imagine the case when someone wants to use cheapo 8 bit micro and just use integer math for measurements) would be good enough.
    If you really need to use a 8-bit micro or the like, you can convert units only at ingress or egress of data, and use whatever internal representation you like as long as it is not leaked onto the bus. I made a point to force a fixed length on this unit representation, exactly because it have data exchange in mind, and data ingress and egress algorithms can be a lot more complicated (as you need to match data formats. Fixed length data is a lot easier to capture and check.)
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    DIB r1B4 proposal
    « Reply #165 on: April 05, 2018, 03:04:00 pm »
    Last few weeks I spent working on new pin mapping together with @jbb. It continues to be based on serial star topology (point-to-point) between master/CPU/#0 module and peripheral modules since neither many times mentioned here USB and Ethernet unfortunatelly don't fit for purpose. The max. number of periperal modules drops from 7 to 6 (to stay within single 96-pin connector for #0 module), but four general-purpose lines are available for all modules (multipoint) and well as reference clock of 10 MHz and 100 MHz, and SYNC and TRIG lines. Routing differential lines with minimum or no vias was quite chalenging, and I succeed to do that for up to 4 periperal modules. For 5th and 6th modules their point-to-point lines require only one via between top and bottom layer.
    New pin mappings looks like this:



    As we can see each module has dedicated full-duplex, hi-speed SPI (SCLK, MOSI, MISO i CS) and low-speed (single-ended) IRQ. Depending of module capability two of SPI lines can be used as UART. That of course require that MCU/CPU on the #0 has flexible pins or sort of muxing is implemented. For general purpose signals MLVDS lanes are used (multipoint), where CLK10, CLK100 and SYNC are multidrop. TRIG could be multipoint or multidrop. All of that lanes reqire termination on both ends. One I2C channel is shared between all modules. Additionally NRST (master reset, active low) and NFAULT (active low) are available to all modules.
    It's recommended (but still optional) that each module has its own EEPROM connected via shared I2C (SSCL, SSDA) where ifo about module ID, capabilities, usage of bus lines, calibration data, working hours, required firmware/driver, etc. can be stored.
    Module's I2C slave address is set with three address pins A0, A1, and A2.
    Basic power rails are +5V and +12V, and +Vaux (5V too) is used as backup/standby power that can be sourced via backplane power connector (X5 in schematic below) or from e.g. #0 module. Two pins are assigned for low voltage AC/switched power source that can be used for generating isolated power when module require such thing (e.g. floating power supply module, el. load, etc.). PE (Protective Earth) is also available to each module. Currently using two pins on #0 module and single for other modules. For increased safety/security maybe another one should be added on peripheral modules, too (e.g. A15). PE and GND could be tied together on backplane with an RC element (C5, R20).

    Schematic for backplane with 5 modules (CPU/MCU + four peripheral) what I use as an example for PCB routing:









    Although backplane should be passive, I decided to put two things on it that is optional but convenient: backplane EEPROM and fan controllers. First one can be used to store some info that is related to chassis (not even #0 module), and second remove needs for extra (and longer) fan cables (that means higher EMI figure) from any of the connected modules. Chosen (AMC6821) works with two temp. sensors (internal/on-chip and external) and support tacho input on 3-wire DC fan. External sensors are placed on the top edge of the backplane (Q2, Q3).

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    DIB 5-module PCB example
    « Reply #166 on: April 05, 2018, 03:04:55 pm »
    4-layer PCB for 5 module backplane:

    Top:



    L1:



    L2:



    Bottom:



    All diff. pairs are routed in accordance with the following calculation:



    ... using the following rules prescribed by ALLPCB.com:



    Therefore all traces are 6 mils wide with 6 mils space inbetween and groundplane spaced 7 mils (~0.18 mm) that is good for ~99 Ohms that is within +/-2.5% tolerance.
    « Last Edit: April 05, 2018, 03:07:20 pm by prasimix »
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    DIB 5-module enclosure example
    « Reply #167 on: April 05, 2018, 03:06:13 pm »
    Here is a proposal for enclosure for above mentioned backplane. As you can see I gave up from horizontally placed backplane to vertical one. The enclosure is 4 U tall with module width of 8 HP (~40 mm). MCU #0 module is 120 mm (24 HP) wide that is enough to host a 4.3" TFT touch-screen display (480 x 272). For an extra 10 mm it is possible to host even 5" display for higher resolution (800 x 480). On #0 module front panel is now enough space to place two encoders with 30 mm knobs, few additional I/O connectors, SD card, possibly an USB-A as host. Ethernet and USB-B sockets should go on the the rear panel.

    « Last Edit: April 05, 2018, 03:17:02 pm by prasimix »
     

    Offline ogden

    • Super Contributor
    • ***
    • Posts: 3731
    • Country: lv
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #168 on: April 05, 2018, 03:36:04 pm »
    Those connectors are rather expensive, they does not allow reflow soldering as well. Have you considered PCI Express card edge connectors?
     

    Offline welterde

    • Contributor
    • Posts: 19
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #169 on: April 05, 2018, 04:45:06 pm »
    I noticed that the 48pin connector is actually slightly more expensive than the 96pin one.. so why not use 96-pin connectors for the non-cpu modules as well? Maybe in a slightly different variant if we don't want the slots to be compatible (although there are other methods to ensure that as well).
    That way we also have some more pins available for some more voltage rails (like +/- 15V for analog stuff, etc.), grounds or internal busses (which aren't connected to the CPU module).

    And I am glad you switched to a vertical backplane - that way one can pile stuff on top of the enclosure  :)
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #170 on: April 07, 2018, 06:41:43 am »
    Those connectors are rather expensive, they does not allow reflow soldering as well. Have you considered PCI Express card edge connectors?

    PCIe looks interesting due to low connector price and fact that only one connector per module is needed. On the other side that increase a little bit a cost of PCB (due to gold plating). Main obstacle could be routing diff. pairs without going to 6 or more PCB layers (e.g. take a look how diff. pairs are currently routed between two pins). I don't know what is possible, I should try to do that.

    I noticed that the 48pin connector is actually slightly more expensive than the 96pin one.. so why not use 96-pin connectors for the non-cpu modules as well? Maybe in a slightly different variant if we don't want the slots to be compatible (although there are other methods to ensure that as well).
    That way we also have some more pins available for some more voltage rails (like +/- 15V for analog stuff, etc.), grounds or internal busses (which aren't connected to the CPU module).

    Ok, from current experience I can say that one thing is thinking about what to put in pin mappings spreadsheet that is at the beginning empty and allows you to put anything, and another thing is to try to implement that on the PCB layout (and stay within targeted 4 layers) :). Adding just one new signal line could ask for rearranging of almost complete existing layout, a real nightmare. Still, if you'd can articulate your wishes in more details please let me know and we'll see if something like that is doable within set limits (i.e. dimension, 4-layer PCB).

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #171 on: June 29, 2018, 06:51:40 am »
    Finally I came into position to test SPI devices select using '595 shift register as announced in #43. It works fine for device selection but doesn't work with some device deselection (e.g. I/O expander MCP23S17-E/SS). The problem is that for changing the target SPI device you have to send 0xFF code over MOSI to instruct '595 to deselect last selected device. But that code received last selected SPI device too (before it being deselected) and that can confuse it. The similar thing can be expected with sending other device CS code to the '595. Therefore idea with just over CS line per peripheral board (or SPI bus) is not "bullet-proof" and at least one more line has to be introduced to separate addressing of '595 from other SPI devices. But with two CS lines and 2-to-4 decoder it's possible to address directly up to 4 devices per board, and whole idea of saving DIB connector lines with '595 doesn't make a lot of sense in many cases. Question is what to do if more then 4 devices is needed. Anyway, whatever is a case I have to revisit latest DIB pin mappings. 

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #172 on: June 29, 2018, 07:31:19 am »
    Ah, good thing you tested that and found the problem.

    If you go for 2x CS lines you can access 2 chips easily, or 3 with a decoder.
    11: not selected
    10: device A
    01: device B
    00: device C

    For more chips, you could do some expansion, e.g:
    11: not selected
    10: end point device selected
    01: address pointer selected
    00: not allowed

    If one chip needs to be extra fast, you could really go crazy:
    11: not selected
    10: end point device selected
    01: address pointer selected
    00: fast slave (always acceptable)
     

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #173 on: June 29, 2018, 07:43:16 am »
    If dedicated SPI channel is used per board, I think that with 2-to-4 decoder its possible to select 4 not just 3 devices, i.e. one (default) will be always selected without interference with SPI channels assigned to other peripheral boards, or not?

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #174 on: June 29, 2018, 10:56:35 pm »
    In principle, it's posisble to do 4 chips.  But as a practical matter, I would be worried about the following challenges:
    • Some master controllers may leave the clock running
    • Some master controllers may gang together multiple SPI busses and expect cards to work together even if the bus is operating
    • Switching between SPI modes (clock phase and clock polarity) may generate stray clock edges
    • Some SPI slaves may have timing limits on their nCS input

    Unfortunately, I think the open nature of the DIB means that some 'optimisations' have to be thrown out in the name of reliability and predictability.
     
    The following users thanked this post: prasimix

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #175 on: June 30, 2018, 06:03:07 am »
    You're right. Addressing just 3 looks more reliable. Anyway, DIB pin mappings (and connector?) has to be changed, Back to drawing board :).

    Offline Doctorandus_P

    • Super Contributor
    • ***
    • Posts: 3321
    • Country: nl
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #176 on: June 30, 2018, 05:48:08 pm »
    First post in this thread. My interest was awakened because I'm thinking about similar lines.
    But simpler / less performance.

    One of my idea's is to define "open space".
    For example, if the backbone pcb has connectors of 5 cm high, then define the board height of for example 8cm, and 3cm are left deliberately open and for "user defined" connectors.
    This leaves room at the side of the backplane for
    - Standard Ethernet connector.
    - Standard USB connector
    - Custom board to board connector.
    - optical fibre stuff.
    - Thick power supply connectors for custom power supply or extra isolated power supply.
    - other custom implementations.
    For this to work, the backside of the backplane board would have to be accesible though.

    Some other nice features would be to specify a bolt / hole patern on the side of the box, so another box can be easily mounted to it on the side.
    Can for example be used for:
    - Additional transformers / power supplies (Laptop power brick + low voltage SMPS).
    - Keeping all mains voltages out of this box.
    - storage space for USB hub / Ethernet switch.
    - Connecting multiple modules together.
    - Storage space for weird stuff (Rubidium standard).
    - Adapter for mounting in a 19" rack.
    - ...
    A bit like the 100x100mm VESA wall mounting standard for monitors, projectors, industrial PC's etc.

    Another Idea I've made some prototypes with is to glue a lego baseplate on a piece of wood, and lego bricks under a bunch of electronics components.
    This works pretty nice to keep (somewhat bigger) temporary projects together, such as:
    - several Breadboards.
    - Small custom PCB's (for example MOSfet + inductor which is too high current for a breadboard).
    - Strips with connectors for off-board connections (much more reliable than Breadboard alone).
    - Logic Analyser ("24m 8ch").
    - Beaglebone.
    - Chinese panel Volt meter modules (with added isolated dc-dc converter).
    - Homebrew AVR microcontroller board.

    Some other thing I do not like much is the 40.46mm spacing.
    Why not a nice round metrical number?
    It is also an awful lot of height for a lot of modern electronics.
    With a connector spacing of 20mm you still have plenty of height for most electronics. and if more is needed you can build a "double height" module.
    Aluminum profile of 20mm is also common. and a frontpanel can be easily made by hobbyists by filing some corners out of such a piece of aluminimum and drilling some holes in it.

    Just halving the distance between the connectors on your backplane would give 20.23mm spacing. Very close to standard 20mm aluminimum angle profiles, with a bit of room for mounting them.
    Note that adding these connectors does not cost anything. You do not have to populate the connectors on the PCB.

    This project is probably way over the budget for what I had in mind for myself.
    I was thinking more along the lines of using IDC connectors and a simple ribbon cable as a backplane.
    With ribbon cables you can also relatively easy make custom mods such as running separate wires from all boards to the same power supply. For the box itself I was thinking about something that can be easily 3d printed or made on a router.

    @prasimix:
    Both 10MHz and 100MHz clocks? (10MHz is the most prevalent standard).
    I would use at least 2 pins each for the AC_HOT and AC_COLD power.
    No UsART / RS485 / CAN?
    About 10+ years ago I built an AVR/RS485 based network. which has been controlling things like curtains and lights for quite a while now. I like RS485. It is also much "higher speed" than I2C, but it is "overkill" for short cables.

    Most Hobby / diy level users are probably never going to use the LVDS channels, but I do think that some bins reserved for "board to board" connect on the connector can be handy. I think it is a good idea to put that in the specifications.

    Galvanic isolation between modules has been mentioned a few times.
    A very easy and cheap way to do this would be to use a UART and a few optocouplers.
    TxD pin goes through an optocopler to an open emitter single pin databus.
    RxD has an optocopler to this same bus (with a resistor).
    The TxD optocoupler would have to be able to deliver enough current for multiple RxD lines.
    This is only half duplex of course.
    « Last Edit: June 30, 2018, 06:26:18 pm by Doctorandus_P »
     
    The following users thanked this post: prasimix

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #177 on: July 01, 2018, 11:51:31 am »
    Thanks for your post. There is a lots of food for thought.

    "Open space" sounds good, and that is already present in latest proposal and can be seen on PCB prototype for my first candidate for DIB backplane/enclosure here. DIB board connector occupy just a fraction of the PCB side facing rear panel. But, even if it seems that many space left available for other connectors it is not a case if you need cooling and fan could occupy most of them (all of usable 60 mm below DIB connector in my case). I presume that top or bottom placed cooling fan section is not an option.

    40.64 mm is not my invention :). It correspond with 8 HP (1 HP = 5.08 mm or 200 mils). Having a little bit over rounded 40 mm is a good for accept more tolerance for mechanical parts (i.e. metal front panel). But your suggestion to cut it in half have enough sense even for DIY/maker designs as long as some power management is not in question. Actually, I set 8 HP in accordance with what I need for my first DIB board :). Having 4 HP (i.e. 20.32 mm) spacing sounds good. Other possibility is to allocate space for power boards "left" of MCU board (that can placed centrally) and use different spacing and even connector type on the backplane. Low-power boards with e.g. 4 HP spacing can remain on the right side as in the latest proposal.

    I still don't have a real idea what to do with 100 MHz clock. That's something that is borrowed from VXI specification, and possibly is a overkill to be distributed to all slots. If two or more advanced boards need it they can be always connected with cable (that could be then even coax for better signal and lower EMI).

    The good thing about LVDS is that AFAIK it can be found nowadays on many hi-speed ICs (e.g. ADC, DAC). Therefore hi-speed transfer between two points/boards could be simpler if processing power is centralized that handle many peripherals. If all hi-speed and intense processing jobs are performed on the same board then LVDS or perhaps anything over low-speed serial interface is overkill.
    After I realize that "optimized" CS (chip select) with '595 doesn't work as intended and now more CS lines are needed I started again to think about "two connector" approach: basic/mandatory and advanced one where former should be used for low-speed signaling and data transfer and later for hi-speed.
    Such approach should nicely address your prediction that most DIY users never going to use LVDS but also suggestion for low-speed galvanic isolation where optocouplers should be an affordable solution.

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #178 on: July 05, 2018, 04:51:32 pm »
    Since it's now clear that chosen DIN connectors for both master and peripheral modules doesn't offer enough pins because more then one CS line is needed per module, I'm start to thinking again about PCIe as possible solution which @ogden suggested in #169. I have one question here: since it's possible to get PCIe as both THT and SMT I'd like to know does anyone have any experience or recommendation which one to use? THT variant has holes organized in 4 rows, while SMT has pads in just two rows. Which one is more economical (in number of min. PCB layers e.g. 4 or 6) and/or easier to route?

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #179 on: July 05, 2018, 08:35:36 pm »
    I like through hole connectors for this sort of thing because they are usually harder to knock off the board.  I see that a 2mm staggered pitch is available.

    Size budget:
    • 2mm pitch
    • 0.7mm hole
    • 0.25mm annular ring (times 2 for each side of hole)
    • Gap between rings: 2 - 0.7 - 2*0.25 = 0.8mm
    • Assuming 0.15mm trace & space, can fit 2 traces between. (Have to check PCB layer stack for controlled impedance.)

    I think that you might be able to get a good number of tracks through in 4 layers.

    Going to 6 layers gives up to twice the available area, but will really drive up prototyping costs.
    • Sig
    • Gnd
    • Sig
    • CORE
    • Sig
    • Gnd
    • Sig
     
    The following users thanked this post: prasimix

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #180 on: July 07, 2018, 08:38:19 am »
    Yes, it seems that routing diff. traces between two pins is doable in the following manner:

    (pad)
    (space between pad and trace) 5 mils
    (trace width) 6 mils
    (space between traces) 6 mils
    (trace width) 6 mils
    (space between pad and trace) 5 mils
    (pad)

    That 5 mils spacing can generate additional cost of manufacturing but it's still way cheaper then switching from 4 to 6 layers. With PCIe we could use 64-pin for peripheral modules (increase of 16 pins) and 164-pin for master/CPU module (increase of 68 pins!). That will give us more possibilities for additional CS (chip select) and perhaps also for adding of "slow speed" channels if someone really don't need/like LVDS as only/mandatory way of communication. Also with PCIe connector that has higher pins density we can think again about basic/advanced configuration, i.e. one connector for mandatory system signaling + low-speed communication and another for hi-speed communication between master and peripheral modules and signal switching/distribution between peripheral modules.

    Offline carljrb

    • Contributor
    • Posts: 24
    • Country: ca
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #181 on: July 09, 2018, 06:51:43 am »
    This seems like an interesting but perhaps over-ambitious project. At this point, it seems quite unclear what kind of instruments you expect to be built for it, or who it's designed for.

    Most instruments talked about would not be a great fit for such a rack. For example:
    -good lab-grade power supplies typically need AC power, generate tons of heat and are very bulky (big transformers and heat sinks)
    -loads generate a ton of heat, use a ton of space (large heat sinks and fans) and need a ton of ventilation
    -"higher end" instruments like arbitrary signal generators, scopes and logic analyzers (which are better than cheapo ebay logic clones) will most likely be held back by various limitations this design

    On one hand, "hobbyist" modules are pretty much guaranteed to misbehave in many ways (buggy software, incompatibilities, conducted and radiated emissions, etc), and those who build "fancier" instruments most likely will object to various design choices and limitations. Then again, it's vastly too complex and pricey for the "arduino crowd", and too limited for serious stuff. That leaves an awkward zone right in the middle for (...not sure what?), which will somehow need to be calibrated against better instruments which most people won't have access to.

    There's a bunch of other general factors that will probably stop a lot of people:
    -a one man team, which always means that things like support/future development and such is anything but guaranteed. Especially when it's from a hobbyist, because most hobbyists soon find a new exciting project to start and drops the current one before completion...
    -no guaranteed backward compatibility in future designs/versions (who wants to spend $500 to make a prototype today which could be obsolete next week?)
    -the old catch 22: both the software and hardware guys will wait on each other basically...

    Making a backplane is IMO by far the easiest part of this all. The hard parts will be coming up with a good standard, getting other people involved (interest groups? academia perhaps?), seeing what kind of needs those people would have and how that standard will be helpful now (it's got to be very clearly better than the other options somehow) and how it'll expand in the future, getting things documented properly, there's lots of code to write and so on. Adding a few mounting holes and differential traces on a PCB is the quick and easy part.

    Meanwhile, there isn't even the most basic 3D design (that'd take perhaps an hour in solidworks or fusion 360) so the PCB shapes and overall placement of things is likely not to work out... And the enclosure design seems like it could be a problem to many. Most people don't have access to milling machines and other similar machinery. It's not like you can build stuff like this (with a good fit and finish) with just a hacksaw and a hand drill. Getting metal plates custom cut to size, with the necessary openings and holes, plus shipping... Plus all the other hardware (again, with cuts and all) and fasteners, with shipping from other/different suppliers... That seems like a lot of time and hassle, and not much cheaper than buying something like a pre-made, modular system. I for one would sooner buy a vectorpak subrack  or the like (and I'm used to getting quotes for custom parts).

    Developing for this would be too expensive for a lot of people. Just the PCB prices alone will probably discourage many. The absolute cheapest 194x88mm 4 layer board (the size of the backplane) is ~$65, and the typical daughterboard size (170x145mm) in 4L, with gold fingers (I'm hoping the bevelling is included, and proper hard gold plating, not just an ENIG finish!) starts around $100 per board, with few available manufacturers (basically locking you into the cheapest manufacturer's choice of stackup).

    Also, the project seems to ignore all already established protocols and standards (USBTMC, VISA, SCPI, LXI/HiSLIP, etc) which works well with existing instruments and code, which would make the instruments most likely less useful overall. Also, it's unclear how the current choice of interconnect is an improvement over cheap, well-established stuff. 100MHz SPI is kinda slow. USB2 is much faster, as is Ethernet (isolated too), and of course USB3. They're cheaper, vastly faster and also bi-directional (there's a good reason "low end" keysight/NI systems uses USB!)

    The choice of XMOS (a fairly non-standard architecture, with a non-standard language, from a minor player) is a deterrent IMO. It's too slow and doesn't have enough memory for a lot of stuff. Here again, there's a reason most systems use a beefy CPU or directly connect to a PC. A dual-core XMOS loses to a Pentium MMX from 1997. A single desktop-class CPU like an AMD 1800X is *literally* a million times faster, and the situation is much worse if you consider things like GPGPU (with mainstream consumer GPUs) or even cheap 2nd hand Workstations with fast Xeons, tens of GB of RAM, tons of fast storage, along multi-monitors and all... Having it also drive an LCD display will only make it more of a limit, for an interface that's so minimalist that it might as well not be there (two encoders for 4 instruments plus a master?) Again, I think there's a good reason there isn't one on such systems from big players... It's just too limited.

    Then of course, you need to get everyone to agree on CAD tools, programming languages, coding styles, protocols, licenses, documentation, etc. That's a major undertaking in itself!

    Not that I agree with software being the main "limit", or the main thing people need help with. There's tons of that at *every* level of the design, and so far a backplane (or any other type of interconnect or cable of any kind) and enclosure aren't solving that problem either.

    Sorry if it sounds harsh. I tried my best at constructive criticism. If anything, I think you should reevaluate what it's trying to accomplish (like: what it does better and why it's a better option) before routing more traces on backplane version N+1.
     
    The following users thanked this post: prasimix

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #182 on: July 09, 2018, 09:42:40 am »
    Thanks for your lengthly reply. Let's go back to the beginning: this topic was opened to discuss possibility to define "bus" that should address building T&M instruments that belongs somewhere in between existing entry-level/low-cost and commercial solutions (nothing more, nothing less :)).
    I'm still attracted with idea about modular and well connected instruments as better solution then have many stand-alone, "portable" (and often "naked", i.e. unprotected even with most basic enclosure) instruments on my benchtop while I'm experimenting, measuring or building something. I don't even need to mention open source approach that is mandatory for me.

    An idea of what kind of instrument I'd like to have over time one can get from #76. Lots of energy was spent about pro's and con's of speedy USB and Ethernet. I believe that VXI as an example of big guys solution is also mentioned somewhere and that "DIB" should be something less demanding but still useful people who is not interesting in collecting new neat "eBay grade" gadgets. Regarding already established standards, I'm well aware or them, SCPI is already discussed here and when I decide to make an open-source programmable benchtop power supply (aka EEZ H24005) we tried to follow SCPI "way of thinking" and that helped us a lot to structure firmware in the right way. One of the end result is visible here. Also our dedication to the SCPI & Co. is clearly visible in open-source multi-platform EEZ Studio.

    So far people did a great job to discourage me to move this forward and to stick for various reason to the existing solutions (either entry-level or commercial one). That's fine, I have no illusion (I'm not delusional, saying in English, right?), nor have ambition (vision?) that DIB can became anything even closer to the most unsuccessful specification/standard.
    My call was based on a guess that "DIB" idea could attract people which are experienced in the field of T&M and come out with suggestions that can be used to eventually build something for the common good. Perhaps I'm not a good listener, and cannot spot details, since so many people told me what you've also repeated, that is too big challenge for one person. Indeed, that is true, and everyone is still invited to spend a little bit more time trying to addressing in more detail any part of this concept instead of repetitively let me know how that is not possible, or that is not worth to do. The question is not worth of what? Somebody time and money? But it seems there is an abundance of time and money when you see how people spent their resources. Ok, we have to make a strict distinction about creators and consumers and that former have less resources to spent the later. But this call is not directed to consumers. Its directed to creators (what I'd like to become, since I'm in the best case skilled-enough builder). Ok, if creators are already busy with their own ideas and creation, then lets forget DIB (this "call" for mission impossible). I'll try within my limited resources (knowledge, time and money) to make something out of it with people like @jbb who already assisted me in most constructive way and keep you informed about our progess, mistakes, success, etc. ;)
     
    The following users thanked this post: s8548a

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    DIB v1.0 working draft
    « Reply #183 on: June 22, 2019, 07:41:37 am »
    It's a time for an update of this topic since Bench Box 3 is progressing well, and helped me to define needed set of functionalites to make connection between MCU and various lo-speed periperal modules.

    This specification defines four physical connectors: two mandatory (MCU 40-pin and Peripheral module 28-pin) that are related to DIB backplane and two optional, one (16-pin) that defines power connection when the EEZ DIB AUX Power supply is used for powering MCU and backplane, and another (20-pin) that allows coupling of power sourcing module output terminals such as DCP405 power module.

    Connector's pin mappings are presented in the picture that follows. All connectors contain two rows hence pin mappings description is separated in two columns (A and B). Direction (Dir column) when applicable shows unidirectional signal flow referenced from the inserted module, not backplane.



    For example, NRESET on the MCU module connector is assigned as an output (O). Therefore the same signal represents an input (I) on the peripheral module connector. Bidirectional signals have the same direction mark (I/O) on both sides (MCU and peripheral module).

    MCU module connectivity

    A 40-pin (2 x 20-pin) right angled pin header and receptacle with 0.1” pitch are used for making connection between MCU board and DIB backplane. Receptacle is used on the MCU board side while header is on the backplane side. The MCU module provides the following power and signaling lines:
    • +5 V pass-thru power output (from the AUX Power Supply)
    • +12 V pass-thru power output (from the AUX Power Supply)
    • +3.3 V low power output (provided from the MCU board LDO, max. 20 mA per module)
    • +3.3 V backup, low power battery backup output
    • Reset output (active low) and Fault open-collector signal
    • I2C bus (SSCL and SSDA, 3.3 V level) shared between all peripheral modules and AUX Power Supply
    • Async UART (RX and TX, 3.3 V level) shared between all peripheral modules that can be used for firmware uploading of the peripheral modules' on-board MCU if it does not support SPI for such operation
    • Three dedicated SPI buses (SCLK, MISO and MOSI for CH1, CH2, CH3) and two device select lines (CSA and CSB for CH1, CH2, CH3) that allows addressing of up to four SPI devices on the peripheral module (using 2-to-4 line decoder like SN74LVC1G139)
    • Peripheral module interrupt (IRQ for CH1, CH2, CH3)
    • SYNC output for synchronizing activities between two or more peripherals, e.g. OE (Output Enable) of power sourcing peripheral modules.
    Although only three SPI buses are defined with DIB v1.0, that doesn't limit max. number of peripheral modules to three. The DIB backplane can be designed in a way that two or more peripheral module connectors share the same SPI bus. If more device select (CS) lines are required, a SIPO register (e.g. 74HC595) can be used to address up to eight SPI devices. Addressing more SPI devices can be accomplished by deploying two or more daisy-chained SIPO registers.

    Peripheral modules connectivity

    Power and signaling lines for the peripheral modules are provided with 28-pin (2 x 14-pin) 0.1” pitch right angled pin header on the side of the peripheral module and receptacle on the backplane side. The peripheral module connection includes the following power and signal lines:
    • +5 V input (from the AUX Power Supply)
    • +12 V input (from the AUX Power Supply)
    • +3.3 V low power input (provided from the MCU board LDO, max. 20 mA per module)
    • +3.3 V backup , low power battery backup input for e.g. standby
    • Reset input (active low) and Fault open-collector signals
    • I2C bus (SSCL and SSDA) shared between all peripheral modules and AUX Power Supply
    • SPI bus (SCLK, MISO and MOSI) and two device select lines (CSA and CSB)
    • Interrupt output (IRQ)
    • SYNC input for synchronizing activities between two or more peripherals initiated by MCU
    • Module identification inputs (A0, A1, A2)
    • BOOT input
    • Shared async UART (optional)
    The BOOT input can be used with peripheral modules that comes with on-board MCU and which firmware could be uploaded via SPI or UART. If BOOT input has to be dedicated (i.e. one per module) that only one on-board MCU can be put into bootloader mode after the reset (power up) a DIB backplane can be equipped with I2C I/O expander that could provide one BOOT control signal per module.

    The module identification inputs can be used as device selection for I2C peripherals such as on-board EEPROM, temperature sensors, etc. When used for EEPROM addressing the 000 address cannot be used since it's assigned to the I2C EEPROM on the MCU board. Inputs A0-A2 require pull-up resistors connected to +3.3 V (e.g. 10 KΩ) on the peripheral module PCB. Module position on the backplane is defined by “hardcoded” wiring of A0-A2 to GND.
    Please note that #0 position should not be used to avoid possible conflict with already mentioned EEPROM on the MCU board and also other devices in the future.

    When selecting I2C EEPROM pay close attention on its addressing capabilities even if it provides three address inputs. Many low capacity devices can effectively use only a single input for addressing purposes.

    If two or more modules have to be galvanically isolated (e.g. like in case of power modules with floating outputs) use appropriate isolators (e.g. Silabs Si86xx, Maxim MAX14850) for control and data lines.

    AUX PS module connectivity

    The main purpose of this connection is power delivery for MCU board and peripheral modules. Two voltages are specified with DIB v1.0: +5 V and +12 V. Additionally, two lines are assigned to +3.3 V auxiliary powers: a) +VAUX as (battery) backup and b) +3.3 V that is sourced from the MCU board LDO and can be used to power e.g. an I2C low-power (max. 20 mA) device like fan controller. This connection contains also the following functions:
    • Shared I2C bus (SSCL, SSDA) for fan controller or similar devices
    • AC Soft-start/Standby control inputs (PWR_SSTART, PWR_DIRECT)
    • Reset input (active low) and Fault open-collector signal
    • PE (Protective Earth) output
    • MBOOT output for define MCU bootloader mode
    Power sourcing module connectivity

    This connection is optional, but its physical location should be taken into account when peripheral module PCB is designed to leave that area unpopulated to avoid possible issues with inserting peripheral module into the DIB backplane that includes this connectivity (e.g. EEZ DIB BP3C backplane). Therefore it is highly recommended to follow the peripheral module PCB template available on the project's GitHub repository.

    A 20-pin (2 x 10-pin) 0.1” pitch right angled receptacle is used on the side of peripheral module and straight pin header on the DIB backplane side. Pinout scheme is rather simple: it provides power terminal inputs and outputs that are assigned on multiple pins for increased current capacity. Allocation of five pins per power lines should be sufficient to carry 5 A continuously.

    The idea behind output terminal coupling is to avoid usage of external wiring as it is accomplished on the EEZ H24005's Arduino Shield board by using power relays for reliable connection under MCU control.

    If peripheral module such as DCP405 power module is deployed, this connectivity becomes mandatory on the DIB backplane. If no coupling capabilities are provided, a simple pass-thru connection (i.e. IN+ to OUT+ and IN- to OUT-) has to be made to ensure normal operation of such module.

    Peripheral module PCB dimensions

    The DIB v1.0 specifies only the physical dimensions of the peripheral module and related connectors (i.e. 28-pin peripheral module connector, and optional 20-pin power sourcing module connector) positions. Dimensions of other parts of the system (e.g. MCU board, backplane, power supply module) can differ from project to project depending of e.g. chosen enclosure dictated by builder budget and appearance preferences. Allowed dimension of the peripheral module is shown below.



    Thanks to the fact that DIB connectors are located at the bottom end, the PCB width can vary and it could be anything from 90 to 185 mm. In fact it could be even wider, but this is recommended if the EEZ Bench Box 3 design is used. Recommended PCB height is 95 mm but it can also vary in accordance with selected enclosure, and that is a max. height for the EEZ Bench Box 3 design.

    Distance (horizontal pitch) between two peripheral module connectors is 35.5 mm (7 HP) and could appear that is somewhat too large for today's standards and components. Such distance is selected to allow mounting of larger heatsink elements on the peripheral module that is beneficial for power sourcing and sinking modules where increased power dissipation is expected. Still, the specified modules distance does not limit builder to design a backplane that combine few DIB v1.0 modules (i.e. 7 HP wide to “comply” with specification) with thinner modules (e.g. 5 HP).

    Note that even if peripheral module does not require 20-pin power sourcing module receptacle, related PCB area has to remain unpopulated to avoid issue with inserting peripheral module into DIB backplane which has that connector.

    Peripheral module front panel contains two pairs of holes for fixing it on the peripheral module PCB and to the DIB enclosure front panel.

    DIB 3-slot backplane example

    The DIB backplane shown below is an example of possible DIB v1.0 backplane design. Its design is used for making the BP3C backplane for the EEZ Bench Box 3. It provides connectivity to up to three peripheral modules which can also be a power sourcing modules. Therefore both 28-pin peripheral module connector and 20-pin power sourcing module connector are included for each slot.



    Peripheral modules are inserted in this backplane vertically, and this is a mandatory, while MCU board is connected horizontally which is not a mandatory orientation. If a backplane is designed to accept MCU board vertically, and positioned on the far right of the backplane, the same horizontal pitch (7 HP) has to be used for MCU 40-pin connector as for the peripheral module connectors.

    It is recommended that PCB with min. two layers is used and filled with huge GND planes.

    Your comments are welcome as usual.

    Offline jbb

    • Super Contributor
    • ***
    • Posts: 1128
    • Country: nz
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #184 on: June 22, 2019, 10:27:33 pm »
    Hi prasimix

    It's nice to see some hardware on the bench; now you'll really see how well it works.  I hope you get everything finished by your deadline.

    In terms of 'Optional' bus signals, it would be nice to see some frequency/timing distribution; maybe a 10MHz ref, a 1 second pulse, an uncommitted 'event' line and another ground?

    I assume you're using the existing concept of fitting an I2C EEPROM to each card for ID purposes? Do you have a fully defined table of addresses?
    Card SlotI2C Address
    0 (Master)0x??
    10x??
    20x??
    ......
    70x??

    Some time ago we discussed data structures for an I2C EEPROM.  I spent a while drawing complex data structures with Excel but, in hindsight, this wasn't the best use of my time.  As we are looking at a much simpler bus these days (compared to previous efforts), I think that the EEPROM should start off with a simple data structure that contains only a small amount of information.  I suggest:

    AddressField NameField ContentsLength (B)Notes
    0DIBVersionDIB interface version x.x.x.x4
    4CardManufManufacturer Name (UTF-8, 32 char max)129UTF-8 takes up to 4B per character, length encoded expliticly
    133CardNameProduct Name (UTF-8, 32 char max)129
    133CardVersionCard HW version x.x.x.x4
    264CardSerialSerial # (UTF-8, 32 char max)129Set length to 0 for no serial number
    395ExtraDataStartExtra data field start address4Set to 0 for no extra data
    399ExtraDataEndExtra data field end address4Set to 0 for no extra data
    403HeaderCRCCRC32 for above record4

    Features:
    • Use of strings for manufacturer and product hopefully removes the need for a centralised numbering control body (compare with USB VID, PID)
    • There is just enough data to fully-define a card (manufacturer, product, version)
    • The use of a fixed-size data structure makes it easy to parse
    • Explicit lengths on strings can help parse unicode strings (but use of Unicode strings at all may be overkill)
    • CRC is included to detect I2C read errors (which may well occur on this bus!)

    The 'extra data field' isn't defined at this point; it's a slice of memory in the EEPROM.  The encoding would be left up to the manufacturer of the card, but I would suggest that whatever is used include a CRC32 protection at the end.  Possible data formats: more predefined tables, a Tag Length Value (TLV) string, XML string or JSON string.

     
    The following users thanked this post: prasimix

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #185 on: June 23, 2019, 07:04:21 am »
    Hi prasimix

    It's nice to see some hardware on the bench; now you'll really see how well it works.  I hope you get everything finished by your deadline.

    In terms of 'Optional' bus signals, it would be nice to see some frequency/timing distribution; maybe a 10MHz ref, a 1 second pulse, an uncommitted 'event' line and another ground?

    Idea is to expand peripheral module connector with optional signals or even introduce additional connector if needed. But, I'd like to leave that for some future revisions when more complex module come into picture. So, all what we discussed are good candidates for next DIB specification.

    I assume you're using the existing concept of fitting an I2C EEPROM to each card for ID purposes? Do you have a fully defined table of addresses?
    Card SlotI2C Address
    0 (Master)0x??
    10x??
    20x??
    ......
    70x??

    Yes, and backplane has A0-A2 lines as you proposed that is hardcoded that each slot has different address. I2C EEPROM on MCU board is hardcoded to 000.

    Some time ago we discussed data structures for an I2C EEPROM.  I spent a while drawing complex data structures with Excel but, in hindsight, this wasn't the best use of my time.  As we are looking at a much simpler bus these days (compared to previous efforts), I think that the EEPROM should start off with a simple data structure that contains only a small amount of information.  I suggest:

    AddressField NameField ContentsLength (B)Notes
    0DIBVersionDIB interface version x.x.x.x4
    4CardManufManufacturer Name (UTF-8, 32 char max)129UTF-8 takes up to 4B per character, length encoded expliticly
    133CardNameProduct Name (UTF-8, 32 char max)129
    133CardVersionCard HW version x.x.x.x4
    264CardSerialSerial # (UTF-8, 32 char max)129Set length to 0 for no serial number
    395ExtraDataStartExtra data field start address4Set to 0 for no extra data
    399ExtraDataEndExtra data field end address4Set to 0 for no extra data
    403HeaderCRCCRC32 for above record4

    Features:
    • Use of strings for manufacturer and product hopefully removes the need for a centralised numbering control body (compare with USB VID, PID)
    • There is just enough data to fully-define a card (manufacturer, product, version)
    • The use of a fixed-size data structure makes it easy to parse
    • Explicit lengths on strings can help parse unicode strings (but use of Unicode strings at all may be overkill)
    • CRC is included to detect I2C read errors (which may well occur on this bus!)

    The 'extra data field' isn't defined at this point; it's a slice of memory in the EEPROM.  The encoding would be left up to the manufacturer of the card, but I would suggest that whatever is used include a CRC32 protection at the end.  Possible data formats: more predefined tables, a Tag Length Value (TLV) string, XML string or JSON string.

    Module's EEPROM definitely has to include information similar to what you are mentioned, and we'll have a plenty of room for "extra data fields" for simple reason: the min. EEPROM size has to be 32K. I found that in hard way, starting from 1K and going up, and finally realizing that only EEPROMs starting with 32K could be effectively addressed with all three address lines!

    Martin is still working on other issues with STM32 MCU board, and when he starts to work on software parts of DIB concept, I'll post more details about that.

    Offline msat

    • Regular Contributor
    • *
    • Posts: 113
    • Country: us
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #186 on: November 13, 2020, 01:55:55 am »
    The forum software is trying to make me feel guilty for reviving an old thread.

    I recently created a thread about a similar project (https://www.eevblog.com/forum/oshw/open-bus-architecture-for-instrumentationcontrol-(vme-vxi)-feedback-wanted/) and was referred to this one. I finally got through this and found numerous aspects of what was discussed here to be similar to what I've been thinking, so perhaps that's a good indication that I'm heading down the right path. It also brought up some potentially important things that I haven't considered, such as:

    A) Trigger signal on the bus with the source being either external or internal. Should have been obvious

    B) Special power supply requirements for some modules. So I was mainly thinking of sticking in something like an ATX PSU to provide many of the common logic voltages in the instrument rack. For the various things where such a power supply won't suffice, I was thinking that another rack whose primary purpose is to house PSUs could be set on top or underneath of the instrument rack, with the outputs being jumped in the back. So basically each module slot on the instrument rack would have a connector coming through the backplane which would be an external PSU input.

    C) The importance of trying to comply with USBTMC and SCPI. From my current design plans, compliance would be partially placed on the module designer, so no guarantees. That said, I'm not entirely dead set on USBTMC.. As I mentioned in my thread, I also like the idea of enumerating the instrument bus as a mass storage device with virtual file(s) representing the modules. SCPI commands or whatever could be written to/read from these files. So in theory, you can possibly test/operate modules with a text editor. It might not be too much work to support both methods.

    So I'm more and more trying to avoid the "everything plus the kitchen sink" approach. I don't want to reduce features to the point to where it's useless, but I also don't want to add features that are likely to be useless for all but the edge cases. Also, and I mean no offence, but this won't be a "design by committee". I just want feedback in an effort to avoid any gross oversight on my part.

    Pretty much everything is up in the air, but if one thing is for certain it's that this is a module bus <-> host computer via USB interface design. There won't be any intentional support for inter-module comms or a computer-on-bus. Also, all modules are expected to have an MCU/FPGA for command encoding/decoding. The USB transceiver on the bus is intended to be little more than a low-level protocol translator.

    Right now, I'm thinking of proceeding one of two ways:
    1) As I mentioned in my thread, going with a 16-bit wide and up to 100MHz bus using a Cypress FX3 USB3 peripheral controller, with a theoretical max bandwidth of 1.6Gb/s. Each module will control the bus clock when they communicate with the FX3, so they can run at an arbitrary speed up to 100MHz. Since only one device can communicate on the bus at a time, slow devices can choke up the bus. It might be a good idea to allow prioritizing modules. The other downside is that this requires 16 + some additional pins for control and clock, meaning tiny micros are out of the question. The other thing is that many micros won't have native parallel bus hardware, so the bus would have to be bit-banged (er, word-banged?). That said, I foresee it being a pretty simple bus that's tolerant to significant jitter, so it shouldn't pose a big issue. I don't think.... The FX3 also has an SPI and I2C peripheral - I'm not sure if I want to throw those on the bus.

    2) There's a few microcontrollers from ST that supports USB2 hi-speed and 5 SPI ports with 3 @ 50mbit and 2 @ 25 for a total of 200mbit bandwidth - obviously much less than the FX3. The thought here is that all 5 SPI buses run to all module slots. Any module can use multiple SPI ports for bandwidth reasons. Also, multiple devices can be communicating simultaneously, so that way a slow device doesn't eat up all the bandwidth. For best performance, this would require modules to be able to jump to different SPI ports depending on availability, so either the module's mcu would need to support flexible pin mapping for it's SPI port (eating up pins in the process), or either the modules or the bus itself would need to contain a MUX. If the MUX isn't on the bus, it would be worth allowing simple modules to request use of only one SPI port on the bus at the expense of potentially greater latency. The benefit with going SPI is that it has decent bandwidth (for many applications), and is widely supported on even cheap MCUs - meaning there is minimal processing overhead for transceiving. That said, this idea isn't particularly elegant and for best performance can either eat up a bunch of pins or require a MUX. I think I prefer the first method for the most part.
     
    The following users thanked this post: prasimix

    Offline prasimixTopic starter

    • Supporter
    • ****
    • Posts: 2022
    • Country: hr
      • EEZ
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #187 on: November 13, 2020, 08:10:27 am »
    Thanks for stopping by and sharing some of your thoughts and leaving a link to the topic you opened.

    You are right that “design by committee” is not the right path, i.e. it easily leads to nothing. This almost happened with my proposal for DIB, but I continued to work on it myself and some result was eventually achieved: EEZ BB3 about which there is a discussion about the development here, and about the crowdfunding campaign here.

    I can also notice that you tend to cover everything from the first try: high-performance hardware and one that couls have a $1 MCU in the core. I started with such ambition myself, but then I cut it by putting the emphasis first on low performance hardware for which one SPI channel per slot should be enough. From the very beginning, I thought of DIB as something that others could benefit from, so as a basis for open T&M hardware. As many have seen so far, open hardware is significantly different from open software because it is not easy to gather more interested people around it because it requires much more than a PC and internet connection. That’s why I think it’s important to lower the entry barrier as much as possible because it’s one thing to try to design something on a gigabit bus and another on an SPI of a couple of Mbps.

    I believe that the DIB concept will become successful when the first module appears independently developed, albeit with the support of the EEZ team (i.e. Martin and me :)), and the micro community gathered on this forum and on the Discord server.

    I don't know anything about the capabilities of today's USB controllers, but somehow it seems to me that the LVDS with a FPGA as a controller/dispatcher is a much more flexible option. This will most likely be in the core of the DIB v2 extension, and the first candidate for this is the integration of the ULX3S project which is currently being worked on.

    The detail that distinguishes DIB from your proposal is that from the very beginning I wanted to have local control. For this we have a TFT color touchscreen and I think many have recognized this as an important feature: especially when the device is ready for action in about 3 seconds :).
    I was guided by the idea of ​​a DVD player (open source if there was one!): You turn it on, insert the media and watch, unlike turning on the PC, clicking on the menus to start the media player and choosing what you want to watch. When all is well it can go very quickly, however we know that this is often not the case for a variety of reasons.
    We didn't stop at offering just "play/rec" actions, but we also added MicroPython so that some more complex usage scenarios could be created and had on the device itself, without the need to depend on the PC.

    That’s not to say we didn’t think about how to connect to the PC and the rest of the world: the EEZ Studio cross-platform was developed for the PC which has two components: a visual GUI editor and a SCPI controller (for BB3 but also third-party instruments). The GUI editor allowed us to not depend on other tools (as in the case of choosing Nextion or similar HMI). The SCPI controller allows us to communicate with the device without paying expensive licenses for additional software (e.g. LabView, BenchVue, etc.).
    Furthermore, we started adding MQTT, so BB3 has become a device that can be integrated into a growing IoT infrastructure.
    All of the above is anything but easy to support (we still miss e.g. USBTMC).

    Offline msat

    • Regular Contributor
    • *
    • Posts: 113
    • Country: us
    Re: "DIY instrumentation bus" (or DIB)
    « Reply #188 on: November 14, 2020, 12:31:27 am »
    Oh, wow! The EEZ BB3 and various modules look great! Nice work! It'll take me a while to make it through those threads, but I plan on it and hopefully they inspire me.

    I have nothing against integrated computing, and your fast-boot example is compelling. Rather, since I'm looking for something to fulfill my wants and style of workflow, is why I'm going for external compute via USB interface. This is one of those things that has no right or wrong answer  ;)

    Last night while lying in bed I realized that if I go with the FX3 controller (which I think I probably will), then I'll put its SPI peripheral on the bus. It would be stupid not to since many module's comm requirements would be perfectly satisfied with the bandwidth it provides, allowing potentially small micros to be used, and also freeing up the parallel bus for modules with high performance requirements.
     


    Share me

    Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
    Smf