Small Lab (SLab) release

[Vic20]

Hi, I have been viewing the tube channel for a long time and connecting to the blog as guest from time to time.
Now I have developed a project that perhaps could be interesting for someone.

It is basically a, Python based, ultra low cost instrumentation system for learning or playing with electronics:

http://r6500.blogspot.com.es/2018/02/slab-first-release.html

The hardware details are acompained, for now, with 13 tutorials about common electronic devices.

The software is open source and the documents are free to share.

[Marco]

Interested to see where you take this.

I'd put some 100K resistors on the opamp inputs and the feedback paths of the outputs, make it a bit more robust. Also lack of galvanic isolation of any measurement system is always a bit iffy.

[Vic20]

Interested to see where you take this.

As far as I can.
From the hardware point of view, I'm now planning on a 0V..12V or -6V...+6V shield with good current capabilities at the supply limits.
But it will be complementary because it increases system complexity.
From the firmware point of view, I'm planning in increase sample rates by using a lower level programming in the MCU.
From the Python point of view, more functions will be added.
From the documentation point of view, I plan on expanding, for now, the BJT and Opamp tutorials.

I'd put some 100K resistors on the opamp inputs and the feedback paths of the outputs, make it a bit more robust. Also lack of galvanic isolation of any measurement system is always a bit iffy.

Take note on the suggestion. This will be most interesting to protect the ADC opamp inputs. The idea was to have a low part count so that anyone can play with this without even a shield on the 303RE board. Till this point in time I have not had any problem with the system, however. The fact that the system is powered only by its own outputs help on that although I know that there could be hazards using L or C components.

Don't understand why galvaninc isolation could be so important. The system is grounded by the USB connector. In most labs, measurements are grounded, at least, on the BNC scope connectors.
AFAIK, low cost USB instrumentation devices, like the Analog Discovery, for instance, are not galvanic isolated.

[rstofer]

That is a very neat project!  I like the arbitrary waveform of the house and car because I can see using it with an analog computer model of an automotive suspension system.  Then I can use the analog inputs to capture the analog computer outputs and somehow merge them together.  The arbitrary waveform generator will also create a model of the roadway, potholes and all.

The power of having Python computing capability to draw the analytic plot and the hardware to create a physical plot of the RC circuit is awesome.  I don't think I have seen anything like that.

[rstofer]

Your decision to use the mbed platform is excellent.  In one stroke you have eliminated the inevitable "How do I install the toolchain on my Frambus 300 with Windows 3.1".  For portability, mbed wins hands down over resident toolchains.

I ordered the basic parts (a couple of op amps) and I'll soon be having a PCB built.  I want to wait until the Nucleo board is in hand before I commit to a layout.  I will very likely add a row of GND pins adjacent to the signal pins and I might want to move the Halt button to the top board.  It seems like it might be reachable if I only use the Arduino headers but it seems partially concealed if I use the Morpho headers which are easier to lay out.  I need to think about this...

The transistor curve tracer alone is sufficient reason to build the project.  I have a little 'show and tell' coming up as my grandson pursues EE.  Excellent!

[tggzzz]

Your decision to use the mbed platform is excellent.  In one stroke you have eliminated the inevitable "How do I install the toolchain on my Frambus 300 with Windows 3.1".

... And introduced the problem of "now the server has gone the way of Microsoft's PlaysForSure(TM) servers, how can I access an dmodify my design.

Some of us remember the 1970s, and why the IBM PC was greeted with relief. TANSTAAFL.

[Vic20]

The power of having Python computing capability to draw the analytic plot and the hardware to create a physical plot of the RC circuit is awesome.  I don't think I have seen anything like that.

Thanks

Being able to use numpy vectors as waveforms and being able to capture the response also as vectors give a path to use the SciPy computation capabilities together with the measurement data. The possibilities are mind blowing. In no time I'm able to compute a rough estimation of THD from measurements, for instance.

[janoc]

Don't understand why galvaninc isolation could be so important. The system is grounded by the USB connector. In most labs, measurements are grounded, at least, on the BNC scope connectors.
AFAIK, low cost USB instrumentation devices, like the Analog Discovery, for instance, are not galvanic isolated.

Galvanic isolation is important because sooner or later someone connects a scope or something else (e.g. a non-floating power supply) that is mains earth referenced to the circuit incorrectly and promptly blows up both the board and the USB ports in their computer. This is a very common problem - just google "Arduino blown USB port".

It also helps to somewhat protect against conducted noise getting into your circuit (PC is *horrible* for that) and any oopses if someone plays with higher voltages (12V or such) on the board and manages to short the voltage to the USB bus.

Otherwise it is a pretty neat project, it could be very much a poor man's Analog Discovery for learning analog electronics.

[Vic20]

Your decision to use the mbed platform is excellent.  In one stroke you have eliminated the inevitable "How do I install the toolchain on my Frambus 300 with Windows 3.1".  For portability, mbed wins hands down over resident toolchains.

Well, MBED is great for working with MBED enabled boards, like the nucleo ones, without needing to install a toolchain and with the availability of a ton of libraries.
I think it wins hands down to most Arduinos.
But it's not perfect. Basic things like changing processor frequency is not easy on MBED.
Moreover, there are too much different MBED enabled boards and not all functionalities work on all of them.
A future firmware won't use MBED because I need to use all four MCU ADCs at the same time and use DMA to speed-up the sampling.

I ordered the basic parts (a couple of op amps) and I'll soon be having a PCB built.  I want to wait until the Nucleo board is in hand before I commit to a layout.  I will very likely add a row of GND pins adjacent to the signal pins and I might want to move the Halt button to the top board.  It seems like it might be reachable if I only use the Arduino headers but it seems partially concealed if I use the Morpho headers which are easier to lay out.  I need to think about this...

A used a short board on the Arduino connectors in order to not block the buttons (Reset and Halt).
Having the buttons on the shield is better but it requires a little more routing. If you leave space for Halt, put also a Reset button.
If you are building your own shield I recommend, as Marco proposed, that you leave space for 100k resistors in series with the positive opamp inputs of the ADC drivers. That will protect the Opamps in the case that you try to measure voltages outside of the board supply range. (Like connecting to node at 20V  from ground)
In the future I will change the pin assignement to locate each ADC input in a different hardware ADC. That means using the Morpho connectors.

The transistor curve tracer alone is sufficient reason to build the project.  I have a little 'show and tell' coming up as my grandson pursues EE.  Excellent!

