DIY Modular Test Equipment Project

[Leo Bodnar]

If you are designing your own modular instrumentation project you might find this http://www.easy-phi.ch/ interesting.
Leo

[void_error]

Prasimix has an idea like that. I did mention in a previous post that my version of modular is not going to have everything in the same enclosure and try to keep the costs down, although you could combine some of them. It's not going to be rackmount either.

[void_error]

A simple solution to this is to use a window comparator circuit (LM393) for each rail and some P-channel MOSFETs paired with a delay circuit (CMOS 555 or some monostable using logic gates) and a cheap voltage reference (TL431 or LMV431).

Turns out that it's not going to be so simple so I'll just use an undervoltage lockout comparator for each rail, OR them together, some TVS diodes for overvoltage protection and rely on the polyfuses at the linear regulators' inputs to limit the current. The reference for the UVLO comparator is  going to be a TL431. Output disconnect will still be done using MOSFETs.

[void_error]

After more than enough stupid ideas I managed to come up with a circuit that seems to work. You can find a crude mock-up of it below (http://falstad.com/circuit/circuitjs.html - File > Import From Local File). It's neither built up to scale (component values are subject to change) nor painted (no part numbers). Used a simple zener based series regulator instead of an LM317 just because it'll do for the simulation.

Time to see how I can add most the same to a negative rail. After that I'll draw it in LTspice and 'virtually' abuse it some more then breadboard it at some point.

Yes, I know, it's overkill.

[void_error]

It's now time for a design goal (or feature?) update for each of the pieces of test equipment, it's the stuff on the first page.

Someone mentioned a useful feature would be to turn two channels of a bench power supply on at the same time here so I went ahead and opened my KiCad project for my bench supply to see if it was possible and it apparently is but more on that after I polish the schematic a little bit, I think it's lacking a few details at this point, like component values and associated footprints, maybe I should make a new component library for passive components with footprints associated instead of the standard generic resistor/capacitor ones which need to be linked to footprints manually since I have quite a few different size passives... anyway, since I'm using 595 shift registers for SPI addressing and the DACs used to set the voltage and current only have the clock input (SCLK) and the data input (MOSI) pins tied to the SPI bus they can be updated at exactly the same time given the output voltages are the same which is not that useful so I'll either have to find a DAC with a Latch DAC pin or find another way to make the DAC outputs rise at roughly the same time with the latter being an easier task as I already settled on some specific parts (see first page).

Another idea I've been messing around with is completely ditching the on-board fan control circuit on each of the PSU channel. The new location will be the aux digital supply board since that will be used by the DC load modules anyway, which are now going to be 200W or lower, depending on the power MOSFETs' type and number of devices used. An extra connector will be required. In the case of the bench power supply the aux digital board's fan control circuitry will drive one fan for both channels.

Also, sorry for not posting in a while, I thought I'd get enough stuff done first.

[prasimix]

[reserved for future use]

Maybe it's time to think about data acquisition module, for beginning a modest one for e.g. multiple/multiplexed channels temp sensor logging and slow changing signals. The same module could also include few buffered PWM and/or DAC outputs and multiple protected/buffered Digital I/O.

[void_error]

That has been thought of, although I haven't mentioned it anywhere. I could add that to a third power supply channel (the 0-5.5V one for powering digital circuits). An ethernet connectivity module is also planned.

Right now I'm standardizing the 595+SPI addressing across the three modules I'm currently working on. I've also been thinking about a way to identify the location of each module on the bus without changing things too much or using an EEPROM which will have to be written to before assembly and I have a possible solution which is going to fit the current bus architecture.

Since the addressing and multiplexing of different functions on a module is based on daisy-chained 595 shift registers it appears to be simply adding a 74HC165 with its inputs tied to either the positive or negative supply like the address pins for I2C chips (see PCF8574 or similar). One of the  pins will be used to indicate whether it's the last module in the chain. The firmware on main MCU will know how many bytes it needs to shift through the 595s and the location of each module regardless of the the order based on the definitions of each module programmed in. I'll need to modify the communications bus a little bit to accommodate an input from the shift register side or switch back to the initial idea to switch between MCU SPI connected to the shift registers or to the SPI slave devices outside the MCU which will free a few lines on the bus.

I must admit I was too slow to reserve posts for future use as the replies started coming in too fast when I started this topic...

Another module will be the front panel for the PSU / Electronic load which will also use 595s for the different functions it'll provide like channels in series/parallel or whatever else comes to mind. Or I might put the digital I/O and temp sensor inputs in there...

[void_error]

Since the addressing and multiplexing of different functions on a module is based on daisy-chained 595 shift registers it appears to be simply adding a 74HC165 with its inputs tied to either the positive or negative supply like the address pins for I2C chips (see PCF8574 or similar). One of the  pins will be used to indicate whether it's the last module in the chain. The firmware on main MCU will know how many bytes it needs to shift through the 595s and the location of each module regardless of the the order based on the definitions of each module programmed in. I'll need to modify the communications bus a little bit to accommodate an input from the shift register side or switch back to the initial idea to switch between MCU SPI connected to the shift registers or to the SPI slave devices outside the MCU which will free a few lines on the bus.

Ended up using a 74HC166 with a D type flip flop connected to the data output (pin 13) to make it compatible with one of the SPI modes, using the SH/~LD pin (15) as Chip Select and an extra AND gate to gate the clock of the flip flop (one input goes to SH/~LD, the other one to SCLK, output to flip flop CLK) and a tri-state buffer tied to the Q output of the flip flop, enabled by a low chip select signal. The whole thing end up as a SPI General Purpose Input expander and it's cheaper than say, a MCP23S08 8-bit GPIO expander, by a factor of two or more.

[prasimix]

The whole thing end up as a SPI General Purpose Input expander and it's cheaper than say, a MCP23S08 8-bit GPIO expander, by a factor of two or more.

That is not a real saving when MCP23S08 is around $1. On the other side you're decided to use not so cheap ADC and DAC for e.g. Power supply and electronic load. Also when you are thinking about savings, that is fine, take into account that one component even more expensive then few used as its substitute could cost less at then end (if you or anyone else want to organize production, because assembly line "time is money").

[void_error]

But on the other hand you can pair the read of the expander configured in this way with something that only uses the MOSI line like a DAC. Since I only need to read inputs a fully featured GPIO expander seemed overkill and it also has some communication overhead for configuring, making it slower. The read can also be paired with a DAC write if the DAC only uses the MOSI line and the same SPI mode.

You're right about assembly line time, but I'm not going straight for production-readiness with the first revision.

[void_error]

After spinning around in circles looking for suitable DACs with an LDAC pin in order to update two power supply or DC load channels at the same time it seems I'm back to the initial selection of cheap string DACs.

• DAC
  
  • 16bit
    
    • AD5662
    • DAC8501
    • DAC8531
    • DAC8551

None of them have a LDAC pin which means I'll need to find a way to update them at the same time. Having the MSB the first bit that needs to be shifted in makes it more difficult so I should find a way to delay the LSB by at least one clock cycle and use that to clock it in simultaneously for both DACs. Some glue logic will be required or just ditch them and go for an AD5761 which has everything I need. The latter option is easier to implement so I'll probably be sticking with it.

EDIT: Looks like the AD5761 is a clear winner. Just had a look at the waveform generator output stage and I'll use the 12-bit variant there for output offset adjustment since it gets rid of one op amp used for level shifting. Problem solved.

[void_error]

Time for another short progress update...

The UI board is going to use 3.3V logic, mostly due to the fact that the display is a 3.3V part and there's no information in the controller's datasheet regarding the output current of the data lines which means using open drain outputs and pull-up resistors to do the level shifting from the previously 5V powered MCU might not work properly so I'm not risking it.

The changes to the UI board aren't going to affect the DC load or the Lab Power supply since they use digital isolators.
What needs changing so far is the Waveform Generator / Frequency counter board and the good thing here is that the AD9834 DDS chip can use different supplies for the analog and digital supply pins which means I can get rid of a few parts like the level translator chips for the clock generator chips which run on 3.3V. The analog stuff will still run on 5V.

Regarding the 595 shift registers, each board is going to use two of them because I couldn't find a way to implement all the SPI addressing and any other functionality using only 8 pins.

I want to have everything ready for the PCB design stage by the end of the year but I might not be able to since the front panel board for the Lab Power Supply and DC Load as well as the digital channel for Lab Power Supply haven't been designed yet.

[void_error]

Looks like the frequency counter part is almost complete with only a few tweaks here and there still to be done. Managed to get rid of the MCU and replaced it with about two truckloads of logic chips, mostly counters, flip-flops and multiplexers. It should go up to 20MHz @ 1Hz resolution with LVC series counters (74LVC161) but I've also included a divide by 10 prescaler which should allow it to go up to 100+ MHz with 10Hz resolution.

[Kleinstein]

Looks like the frequency counter part is almost complete with only a few tweaks here and there still to be done. Managed to get rid of the MCU and replaced it with about two truckloads of logic chips, mostly counters, flip-flops and multiplexers. It should go up to 20MHz @ 1Hz resolution with LVC series counters (74LVC161) but I've also included a divide by 10 prescaler which should allow it to go up to 100+ MHz with 10Hz resolution.

This direction is odd. The more normal way today is to get rid of the logic chips and use a µC to implement a reciprocal counter.  This way a frequency counter is a rather simple task and still can get really good resolution. So more like 8 digits of resolution after 1 or 2 second in a frequency range of about 10 Hz to around 50 MHz (more with prescaler) with just a single µC (like STM32F3...) and an external clock (e.g. TCXO) and the input stage. So the difficult part today are more like the input stage and maybe the software. So a frequency counter today is a small project, unless you want to go beyond something like 8 or 9 digts. With some special TDC modules / chips very high resolution is possible, that might want a good OCXO or more to get a meaning to 12 digits.

[void_error]

This direction is odd. The more normal way today is to get rid of the logic chips and use a µC to implement a reciprocal counter.  This way a frequency counter is a rather simple task and still can get really good resolution. So more like 8 digits of resolution after 1 or 2 second in a frequency range of about 10 Hz to around 50 MHz (more with prescaler) with just a single µC (like STM32F3...) and an external clock (e.g. TCXO) and the input stage. So the difficult part today are more like the input stage and maybe the software. So a frequency counter today is a small project, unless you want to go beyond something like 8 or 9 digts. With some special TDC modules / chips very high resolution is possible, that might want a good OCXO or more to get a meaning to 12 digits.

Yes, I know it's odd. Initially I went for a local MCU as a frequency counter but I figured it wouldn't be too nice to force anyone who wants to build this to use a PIC (16F1619 in this case).

But in one of the next revisions I will change to a MCU which is going to be installed on a daughter board so one can use their MCU of choice.

With that in mind, the old-school version of the frequency counter it will be on a separate board, with the waveform generator having a MCU-based frequency counter.

I'll build both versions, I'm curious how they perform.

[Kleinstein]

One can also do classical counting with an µC. AFAIK the PICs are quite good at this. Other µs might need a little extra HW to get to higher frequencies. AFAIK some of the PIC18 include hardware that is supposed to be useful for analog time interpolation with relatively little additions This would give a rather high resolution reciprocal counter (e.g. sub ns resolution) with moderate effort.

Usually reciprocal perform better than simple classical counters, as the resolution is no longer limited to fixed increments of 1 over gate time. Its only at the upper limit that both ways have about similar performance.

Many other function would need an µC anyway - so I see no big advantage in avoiding an µC for a counter, if this is something the µC can do very well.

[void_error]

One can also do classical counting with an µC. AFAIK the PICs are quite good at this. Other µs might need a little extra HW to get to higher frequencies. AFAIK some of the PIC18 include hardware that is supposed to be useful for analog time interpolation with relatively little additions This would give a rather high resolution reciprocal counter (e.g. sub ns resolution) with moderate effort.

Usually reciprocal perform better than simple classical counters, as the resolution is no longer limited to fixed increments of 1 over gate time. Its only at the upper limit that both ways have about similar performance.

Many other function would need an µC anyway - so I see no big advantage in avoiding an µC for a counter, if this is something the µC can do very well.

It seems that I have implemented a reciprocal counter. Didn't know it was called that.

I guess I'll be sticking with a MCU in the end. Found this neat little document.

For anyone not wanting to use a PIC there will be the possibility to put their own MCU on a daughter board.

[void_error]

I've almost finished everything needed for the waveform generator / frequency counter as far as schematics go, with the electronic load and lab power supply not far behind. Depending on how things progress I might have stuff on GitHub this weekend.

One thing I've settled for is using 3.3V for the logic and +/-3.3V for the analog stuff where digital isolators aren't used, the only exception being the AD603 used to adjust the output amplitude of the waveform generator's output for sine/triangle which requires +/-5V, delivered via a pair of LM317L/LM337L off the +/-15V supply of the output stage.

As far as the electronic load and lab power supply are concerned, they're 80% done unless I find easy ways to add more features which I've been doing a lot lately at the expense of them not being finished yet (like another multiplexer for the option to measure all the internal supply rails). Oh, and it's 80% of the schematics, PCBs not included.

Speaking of PCBs, that's another can of worms since it's about a dozen of them... almost:

• UI board
• Waveform Generator & Frequency Counter
• Lab Power Supply
• Electronic Load
• Front Panel & Aux Digital Channel
• USB Charging Module
• USB - UART interface
• Aux Analog Supply (linear regulators - easy)
• Aux Digital Supply

Ok, it's only 9 of them.

Another thing I have planned for sometime in the future is an ethernet module based on some PIC18 and Microchip's TCP/IP libraries but I'm not going too far with it from the start and I'll probably base it on an existing example.

One thing I still have to look into is whether I can reuse the Front Panel module designed to be used with the lab power supply for the electronic load as well, without the relays used to switch the two channels between independent/series/parallel and for that I have to decide what the high current range will be and what connectors I'll use and whether they'll be PCB mounted or panel mounted. Looking for parts is very time-consuming, especially when I'm trying to stick with only 2 distributors - TME & Farnell. Digikey and/or Mouser will have everything anyway but shipping cost will be higher for me at least.

If anyone has any comments or questions or pretty much anything related you can leave them below. Blame the way the forum works if they end up on the next page (joking).

[bg9gas]

 

[xani]

For ethernet side honestly you're probably better off just sticking raspberry pi there, it has serial, SPI and I2C on it, it's cheap, and you can then run any data acquisition directly in the system instead of pushing data to dedicated PC. Or even run a web UI with modules state/controls

For IDing modules daisy chaining is probably easiest option, but you should also probably have modules send their name and some unique ID if a micro has it) with it. That makes it possible for code to work regardless of which order modules are put in or even (if unique IDs are used) if you reorder stuff for whatever reason. Of course, that requires a micro per board

