I love the concept, but I don't understand why we can't just start creating hackable interfaces for existing schemes like:
- Virtual Instrument Software Architecture (VISA) --
https://en.wikipedia.org/wiki/Virtual_Instrument_Software_Architecture (https://en.wikipedia.org/wiki/Virtual_Instrument_Software_Architecture)- Standard Commands for Programmable Instruments (SCPIP) --
https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments- High Speed LAN Instrument Protocol (HiSLIP) --
https://en.wikipedia.org/wiki/High_Speed_LAN_Instrument_Protocol
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.
linux capable SBCs like Raspberry Pi. Many other SBCs exist but often because they are closed source,
As long as we're throwing out ideas...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.
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.
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.
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.
We don't need to be limited only to simple instruments, and your examples are just to the point.
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
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: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.
- 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.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.Ok, that should be clearly stated in specification. Also e.g. max. capacitance on the each input power line has to be specified.
- 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.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: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 (http://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-introduction.html) over USB and Ethernet).
- 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.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:
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 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.
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?
Also, I'd like to be involved :-)
If you talk about Easy ? (http://easy-phi.ch/index.php) it is still around.
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 (http://www.ti.com/product/sn74lv595a) 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-.
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.
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) :).
Yeah, connectors are hard. Do they have some pins which are a bit longer than others and engage early?
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 would suggest a separate power ground return as well to keep power return currents out of the signalling.
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 (http://brettbeauregard.com/blog/2009/07/arduino-offset-header/), 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.)
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?
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.
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?
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 :).
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.
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).
(Possible AUX connector: DIN41612 power connection)Do you have anything in particular, since DIN41612 include dozen of power connector?
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.
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.
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.
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? :-//
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.
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.
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.
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?
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?
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?
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.
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.
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?
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.
QuoteIn 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.
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.
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.
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.
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.
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.
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.
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.).
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:
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.
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.That assumes you are using all the levels of 802.3 "Ethernet" protocol.
That sounds like royal pain in arse for everyone involved honestlyThat assumes you are using all the levels of 802.3 "Ethernet" protocol.
gigabit ethernet is not multidrop, it is point-to-point only.
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 .
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.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
I'm working on new pin mappings trying to include some of your thoughts and saying that is quite challenging is simply understatement.
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...
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 (https://en.wikipedia.org/wiki/Self-clocking_signal#Isochronous_self-clocking_signals)?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.
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.
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)
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.
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
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.
Without builtin 8/10b that's still some work to make it work and still requires driver; but it also does have USB ;)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 ;)
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
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*
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.
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 (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.
Multimeters sure, but scopes and sig gens generally have gnd tied to ground. So it is definitely not "all"
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
Multimeters sure, but scopes and sig gens generally have gnd tied to ground. So it is definitely not "all"
Good point to think about :)QuoteLike, 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.
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
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.
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 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.
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..
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).
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.
QuoteYou 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?
Anything else I need (~30 trigger signals, analog routing, fast LVDS connections) is probably outside the scope of this project
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.
QuoteAnything 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.
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.
QuoteHence 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
No more then one CS signal is needed if you are using '595 (see post #43 (https://www.eevblog.com/forum/projects/diy-instrumentation-bus-(or-dib)/msg1425269/#msg1425269)) 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).
Please let me know how "LVDS SPI" is different then "RS485 SPI" that you proposed?
I would add RS485 or RS422 to the list:
+ common bus, does not need mux
+ still async serial
So something like VME, where you read/write a bunch of addresses to control the modules would be fine I guess?
No more then one CS signal is needed if you are using '595 (see post #43 (https://www.eevblog.com/forum/projects/diy-instrumentation-bus-(or-dib)/msg1425269/#msg1425269)) 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.
If you can recommend connector with higher pin count that does not cost a fortune and is easily to obtain, please let me know.
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.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.
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.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.
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...
Let me dumb it down for you: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.
'manufacturer'... see above.QuoteAlso, 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
I know that. See my statement above, featuring Bob, Jim and Matt.
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.
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?
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).
No more then one CS signal is needed if you are using '595 (see post #43 (https://www.eevblog.com/forum/projects/diy-instrumentation-bus-(or-dib)/msg1425269/#msg1425269)) 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).
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 (https://www.eevblog.com/forum/projects/diy-instrumentation-bus-(or-dib)/msg1425269/#msg1425269)) 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?
Let me dumb it down for you: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.
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?
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
I'm taking software/firmware part of the whole solution very seriously (that is I believe visible from EEZ H24005 project)
In summary, I don't like idea that multiple MCU setup is mandatory (nor impossible!)
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.
QuoteIn 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?
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).
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.
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?
Did you check Agilent chassis I mentioned in my post (https://www.eevblog.com/forum/projects/diy-instrumentation-bus-(or-dib)/msg1446507/#msg1446507)?
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.
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
I'd like to learn about 4-qudrant programmable power unit under < 50 USD :)
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.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 (https://www.eevblog.com/forum/projects/simple-4-quadrant-psu-with-remote-sense-please-recommend-topologyschematic/). Pay attention to http://www.linear.com/solutions/4288 (http://www.linear.com/solutions/4288) mentioned in the thread. IMHO <50$ in BOM components (including MCU) is possible.
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.
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 :)
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.QuoteAlso, 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
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.
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 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.
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.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
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?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.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
Yes, that constant G. It has a unit. Try describe that in a FourCC.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?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.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
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"
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.Yes, that constant G. It has a unit. Try describe that in a FourCC.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?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.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
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"
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.QuoteIndeed 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 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 tooGive 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.
And there are units that can just not be converted, at least not easily representable in 4 bytesAgain, 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 numbersYou 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.
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...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.
You could just use you idea as a base for generating IDs.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 numbersYou 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.)
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.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...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.
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 dayConversion 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.)
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.)You could just use you idea as a base for generating IDs.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 numbersYou 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.)
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.
Those connectors are rather expensive, they does not allow reflow soldering as well. Have you considered PCI Express card edge connectors?
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).
Card Slot | I2C Address |
0 (Master) | 0x?? |
1 | 0x?? |
2 | 0x?? |
... | ... |
7 | 0x?? |
Address | Field Name | Field Contents | Length (B) | Notes |
0 | DIBVersion | DIB interface version x.x.x.x | 4 | |
4 | CardManuf | Manufacturer Name (UTF-8, 32 char max) | 129 | UTF-8 takes up to 4B per character, length encoded expliticly |
133 | CardName | Product Name (UTF-8, 32 char max) | 129 | |
133 | CardVersion | Card HW version x.x.x.x | 4 | |
264 | CardSerial | Serial # (UTF-8, 32 char max) | 129 | Set length to 0 for no serial number |
395 | ExtraDataStart | Extra data field start address | 4 | Set to 0 for no extra data |
399 | ExtraDataEnd | Extra data field end address | 4 | Set to 0 for no extra data |
403 | HeaderCRC | CRC32 for above record | 4 |
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 Slot I2C Address 0 (Master) 0x?? 1 0x?? 2 0x?? ... ... 7 0x??
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:
Address Field Name Field Contents Length (B) Notes 0 DIBVersion DIB interface version x.x.x.x 4 4 CardManuf Manufacturer Name (UTF-8, 32 char max) 129 UTF-8 takes up to 4B per character, length encoded expliticly 133 CardName Product Name (UTF-8, 32 char max) 129 133 CardVersion Card HW version x.x.x.x 4 264 CardSerial Serial # (UTF-8, 32 char max) 129 Set length to 0 for no serial number 395 ExtraDataStart Extra data field start address 4 Set to 0 for no extra data 399 ExtraDataEnd Extra data field end address 4 Set to 0 for no extra data 403 HeaderCRC CRC32 for above record 4
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.