Glad you find it interesting.
The DC functionalities, like the curve tracer, of the SLab project, are so easy to implement that I don't understand why I haven't seen that before.
I did something similar with the ADALM Board (https://wiki.analog.com/university/tools/m1k) but I needed to reverse engineer the Python interface to the board. In the end I tought that I would have more control developing muy own firmware for a Nucleo board.

[Vic20]

... And introduced the problem of "now the server has gone the way of Microsoft's PlaysForSure(TM) servers, how can I access an dmodify my design.

As I'm somewhat paranoid, I keep local copies of the MBED code.
I'm not worried about MBED closing because I know that I can easily replicate current firmware functionality using other toolchains.

[rstofer]

Your decision to use the mbed platform is excellent.  In one stroke you have eliminated the inevitable "How do I install the toolchain on my Frambus 300 with Windows 3.1".

... And introduced the problem of "now the server has gone the way of Microsoft's PlaysForSure(TM) servers, how can I access an dmodify my design.

Some of us remember the 1970s, and why the IBM PC was greeted with relief. TANSTAAFL.

At which time you need to find the toolchain of the day and install it.  When I was porting the code back and forth (for testing) I was using Rowley Crossworks  but Eclipse/Gcc would have worked just as well.

The fact that ARM owns the mbed platform helps as does vendor participation in the mbed interface by companies like ST.  It costs ARM just about nothing to maintain the platform (although I see a lot more administrative involvement since ARM bought the platform) and it is insignificant as long as ARM licensing is a thing.  I kind of suspect ARM will be around for a while.

And I do keep a copy of my source files locally.  Just in case...

I only go back to 1970 with this code stuff but it has been a fun ride!

[rstofer]

As I'm somewhat paranoid, I keep local copies of the MBED code.
I'm not worried about MBED closing because I know that I can easily replicate current firmware functionality using other toolchains.

For those new to this idea, make sure you download the platform files as well.  My plotter project uses the mbed TCP/IP stack so when I bring down my code, I rip that at the same time.  You want to be able to build you project locally on some toolchain.  Installing said toolchain is a subject for a different forum.

Then there is the effect described in the early FORTRAN world as:  "I wrote the best version of my program after I dropped the box of cards for the previous version!"  Starting over removes the obstacles caused by previous decisions.  Yes, we really did carry around boxes of punched cards.  Early sneaker net, I guess...

[Vic20]

Galvanic isolation is important because sooner or later someone connects a scope or something else (e.g. a non-floating power supply) that is mains earth referenced to the circuit incorrectly and promptly blows up both the board and the USB ports in their computer. This is a very common problem - just google "Arduino blown USB port".

Yeah, I understand your concern.
The project is not designed as an Scope alternative. You are only supposed to power your circuits from the board itself. Connecting the board to circuits powered from elsewhere can produce all kinds of problems and could damage the PC trough its USB port.
As the communication is serial from the main MCU and converted to USB on the STLink MCU it could be quite easy to communicate the board trough an optocoupled isolation barrier.
That would need an independent power supply and in no time the needed budget starts to ramp up.
As I commented, I think that the problem is common to most low cost USB instruments.
At a lower cost that a full isolated system, a more secure version of the shield will benefit from some protection components on the external terminals.

It also helps to somewhat protect against conducted noise getting into your circuit (PC is *horrible* for that) and any oopses if someone plays with higher voltages (12V or such) on the board and manages to short the voltage to the USB bus.

I'm quite puzzled of the low noise levels I get on the AC measurements.
On DC it is much worse but, DC measurements can easily benefit from averaging.
The Marco suggestion of adding 100k resistors in series with the opamp buffers ADC inputs can easily protect them against voltages in the order of 20V.
I think that the supply hazards are somewhat protected by the nucleo board internal circuits as I think that  there is a diode in series with the power line. You can always burn the nucleo board, but it is much better than ruining a PC.
All external lines on SLab, except the supplies, connect with the main MCU and the main MCU connects with the ST-Link MCU through a serial link unrelated to the external pins. It is much easier to blow the Nucleo board or the main MCU than blowing the PC, but I understand that going so low in cost can yield some potential hazards. But they are not much different than using the nucleo board in any other project.

Otherwise it is a pretty neat project, it could be very much a poor man's Analog Discovery for learning analog electronics.

Thanks
That's the Idea. I have an Analog Discovery (Version 1) and it is a quite neat piece of equipment. Version 2 is much better.
I wish it was something like the SLab Python layer for the Analog discovery. Although the Discovery software is good, I miss some easier automation capabilities.
But close to 300$ is too much money if you want a low budget Small Lab for on-hands electronic learning.

[tggzzz]

Your decision to use the mbed platform is excellent.  In one stroke you have eliminated the inevitable "How do I install the toolchain on my Frambus 300 with Windows 3.1".

... And introduced the problem of "now the server has gone the way of Microsoft's PlaysForSure(TM) servers, how can I access an dmodify my design.

Some of us remember the 1970s, and why the IBM PC was greeted with relief. TANSTAAFL.

At which time you need to find the toolchain of the day and install it.  When I was porting the code back and forth (for testing) I was using Rowley Crossworks  but Eclipse/Gcc would have worked just as well.

The fact that ARM owns the mbed platform helps as does vendor participation in the mbed interface by companies like ST.  It costs ARM just about nothing to maintain the platform (although I see a lot more administrative involvement since ARM bought the platform) and it is insignificant as long as ARM licensing is a thing.  I kind of suspect ARM will be around for a while.

You are out of date. ARM Holdings has already gone; it was borged by SoftBank. https://www.ft.com/content/235b1af4-4c7f-11e6-8172-e39ecd3b86fc

So you are actually relying on a Japanese company.

[janoc]

Yeah, I understand your concern.
The project is not designed as an Scope alternative. You are only supposed to power your circuits from the board itself. Connecting the board to circuits powered from elsewhere can produce all kinds of problems and could damage the PC trough its USB port.
As the communication is serial from the main MCU and converted to USB on the STLink MCU it could be quite easy to communicate the board trough an optocoupled isolation barrier.
That would need an independent power supply and in no time the needed budget starts to ramp up.

The issue is not that it should replace a scope but that this sort of tool could be useful outside of the scenarios you envision. E.g. to measure something off-board, to check the signals generated by the board using an oscilloscope, etc. Plenty of possibilities for error - just hook up the scope ground clip wrong!

You have also said you are planning 12V and 6V supplies, so at least boost converters will be on the board at some point. Another chance to make a costly oops - never underestimate the damage a dangling jumper wire can do when it has 12V on it and the other end touches something it shouldn't. With an isolator it would blow up the Nucleo at worst. Without it you have just screwed up your motherboard - a much more expensive problem.

Re - independent supply - a 5V phone chargers are widely available and almost anyone has one. The cheap USB isolators from AD cost few bucks. If this is something aimed at beginners, then I would certainly include them - yes, it gets a bit more expensive but it is certainly less expensive than replacing/fixing a PC motherboard.

As I commented, I think that the problem is common to most low cost USB instruments.

I think Analog Discovery isn't isolated because it uses USB 2.0 and there are no cheap isolators for something that fast. And that other instruments are poorly designed doesn't mean yours should be too.

At a lower cost that a full isolated system, a more secure version of the shield will benefit from some protection components on the external terminals.

I would say that is orthogonal and you really should include both. If nothing else, at least make sure that people can actually use an isolator (e.g. something like this:
https://www.aliexpress.com/item/New-USB-Isolator-1500v-Isolator-ADUM4160-USB-To-USB-ADUM4160-ADUM3160-Module/32719549159.html) by providing for external power possibility in the design.

[rstofer]

An isolator like this from Adafruit is pretty expensive when compared to the Chinese offerings (which I have) but I bought one anyway.  The downside to these things is that there is very little output current available on the downstream side - like 100 mA.

https://www.adafruit.com/product/2107

The board itself, with the blinking LED on the ST-Link gadget will draw about 70 mA and that only leaves 30 mA for the DUT.  I suppose we should deduct a few mA for the analog gadgets as well.

A good plan is the use the E5V input pin and a 5V wall wart or the Vin pin and a 9V wall wart.  These pins are available on both the Arduino and Morpho headers.  I have a bunch of 5V 2A wall warts so that's the way I plan to handle it.  I may put a barrel jack on the PCB when I design it.

The plan right now is to put the analog board on the underside of the uC board.  That leaves the various pins accessible and I could just solder on a couple of pin connectors to the wires coming out of the wall wart.  A little heat shrink and I'm done.  No need for a barrel jack.

I think I'll bring both 5V and 3.3V out for the DUT.  If I need a bunch of 3.3V, I can make it from the 5V line with an external LDO regulator.

I'll be adding a bit of bulk capacitance to the PCB along with decoupling at the op amps.

[rstofer]

On the idea of putting the analog PCB under the uC board:  This will leave ALL of the topside pins available in both formats.  There is no reason to bring the digital pins out to the analog board because they can be reached from the top side.

[Vic20]

On the idea of putting the analog PCB under the uC board:  This will leave ALL of the topside pins available in both formats.  There is no reason to bring the digital pins out to the analog board because they can be reached from the top side.

The problem is labeling.
If I use, say, D2 to D10 as digital pins D1 to D8, it is more complex to use without error.
Also, I like male pins on the board. In the nucleo board Morpho pins are male, buy they are not labeled at all.
Finding the proper pin associated to D1..D8 is a nightmare.
In general, I thik it is better to have available only the pins that SLab knows how to use.

As the first shield board was so small, I think it suits better to have it on the top.
If a make another more capable interface board, the fact that it is over or below the MCU board will be decided from the size of both boards. The bigger one will be on the bottom.

[Vic20]

You have also said you are planning 12V and 6V supplies, so at least boost converters will be on the board at some point. Another chance to make a costly oops - never underestimate the damage a dangling jumper wire can do when it has 12V on it and the other end touches something it shouldn't. With an isolator it would blow up the Nucleo at worst. Without it you have just screwed up your motherboard - a much more expensive problem.

The plan is to have an external, about 20V isolated input, and generate the positive and negative rails from it.
In this way it will be much easier to isolate the PC.
Boosting from the 5V USB is not an option because I want to have a little more current capability.

Re - independent supply - a 5V phone chargers are widely available and almost anyone has one. The cheap USB isolators from AD cost few bucks. If this is something aimed at beginners, then I would certainly include them - yes, it gets a bit more expensive but it is certainly less expensive than replacing/fixing a PC motherboard.

Something like the ADUM3160?
Nice chip.

I would say that is orthogonal and you really should include both. If nothing else, at least make sure that people can actually use an isolator (e.g. something like this:
https://www.aliexpress.com/item/New-USB-Isolator-1500v-Isolator-ADUM4160-USB-To-USB-ADUM4160-ADUM3160-Module/32719549159.html) by providing for external power possibility in the design.

The nucleo board can be powered independent from the USB port. It is in the manuals, I can include the HowTo in the documentation.

Another option will be to communicate using an isolated FTDI RS-232 cable.

Thanks for the time dedicated to review the security of my design.

[Vic20]

The board itself, with the blinking LED on the ST-Link gadget will draw about 70 mA and that only leaves 30 mA for the DUT.  I suppose we should deduct a few mA for the analog gadgets as well.

Perhaps is enough on several scenarios. The microchip opamps I use are selected for their low cost and full rail capabilities. But the current output capabilities are quite small.

A good plan is the use the E5V input pin and a 5V wall wart or the Vin pin and a 9V wall wart.  These pins are available on both the Arduino and Morpho headers.  I have a bunch of 5V 2A wall warts so that's the way I plan to handle it.  I may put a barrel jack on the PCB when I design it.

Yeah, this is a good plan.
I'll sure put it on the documentation.

I'll be adding a bit of bulk capacitance to the PCB along with decoupling at the op amps.

Good idea, although current and speed on the opamps is quite low.
But sure a decoupling never hurts.

[janoc]

The nucleo board can be powered independent from the USB port. It is in the manuals, I can include the HowTo in the documentation.

Another option will be to communicate using an isolated FTDI RS-232 cable.

Thanks for the time dedicated to review the security of my design.

Yes, it can. However, what I had in mind is that if you are designing a board around it, adding a barrel jack and a voltage regulator would cost next to nothing and make it easier for the end user.

[Vic20]

The nucleo board can be powered independent from the USB port. It is in the manuals, I can include the HowTo in the documentation.

Another option will be to communicate using an isolated FTDI RS-232 cable.

Thanks for the time dedicated to review the security of my design.

Yes, it can. However, what I had in mind is that if you are designing a board around it, adding a barrel jack and a voltage regulator would cost next to nothing and make it easier for the end user.

You can use the internal nucleo voltage regulator. It can be powered from 7V to 12V. No need, really, for an external regulator.
I will probably add this option on the next shield version.
I'm not so sure about barrel connectors. As everybody today has 5V bricks with micro USB connectors, an USB connector will be best. Problem is that it is not so easy to solder.
Other problem with barrel is that there are so many kinds of barrels. That's why sometimes I end up using a 3 pin connector with (-)(+)(-) configuration.

The nucleo boards feature two regulators. One (U3) for going from 7-12V to 5V and another (U4) to go from 5V to 3V3
I can put an USB connector on the 5V rail and a barrel on the 7-12V one. Then you can chose which one you solder and use on the board.

There is a third regulator (U1) that powers the ST-Link MCU that connects to the PC using USB. But this power should never reach the circuit under test.

[amspire]

If nothing else, at least make sure that people can actually use an isolator (e.g. something like this:
https://www.aliexpress.com/item/New-USB-Isolator-1500v-Isolator-ADUM4160-USB-To-USB-ADUM4160-ADUM3160-Module/32719549159.html) by providing for external power possibility in the design.

I have some of the Aliexpress USB isolators and I have just taken off the DC power isolator module. The thing is the ADUM4160 chip has really great isolation - 5KV, 10pF, 35kV/us. The cheap power isolation module is pretty bad. From memory, the DC power isolator is only rated at 1kV or 1.5kV and it adds a lot of noise. The board is greatly improved with just the ADUM4160 chip and no power isolator.

Instead, I often use a USB hub on the isolated side powered by a USB battery pack. It is surprising what works with Full Speed USB (12MHz). I have an old Hantek DSO2150 USB oscilloscope and it is very usable with the isolator so as long as I am careful. Gives me a cheap floating oscilloscope isolated to 5kV.

[rstofer]

USB power is diode connected to the 3.3V ST-Link regulator with no way to isolate it short of removing the diode.  The U5V vs E5V jumper only handles power to the uC regulator.

Even if E5V is fed from an outside source, parts of the board are still powered over the USB input.  When E5V is jumper selected, ST-Link loses the ability to control power to the uC.  I don't know what this capability is used for but it goes away.

I had thought that having just 30 mA for the DUT was a little skimpy if I wanted to do transistor curves above that level.  I'm not thinking about 2N3055s but even 2N3904/5 are good for more than 30 mA of collector current.

I am going to break out E5V on my board so I can feed it from a 5V wall wart but I am planning to use it with USB power until I can't.  I always plug my projects into a powered USB hub, never directly into my PCs.  On my Surface Book, the powered hub is connected to the powered docking station which, sooner or later, gets connected to my PC.  I would have to do something incredibly stupid to break through an isolator and 2 powered hubs to get to my PC.  Even without the isolator, it would be tough to damage the PC.  I simply don't work at higher voltage levels.

In terms of the PCB, mine is 2.5"x3.8" no matter what.  That is the MiniBoard size at ExpressPCB and it is fixed - unless I want to pay a LOT of money for custom sizes.  Even the MiniBoard is several times the price of a Chinese board but I don't have to struggle with KiCad <or whatever> to get the artwork.

As such, the board has to be oriented orthogonal to the main board which will leave the IO pins over on the right edge when the board is viewed with the USB connector at the top.  I will probably use two-row female headers with one row grounded.  You can never have to many ground points!

I'm thinking in terms of a 40 pin header with unused positions between features.  Two pins for DAC, unused pin, 4 pins for ADC, unused pin, 8 pins for digital, unused pin , 3.3V, 3.3V, 5.0V - just right!  As 5V would only be used in very special circumstances, I think I'll put a jumper in the middle of that trace.

I guess I better get busy with the PCB layout...

[Vic20]

USB power is diode connected to the 3.3V ST-Link regulator with no way to isolate it short of removing the diode.  The U5V vs E5V jumper only handles power to the uC regulator.

Yes, I noticed that.
You cannot prevent a path from the E5V line to the USB line although the diode gives some protection.
The best way to provide isolation is snapping the USB part of the Nucleo board.
Then power the MCU part of the board from E5V or VIN

There are several lines that go from the USB part to the MCU part of the Nucleo board, but during normal SLab operation only three are needed: MCO, RX and TX. You can use three optocouplers for them. MCO is needed unless you populate the oscillator components on the MCU side of the board. The requirement for the optos will be the 8 MHz MCO signal as the RX and TX signals are lower frequency.
Connecting RX and TX after snapping the board requires installing two solder bridges to have access to those signals on D0 and D1 or the Morpho pins.

During MCU programming you will need to provide a path for the SWIM signals: TCK, TMS, NRST and the Vdd sense. I think SWO is not really needed.

Even if E5V is fed from an outside source, parts of the board are still powered over the USB input.  When E5V is jumper selected, ST-Link loses the ability to control power to the uC.  I don't know what this capability is used for but it goes away.

The E5V jumper position just makes the external source on VIN or E5V power the main MCU. You will still be powering the ST-Link MCU depending on the voltages on the E5V and U5V nodes.

If you remove diode D2 and put jumper JP5 on E5V, then you won't never use USB power.
There will be a path from E5V to 3V3 trough a regulator and from 3V3 to the USB connector trough T1.
But the most important thing is that powering the ST-Link MCU from E5V has the potential hazard that something that blows E5V can blow the ST-Link MCU that is connected to the PC on the USB lines.

I had thought that having just 30 mA for the DUT was a little skimpy if I wanted to do transistor curves above that level.  I'm not thinking about 2N3055s but even 2N3904/5 are good for more than 30 mA of collector current.

I am going to break out E5V on my board so I can feed it from a 5V wall wart but I am planning to use it with USB power until I can't.  I always plug my projects into a powered USB hub, never directly into my PCs.  On my Surface Book, the powered hub is connected to the powered docking station which, sooner or later, gets connected to my PC.  I would have to do something incredibly stupid to break through an isolator and 2 powered hubs to get to my PC.  Even without the isolator, it would be tough to damage the PC.  I simply don't work at higher voltage levels.

Seems like a good plan.
Adding 100k resistors to the opamps positive inputs, both ADC and DACS, will provide some protection for the ADC and DAC lines. Using an external supply independent from USB will somewhat protect the USB power bus.
I know that it is good to be paranoid when dealing with protection, but those kinds of potential problems are always present when you deal with MCU demonstration boards.

[rstofer]

I know that it is good to be paranoid when dealing with protection, but those kinds of potential problems are always present when you deal with MCU demonstration boards.

I can't get past the feeling that this isolation thing is like chasing something down a rathole.  Without building a custom PCB for the entire project and using an external programmer (while not connected to a DUT, of course), it just gets ridiculously complex.

Breaking off the programmer?  Well, there goes that feature!  Popping off a diode?  Sure hope I remember when I repurpose the board.  USB isolator of limited ampacity?  That sure puts a crimp in things, 30 mA isn't much.

How about this solution:  Don't use any source of external power with the tool and be very careful where the scope ground lead is connected if at all.

Seriously, this is getting out of hand.  A powered USB hub will solve all of this other than spiking the USB data lines and, even then, it will probably only trash the hub.  There is a risk with any kind of USB tool.  Perhaps we should just use the tools with disposable PCs.  We all have some (or several)...  I have 3 laptops and at least one workstation I don't care about.

Hey the host is just Python, why not run the setup on a Raspberry Pi?  Trash the Pi, buy another one.  This might be the solution I arrive at.  I have a few Pi's laying around and I doubt I would miss one.  I can use a KVM switch on my 27" monitor and call it a day.

[Vic20]

I can't get past the feeling that this isolation thing is like chasing something down a rathole.  Without building a custom PCB for the entire project and using an external programmer (while not connected to a DUT, of course), it just gets ridiculously complex.

Yes, when you enter in the security game, things can get as complex as you want.
Isolating the data path between the PC and the board, for instance, by using an optocoupled RS-232 connection secures the PC.
In this case, it is best to isolate the USB connection to maintain the debug path that programs the MCU.
If you want to secure the board itself then it comes down to resistors, diodes, MOVs and spark gaps. Like in a multimeter input stage.

Breaking off the programmer?  Well, there goes that feature!  Popping off a diode?  Sure hope I remember when I repurpose the board.  USB isolator of limited ampacity?  That sure puts a crimp in things, 30 mA isn't much.

Breaking the Nucleo board is no problem at 9 or 10€ each.

How about this solution:  Don't use any source of external power with the tool and be very careful where the scope ground lead is connected if at all.

This is a solution.
The initial idea of the SLab project was to power everything from the board itself. If you don't make any connection to other power sources, most potential problems are much reduced.

Another solution is to use an external power supply and make all connection in the signal path trough resistors. You can also include some MOVs, diodes and/or zenners if you like to keep the voltage between bounds.
I have tested the microchip Opamps I use with 100k resistor protections and the handle with no problems 20V input voltages when they are powered at 3V. The microamps current they get in the input protection circuits seems to not give any problem.

Seriously, this is getting out of hand.  A powered USB hub will solve all of this other than spiking the USB data lines and, even then, it will probably only trash the hub.  There is a risk with any kind of USB tool.  Perhaps we should just use the tools with disposable PCs.  We all have some (or several)...  I have 3 laptops and at least one workstation I don't care about.

Well, I work with students that use ST Discovery boards and Arduinos connected to the PCs. We have also power supplies so there is always the option to do very bad connections.
Students do all kinds of things you never thought they would do.  There are some boards damaged but no PC damaged at all.
It is much more common for students to blow the 50 Ohm input on the function generators.

Hey the host is just Python, why not run the setup on a Raspberry Pi?  Trash the Pi, buy another one.  This might be the solution I arrive at.  I have a few Pi's laying around and I doubt I would miss one.  I can use a KVM switch on my 27" monitor and call it a day.

I don't think I will do that.
In my case, I will add some resistors and perhaps some additional protection components.
That's enoug for my needs.

As I understand, the problem related to this thread is not that I blow anything or that YOU blow anything but that someone can take my schematics and, as the SLab project is targeted to newbies, do something really stupid and blow its own PC.

Although this is the same problem with arduinos that are also targeting newbies, I plan to, at least, to give some warnings and add some protection in the schematics.
Tomorrow I will test the impact on signal integrity of adding some protection resistors. I suspect that range of frequencies I use is so low that it would be no problem.

[rstofer]

One little 'gotcha':  If the Nucleo is powered from E5V or Vin, the USB enumeration may not happen properly.  To get the enumeration right, you have to plug the USB cable in AFTER the board is powered up.  I'll bet that's what the MOSFET is doing in the USB incoming 5V.

In the bigger scheme of things, this could be a real PITA!

See page 21 here:

http://www.st.com/content/ccc/resource/technical/document/user_manual/98/2e/fa/4b/e0/82/43/b7/DM00105823.pdf/files/DM00105823.pdf/jcr:content/translations/en.DM00105823.pdf

See Note 3 on Page 55

If it works, the Raspberry Pi idea is looking better and better.

[Vic20]

One little 'gotcha':  If the Nucleo is powered from E5V or Vin, the USB enumeration may not happen properly.  To get the enumeration right, you have to plug the USB cable in AFTER the board is powered up.  I'll bet that's what the MOSFET is doing in the USB incoming 5V.

In the bigger scheme of things, this could be a real PITA!

Yes, I have read that on the Nucleo manual.
But it is not a problem for me to first power the board using E5V or Vin and connect the USB line afterwards.
And yes the mosfet T2 is just for that, to connect U5V to 5V is enumeration succeeds.
In either case, the problem is only important if you use an external supply because you need more than 300mA or if the PC is not able to provide 300mA.
If you use low current levels and the PC enumeration usually goes well, there is no such problem with the power order.
If you don't like enumeration you can always bridge the mosfet M2 by adding solder bridge SB1 (see page 26).

[rstofer]

I have decided that Version 1.0 is going to be as drawn.  I'll worry about the isolation stuff another day.

[AG7CK]

Looks nice - especially for people who wants to modify it themselves. I would like to test SLAB, but I have very little knowledge beyond simple Arduino stuff.

1/ I have a http://www.st.com/en/evaluation-tools/nucleo-f446re.html board that I haven't used yet. Can I use that in stead of the http://www.st.com/en/evaluation-tools/nucleo-f303re.html?

2/ I am blank on Python, but have Python 2.7 running on w10:

Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:19:30) [MSC v.1500 32 bit (Intel)] on win32

Can I keep v.2.7 so that I can use an old HP Compaq running XP or w7 as a dedicated instrument PC?

3/ If I use a Hantek 6022BE USB scope and an external transformer based wall wart as PSU, then I will not have to worry about grounding issues?

4/ My old Compaq XP laptop with metal top seems to have (half) line voltage potential exposed. This seems to be inherited by the scope? Is this a problem for the STM board and shield electronic?

5/ I just bought the hardware box and experiment board for the old obsolete NI ELVIS (it is just a big experiment board, with some electronics inside the box, some connectors and a break out header for an NI DAQ - powered by a transformer based ungrounded PSU).

I do not want to use NI DAQ or Digilent Analog Discovery, but would like to make very simple stuff myself using the DAC/ADC and analog/digital I/O of the STM board. Will most people be able to modify the SLAB STM-code and Python-code for extra analog/digital pins in/out, tables n graphs, stats and math etc. ?

[Vic20]

Looks nice - especially for people who wants to modify it themselves. I would like to test SLAB, but I have very little knowledge beyond simple Arduino stuff.

That's the idea. You can modify it for your own purposes.

1/ I have a http://www.st.com/en/evaluation-tools/nucleo-f446re.html board that I haven't used yet. Can I use that in stead of the http://www.st.com/en/evaluation-tools/nucleo-f303re.html?

As long as it has 2 ADC channels, 4 DAC channels and is MBED enabled it can be easily used on SLab.
The 446RE complies with all requirements.
The firmware, however, is only currently compiled for the F303RE and L152RE boards.
That means that you need to create a new header file like the one for the L152RE and recompile

https://github.com/R6500/SLab/blob/master/Firmware/Source/Nucleo64-L152RE.h

I could do that myself. Problem is I don't have this board and I don't want to publish a firmware I cannot test myself.
There is a part of the MBED code optimized at low level for the 303RE board. If you use any other board the sampling rate performance will be poorer although it will work. At DC there will be no difference at all.

2/ I am blank on Python, but have Python 2.7 running on w10:

Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:19:30) [MSC v.1500 32 bit (Intel)] on win32

Can I keep v.2.7 so that I can use an old HP Compaq running XP or w7 as a dedicated instrument PC?

SLab is based on Python 2.7 so it will be ok.
It requires numpy, matplotlib and pySerial so you need to have this libraries installed.

3/ If I use a Hantek 6022BE USB scope and an external transformer based wall wart as PSU, then I will not have to worry about grounding issues?

Current SLab implementation has the same grounding as the PC is connected to. The usual requirements for grounded scopes and function generators apply also to SLab.
SLab should be quite safe if you power your circuits only from SLab itself. If that is not the case, you need to do your own verification of the setup safety.

I'm now working in a SLab shield for the F303RE board with galvanic isolation. Stay tuned.

4/ My old Compaq XP laptop with metal top seems to have (half) line voltage potential exposed. This seems to be inherited by the scope? Is this a problem for the STM board and shield electronic?

Don't really understand what half means in this context.
Basically SLab is connected to the 5V and GND lines of the USB connector so there is currently no galvanic isolation to the PC. If you can use the PC, you can use SLab. Problems could arrise when you want to connect SLab to any other instrument or circuit.

5/ I just bought the hardware box and experiment board for the old obsolete NI ELVIS (it is just a big experiment board, with some electronics inside the box, some connectors and a break out header for an NI DAQ - powered by a transformer based ungrounded PSU).

I do not want to use NI DAQ or Digilent Analog Discovery, but would like to make very simple stuff myself using the DAC/ADC and analog/digital I/O of the STM board. Will most people be able to modify the SLAB STM-code and Python-code for extra analog/digital pins in/out, tables n graphs, stats and math etc. ?

SLab documentation is Creative Common Attribution-ShareAlike 4.0 International license.
SLab hardware is completely open (Don't know about the Nucleo boards but they are full documented).
SLab software is do whatever you please with no warranties (MIT license alike).

The software is designed and documented so that it is easy to modify for your own purposes.

Modifications on the software depend on what you want to do.

A lot of extensions can be performed just adding Python code.
In order to add new core functionalities, like more than 8 digital I/O lines or high speed  sampled digital capture, the board firmware shall be modified also. I have a plan for some new functionalities, but if you cannot wait and want to modify the code yourself, just do it.

It should be easy because the firmware just responds to commands. New commads can be made nearly independent of previously implemented commands. Although using a similar protocol on new commands will help.

[janoc]

SLab is based on Python 2.7 so it will be ok.
It requires numpy, matplotlib and pySerial so you need to have this libraries installed.

Guys, you do want to update that if you don't have a Python 3 version already:
https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst

There is no good reason to start a new project with Python 2.7 today, even if your machine doesn't come with Python 3.x out of the box.

I had a quick look through your code and for the most part it is just replacing the print statement with the print() function (which is, btw, possible to use in 2.7 too if you want to maintain compatibility).

[AG7CK]

Vic20 - Thank you very much.

I have already updated drivers for the 446RE board and compiled a few STM programs found on mbed (including serial stuff that works against Putty). Very slick stuff, mbed.

I am now studying your STM code. I have a little bit experience with C and C++, so I understand quite a lot. I will also try to modify the header for my board.

Concerning the line power from the SMPS I just searched "electric current felt on laptop metal case". It is common for PC metal cases. I don't really know the explanation, but it is not only me - people with the same symptom are all over the internet. I have not killed any Arduinos, PSOCs or Launchpads yet, so I will plan my circuit under test with the STM board as I do with the other boards I have (including sampling up to 15v through resistive dividers 1:5). If I kill anything, I will only blame myself. After all, there cannot be more than using floating supplies, remembering 3.3v limit and current limiting that must be respected. I would suppose that people using Analog Explorer must take the same precautions.

Thanks again. I will report here when I get to compiling your code for the 446RE board and have the necessary libraries for Python to run your PC code.

[Vic20]

Vic20 - Thank you very much.

I have already updated drivers for the 446RE board and compiled a few STM programs found on mbed (including serial stuff that works against Putty). Very slick stuff, mbed.

I am now studying your STM code. I have a little bit experience with C and C++, so I understand quite a lot. I will also try to modify the header for my board.

If you have MBED experience, modifying the board header file should be easy.

Concerning the line power from the SMPS I just searched "electric current felt on laptop metal case". It is common for PC metal cases. I don't really know the explanation, but it is not only me - people with the same symptom are all over the internet. I have not killed any Arduinos, PSOCs or Launchpads yet, so I will plan my circuit under test with the STM board as I do with the other boards I have (including sampling up to 15v through resistive dividers 1:5). If I kill anything, I will only blame myself. After all, there cannot be more than using floating supplies, remembering 3.3v limit and current limiting that must be respected. I would suppose that people using Analog Explorer must take the same precautions.

Yes, the SLab system is no different of any other uses of the Nucleo boards.

Respect to noticiying electricity on the metal case it can be static discharges or mains coupling. If the laptop uses a power brick it could be isolated from earth ground and mains, so I don't really understand what is happening.
If the Laptop is grounded, it could be static discharges.

Thanks again. I will report here when I get to compiling your code for the 446RE board and have the necessary libraries for Python to run your PC code.

If you do that, I can upload your firmware contribution in the Github repository.

[AG7CK]

I have never touched mbed before, but anyone can start using a Nucleo board in 5 (10-30) minutes by watching  the video below. My board hadn't even been opened in the year or so since I bought it - today it runs smoothly with mbed. The procedure in the video might have changed a slightly since 2014, but I had no problems.

My experience in C++ / C is from Arduino / TI Launchpad / PSoC.

I will report back after I have studied and tried to compile your code. Thanks again.

[AG7CK]

The C code from https://os.mbed.com/users/vic20/code/SLab_Python/ was just a click to import and compiles now also for platform Nucleo64-F446RE. All I had to do was to turn off the #define FAST_ADC. I am going away for a few days. When I come back, I will compare pins and schematics / datasheets for the F446RE vs. F303RE and study all code for ADC/DAC closer. I have already discovered that I will have to change a DAC pin (DA2) from D13 to A3 (iirc).

I'll be back late next week.

[rstofer]

Step 1 was to get the board and program it - done
Step 2 was to get Python 2.7 and all the required packages installed - done
Step 3 will be to assemble the board when it gets here Monday

The software seems to work.  I get a couple of plots but it ultimately hangs when it tries to do the transient part of the board test.  Sure, there is no analog stuff!

I bought one of the AdaFruit Arduino Proto Shields but I'm not sure I want to populate it.  I can wait a couple of days.

[rstofer]

SLab is based on Python 2.7 so it will be ok.
It requires numpy, matplotlib and pySerial so you need to have this libraries installed.

In the readme.txt or any other documentation, it would be helpful to newcomers to detail exactly how to install Python 2.7 (easy to do) but pip may or may not be in the path after installation and new-to-Python users are going to get frustrated.  Especially if they already have Python 3.x on the path.

[Vic20]

SLab is based on Python 2.7 so it will be ok.
It requires numpy, matplotlib and pySerial so you need to have this libraries installed.

In the readme.txt or any other documentation, it would be helpful to newcomers to detail exactly how to install Python 2.7 (easy to do) but pip may or may not be in the path after installation and new-to-Python users are going to get frustrated.  Especially if they already have Python 3.x on the path.

That's why I recommend using a full Python installation like Anaconda:

https://www.anaconda.com/download/

I have no tutorial about pip because I don't use it myself.

[rstofer]

I dumped Python 2.7 and installed Anaconda2 - that installation is HUGE!
As it turns out, pySerial isn't part of the download so there's a bit of a complication getting conda to add the package.  Conda isn't on the path...

For the IDE, I have been using PyCharm and I think I prefer it over Spyder.  I'll play with Anaconda2 a little more next week when I get the analog board finished.  Visual Studio Code might have some good features - it comes along for the ride.

That high priced USB Isolator ($34) from AdaFruit works well.  It turns out the 2 main chips come up to over $20 (qty 1 at Digikey) so if I toss in a few bucks for the other parts, maybe it isn't so overpriced at that.  Of course, it is a lot more than the Chinese copies.  I could see using the Analog Devices reference designs and building an isolator into some projects.

[Vic20]

I dumped Python 2.7 and installed Anaconda2 - that installation is HUGE!
As it turns out, pySerial isn't part of the download so there's a bit of a complication getting conda to add the package.  Conda isn't on the path...

Strange. I think pySerial was in the package. I don't remember having installed it myself.

For the IDE, I have been using PyCharm and I think I prefer it over Spyder.  I'll play with Anaconda2 a little more next week when I get the analog board finished.  Visual Studio Code might have some good features - it comes along for the ride.

I don't use any IDE. Just an interactive window or files written on nopepad+

That high priced USB Isolator ($34) from AdaFruit works well.  It turns out the 2 main chips come up to over $20 (qty 1 at Digikey) so if I toss in a few bucks for the other parts, maybe it isn't so overpriced at that.  Of course, it is a lot more than the Chinese copies.  I could see using the Analog Devices reference designs and building an isolator into some projects.

I plan to propose an isolation solution using optocouplers and an FTDI cable USB. It will be cheaper and the cable can be used on other projects.

[AG7CK]

I now have the basic functionality of SLab running on NUCLEO-F446RE in Python 2.7 manually installed by pip etc. A few printouts are attached below.

SLab will be a very useful toolset for me. I highly recommend it as a starting point for (learning) real bench use of Python, and say "Thanks a lot" to Vic20.

Combined with the ability to control SCPI instruments with PyVISA http://literature.cdn.keysight.com/litweb/pdf/5990-9362EN.pdf p.7 - which I have also managed to get running, I can now imagine myself having all tools needed to set up a few old HP Compaq desktops that I have as dedicated test and measurement terminals.

[
Note:

I have not changed the 'main.c', but just prepared for a new board header file

// Information about the board
//#include "Nucleo64-F303RE.h"  // Board 1
//#include "Nucleo32-F303K8.h"  // Board 2
//#include "Nucleo64-L152RE.h"  // Board 3
#include "Nucleo64-F446RE.h"  // Board 4

My unfinished file 'Nucleo64-F446RE.h' is just a copy of 'Nucleo64-F303RE.h' changed a few places:

#define BSTRING  "Nucleo64-F446RE MBED SLab"   
//#define FAST_ADC // Optimized code for single readings

A few more simple changes will probably be needed due to pin differences between the boards.
]

[AG7CK]

I forgot the code ... and the hardware is just a jumper from DAC1=Arduino-A0-pin to ADC1=Arduino-A2-pin. See the SLab header file, documentation and printout.

Code: [Select]

import matplotlib.pyplot as plt

import slab
slab.connect('COM12')
slab.printBoardInfo()
slab.setVoltage(1, 0.33)
print("DAC1 nominal output "+str(0.33))
a1 = slab.readVoltage(1)
print("DAC1 measured by ADC1 "+str(a1))
slab.setVoltage(1, 1.33)
print("DAC1 nominal output "+str(1.33))
a2 = slab.readVoltage(1)
print("DAC1 measured by ADC1 "+str(a2))
slab.setVoltage(1, 2.66)
print("DAC1 nominal output "+str(2.66))
a3 = slab.readVoltage(1)
print("DAC1 measured by ADC1 "+str(a3))

x1, y1 = [0.33, 1.33], [a1, a2]
x2, y2 = [1.33, 2.66], [a2, a3]
x3, y3 = [0, 3], [0, 3]


plt.title('SLab Test (3 points linearity check) : ADC1 vs. DAC1')
plt.xlabel('nominal voltage DAC1')
plt.ylabel('measured voltage ADC1')
plt.plot(x1, y1, x2, y2, x3, y3, marker = 'o')
plt.show()


[Vic20]

Guys, you do want to update that if you don't have a Python 3 version already:
https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst

There is no good reason to start a new project with Python 2.7 today, even if your machine doesn't come with Python 3.x out of the box.

I had a quick look through your code and for the most part it is just replacing the print statement with the print() function (which is, btw, possible to use in 2.7 too if you want to maintain compatibility).

When I started SLab developement I thought about using 3.x
I didn't knew about libraries that I would need in the future so I opted for the most compatible version at the moment
The idea is to make the final version run both on 2.7 and 3.x, but, for now, it is 2.7
I think that some serial code can also be affected a part from the print code

[Vic20]

I now have the basic functionality of SLab running on NUCLEO-F446RE in Python 2.7 manually installed by pip etc. A few printouts are attached below.

SLab will be a very useful toolset for me. I highly recommend it as a starting point for (learning) real bench use of Python, and say "Thanks a lot" to Vic20.

Glad that it is usefull for you
When you have a final firmware version for the F446RE board, i can add the files (source and binnary) to the Github proyect in a contribution folder.

[janoc]

Guys, you do want to update that if you don't have a Python 3 version already:
https://github.com/numpy/numpy/blob/master/doc/neps/dropping-python2.7-proposal.rst

There is no good reason to start a new project with Python 2.7 today, even if your machine doesn't come with Python 3.x out of the box.

I had a quick look through your code and for the most part it is just replacing the print statement with the print() function (which is, btw, possible to use in 2.7 too if you want to maintain compatibility).

When I started SLab developement I thought about using 3.x
I didn't knew about libraries that I would need in the future so I opted for the most compatible version at the moment
The idea is to make the final version run both on 2.7 and 3.x, but, for now, it is 2.7
I think that some serial code can also be affected a part from the print code

The problem is that the "most compatible version" is 3.x series now, not 2.7 anymore. Unless by "most compatible" you mean "comes preinstalled on a Mac". 3.x series ships pretty much with every modern Linux for a few years now and popular Window distributions, such as Anaconda, ship 3.x by default. Also the default download on Python.org is a 3.x version.

There used to be issues with Python 3 that some libraries that depend on binary plugins (Numpy/Scipy mainly) didn't work or weren't ported to Python 3 yet but that is not the case for several years now. Lot of libraries and tooling doesn't even support 2.7 series anymore because it is too much work to maintain a separate codebase.

For example it would be great to integrate your work with Jupyter (http://jupyter.org/), whether the new Jupyter Lab or the older Notebook so that people can easily work with the measurement in an interface resembling Mathematica or Matlab, including interactive plotting, dynamic controls (buttons, sliders, etc) - but the new JupyterLab doesn't work with old Python 2.7 anymore and Jupyter Notebook is not being developed further for 2.7. ...

I strongly suggest supporting Python 3 - you will need to do it in the future anyway and it is best to do it while the codebase is still small. Porting a large pile of old code is not fun. If you need some help or advice on this front, feel free to PM me, I have quite a bit of Python experience.

[rstofer]

It's alive!  I finally received the PCB only to find out I needed solder paste.  It took a day or so to sort things out.

It seems to pass all the functional tests so now I need to get after the diode and transistor examples.

[Vic20]

I strongly suggest supporting Python 3 - you will need to do it in the future anyway and it is best to do it while the codebase is still small. Porting a large pile of old code is not fun. If you need some help or advice on this front, feel free to PM me, I have quite a bit of Python experience.

Don't worry. I will support Python 3. Probably in next SLab version.
The idea is that next version will be compatible with both Python branchs.
I will contact you if needed, but as I only use the SciPy libraries (numpy, matplotlib...) and the pySerial library, I think it will be easy.

[AG7CK]

@Vic20

I am sorry, but I am am not able to contrinute to the code. I have already done one mistake by thinking that I could use A3 in stead of D13 for DAC2. My mistake came about when I looked at these 2 pinout diagrams, noting that my board had an analog pin 3 while yours did not:

https://os.mbed.com/media/uploads/adustm/nucleo_f303re_arduino_left_2016_7_22.png

https://os.mbed.com/media/uploads/adustm/nucleo_f446re_arduino_left_2016_7_22.png

Then when taking a coser look I realized that the reason you use D13 with the reduced range caused by the led is that all boards only have one analog output A2.

So I will not try to change anything yet. (I have looked at the user guide / data sheet, and things like (Arduino pin) A3 port PB0 ADC12_IN8 (303-board) ADC3_IN12 (446-board) tells me little more than that it is some mux/ADC stuff).

I will now concentrate on my experimental setup and use only ADC1 and DAC1. The most important thing for me in getting your project running is that I am now convinced that I will switch from Basic/Fortran/C/Pascal to Python whenever possible. So thanks again.

It will take me months/years with Python in order to integrate clock, trigger, relays, thermometer, PID controller, 6.5 digit DMM, PSU, precision current source and other devices controlled by RS232, SCPI, non standardized GPIB etc. in my experiment set up.

In addition to your DAC/ADC I will try to get these Arduino/Python based projects running in order to control vintage devices and DIY hardware for experimental physical electronics:

https://github.com/mathiashelsen/agipibi

https://pypi.python.org/pypi/instrumentino

[Vic20]

@Vic20

I am sorry, but I am am not able to contrinute to the code. I have already done one mistake by thinking that I could use A3 in stead of D13 for DAC2. My mistake came about when I looked at these 2 pinout diagrams, noting that my board had an analog pin 3 while yours did not:

https://os.mbed.com/media/uploads/adustm/nucleo_f303re_arduino_left_2016_7_22.png

https://os.mbed.com/media/uploads/adustm/nucleo_f446re_arduino_left_2016_7_22.png

Then when taking a coser look I realized that the reason you use D13 with the reduced range caused by the led is that all boards only have one analog output A2.

AFAIK both the F303RE and F446RE have the DAC outputs at A2 and D13
As D13 is connected to the user LED in both cases, you need to mess with solder bridges or add gain in the D13 DAC driver.

So I will not try to change anything yet. (I have looked at the user guide / data sheet, and things like (Arduino pin) A3 port PB0 ADC12_IN8 (303-board) ADC3_IN12 (446-board) tells me little more than that it is some mux/ADC stuff).

Yes, ADCs are muxed. For instance PB0, connected to arduino pin A3 is the input number 8 of both ADCs #1 and #2 in the 303 board. But in the MBED code you only need to indicate which are the pins associated to the four ADC inputs SLAB uses.

In addition to your DAC/ADC I will try to get these Arduino/Python based projects running in order to control vintage devices and DIY hardware for experimental physical electronics:

https://github.com/mathiashelsen/agipibi

https://pypi.python.org/pypi/instrumentino

Seems interesting

[Vic20]

I strongly suggest supporting Python 3 - you will need to do it in the future anyway and it is best to do it while the codebase is still small. Porting a large pile of old code is not fun. If you need some help or advice on this front, feel free to PM me, I have quite a bit of Python experience.

I have taken your suggestion seriously and I'm now proud to announce the 1.3 release of the SLab system.
https://github.com/R6500/SLab
It now should run without problems both in Python 2.7 and Python 3.x

[rstofer]

Regarding the transistor family of curves:  Am I correct in using 330k Ohm for the base resistor and 1k Ohm for the collector resistor?  FWIW, I am using a 2N3904 and I don't recall the documentation specifying a particular transistor.

Code: [Select]

dc.iDeviceCurve(1.0,3.0,0.25,0.0,3.2,0.1,ri=330.0)

For some strange reason, I only get 4 curves versus 8 and my graph scales don't extend as far as those in the documentation.

In any event, this project is neat!  I have a lot to read but, so far, the Examples are working out fine.  Except Example 12 and that will turn out to be operator error...

OOPS!  Forgot the picture...

[janoc]

I strongly suggest supporting Python 3 - you will need to do it in the future anyway and it is best to do it while the codebase is still small. Porting a large pile of old code is not fun. If you need some help or advice on this front, feel free to PM me, I have quite a bit of Python experience.

I have taken your suggestion seriously and I'm now proud to announce the 1.3 release of the SLab system.
https://github.com/R6500/SLab
It now should run without problems both in Python 2.7 and Python 3.x

Excellent!  Thanks a bunch! 

[rstofer]

For some strange reason, I only get 4 curves versus 8 and my graph scales don't extend as far as those in the documentation.

What's actually happening is that the top trace has the other 4 traces buried under it.  Not exactly, but close enough they can't be seen unless I zoom in to a rectangle.

I need to think about what that means.  I did a few print statements to convince myself that I was looping enough times and generating 8 traces of data - which I am.  But the last few blocks look pretty much alike.

Maybe I'm saturating the transistor.