EEZ Bench Box 3 (BB3)

[AlanS]

This is looking great; if it was good enough for HP to have stackable cases for the HP3497/98; it's good enough for me. Imagine - setting up a test condition, powering it up, characterising the results, recording and displaying them all from the one(2) box. Fantastic.

Looking forward to the simultaneous 16/24 bit sampling unit too. We may need the capability to go >48V? Is that where the electric car market is going?

[danielbriggs]

The question is what to do with analog outputs, especially if we want to support all the levels mentioned above. I've found one possibly interesting solution from Maxim, MAX155000 that is advertised as "output conditioner" and provides a programmable current up to ±24mA, or a voltage up to ±12V proportional to a control voltage signal. The control voltage is supplied by an external DAC (2.5 or 4.096 V FS). The MAX155000 solution cannot be cheap because of its price and that it requires DAC (and Vref). Perhaps more flexible solution and little bit cheaper could be using four of single channel DAC7760 or one quad channel DAC7716 with some extra circuits.
Your input is welcome.

I really like using AD5752R (16-bit software programmable bi-polar with integrated reference) with success on some projects.
Also pin compatible with the 14+12-bit versions AD5732R / AD5722R if you need to save a little £ and don't need all the bits.
Also available without the built in reference, but the AD5752R is perfect for my uses + worth the extra cost.

[prasimix]

Thanks for suggestion. The AD5722R looks nice except it's not cheap. I'll try in the first run to use DAC7563 instead for the first two analog outputs. It also has internal reference, but lacks bipolar output. That can be resolved with additional op-amp on the output. For another two analog outputs I'll use DAC7760. It offers both current and voltage outputs. The good thing about both devices is that they have a 16-bit counterparts if someone need higher resolution.

[prasimix]

Looking forward to the simultaneous 16/24 bit sampling unit too. We may need the capability to go >48V? Is that where the electric car market is going?

Yes, I was thinking about up to 100 V on the input. Talking about electric cars, it seems that powertrain battery could go up to 800 V

[jbb]

Yeah, electric vehicles are going up. I think a many run at 400V (ish), with higher voltages like 800v for higher performance.

I wouldn’t be surprised to see 1300V or even +-750V come in for heavier vehicles.

I would be nervous about making test gear for EV applications as these systems could have very high energy faults (remember DC arcs are hard to extinguish).

[rstofer]

If EVs don't use higher voltages, the current gets insane.  The Chevy Bolt has a 149 kW motor.  I don't know the voltage but I suspect it is on the order of 400 volts so the current will be on the order of 370 Amps.  That's a lot of current!  They certainly wouldn't want to use something like 100V and 1500 Amps.

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

I have had mine for 3 years and I like it a lot.

[AlanS]

It seems that every time I have to work on auto-electrics, the laws of physics get broken - because half the readings don't seem to make sense. 

Re the upper limit, maybe another of your famous (and worthwhile polls). 48V would do me (which probably means 60).

[Andrew McNamara]

If EVs don't use higher voltages, the current gets insane.  The Chevy Bolt has a 149 kW motor.  I don't know the voltage but I suspect it is on the order of 400 volts so the current will be on the order of 370 Amps.  That's a lot of current!  They certainly wouldn't want to use something like 100V and 1500 Amps.
[...]
I have had mine for 3 years and I like it a lot.

You might like this dissection of a Bolt battery pack by Weber State University's John D. Kelly:

[prasimix]

We made some real progress regarding fusion of BB3 and ULX3S. Goran from radiona.org (from ULX3S team) made a PCB (available on the GitHub) where RGB output from BB3's STM32F7 MCU is serialized into LVDS from one side, and FPGA video output (LVDS) is deserialized into RGB output to drive directly TFT display. Therefore we can swap between "slow" content (GUI/HMI) and fast content that can be generated directly from FPGA (e.g. data logging, scope, etc.).
In this way we don't need to get rid from "legacy" code written for STM32 and have fast processing on board (Lattice ECP5).
Next step is to try to synchronize video outputs from STM32 with ECP5 that we can combine "slow" and "fast" (e.g. ScopeIO) content on the same screen!