If you go with micro per board it would also be worth to add a single LED dedicated to identify function, that allows for making queries like "which board is ADC number 4" or "which board is one with ID 413e6f"

Or go even fancier and put RGB led on, then you can do "connect left channel to green input, and right channel to purple one"

[void_error]

For ethernet side honestly you're probably better off just sticking raspberry pi there, it has serial, SPI and I2C on it, it's cheap, and you can then run any data acquisition directly in the system instead of pushing data to dedicated PC. Or even run a web UI with modules state/controls

Adding ethernet is just an idea, only mentioned it because I saw it's possible with what I have so far. I'm just playing with the idea and not taking it too seriously at the moment.

For IDing modules daisy chaining is probably easiest option, but you should also probably have modules send their name and some unique ID if a micro has it) with it. That makes it possible for code to work regardless of which order modules are put in or even (if unique IDs are used) if you reorder stuff for whatever reason. Of course, that requires a micro per board

Found a way that requires no micro and with jellybean parts. The ST_CP pulse is already used to latch the data onto the 74HC595's outputs so it's reused by U713 to latch the input data. U715 & U712 just make the whole thing SPI compatible. U712 outputs into the SPI MISO line and the STS line acts as an active high chip select. U715 is there to delay the data by one bit. In other words, the board ID is programmed via 6 solder links. D0 & D1 will have board specific functions, like signalling an overtemperature condition.



