That’s very useful to know! Here’s a TI app note that shows one way of doing it. (TI app note, but a Linear part for the charge pump… [Wrong. It’s a TI part. I thought LM… meant Linear.])
You could offset the sense voltage instead of a negative supply. A simple voltage divider and resistor to the sense resistor point can offset that by say 50mV (you now measure on a shifted voltage)
The input control voltage will be shifted also, so the DAC output voltage won’t current direct
… Won’t correlate to a current directly, but that can be calibrated out at regular intervals
Thanks, Klaus! That sounds like something that would work, and the DAC calibration would be easy enough.
Learning analog electronics is interesting. It’s been quite a while since I’ve started learning a new field where there are so many interconnected things to think about, and so many opportunities to make mistakes. It should be frustrating, but somehow it isn’t! (I do wish I’d started reading The Art of Electronics earlier though, since this project might be easier once I’ve read their opamps chapter.)
I think I might have found a little problem. It might not be everything that’s wrong, but it’s definitely a thing that’s wrong. Here’s a funny thing. If you’re in KiCad’s schematic editor, and you bring up the “add symbol” dialogue and search for “diode”, you get a symbol called “DIODE”. Which, if you’re me, you go ahead and use, assign a reasonable footprint, and you’re off to the races.
Unfortunately, a healthy dose of paranoia would have led to a careful reading of the small note that goes with that “DIODE” symbol, which says: “Diode symbol for simulation only. Pin order incompatible with official kicad footprints.” And indeed, every single two terminal diode footprint in the KiCad footprint libraries has the anode on pin 2 and the cathode on pin 1. This “DIODE” symbol has them the other way round. To be fair, the symbol is in a library that has “spice” in the name, but it seems a little unfortunate that the simulation symbols are different from and pin-incompatible with the “normal” symbols.
For reference, the right one to use is symbol “D” in the “Device” library.
Maybe I’ll try unreversing my diode tomorrow and see what happens…
I’ve been thinking about the problems I’ve been having more generally. I don’t think the output swing of the opamp is a problem: the threshold voltage for the FET I’m using is 1.7V, so the opamp only needs to bring its output below that to switch the FET all the way off. I think my tiny signals probably are a problem, and although I like the idea of using one of these charge pumps to fake up a negative rail (or doing the voltage divider plus opamp follower thing to make a split supply), I think Klaus’s suggestion of biasing the current sense point is what I’ll try. It has the great benefit of being something that can be bodged together with a few resistors. (Of course, I’m really hoping that putting the diode the right way round will make everything suddenly work, but it’s good to have an option to try if that’s not the case.)
There is an extra trick to get even better performance
You offset shift the sense voltage by say 50mV
That means the DAC has 0 current setting at 50mV, which takes up some of your DAC resolution
You can level shift the DAC output with the same resistance. The microcontroller is supplied from the same voltage, as is the level shifts. So it’s all ratio metric
For even better performance, use the same resistor array for both sense and DAC since the resistor values track almost perfectly, much better than 0.1% resistors
Thanks! I did wonder about offsetting the DAC output as well, but was worrying about matching the bias points. I hadn’t thought about a resistor array, but that’s definitely the right way to do it!
I think there will have to be a rev. 2 of this thing, even if I do get it approximately working with some bodging this time around. I’d like to have a “design to spec” success with it, rather than just a “limps along, sort of works” result. I’m learning a lot though, which is pleasing, even if the thing doesn’t work yet!
Trying out different ideas plays well with simulation so there’s no gotchas
But, just remember to sit down and look hard at your idea first. Just plopping stuff into Spice is not the way to learn, but can be tempting
I certainly learn by doing, even in Spice. Although I try to make sure I have a goal in mind before I start my plopping.
For example, for my CSOS design, there was a LOT of time spent in Spice designing and tweaking before I got it to the point I was comfortable with. That being said, I was using the math and some tools to help design, but the quick iterations of Spice certainly help provide me feedback when I’m not 100% sure what the next step is for getting the design to do what I want.
At what potential relative to your system ground is “In-”?
It’s connected directly to the system ground.
Yeah, I’m just starting to learn how to use Spice. It looks like another thing with unlimited vistas of complexity, once you start trying to make your own models, or tweak existing models. Using LTSpice the temptation is to use the parts that have models included. But they’re all expensive Analog parts. Sneaky marketing: give the simulation software and models away for free, and get everyone hooked on using your parts…
LTspice is an amazing piece of software. For reference, here’s the schematic for my CSOS. I have imported new models for the op-amps, the FET is an auto generated symbol, and I was able to make other parts to simulate various other bits.
Granted, I haven’t done much analog design in it and therefore haven’t needed to look at their parts much. But I do always try to find models for the parts I want to use. Which are available about 50-70% of the time, mostly depends on the manufacturer.
1 Like
That’s great! I need to start doing stuff like that.
1 Like
So, turning that diode round to point the right way made all the difference…
It’s quite possible that I’ll still need to do the current sense point biasing thing that Klaus suggested to make things work accurately, but I’m now getting reasonable behaviour: I’m able to set the current draw using the firmware I have on the Teensy and the current sensing shows the sort of value I expect, I can set the voltage limit and things get shut down if it’s exceeded. I only did a quick review of things this morning because I want to finish off the Python GUI software I’ve been writing to display current and voltage values in real-time to make testing more convenient, but I’m now back on track!
And I learnt a valuable lesson: I’d been super careful about checking the footprint and pin ordering on the FET I used because I know that getting that wrong is a “classic” mistake. But I totally didn’t think about the diode much: there are only two ways to place it, the cathode is labelled clearly on the symbol, the footprint and the part, so what could go wrong? I won’t do that again. The main principle involved in having electronics assemblies work first time is: TRUST NOTHING!
1 Like
Good news you got it working
I always double check all components since more often than not when a problem occurs in bring up of a board the error is in the layout (simulation should weed out most other errors)
1 Like
Yeah, I’m learning the benefit of double and triple checking! Once you know the things to check, it’s not so bad. You can write yourself a checklist, or use someone else’s and you know what kinds of problems might occur under each checklist point. As a beginner though, you need to see some of these mistakes for real to get that understanding of what to look for. It’s good though. I’m developing a healthy paranoia about footprints and layout issues!
I did some testing! And it (partially) worked!
In a fit of hubris, I made a video of the testing. Bear a couple of things in mind:
-
I had done no testing of the software I show here with the real hardware, so it’s all a bit wobbly. And I discovered a couple of bugs, so not everything I wanted to try worked first time.
-
The sound quality in the first part of the video is terrible. There was a huge rainstorm, I had the door open, and didn’t really pay attention to just how loud it was. (I also didn’t pay attention to the rain coming in through the door into the other room of the shed, so I had to mop up a little flood when I was done!)
There’s some work to be done on calibration and fixing the bugs I found (which are probably software or firmware issues, rather than hardware). I also want to write some more little utilities to measure V/I curves and discharge curves, to complement the “meter” software in the video.
1 Like
As well as the Teensy Load, I’ve also been working on another project, which is a longer term learning thing. It’s called the Mini-Mapper, and it’s a mapping and exploration robot. (Well, it’s going to be a mapping and exploration robot. At the moment, it’s a schematic for an early stage prototype of one part of a mapping and exploration robot and a bunch of more or less infeasible ideas about the rest of it…)
I’ve been keeping quiet about it so far because it’s going quite slowly, partially because I’ve been trying to make an ongoing mixed video/documentary build log of what I’ve been doing. This is mostly something I’m doing for my own amusement, and it does mean rather low-quality videos about more or less low-quality electronics (!), so it might not be of general interest. I’m posting it here in the spirit of working with the garage door up, and to help keep me honest and moving.
I’m close to having a schematic finished for the first part of this, which is a prototype motor control board. I’ll post that for critique once it’s ready.
If you’re interested in seeing any of this, the project page is on my website.
I debugged the Teensy Load problems I had. Pure software screwups! Seems to work pretty well now from my Python GTK meter software. Next thing with that is to write a little utility to collect calibration data and to make the meter UI use that data. Shouldn’t be too difficult.
On my Mini-Mapper project, I’ve got a schematic finished for the prototype motor board I’m working on. It’s taken a surprisingly long time to get that done, mostly because I spent a lot of time making mechanical models of robot components in FreeCAD to make sure that I was lining up a photointerrupter with an encoder disk on a motor shaft just right. Time-consuming, but FreeCAD is a lot of fun!
Here’s the schematic (link to a PDF version below). Any critique very welcome. The idea is to connect this thing to a Nucleo STM32 development board, to drive the motor driver with a PWM signal, to measure the motor coil current (I want to do some current/torque experiments), and to count pulses from a motor encoder disk on the motor shaft using a photointerrupter. I don’t think there’s much scope for doing things very wrong, but I’ve been surprised that way before… Layout next!
