EEZ Bench Box 3 (BB3)

[AlanS]

The curve tracer software is wonderful! Updating the display on the fly - even better!

[prasimix]

Nice! Should be applicable to other devices too (MOSFETs etc.). Seeing a video demo also shows the value of the nice big touch screen .

At risk of being a little picky - I know you’re busy! - it would be really cool if the last couple of seconds of the video were a screen grab (or close up photo of whatever) of the curves to show what you got.

Yes, it is applicable, check new video: https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/msg2856622/#msg2856622

And now on another subject; it looks like you might make your stretch goal.  If you do move the Ethernet and USB ports, would that free up a little room on the front of the master control board? If so, I think moving the boot mode switch from the aux power board to the master control board would be nice; those traces went quite close to the main power switch and were making me nervous.

Thanks for suggestion, I'll definitely take that into account (added in GitHub as #62) if we're going to implement changes on front panel as required for stretch goal.

[Sabrosa]

The curve tracer functionality looks awesome and could potentially replace the PC connected unit I currently have. Is there any reason why the BB3 couldn't support P-channel transistor tracing in the future, or negative voltages (even if you just swap the polarity manually on the breadboard)?

[prasimix]

No, there is no reason. For N-ch/NPN we are using "common ground" coupling. For P-ch/PNP you cannot use it, but Ch1 and Ch2 Vout+ has to be connected with external wire. We'll include P-ch/PNP version soon.

[AlanS]

No, there is no reason. For N-ch/NPN we are using "common ground" coupling. For P-ch/PNP you cannot use it, but Ch1 and Ch2 Vout+ has to be connected with external wire. We'll include P-ch/PNP version soon.

Hmmm. I wonder how easy it is to display a connection diagram on screen as you set up the connections for the DUT. This may be useful as we head to new modules - especially if they interact with each other.

[prasimix]

That's a valid idea. Displaying a picture with wiring details is not a problem at all. I'll add that to Martin's todo list 

[danielbriggs]

Wohoo! $100k! Congratulations.

So where does this leave the USB / Ethernet? 

USB: Front + Rear?
Ethernet: Rear only?

[prasimix]

Follow this link please: https://twitter.com/envox/status/1214314436359532544

[danielbriggs]

Follow this link please: https://twitter.com/envox/status/1214314436359532544

I don't have Twitter so can't vote.

My vote is:
If it's USB Host / mass storage [USB on front, Ethernet on rear]
If it's USB Device to plug into a PC [Both USB and Ethernet on rear]

[fuzzoli]

...no Twittering here either.  I second Daniel's vote:

  If USB Host / mass storage -> USB on front, Ethernet on rear
  If USB Device to plug into a PC -> Both USB and Ethernet on rear

Congratulations, Denis & Martin!

[jbb]

Ditto for me
(Note: just moving one port will reduce design risk, and I suggest that be the Ethernet port.)

[jhenderson0107]

Ditto for me. 

[Sabrosa]

No, there is no reason. For N-ch/NPN we are using "common ground" coupling. For P-ch/PNP you cannot use it, but Ch1 and Ch2 Vout+ has to be connected with external wire. We'll include P-ch/PNP version soon.

This is excellent, thanks prasimix. I've been using my curve tracer to match transistors for Vgs and transconductance, so the transfer curve script is very interesting to me. In my ideal world you'd be able to set the constant Vds and sweep range for Vgs either positive or negative, to allow for testing depletion-mode devices. Excited to see how the script capabilities continue to develop. There's lots of interesting matching automation that could be done with Python!

I was also curious to get your opinion on whether those of us who ordered the two channel 'full' kit should consider adding a DCM220 before the campaign ends tomorrow. Will this module continue to be available afterwards? I don't have a specific use in mind for it currently, but am trying to decide whether to get one now if it won't be available, or save the space for future modules.

Thanks again for all the time and effort you've put into the design and campaign!

[prasimix]

I was also curious to get your opinion on whether those of us who ordered the two channel 'full' kit should consider adding a DCM220 before the campaign ends tomorrow. Will this module continue to be available afterwards?

Yes, it will be available afterwards.

[mcdanlj]

My vote is:
If it's USB Host / mass storage [USB on front, Ethernet on rear]
If it's USB Device to plug into a PC [Both USB and Ethernet on rear]

I did vote on twitter for USB on front, Ethernet on rear, but this from @danielbriggs makes even more sense. I was assuming USB mass storage was a supported mode when I voted for front/back instead of back/back.

[prasimix]

Who told you that host/device mode is not supported? Actually, we still need to do some job for host mode that will allows us to communicate with e.g. keyboard, keypad or USB foot pedal. The same is valid for mass storage. I'm not sure about possible performance of mass storage and is it possible to have acceptable performance without jeopardizing the rest of the system. Therefore if mass storage is the only reason why USB should be on the front panel, then I'd prefer to move USB to the rear, too.

[prasimix]

Thanks Denis for the detailed reply; all sounds really promising.

What does the digital I/O on the front panel currently do?
Would it be easy enough to allow the units to trigger each others "outputs enable / disable" from the state of the digital IO?

If this is, then I'd almost certainly be up to backing a 2nd unit. [Not pressuring you, just would be personally useful to me if I can turn on 6-8 outputs at once].

All the best,
Dan

Hi Dan, just to let you know that I find some time today to test this. Wiring is quite simple:



On "master" chassis (upper one) Dout2 has to be defined like this:



... and on "slave" chassis Din1 is defined like this:



I also defined on "master" User SW as Inhibit that gives me control of all power outputs at both chassis:

[danielbriggs]

This is excellent! Many thanks for taking the time to demonstrate that small (but important to me) feature.