[AlanS]

if the BB3 gets any smarter I'll have to move it to the server room. 

[prasimix]

I've finished another module for BB3 this time for mixed I/Os (MIO168). I'd like to thanks once again to @jbb for assistance and few great suggestions. My idea was to have module that could accept low-voltage (3.3/5 V) and industrial voltages/levels. Therefore digital inputs should withstand at least 24 V. Digital outputs are low-side and could drive load connected to up to 60 V. Analog inputs are bipolar and could be voltage (up to +/-10 V) or current (0-24 mA). Analog outputs are also bipolar (+/-10 V) and two channels supports both voltage and current outputs.
Instead of isolating inputs and outputs, a whole module is "floating" and power rails are isolated using 2 W off-the-shelf DC-DC converter. I'll test two different model from TRACO and Mean Well, both with and without LDOs for +/-12 V rails (+5 V and 3.3 V LDOs are mandatory).
Analog input in current mode is accomplished by applying burden resistor that comes with current limiter. Input mode is selected with analog switches DG468 that can withstand over +/-12 V when powered with +/-15 V.
Selected MCU is probably overkill, maybe not, but can drive SDRAM if necessary, and I've already added place for optional micro SD Card just for testing (BB3 MCU module has micro SD Card).

Quick facts

• 2 x 16-pin dual row 3.81 mm I/O connectors
• 8 x protected digital inputs (3.3/5/24 V), 2 x fast/slow, 6 x slow
• 8 x digital outputs (4 x low-side, dual channel smart switch BTS3408G) with multiple protections and FAULT detection, 550 mA per channel (current limit 1 A)
• 2 x PWM outputs, protected
• 4 x analog bipolar inputs with protection. Voltage or current selection per channel. 14-bit ADC, max. 500 KSPS (ADS8674), replaceable with pin compatible 12- or 16-bit version. Switchable bias for NTC sensors on first two channels
• 2 x analog bipolar outputs (+/-5 V, +/-10 V, 0-5 V, 0-10 V). Voltage or current output with protection. 12-bit DAC (DAC7760), replaceable with pin compatible 14- or 16-bit version
• 2 x analog bipolar outputs +/-10 V (DAC7563)
• On-board isolated +/-15 V (2W) power supply with +/-12 V, +5 V and +3.3 V LDOs
• STM32F446 MCU
• Firmware download via SPI
• Optional SWD for debugging
• Optional Micro SD card
• I2C EEPROM for storing board specific parameters
• Dimensions: 146 x 95 mm, 2-layer PCB

Source files on the github: https://github.com/eez-open/dib-mio168
Schematics are in the attachment.
I've used 4-layer PCB this time. Your comments and suggestions are welcome.

[danielbriggs]

Brilliant work.

One very minor point:
Is there a reason for having 2x different types of analog out functionality?
It would be (albeit slightly selfish for what I want to do) great if all analog outputs could be of the first type (DAC7760) to give a total of 4x 0-5V analog outs. Or is there good reasoning to have 2x of each type?

Keep up the good work.
Dan

[exe]

I see pads are not just plain areas of copper, they look to be segmented. What advantage does this give and how is this done? With solder mask?

[prasimix]

Is there a reason for having 2x different types of analog out functionality?
It would be (albeit slightly selfish for what I want to do) great if all analog outputs could be of the first type (DAC7760) to give a total of 4x 0-5V analog outs. Or is there good reasoning to have 2x of each type?

I've put two types for testing purposes, and DAC7563 is selected because of its price. Originally comes with unipolar voltage output it is still cheaper with added extra op-amps for Vref/2 and bipolar output. It shouldn't be a problem to put four DAC7760 (or even its 16-bit counterpart) if someone find a good "use case".

[prasimix]

I see pads are not just plain areas of copper, they look to be segmented. What advantage does this give and how is this done? With solder mask?