Why I went that route is because I don't want to force anyone else building one of the aforementioned modules into using the same micro I used. Perhaps one would want to use an arduino, or STM or raspberry pi or whatever else to control the module(s).

If you go with micro per board it would also be worth to add a single LED dedicated to identify function, that allows for making queries like "which board is ADC number 4" or "which board is one with ID 413e6f"

Or go even fancier and put RGB led on, then you can do "connect left channel to green input, and right channel to purple one"

Going one micro per board would have been one way to make everyone happy but only if I provided a way of mounting a daughter board for each module which IMHO I found it would be a pain in the butt so I'm only doing it for the module that has the frequency counter where a micro is the only sane way to go. I should probably make a new lock diagram of how things would work together as the last ones I posted are quite outdated.

[void_error]

I've almost finished everything needed for the waveform generator / frequency counter as far as schematics go, with the electronic load and lab power supply not far behind. Depending on how things progress I might have stuff on GitHub this weekend.

This guy spoke too soon.

I thought I'd first see if everything fits together and it's not a huge pain in the ass to route where MCUs are employed so I had to move pin functions around. After finally getting to something doable for the UI board (yes, it strikes again) I realized it's way too big so I'm changing the connector placement from something like this to moving the 30-pin bus connector to one side and maybe the pushbuttons to the bottom below the display depending on how much I can shrink the board vertically. It currently looks like this and one can almost build a factory on top of it:

[John Heath]

I like it. Do you have a picture of what it physically looks like on your bench? Have you thought of a computer interface secondary display and mouse buttons for secondary desk top computer control. This would open new doors for your modular data acquisition system . One of those doors would be the internet where I from 1000s of miles away could press a bottom to make a measurement on your bench. Can not think of a practical reason to do this but then again why does a man climb a mountain , because it is there.

[void_error]

I'll be using one of these because they're cheap and I'm cheap, unfortunately (not for me) no backplane/rackmount possibility out of the box, too much work for too little gain.

Modular... hmm... nope, won't change the title but you can find something being designed to be modular here.

This is just a collection of bits of test equipment sharing a similar communications bus simply because it was easier to have it that way.

Internet? Just hook up a raspberry pi or something via UART and you can have it. Going for practical first, after fancy a bit later.

[void_error]

I think I have finally managed to get the PCB sizes right for the 4 stacked boards of the waveform generator. UI ended up 115x70mm, with the waveform generator 115x95mm. It might be the time to upload some schematics to github as drafts since things might change a bit with the PCB layout which is what I'm currently working on.