Roll on March (or whenever they ship) 

[prasimix]

I've found time to design two new peripheral modules so far. They are very simple: one features 6 power relays (name: PREL6) and another 4 x 6 switch matrix made with signal relays (name: SMX46). Both modules have two thing in common: connector on their front panel (see below) and entry-level on-board MCU.



The connector is 16-pin dual row 3.81 mm and two of them is possible to mount on the module's front panel. Sockets with various number of pins (8-pin push-in type is shown on the picture) can be used and they could be of push-in type, with screws, etc. Few manufactures has it in offering like WE and Weidmueller and cheaper versions are available on Alibaba, etc.

Functionality of both modules are trivial and control could be easily accomplished with I/O expander parts such as MCP23S08 or MCP23S17. But I found that entry-level STM32F030 MCU is in the same price range and offers more freedom in programming and has extra features (e.g. PWM generation). Since on-board firmware downloading procedure completely automated on the BB3 (i.e. few clicks and master MCU will do it for you) there is no reason what not use MCU instead of I/O expander.

PREL6
Quick facts

• 4 x SPDT relays, max. 8 A / 230 Vac
• 2 x SPST relays, max. 8 A / 230 Vac
• On-board +3.3 V LDO
• STM32F030 MCU
• Firmware download via UART
• Optional SWD for debugging
• 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-prel6
Schematics are in the attachment.

SMX46
Quick facts

• 24 x SPDT relays, max. 2 A
• 1 x power relay, max. 8 A / 230 Vac
• 2 x DAC output 0 - 10 V
• On-board +3.3 V LDO
• STM32F030 MCU
• Firmware download via UART
• Optional SWD for debugging
• 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-smx46
Schematics are in the attachment.

The SMX46 module also includes one power relay and two analog outputs derived from PWM generated by the on-board MCU.
Both modules will be programmed from local TFT touchscreen display or remotely with new set of SCPI commands that we have to add. They will be also accessible via MQTT.
Your comments are welcome as usual.

[jbb]

Relays for everyone!

A relay mux is a classic part, so I’m sure some people will want one.
- great to see its differential
- maybe there should be provision for marshalling rails inside the BB3 case?

On the power relays:
- good to see MOVs
- remember to note that DC switching ratings are much lower than AC
- I expect someone will try to switch mains with it, so you’ll need all the clearance you can get between the power and relay drive lines. (I think IEC 60950 likes 3.5mm creepage, but I’m not sure)
- to make some room in the congested zone, maybe you could move the drive transistors and catch diodes away from the relays?


On relay cards in general:
- it would be nice if the microcontroller kept a cycle count for each relay
- you can never cover all use cases, so having an easy open-source design template could be very useful for someone who needs to roll their own custom card

[prasimix]

Many thanks for suggestions. Catch diodes are already away 4.5 mm from the relay power inputs, and I moved Q4 and Q5 away to increase clearance over 3.5 mm. New revision is committed on the GitHub.

Cycle count for each relay will be stored on the EEPROM locally together with total and last working hours.

[prasimix]

The next module that I'd like to make is mixed I/O. Selected front panel connectors (2 x 16 pins) allow e.g. 8 digital inputs and outputs, and 4 analog inputs and 2 or 4 outputs. Question is what voltage (and current?) levels to offer? So far I've found that other manufactures usually offer industrial/PLC levels:

• Digital inputs: Voltage: +24 V for hi level (usually with wide margin and hysteresis), Current: 0-20 or 4-20 mA
• Digital outputs: 500 mA output hi-side or low-side with various protections, usually resistant to over +40 V
• Analog inputs: 0-10 or +/-10 V, 0-20 or 4-20 mA
• Analog outputs: same as above.

I/Os should be isolated from MCU. I found that e.g. Silabs Si838x could be a good candidate for 8 isolated digital inputs. For isolated digital outputs I'd like to use ST ISO8200B or Infineon ISO1H811G.
I'm still searching for suitable analog I/O solution and currently looking for DAC. I believe that, for the start, 12-bit will be enough (I'd like to deploy multichannel 16/24-bit on the other module, simultaneous sampling, etc. but that is another story). 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.

[danielbriggs]

Denis,
Just thinking ahead: how is the BB3 suited to quickly reconfiguring modules?
i.e. obviously not hot-swap, but made me think with all new module designs on the horizon, if I have a full chassis, say I need to pull out the dual output module and pop in a DIO card for a project for a day or two... it's not a big job to reconfigure / hassle to swap a module software-wise?

Thanks,
Dan

[prasimix]

Firmware already automatically recognize all supported modules in any combination and locations. For example you can swap DCP405 and DCM220 between slot #2 and #3 and that change will be reflected on the display and firmware will even try to match modules params saved in user profile despite the fact that channel type are changed. Additionally all module specific params such as activity counters and calibration cannot be compromised with such change since that params are stored on their on-board EEPROMs.

The arrival of new modules raises the question of BB3 capacity. I've already mentioned that one of possibility is to make an chassis with same footprint (to be "stackable") as BB3 but without display. Such chassis should host up to 7 modules that don't require AC/DC converter as power modules. Inter-chassis communication for start could be over Ethernet where BB3 (with display) can detect other chassis and become their master. Such chassis will be accessible remotely over Ethernet (SCPI/Telnet and MQTT).

[danielbriggs]

Thanks Denis,
That's really promising, and long term would love to extend my involvement within this ecosystem, by buying new modules to suit projects to hand + hopefully developing my own modules for specific tasks if time allows.

I think for the next few months though, using the 2x I've bought as fully loaded PSU's would be tremendous.  But good to know the roadmap of the system as it develops + looks like it's got a great future with enough support behind it.

All the best,
Dan