I believe that started to happen to OSHpark previews when I made changes in corner "roundness" in Eagle (or something similar, I cannot remember), if you're talking about "artifacts" shown below, but that is not visible on the manufactured PCB.

[jbb]

Thanks

Let’s hope people like it.

I’ve been wanting to have a play with Peltier coolers, and the combo of some analog IO with a programmable DC supply is very promising. Just the sort of thing that modular test gear should be good for.

I don’t have time to do a big review, but noticed a couple of things:
- there should probably be a high value high voltage resistor across the GND to PE capacitor (eg 1 Meg 1kV or similar series string). This is to discharge accumulated potential (eg from ESD strikes)
- the input protection components should be placed as close to the connectors as reasonably possible (it looks like there will be competition between the various pins
- some components are really close to the main connector and could be hard to repair
- the ground traces on input protection should be nice and wide to conduct high frequency ESD energy (or use ground plane)
- the protective earth connection seems to be a long way from the plugs. Is this for cable routing reasons?
- you’ve got the option for common mode chokes on the isolated +-15V supply. I don’t think using two common mode chokes like that will be very effective. A three-winding choke is probably better. Or place it on the power input side where there are only 2 lines.
- LDOs May get hot. You could consider a buck converter for the 3.3V if the STM22 draws lots of current
- you might want a little series resistance on the PWM outputs in case of short circuits

[prasimix]

I don’t have time to do a big review, but noticed a couple of things:
- there should probably be a high value high voltage resistor across the GND to PE capacitor (eg 1 Meg 1kV or similar series string). This is to discharge accumulated potential (eg from ESD strikes)

Good point, I'll add 2 x 470K 1206 in parallel with C97 (4n7 1812).

- the input protection components should be placed as close to the connectors as reasonably possible (it looks like there will be competition between the various pins
- some components are really close to the main connector and could be hard to repair

Yes, I tried to place protection component close to the connectors, and without using both sides of the PCB. Therefore some compromise was needed, and I decided to place digital inputs after analog inputs and use bottom layer for traces to that section.
Protection components for remaining sections are close to the connectors and could be problematic to service them with hot air, but shouldn't be an issue in two soldering irons are used .

- the ground traces on input protection should be nice and wide to conduct high frequency ESD energy (or use ground plane)

PCB is 4-layer and second layer is dedicated ground plane. Do you suggest additional ground plane on other layer?

- the protective earth connection seems to be a long way from the plugs. Is this for cable routing reasons?

Yes, all cables are cut to size with presumption that input connectors are on the far right side of the PCB.

- you’ve got the option for common mode chokes on the isolated +-15V supply. I don’t think using two common mode chokes like that will be very effective. A three-winding choke is probably better. Or place it on the power input side where there are only 2 lines.

I have used "off-the-shelf" tiny (0805) CM chokes, that was the easiest way but probably not so effective. I have to find out if small 3-winding choke exists.

- LDOs May get hot. You could consider a buck converter for the 3.3V if the STM22 draws lots of current

3.3V LDO shouldn't be a problem, ST power calculator estimates no more then 55 mA in worst case scenario. The 5V LDO is under more stress stepping down from 12 V, but still, that shouldn't be a problem even for SOT23-5 package (perhaps I should put more pads on its GND pin?).

- you might want a little series resistance on the PWM outputs in case of short circuits

Ok, how about 47R, or that is too little?

[jbb]

Sorry for delay; it's been a busy few days.

PCB is 4-layer and second layer is dedicated ground plane. Do you suggest additional ground plane on other layer?

Ah, the joys of 4 layer boards.  A good ground plane should do a lot for you.

Suggest you try to get roughly equal areas of copper on each side of the PCB (i.e. top vs bottom, mid1 vs mid2) to reduce the risk of warping.

- you might want a little series resistance on the PWM outputs in case of short circuits

Ok, how about 47R, or that is too little?

Seems like a good first try.  May need to test it a little with sample loads (e.g. 70 cm of coax or twisted pair).  Given you're paralleling output buffers, maybe put 100R on each buffer output?  This will also prevent large current flows if buffer delays don't match exactly.

[prasimix]

I've wanted for a long time to have electrical/electronics calculators next to me on the benchtop when I'm working with electronics. For the same reason why I don't like USB (i.e. PC based) instruments like scope, logic analyzers, etc. I don't like online calculators to find out quickly right resistors value for certain opamp gain, output from voltage divider because I have to move back and forth from one table to another. Other possibility will be to place PC next to my D.U.T. but I don't want that only keyboard occupy a substantial area of already crowded benchtop. MicroPython (MP) scripting starts to changed that and first results are already here. Currently I don't have a time to shot a video about that but few screenshots could help you to get an idea.

First, the BB3 SD card file manager are changed to present files with thumbnails, then when you enter Scripts subfolder, first comment from .py file could be displayed as description, and finally we made a first step toward integration of MP scripting and GUI editing in EEZ Studio. The underlying mechanism is SCPI, and new set of commands was added that MP could interact with custom made pages (created in EEZ Studio).

So far, we have the following calculators available:

• Op-amp (non-inv, inv, differential and diff. simplified)
• Voltage divider
• R/L in parallel and C in series

You can be sure that we will not stop there and that the number of scripts will increase over time

[prasimix]

... and yes, your suggestions are highly welcomed. Just to let you know what is already in the queue:

• RC snubber calculator (based on this method)
• PWM/Square wave generator (within limits of Dout pins on the front panel)
• Ohm law calculator

[danielbriggs]

This is an incredibly good idea, and another reason why I’m so glad I got onboard with this platform. 

[wizard69]

With all the downtime of late I just read through this thread and have to say i'm very impressed.   This is a very useful product that could find use on an advanced hobbyist desk to an Engineers test stand.

One thing I noticed is for people calling for modules a little outside of what one might find suitable for a power supply.   I suspect what many want is a modernized approach to instruments like was seen in the Tektronix TM500/5000 series.    In a way that is what I would like to see come to market.   However a power supply with the capability of delivering this power level would never fit into such a platform.   So I rather like the platform as is and especially like the use of MicroPython.    Even better is that the right type of expansion boards are on the way!

Since everybody envisions a version #2 of a successful product here are some ideas that might be wroth considering for the mainframe:

• Consider a USB-PD port on the mainframe.   You could instrument it or not, my primary interest is in all the devices that need power from these ports.   However I can see how product designers could use an USB-PD port with full reporting of voltage and current usage.
• It would also be nice to have a 5VDC port on the main panel, banana plugs of course.  Nothing fancy here at all, 1-2 amps with no adjust ability.
• Yes it is extra work but the Ethernet port needs to be on the back side of the box
• This one I'm not sure about as it is user interface related but you might consider integrating the user switch into the rotary knob.
• Directly related to the above You might want an M12 receptacle wired in parallel with the user push button.   The would allow for remote pushbutton cords that you can easily buy for pushbutton operation.   A switch like these: http://www.switchcraft.com/productsummary.aspx?Parent=1162, with an M12 connector on the other side.   M12 connectors are heavily used in automation and industry and have the right qualities for something that gets puled on.   Of course cheaper solutions can be used but probably not as convenient or widely used.
• Always make sure there is room for that second fan.   Not ever installation will be on an air conditioned desktop.

That is about the only real suggestions I can offer up for a version 2 maintframe.   IF there are ergonomic issues they will show up in time.

As for your I/O cards, looking at all the comments in one read tonight I think what you might need is a MicroPython based intelligent card.   Possibly a card that sits on top of one of these new relay cards.   The reason I say that is because some of the requests involve I/O and processing that probably wasn't thought about when the project started.   That could be handled by a card with processing capability and some good ole RS232 comms.   Yes RS232 is old but it is still widely used on process controller and the like.  If you can imagine the card would buffer or process data in the middle so to speak.  Say read data from an environmental chamber, process and format for the mainframes controller.    Maybe make control decision on its own.   In an ideal world the mainframe controller would do that itself but apparently you don't have the I/O or didn't expose it.

This has become long winded but it took a good portion of the night to read this thread anyways.

[AlanS]

 
I love it. Now if we can only have the ability for component substitution and test under programme control.

[prasimix]

Thanks for your feedback, more comments below ...

Since everybody envisions a version #2 of a successful product here are some ideas that might be wroth considering for the mainframe:
Consider a USB-PD port on the mainframe.   You could instrument it or not, my primary interest is in all the devices that need power from these ports.   However I can see how product designers could use an USB-PD port with full reporting of voltage and current usage.

Ok, that sounds like a valid idea, its connector could take the place on the front panel where the Ethernet jack was previously (see below). Quite another thing is how to accomplish "power source/drain" section and where to place it.

It would also be nice to have a 5VDC port on the main panel, banana plugs of course.  Nothing fancy here at all, 1-2 amps with no adjust ability.

Hm, that is not so simple, especially if you'd like a properly spaced banana plugs that take a lot of space. Other possible issue for some people could be isolated/floated output that offers currently available power modules (DCP405 and DCM220). A whole idea about DCM220 module is to provide two AUX outputs. Perhaps a too expensive approach .

Yes it is extra work but the Ethernet port needs to be on the back side of the box

That is already done as part of crowdfunding campaign stretch goal. New front and rear panel can be seen in the picture here.

This one I'm not sure about as it is user interface related but you might consider integrating the user switch into the rotary knob.

Rotary knob/encoder already comes with switch that is used for "confirmation" mode. User switch provides quick access to few extra functions.

Directly related to the above You might want an M12 receptacle wired in parallel with the user push button.   The would allow for remote pushbutton cords that you can easily buy for pushbutton operation.   A switch like these: http://www.switchcraft.com/productsummary.aspx?Parent=1162, with an M12 connector on the other side.   M12 connectors are heavily used in automation and industry and have the right qualities for something that gets puled on.   Of course cheaper solutions can be used but probably not as convenient or widely used.

For remote control you have SCPI commands that can be send via USB or Ethernet. I'm fan of foot pedal because it leaves both hands free, but yes, why not also use mentioned push button cord. You can wire it to one of digital inputs on the front panel right now.

Always make sure there is room for that second fan.   Not ever installation will be on an air conditioned desktop.

There is a room for second fan. The first prototype of rear panel had a second hole, but I gave up because only one was enough.

That is about the only real suggestions I can offer up for a version 2 maintframe.   IF there are ergonomic issues they will show up in time.

As for your I/O cards, looking at all the comments in one read tonight I think what you might need is a MicroPython based intelligent card.   Possibly a card that sits on top of one of these new relay cards.   The reason I say that is because some of the requests involve I/O and processing that probably wasn't thought about when the project started.   That could be handled by a card with processing capability and some good ole RS232 comms.   Yes RS232 is old but it is still widely used on process controller and the like.  If you can imagine the card would buffer or process data in the middle so to speak.  Say read data from an environmental chamber, process and format for the mainframes controller.    Maybe make control decision on its own.   In an ideal world the mainframe controller would do that itself but apparently you don't have the I/O or didn't expose it.

This has become long winded but it took a good portion of the night to read this thread anyways.

Since MicroPython is already "on board" everything inserted into the "mainframe" will be MicroPython enabled. Announced MIO168 module is no exception. The same goes for the remote control of its resources using SCPI and MQTT.

Regarding "mainframe version 2": what will happen in the future will be directly connected and affected with destiny of "version 1" that I have first to deliver to crowdfunding campaign backers and try to establish sales channels that could generate enough revenue to keep us alive. Looks like this year will be decisive for us and many others.

[prasimix]

I love it. Now if we can only have the ability for component substitution and test under programme control.

Thanks Alan, could you be more specific about component substitution?