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!
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.
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.
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!
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)
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!
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.
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!
Layout is done for my motor prototype board, boards and parts ordered…
And I just had a little play with KiCad StepUp. It’s pretty cool! I got this after a relatively small amount of messing around (most of which was vanity: trying to get the silkscreen looking nice…):
I’ve been doing some more stuff on my Teensy Load project. I wrote some calibration software, plus some software to collect data to make V/I curves for devices. The calibration software has some “weird stuff” going on with it that I’ve not figured out yet, but the V/I sampling stuff works nicely, and I was able to make a quick V/I plot for the little breadboard power supply I use, which runs off a 5V wall wart. It’s a very tiny thing (“teensy” even…), but it’s quite fun to type a command line in a terminal window on my laptop and have it spit out a data file containing these measurements from a “real thing”. What can I say? I’m easily pleased!
I only have a couple more things to do on this one before declaring it substantially complete, but I definitely need to sort out the weird thing with the calibration software!
Mixed results today. I get to tick a project off as finished, but it didn’t really work. After a long wait, I finally got the respin of my example Morse blinky thing (the boards were dispatched from OSH Park on April 28, and arrived here in Austria on August 10!). It was a silly project anyway, and it was such a long time that I’d more or less loss interest.
I assembled one anyway, but didn’t do a great job on it. It got dark and I kept going even though there wasn’t any natural light and the lighting in my shed isn’t the best. So there’s a short somewhere. The thing is supposed to blink “K” for KiCad in Morse, which is dash-dot-dash, but instead it blinks dot-dash-dot-dot-dot, which doesn’t mean anything!
Here’s the proof. Anyway, I declare this project done. Which brings me down from seven active projects to six. 14.3% more reasonable!
Pushing past the finish line is important! Good job on that.
I usually keep build logs for myself as well, and I always consider projects “done” when I have a filled out list of things I will (or would) improve on the next rev.
