Eurocard Metrology Standards Rack Build

[ZGoode]

Not sure if this would belong here or metrology since I'm planning on using this for the 10V, 10MHz, and various standards I'm building but I thought I'd put into a compact Eurorack enclosure with backplane power and communication.  I've only just started the project and designs, but thought I would start a thread to document the project.
So far this is what I have:
 - +/- 12V
 - + 5V
 - +3V3
 - GND (lots of it)
 - Earth/Chasis Ground
 - I2C and UART
 - PowerGood monitoring
 - PPS for synchronization if desired

I'm basing it on this rack from Reichelt: https://www.reichelt.com/us/en/shop/product/system_housing-50439
And I'm currently using these casettes: https://www.reichelt.com/us/en/shop/product/insert_modules_12te_60_4_mm_-50418
                                                          https://www.reichelt.com/us/en/shop/product/insert_modules_8te_40_3_mm_-50416

I'm planning on having it mains powered, but adding in a sealed lead acid battery to try and get at least several hours of backup (if not hopefully more, haven't done the capacity calculations yet).  The main power lines will be some kind of filtered switching power supply, but on the plugin cards I'm looking at doing mostly linear power regulation.

Attached is the pinout I have so far for the backplane connector, I still have a few extra pins on it, so I'm open to suggestions on additional data/power/signals that could be nice to have for the modules.
These are the connectors I am probably going to end up using, just cause I already have a few and they seem to work pretty well: https://www.digikey.com/en/products/detail/harting/09042326831/3179814
https://www.digikey.com/en/products/detail/harting/09041326921/3179808

[squadchannel]

Marco reps was making 18650 based batteries for the ADRmu project. With lead-acid batteries, I think the width would be more. Might be helpful.

Regarding backplane connectors, I have recently seen one called "har-modular" from harting that I am interested in. It is one of the few backplane connectors that supports coax.

[ZGoode]

Yeah, this design is definitely influenced by Marco Rep's build.  Although there are a few things on his design I wasn't all too happy with, such as his wasted use of that expensive backplane connector.  That's why my pinout is fairly different to his.
As far as SLA vs Li-Ion, it came down to a few key factors for me.  From everything I've read it seems like SLA is a better long term solution, and also a significantly less dangerous option.  I didn't want to have a rack full of 18650's in my office.  Also SLA is a little bit simpler to maintain and manage.  It does have its drawbacks, like lower energy density, but given that I don't really have problems with power reliability where I am I don't think that is a huge concern.  I am planning on putting a connector on the back for adding a larger secondary battery maybe for transport or something?

[Doctorandus_P]

I have also created a design similar like this, but there is no way I am going to pay EUR80 for an empty box, or EUR 30 for an empty cassette.
As a result my own design is more complicated to start with, but it does not need a large investment.

Some details:

• The "front" is made of 20x20x1.5 aluminum profile.
• Each module is just the bare PCB, Alu profile for the front and connector on the bottom, so a few Euro's per node.
• Connections are on the underside. This allows for variable card size depending on project complexity.
• The Underside has 40 pin 90 degree male IDC connector. (Cheap (depending on quality) and common)
• Simplest form for the "backplane" is a 40 pin IDC flat cable 
• Inside the thing there is enough open room for "adhoc" cabling. From USB to things like connecting a multiplexer card with an ADC card.
• PCB for the "backplane"  (Gound plane  has lower impedance, GND plane, provides sturdiness.
• "Backplane" PCB has 44 pin female 2.54mm headers. These align nicely with the 40 pin box headers. 
• Power is (raw) 24Vdc +- 15Vdc and 5Vdc. 3V3 is made only by local regulators.
• I2C and SPI, but the main communication is two busses with RS485 or CAN transceivers. (I already have a custom network protocol for UART)

I specifically designed this to be as cheap as possible and easy to reproduce by hobbyists, (No edge connectors) and at the same time incorporating as much flexibility as possible into the design, and also still having a decent set of capabilities.

The form factor of the PCB is for example designed around a 80x120mm matrix board. Any regular experimental matrix board can be used for a prototype or a one-off design. I also designed it in such a way that the location of the matrix relative to the PCB outline is not important, and this makes it independent of the brand of matrix board. Both bigger and smaller PCB's can be used too. This matrix board is also (just) big enough to hold a small Linux computer, This may be nice for automated test and measurement, but it's fully optional, it can also be connected to a standalone PC.

I also want to maintain compatibility with my custom protocol. (description below) One of the nodes planned is a backside for a Brymen BM869s. The intention is to "catch" the IR data, and convert it to SCPI strings for the network node. In this fashion each brand of DMM only needs a bit of firmware to convert it's simple protocol, and on my own network, they are all connected to the same cable and interchangeable. (But still dependent on the rotary dial and other limitations).

A part of my inspiration is from:
https://www.eevblog.com/forum/oshw/open-bus-architecture-for-instrumentationcontrol-(vme-vxi)-feedback-wanted/
https://www.eevblog.com/forum/projects/diy-instrumentation-bus-(or-dib)/
https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments
https://en.wikipedia.org/wiki/List_of_automation_protocols

My protocol:
I am running a custom serial protocol for home automation over RS485 and CAT-5 cables for 15+ years and it works pretty well. At 115kBaud this protocol has 8 bytes of overhead for a packet (16 bit address space, 1 byte for data size, 1 byt for flags and 16 bit CRC) This limits the data to around 800 packets per second. (I have some test runs with 1M packets send and just a handful of errors while using collision avoidance.

There are just a few details I still have to decide on for the final form factor.

• 115k2 is a bit slowish for such a rack, so I'm thinking of a higher baudrate. Maybe 1Mbaud or 2Mbaud.
• Maybe CAN transceivers, this allows for (software) collision detection instead of only collision avoidance (that does not work with RS485)
  
• Maybe a simpler / cheaper interface, as the (fast) data is contained within the box (The long cable variant can stay at 115k2)
• Current protol depends on 9-bit communication mode, this adds 10% overhead. Using a "Break" as Modbus does is more efficient for packets > 12 bytes (4 bytes payload)

[Doctorandus_P]

I got a bit carried away on my own design, I apologize for that.

From your design:
If you change the pinout / connector compared to Marco Reps' design, then it's already incompatible. As a result keeping "close" to his design is not very useful. You either maintain compatibility or you don't.

I see very many power pins, but GND pins are a bit lowish.
What to do with uart? How do you connect more then two nodes? (It's why I chose RS485/CAN)
Maybe a one wire protocol such as LIN ( or only LIN signalling) is a good idea). https://en.wikipedia.org/wiki/Local_Interconnect_Network#LIN_hardware
I2C is nice to have.
With only UART and I2C there are not many options and bandwidth to communicate between cards.
What are the PGA and PGB pins?
Having spare wires in your connector is a good thing. You can reserve them for the user, (custom signals) ( have 8 unassigned wires at the moment)
PPS I assume Pulses per Second or some other sync signal (It's used for different acronyms). I thought of a standard 10MHz signal, and the other "sync" would be via a programmable divider in a uC.
I see you have groups of GND pins. It's better to spread them around in between signals. Take a look at https://en.wikipedia.org/wiki/PCI_Express for an example (lots of high speed digital communication).

How do you define the difference between "GND" and "Earth"?
It's also one of the details I am not sure of yet myself. For me most is "GND", and I have a "clean GND" that is used only as a reference and carries no current at all. I don't know if it's useful.

For extra communication protocols, Uart data could be sent with an open drain driver and a passive pullup similar to I2C. Uart receivers can always listen. This is the simplest multi-drop I can think of. But the cost of RS485 or CAN transceiver is not a big issue compared to the total cost of a node. The protocol for the software is the main thing.

For a higher speed protocol SPI or Quad SPI is an option, but I am not sure how to combine multiple nodes on a "bus".

[ZGoode]

You make some good points.  I'll probably get rid of the 3V3 rail and replace it with a 24V one instead.  Also good point on spreading the ground out more throughout the connector.  As far as Earth ground vs ground, I'm planning on keeping this relatively isolated from main Earth so that I can use it with non-isolated equipment.
I was looking into using RS485 instead of UART, but have not looked into it thoroughly yet.  I was planning on probably using an addressing type system for multiple slaves on the UART bus, although I haven't fully flushed out the communication side of this project here.  CAN is an option, although I kinda want to avoid it, probably since it gave me a headache during my undergrad capstone on an automotive project we had to do.  Could also do an ethernet solution maybe since it is inherently isolated based on its application, maybe a two wire solution such as 10baseT?
And I never said I'm making it compatible with Marco Rep's design, I just said it was inspired by it.  As I had said earlier, I was not really a huge fan of how he was utilizing the backplane connector.
You make a good point on cassettes and a rack not being super cheap, but by using the cassettes like this I can keep modules such of ovenized references much easier thermally isolated from other things happening in the rack (such as fans for the main power supply and controller)

[jbb]

I know it won’t exactly hit the spot, but how about making modules for the EEZ BB3?

Pros:
- existing hardware design for the chassis etc
- pre-defined comma interfaces
- master controller is open source and should hopefully support new card development

Cons:
- only 3 slots
- backplane doesn’t support analog signal distribution; you’d need to define some kind of flyover cable solution
- limited DC power available (but there is room in the box to fit additional AC-DC power converters)

On signal handling: I wonder if it’s acceptable to distribute a 10 MHz reference clock using Multidrop M-LVDS? (Differential scheme)

Edit:
If you do roll your own, might I suggest:
- adding an I2C lane to the backplane and an EEPROM on each card to store make, model, serial # and maybe calibration data? The EEZ DIB also uses some pins on the backplane connector to set the I2C address, which lets you identify where the card is plugged in
- keeping the 3v3 rail as a potential supply for signal isolators (and I2C EEPROM if you go that way)?
- including a 10 MHz reference clock distribution in addition to the 1 PPS

[ZGoode]

Yup, I was planning on adding an EEPROM to each card, that's what the I2C SDA/SCL pins on my backplane connector are primarily for.  I'll look into LVDS, although I don't know how effective it will be for me since I haven't used an LVDS in my designs before, whereas RS485 is pretty similar to UART in application which means it is pretty universal and easy to apply regardless of which MCU's I am using.
I don't know if I want to add the 10MHz reference as a signal on the backplane connecter since I am planning gon having a few different GPSDO's and reference standards housed in this rack.  I have sourced a variety of OCXO's for long term testing and am also looking to get a rubidium source for my long term testing as well.

[ZGoode]

I've made some changes to the pinout of the card.  More GND and also spread it out.  Added +/-24V.  Having two of each power pin is probably more than overkill since this connector is rated for 6A at each pin according to the datasheet.  Particularly since this will be battery backed up, I can't imagine I'll be making any modules for it that take more than 1 or 2 amps at any of the power lines.
As far as communication, I'm thinking of going with the CA-IS3082W for isolated RS485 on each module since it behaves similarly-ish to UART so it shouldn't be too much different to implement

[Doctorandus_P]

I was interested in the EEZ Bench Box https://www.crowdsupply.com/envox/eez-bb3 but it's a bit out of my price range. It's also not designed as a data acquisition system, it's just a modular power supply

It looks like ZGoode and I are quite far apart in what we want to build. Mayor goals for me are low cost and as universal as possible, while ZGoode is more geared towards easy to use modules with more specific uses in mind.

I don't like putting an EUR10 connector in the thing, It's probably a good connector, but data is low current and does not need 6A. I rather have a higher density connector, and then parallel connections only when needed. 40 pin headers are < EUR3 from digikey and pennies and cents from aliexpress. The cheap ones have bad plating, that may be acceptable for low insertion counts or prototypes or just hobby experiments. for more "professional" applications, better quality is probably worth it.

I wonder about the problems you had with CAN. Shitty wiring or a missing termination resistor can wreck such a bus. Faulty setup for CAN controllers in a uC or a defective node can also create plenty of headaches.

I started with UART and RS485 drivers long (15+ years) ago, and it works pretty well, but you have no collision detection. As soon as there is more then a few meter of cable in between nodes, then each node read's it's own data without faults, even when sending at the same time.

My main turnoff for CAN is it's weird addressing scheme, and it's very short data payload. But apart from that there are a bunch of advantages of using CAN transceivers with a UART.

• No need for data direction control.
• Dominant and recessive states allow for collision detection.
• CAN transceivers with built in galvanic isolation are readily available.

Galvanic isolation can be done with some optocouplers, or digital isolators such as in the ADUM series. Or at least with CAN, integrated into the transceiver itself.

The "cheapest" galvanic isolation is with optocouplers on an Uart, combined with passive pullups on the bus side. Such a simple setup is probably pretty limited in bitrate. But if you want galvanic isolation, you also need to isolate the power and that is also going to cost a bit.

Ethernet is indeed also an option, and for things like that, I concluded to make it as an "open frame". Wiring for Ethernet, USB or a separate isolated power supply can then be routed to specific nodes. I like it to keep options open like that.

[3roomlab]

some time ago, i was fiddling with some backplane based on omron XC5
there are many brands making this same DIN design
i found 1 called OUPIIN
website https://www.oupiin.com/en/product_ii.html?c1=15&c2=62

XC5 omron is fiber filled PBT, OUPIIN is just PBT
there is also similar makes on LCSC (eg : HC-CZ254-2-10-Z-11.5-G0-F)
the CZ254 is also PBT no fiber

under oupiin they also have the high current version = 9001D5 (15A)
but i have no luck locating this 1

i bought some samples back then to take a look
the 2x10p version i got cost rmb1.6 each before shipping (loose qty webstore)
the 3x16p is something like rmb3
i have not seen the original omron XC5 before so im not sure about them

I was interested in the EEZ Bench Box https://www.crowdsupply.com/envox/eez-bb3 but it's a bit out of my price range. It's also not designed as a data acquisition system, it's just a modular power supply

It looks like ZGoode and I are quite far apart in what we want to build. Mayor goals for me are low cost and as universal as possible, while ZGoode is more geared towards easy to use modules with more specific uses in mind.

I don't like putting an EUR10 connector in the thing, It's probably a good connector, but data is low current and does not need 6A. I rather have a higher density connector, and then parallel connections only when needed. 40 pin headers are < EUR3 from digikey and pennies and cents from aliexpress. The cheap ones have bad plating, that may be acceptable for low insertion counts or prototypes or just hobby experiments. for more "professional" applications, better quality is probably worth it.

I wonder about the problems you had with CAN. Shitty wiring or a missing termination resistor can wreck such a bus. Faulty setup for CAN controllers in a uC or a defective node can also create plenty of headaches.

I started with UART and RS485 drivers long (15+ years) ago, and it works pretty well, but you have no collision detection. As soon as there is more then a few meter of cable in between nodes, then each node read's it's own data without faults, even when sending at the same time.

My main turnoff for CAN is it's weird addressing scheme, and it's very short data payload. But apart from that there are a bunch of advantages of using CAN transceivers with a UART.

• No need for data direction control.
• Dominant and recessive states allow for collision detection.
• CAN transceivers with built in galvanic isolation are readily available.

Galvanic isolation can be done with some optocouplers, or digital isolators such as in the ADUM series. Or at least with CAN, integrated into the transceiver itself.

The "cheapest" galvanic isolation is with optocouplers on an Uart, combined with passive pullups on the bus side. Such a simple setup is probably pretty limited in bitrate. But if you want galvanic isolation, you also need to isolate the power and that is also going to cost a bit.

Ethernet is indeed also an option, and for things like that, I concluded to make it as an "open frame". Wiring for Ethernet, USB or a separate isolated power supply can then be routed to specific nodes. I like it to keep options open like that.

[MarkF]

This reminds me of the old VME chassis.
A 1U VME chassis with the backplane and power modules already for cards.

 

Pin assignments attached (3 rows of 32 pins):

I don't know if any of these are still available.

[Doctorandus_P]

Those VME things really are a thing of the past with those big parallel buses 16 data lines, whole lot of control signals, a gazillion address lines. But if the backplane is passive, (Except for power) then you re-assign the signal wires for whatever you want. May still be nice if you can get some second hand chassis for cheap.

I'm not sure whether PXI is similarly obsolete, but it sure has a lot of pins has even more pins
https://en.wikipedia.org/wiki/PCI_eXtensions_for_Instrumentation

But overall there is nothing wrong with looking around what other sort of standards exist. There have been a whole lot of buses for instrumentation equipment, and one of the main decisive factors is bandwidth, and that is a factor you have nod decided on yet. There are also a whole lot of rack like PLC's with various buses. You can have a look at OpenPLC for example (Uses DB25 with mostly power& GND and a two wires for RS485). A few years ago I have also seen a system that uses USB and has an USB hub integrated in it's backplane.
"Easy phi" uses (used?) USB for data. I've still got some flyer for it, but the website has disappeared. There is still some stuff on github though.
https://hackaday.com/2013/10/22/easy-phi-an-open-source-platform-for-experimenters/


Yokogawa "scopecorder" has a lot of nice small modules, but I am not sure what the electrical interface is.

And and about standards... When going Ethernet, a logical step is:
https://en.wikipedia.org/wiki/LAN_eXtensions_for_Instrumentation
Most "modern" ethernet standards use separate Rx and Tx channels, and that does not work well if you want to connect several nodes over a backplane. But there is also 10Base-T1 which uses half-duplex over a single wire pair, but I have not looked into what extra hardware you need for each node to get that working.

"CompactRIO" is yet another one with nice small modules Looks like it uses VGA connectors (15 pin 3 row DB)

My own preference would be to look at datasheets of some microcontrollers, and then see what sort of other serial busses they support natively. I2S could be useful, but I also already mentioned SPI, and that also goes up to high baudrates, and I think it can be made to work in a multi-master mode with some effort, or you could strictly adhere to a master and slave(s) topology.

I'm afraid this post has become a bit of a mess. I'am a bit fuzzy at the moment.

[ZGoode]

This reminds me of the old VME chassis.
A 1U VME chassis with the backplane and power modules already for cards.

 

Pin assignments attached (3 rows of 32 pins):

I don't know if any of these are still available.

It's funny that you mention VME since I was originally considering that route since I already have a fair amount of VME/VXI C-size equipment, but that standard is just way too complicated for what I am doing here.  The backplane here is mainly just power and diagnostics, with all the cards mainly just operating on their own.  I have a variety of things I wanted to have connected to a UPS, so by putting them all in one enclosure I could just have it as an all in one solution instead of having a stack of things connected to a couple of UPS's

It looks like ZGoode and I are quite far apart in what we want to build. Mayor goals for me are low cost and as universal as possible, while ZGoode is more geared towards easy to use modules with more specific uses in mind.

I don't like putting an EUR10 connector in the thing, It's probably a good connector, but data is low current and does not need 6A. I rather have a higher density connector, and then parallel connections only when needed. 40 pin headers are < EUR3 from digikey and pennies and cents from aliexpress. The cheap ones have bad plating, that may be acceptable for low insertion counts or prototypes or just hobby experiments. for more "professional" applications, better quality is probably worth it.

I wonder about the problems you had with CAN. Shitty wiring or a missing termination resistor can wreck such a bus. Faulty setup for CAN controllers in a uC or a defective node can also create plenty of headaches.

I started with UART and RS485 drivers long (15+ years) ago, and it works pretty well, but you have no collision detection. As soon as there is more then a few meter of cable in between nodes, then each node read's it's own data without faults, even when sending at the same time.

My main turnoff for CAN is it's weird addressing scheme, and it's very short data payload. But apart from that there are a bunch of advantages of using CAN transceivers with a UART.

• No need for data direction control.
• Dominant and recessive states allow for collision detection.
• CAN transceivers with built in galvanic isolation are readily available.

Galvanic isolation can be done with some optocouplers, or digital isolators such as in the ADUM series. Or at least with CAN, integrated into the transceiver itself.

The "cheapest" galvanic isolation is with optocouplers on an Uart, combined with passive pullups on the bus side. Such a simple setup is probably pretty limited in bitrate. But if you want galvanic isolation, you also need to isolate the power and that is also going to cost a bit.

Ethernet is indeed also an option, and for things like that, I concluded to make it as an "open frame". Wiring for Ethernet, USB or a separate isolated power supply can then be routed to specific nodes. I like it to keep options open like that.

Yeah, I just kinda want it to work plug and play.  I agree, the connectors are expensive, but I have been burned (figuratively not literally) in the past by using cheap connectors so that's why I am probably going to stick with that Harting one.
CAN was just obnoxious to implement in what we were doing with too much overhead and wasn't super reliable.  I mean it didn't help I was not super familiar with it at the time, but yeah it was not a fun time.  RS485 or something similar seems much more desirable to me given I don't need high data throughput and it is much easier to implement.  The nodes also won't be more than 100mm or so apart at the most with a total length probably shorter than 1M for the whole chain.  As far as isolation, I have a ton of chips from the ADUM family, so I probably have something in my hoard that should work.  Although I did find a fun little chip on LCSC for RS485 galvanic isolation as well as driving.

[MarkF]

It's funny that you mention VME since I was originally considering that route since I already have a fair amount of VME/VXI C-size equipment, but that standard is just way too complicated for what I am doing here.  The backplane here is mainly just power and diagnostics, with all the cards mainly just operating on their own.  I have a variety of things I wanted to have connected to a UPS, so by putting them all in one enclosure I could just have it as an all in one solution instead of having a stack of things connected to a couple of UPS's

I'm not suggesting that you use the VME standard.  I would recommend you don't use it.
An empty VME chassis and backplane would check a lot of boxes for your hardware interconnections.

Just the backplane with bus connections already routed would save a lot of development.  It gives you address and data buses, control/handshaking lines, power distribution, and 64 unassigned pins.  If you could find a chassis, it would give you some of your power (5V and 12V) needs, cooling fans and the mechanism for making external connections.  You just need to map the interconnections on the backplane to the drawing you posted. 

The last time I looked, the edge connectors are getting hard to find though.

[nctnico]

I've made some changes to the pinout of the card.  More GND and also spread it out.  Added +/-24V.  Having two of each power pin is probably more than overkill since this connector is rated for 6A at each pin according to the datasheet.  Particularly since this will be battery backed up, I can't imagine I'll be making any modules for it that take more than 1 or 2 amps at any of the power lines.
As far as communication, I'm thinking of going with the CA-IS3082W for isolated RS485 on each module since it behaves similarly-ish to UART so it shouldn't be too much different to implement

Skip the earth connections and use them as ground. Don't have ground and earth seperated as they are the same thing. Put extra ground pins near digital signals. If you value precission, then make sure to pair the 1PPS with a ground connection. Treat 1PPS as a high frequency signal as the edges are the most important thing where it comes to timing precission. I'd move the I2C bus away from power and synchronisation signals. If you use a connector with 3 rows, you can have the middle row as ground and leave some pins to serve as slot-ID bits.

[ZGoode]

On signal handling: I wonder if it’s acceptable to distribute a 10 MHz reference clock using Multidrop M-LVDS? (Differential scheme)

For distribution of a PPS source what do think might be best?  TTL pulse or some kind of differential signaling?  LVDS (or something similar) sounds great for a higher frequency like 10MHz, but with the PPS being extremely low frequency (1Hz), I'm not sure if LVDS is the best here.  My thought was to have one main GPS source providing a PPS signal to a few different oscillators.

Skip the earth connections and use them as ground. Don't have ground and earth seperated as they are the same thing. Put extra ground pins near digital signals. If you value precission, then make sure to pair the 1PPS with a ground connection. Treat 1PPS as a high frequency signal as the edges are the most important thing where it comes to timing precission. I'd move the I2C bus away from power and synchronisation signals. If you use a connector with 3 rows, you can have the middle row as ground and leave some pins to serve as slot-ID bits.

Yeah, good point, I'm probably going to switch to a 3 row connector so I can have the outer rows be GND, at least near sensitive signals such as PPS or other analog signals.

[Doctorandus_P]

I am also not so sure about the 10MHz and the PPS.

When used on itself, PPS is a high speed signal because it needs well defined flanks. On further thought, If you already have a 10MHz sync / reference, then you can lower the quality requirements form the PPS signal if you define it as "sync on the next 10MHz flank". And going further on this, I am leaning into the direction of using a simple logic output from a timer on a uC, and then also make it programmable, so you also can use it as a reference to synchronize sampling on any other frequency that the timer can be made to output.

How useful is it to keep the 1PPS, and add a third (or even more) signals for synchronization?
As an alternative Idea, you could use amplitude modulation on the 10MHz signal if you want to save a pin on your connector.

I just don't have enough experience to make a decent decision here.