Project Logs

Collapse

• More software!

  John Duffy • 02/22/2024 at 03:46 • 0 comments

  I see the light at the end of the tunnel, most of the big pieces are in place now.  

  So... fonts

  Very important for simultaneously having the display readable/legible and information-dense.  Easy to make it legible with a huge block font, but then I can't fit more than a few digits.  A tiny font could fill the screen, but would b inscrutable.  In order to push this tradeoff as far as I can requires good fonts, the axis being legibility vs size (separately, horizontal and vertical). 

  Two things to know, the fonts for this are stored as bitmaps, and the screen I'm using now is 128x64, AND updates 8 lines at a time - so it's basically got 8 rows of pixels that are updated together.  That makes it difficult (and slow, and difficult to use the screen efficiently) to update anything other than a full 8-pixel row, so I haven't been.

  Upshot of that is, all the fonts I'm using now are multiples of 8 pixels tall, I've got 8, 16, 24, and 48. 

  Problem I ran into was, that the display isn't crazy wide, especially for the 48-pixel font, digits were previously about 25-30 pixels wide, so couldn't fit more than a couple digits.  Including a unit, milli/micro/kilo/mega and minus sign wouldn't fit more than three digits 

  So, got to shrink the digits horizontally, but don't want to vertically.  

  This was my first step into madness. 

  Fonts and font rendering is a whole rabbit hole I have not dove down before but with this, I've had to start.  My toolchain at this point is three programs, one, FontForge that lets me edit the vector fonts - moving parts around, replacing characters, adding parts (like bars on Z's and 0's, converting triangular-style 4's to open football-style ones, etc).  Then there's another one, FontBuilder, to convert those to bitmap.  Those two are existing programs.  Finally I use a java program I wrote to do pixel manipulation and convert the bitmap to a C header file that the display code can understand.  That took a while but really wasn't *too* bad.  Looking through hundreds of fonts for the perfect blend of legibility, looks, and horizontal size, then tweaking those to look exactly how I want, then tweaking them pixel-by-pixel has taken far more of my finite life (i dunno, thirty or forty hours?) than I ever expected to spend worrying about how the letter M looks (MAN M is a pain at low resolution, you need three lines, which means a minimum of 5 pixels wide with spaces, but then it looks like a sideways E and it's weird.  Lot of fonts I liked had weird M's at higher resolutions too.  That letter alone has been a huge pain). 

  Being a multimeter, numbers are the biggest consideration, of course.  That actually hasn't been terrible, current version is a lightly modified version of "steelfish", which lets me fit five digits across the display, including a +/-, decimal point, and n/u/m/k/M/G, at 48 pixels high, which is all this meter needs. Smaller fonts are different, hacky combinations of BebasNeue, FreeRoad, and LeagueGothic.  Like the look of those more but they're wider, this almost certainly won't be the final version.  The 8-pixel high font has been an enormous pain and is almost entirely handmade at this point, based it off an existing pixel font but changed almost everything. 
  

  So this is *mostly* nailed down by now, though I'm sure I'll keep tweaking it.  

• Software - Round 394

  John Duffy • 01/22/2024 at 07:52 • 0 comments

  Another month, another kajillion hours in front of the computer working on the software.

  Fixes/changes this time:

  -Multicore!  The rp2040 has two cores, this now uses both.  One is dedicated to sampling and per-sample calculations (calibration, filtering), the other handles low-speed IO, ranging, mode switching, and printing to the screen.  Huge pain to keep variables synced between cores, but it works now.
  

  -Stable sampling frequency.  Previously this would one-shot ADC samples as needed, now the ADC samples at regular intervals and the pico reads them as they're available.  This is really the big one, opens up a ton of new options.  Did require going multi-core so the Serial & USB printing doesn't make us wait too long and miss one.  With this I can now do...

  -AC measurement! Finally got around to that.  Needs a high, stable sample rate to get accurate readings.  Supports true RMS, over a pretty significant number of readings.  Little hack for this I was kind of proud of below as well.
  

  -Also, filtering! IIR filters for 60hz and harmonics are added in and work.  I do want some more refinement on switching them in and out and maybe even adjusting strength, Q, etc, but for now I can notch 60Hz, which is the main thing. 
  

  Might not sound like a ton, but this required redoing pretty much everything that hadn't already been redone last month.  It's more of a lasagna-with-one-layer-of-spaghetti of code now.  Still need to clean up the file structure a bit though. 
  

  
  Few specifics:

  1) This ADC I'm using does not have a very stable oscillator, spec is only "somewhere between 3 and 6.6MHz".  This sets the sample frequency, so I'm now using one of the Pico's GPIO (driven of course by a PIO) as the reference clock.  First time I've written anything for PIO! Very exciting, very cool peripherals.  I did plan ahead for this, though more for synchronizing it with something else if that became necessary/interesting, I hadn't noticed that spec.  This is really useful though, because now I can set the clock to anything, on the fly.  This lets us change up sampling for high speed, short sampling instant, accuracy, low noise, etc.
  

  2) The way I'm doing RMS conversion is nontrivial.  It didn't really seem like there's a good way to do an RMS sliding average that works down to 10's of hz without being dreadfully sluggish, so I went with a full sliding window.  Problem is, I've got to sample at ~1KHz or more, and want to integrate for ~1 second so low-frequency waveforms are reasonably accurate, even if I'm not at an exact multiple of the fundamental.  Problem now is, storing and re-adding up 1000+ floating point numbers is going to take a decent chunk of space and time on the pico, probably could but there's a better way.
  

  
  First, we pick a tradeoff of output rate vs storage space vs integration time.  The two control parameters are the "chunk" size, and list length (I'll explain those in a second)
  

  Memory taken up ~= list length * 2 * reading size (so for a list length of 64, and 32 bit floats, that's 64 * 2 * 4 = 512 bytes).  List length must be a power of 2.
  

  Sample rate = ADC sample rate / chunk size - we get the Vrms readings at "sample rate", .  If we didn't care about sample rate, we could do huge chunks and save memory, I used a chunk size of 16.
  

  Integration time = chunk size * list length / ADC sample rate - This is the real kicker - since we need integration time to be only the order of a second, and the sample rate is >1KHz, this means chunk size * list length has to be over 1000 as well, so at least one has to be sizeable, which either means slow updates, OR a lot of memory taken up.  

  On startup we create two arrays of floats, the list, and the sum tree, both empty to start.  Also an index.
  

  list will just be a circular buffer, sum tree will be the clever-ish thing...

  Read more »

• Software update

  John Duffy • 12/21/2023 at 06:47 • 0 comments

  WAIT ARDUINO-PICO HAS HAD SERIAL PRINTF THIS WHOLE TIME?!?!  WHEN DID THIS HAPPEN?!

  I've been using hacks with the preprocessor and dozens of calls like Serial.print("V=");Serial.print(voltageStr);Serial.println(); this whole time!
  

  Dang, wish I'd known that like, four months ago.   Anyway. 
  

  Real quick update, completely overhauled the software, set it up to handle switching between modes make sense, and cut down the spaghetti code.  Well at least a little bit.  Also got most of the weird glitches out of doing large fonts with this display, I can now do 24 and 48 point fonts as well, which are at least closer to a usable size.  Might choose a different font in the future that's a little taller and narrower, but it works for now.  At this point working on making it more real-time so I can get sampling at a consistent frequency to be able to add a notch filter for 60Hz main, some more robust filtering in general, and AC measurement modes.

  Here's the current hardware, I do need to cut down the thickness of this at some point, though it is about 1/2" thicker than originally designed - the switches I used for this were cheap ones off aliexpress, for a nicer rev 2 I plan to use some lower profile but more expensive ones.  That and the ADC and pico are mounted on female headers, so I need some additional depth for those.  
  

• IT'S WORKING

  John Duffy • 11/04/2023 at 08:42 • 2 comments

  Spent the friday night party at supercon getting the display to talk to the frontend, and I've got a working meter! 

  Zero refinement at this point, but you can put a voltage, current, or resistance across it and get a reading! 

  Next big step is a display upgrade, currently the font is only 1/8th the screen height, want to bring that up to use up most of the display, then refine the operation selection, then add autoranging.  Hoping to get that done this weekend, if you're around supercon, feel free to come say hi, I'm the guy that looks like me and won't shut up about his multimeter.  

  I did some basic calibration a few days ago against a nice 6-1/2 digit bench meter.  I made a voltage reference and precisely measured some resistors.  I began to feel the pull towards becoming a voltnut, making nice copper clad boxes for transfer standards.  It is strong but. resist. For now.  I've started dreaming of multiple slopes and integrators.  For now I will take the easy way out. 

• IT'S ALIVE (again)

  John Duffy • 10/27/2023 at 20:55 • 0 comments

  This is like, kind of working!!

  
  I have the first prototype board assembled, and have the paths for voltage, ohms, and current all up and running.  Haven't written most of the software, made the display, calibrated anything, or put the thing in a case yet, but the measurement itself looks like it's working!

  I am excited. Whoo.
  

  Got boards back from fab a little over a week ago, thank you to PCBWay for supplying free boards for the project.  Normally wouldn't take free stuff just to advertise for a company, but this is one of a few companies I've been using for years now and happy with their services.  I've recommended them for prototypes and quick-turn boards for years, even without any incentive. 
  

  
  Boards looked good, funny enough this is my first time ever making slots, but no issues with that.  During assembly, inevitably a couple issues popped up, I'd given a 14-pin SOIC a 16-pin footprint.  D'oh.  Soldering one side down and a few bodge wires to the other side got that working though.  Later on realized that one of the pins on the output shift registers should have been pulled high but was low.  Unfortunately these were tiny DHVQFN packages, but some bodge soldering involving squinting that will probably make my eyes stop working six months sooner, later, and we've got a working board.
  

  Everything went concerning smooth on power up, using the software from the breadboard just read out from the ADC and controlled the PGA out of the box, and my first attempt at controlling the shift registers, gain stage, and ohms sections all worked on the first try with literally zero debugging ... so surely there's probably some horrific, underlying issue with the whole thing that will keep it from ever working.  Either way I'll enjoy the good times before we get to that.

  Now to start putting together the case and display, and start on the real software
  
  

• Layout finished, working on mechanical design

  John Duffy • 09/30/2023 at 07:41 • 0 comments

  Finally finished layout, this ended up being a huge pain though and I'm not super happy with it.  

  Very dense in some places but empty in others. 
  

  Mostly the SPI/I2C/Uart busses going to the input module, ADC, PGA, and radios, and shift registers.  I'm very not happy with the lack of good separation between the analog and digital, and that I wasn't able to get solid ground planes under all the analog lines.  Whole lot of lessons learned but I want to get this out the door already to get *something* together so I can learn all the OTHER ways I screwed it up and can fix them in one go.

  Couple big ones:

  -Having modules on through-hole 0.1" headers makes things a huge pain.  They take up a ton of board space on both layers, so I have to plan on routing around them.  In future I'll probably use SMD header pins.

  -Pi Pico form factor for the MCU wasn't really the way to do it.  Should have had an adapter board and move some of the digital stuff like shift registers to that. 
  

  -Should have made the isolated coms a separate module as well. 
  

  -Having two separate radios was dumb.  Have one, and adapter boards to whatever commodity radios I want.

  -Plan placement with wide digital busses in mind.  I kind of did but it was insufficient, there were a ton of little pinch points where I had to go all over the place.  Also having all the modules spread out meant those busses had to go all the way across and up and down the board instead of being kept short.  I originally placed to keep analog lines short, the ohms and volts sections are right next to the low voltage side of the input protection, and the PGA and ADC are right there in the middle as well.  I'll probably see more problems from having to route big fast digital busses nearby than if I'd had slightly longer analog lines but good separation.
  

  Any case I'm going to make some of the other little boards I need and get this sent out soon.
  
  

  Moving on to mechanical design now.  I found out solidedge has a free, non-cloud version and is related to NX (which I'm already familiar with from work).  Started using that but there's a bunch of weird annoying things about it, like just now I've spent an hour trying to make a simple linear pattern in an assembly.  Yeah turns out you can't, you have to make a sketch with a pattern of something, then make a pattern from that sketch. WHY?! NX supports doing this the normal way, why mess with it?

  Anyway I'm starting that, should be fairly straightforward, it's pretty much just a box with some holes in it for the connectors and stuff. 
  

• Changes partway through layout

  John Duffy • 09/20/2023 at 08:01 • 0 comments

  Some inevitable changes have come up during layout. 
  

  Biggest changes have all been for size - between the volt and ohm protection, two fuses, input module, that I've got less "vertical' room to work with (since the display is separate), and all the big through-hole modular parts (ADC, Pi Pico, radio modules), space is REALLY tight.  I've changed the shift registers from SOIC to a tiny QFN package, and cut a whole bunch of caps and changed the resistors in the voltage frontend to make layout of that section easier.  

  I've also ditched having the PGA/MUX as a modular component - it just doesn't really seem that useful to change that up.  If I've got room in layout I may copy some of the signals to some unused pins on the ADC module - that way if the PGA is limiting in some way in the future it can just be de-populated, and a replacement integrated directly onto the ADC module.  I also realized that going to an MCP3464 may not be a terrible idea - these have some analog gain built into them so with that I could potentially skip the separate PGA/MUX chip entirely. 
  

  I may have to change to SMD header pins for either the ADC or pico.  I like having regular-size pin header holes for as many things as possible since they're so versatile, but if I don't have enough space to route all this there may not be another option. 
  

  Either way here's where it's at now:

  I don't currently have any regular CAD software so can't make models for the non-standard parts.  Namely the fuse holders on the left are just the end clips, the super-wide "DIP chip" in the middle is standing in for the input module, same for the RFM radio in the upper right,.  The ADC module is just a light orange box in the middle on the right.  I'll probably have to finally give in to one of those free cloud-based ones for this eventually to do the case
  

• Schematic and Operation

  John Duffy • 09/16/2023 at 02:14 • 0 comments

  The schematics are done!  I kind of want to do a video going over the design process as this has evolved over what's now several years, there have been a ton of changes to everything. 
  

  
  For now I'll throw some (slightly) better explanations here.

  Lets get right into it. 
  

  Overall block diagram below.  Nothing too surprising, we've got our Volts, Amps and Ohms sections (AFE = Analog Front End) separated, a PGA (programmable gain amplifier) and ADC, and microcontroller.  Specifics of the interconnects to the MCU aren't super important, mostly just some control outputs to the subsections and digital connections to the PGA and ADC.  Only real thing of note is that the front Common jack DOESN'T go straight to the COM global label (which is generally used as our common in the subsections) - it takes a detour through the Amp AFE first.  It doesn't affect much but we'll come back to it.
  

  
  Few things to note in the analog sections are that there are a few different power/signal rails, COM is the star of the show, it's our reference voltage, everything else will be measured relative to that.  It's the same voltage as the Common Jack on the front of the meter.  

  If you're familiar with splitting a single power supply for a virtual ground, skip this paragraph.  If not I won't go through it in a ton of deail, upshot is that COM is about 1.65V (half of 3.3V) relative to the power supply 0V.  It's driven by an opamp (caps are just for decoupling, only R52 and R51 matter):
  

  (this wasn't big enough for it's own section so it's in the MCU section, same as the other supply stuff).
  

  Battery- goes to "D0V" (Digital 0 Volts), Battery+ goes through a 5V regulator to "VSYS".  So VSYS is at 5V relative to D0V.  The pi pico regulator creates "D3V3" (Digital 3.3V, relative to D0V, used to power digital stuff) from VSYS.  "A0V" (Analog 0 Volts ) is connected through a choke to D0V, and U11 shown above creates "A3V3" (Analog 3.3 Volts) relative to that, which is used to power analog parts like opamps.  So A0V ~= D0V (but hopefully without some of the noise), and A3V3 is 3.3V relative to A0V, so ~= D3V3 but may be up to a couple hundred mV apart depending on the regulators.  COM is halfway between A3V3 and A0V, so is roughly +1.65V relative to A0V. 
  

  Upshot: split rails, A0V == D0V = 0V, COM is middle, A3V3==D3V3 = 3.3V  COM ~= Common Jack, but only for low currents
  

  
  We'll start with the Voltage section since it's pretty straightforward.  I made a different version of this as well with a constant input impedance (10MΩ), while this one varies between 10MΩ at < +-1.5V and ~1MΩ at higher voltages.  I'll go into that version later, it's more complicated and not sure it's going to work, while I've already tested this one.
  

  The basic parts are the inputs (Vpin) which goes directly to the front jack, same as Common_Jack, Common, which our reference voltage ("ground"), the protection resistors, R1-R10 (which total to 1MΩ), the attenuation resistors R13 and R14, two switches in U1, "Vout" which goes to the ADC, protection MOVs/GDT, and the frequency compensation caps.  All U1 does is switch R13 or R14 (or neither), and their associated caps, to common.  If we ignore the caps for now, this causes the node at Vout to be the center tap of a voltage divider, with R1-R10 (1MΩ) on the high side, and either R13 (100KΩ) or R14 (6.8KΩ), in parallel with R12 (9.1MΩ), on the low side.
  

  This gives attenuation values of ~1.11 : 1 for neither resistor (and a 10MΩ input impedance), ~11.1 : 1 for R13, (and a 1MΩ impedance), and ~148:1 for R14.  The ADC can take voltage from A0V to A3V3, so about +-1.65V relative to COM.  To keep from nonlinearity near the rails, we'll limit to about +-1.5V relative to COM, this sets our three voltage ranges to 1.5*attenuation ratio, or...

  Read more »

• Fix for ohms section ranging problem

  John Duffy • 09/03/2023 at 03:20 • 0 comments

  GOT IT!

  Figured out how to make ohms work well.  Was looking for a way to get the ranges to overlap better, which would be helped by dropping some voltage (even at very low currents, in the uA range) from the source while keeping the output voltage somewhere around 1.5V and decent drop across the high-side shunt.

  I asked on the stack (and previous log) for a part with a relatively consistent voltage drop from a couple mA down to a few uA, if anyone's looking for a good solution to that problem, a 2-terminal voltage reference, Paul Stoffregen suggested a REF1112, does exactly that.  For some reason I didn't think about a source-follower mosfet though (that doesn't work for the question as asked, but does work for this system as a whole).  Finally got around to actually simulating something since I'm away from home and can't test it in person, so I've got a piece of the schematic:

  It's not super clean, but all the stuff up top is effectively just some pfets switching the 510, 10K, 100K or 1Meg resistors to the 9V rail.  R10 is the resistor being tested, R9 and the diode are input protection, M5 is the source follower (the new part), and Q5/R12-14 are just to enable and set the voltage for that (disabling Q5 lets the output voltage swing up to the full 9V).  For high value ohms, this would be enabled to keep the DUT voltage right at about 1.65V, below a few K, this can be disabled as R9 provides enough voltage drop at the higher measurement current.  I know this isn't a great explanation, planning to do an actual run down of how all this works once it's working but don't have a ton of time right now. 
  

  That said basically the way ohms works is, the voltage measurement path (not shown, impedance ~= 10Meg, which will have to be factored in during measurement but can be ignored for this) is connected to the high side of R10, we then put some amount of current through R9, by knowing that current and the voltage across R10, we have ohms.  Since we're effectively kelvin sensing at that node, R9 and D1 (input protection) won't affect the measurement.  There will be other stuff as well that makes it more impractical to control accurately.  One of R1 through R4 is switched to the 9V rail, we then measure the voltage across it (plus a pfet, but Rdson is in milliohms so can be ignored for now), so we know the current going through it, and thus R9 since there's nowhere else for current to go.  This voltage is tapped off at the two wires going out the right at the top of the image, goes to an opamp and pfet which converts the voltage to a current from the 9V rail towards ground:

  The ratio of R15 to R16 sets the attenuation (since the shunt might have 6+ volts across it, and we have to reduce that to ~1.5V).  We measure across R16, since the current coming down is proportional to the measured voltage, this converts it back to a voltage, but now shifted to be relative to ground (remember shunt voltage is coming from 9V, which is coming from a switcher operating at very low load, so may be noisy or somewhat unstable relative to ground.

  Switching between R1, 2, 3, and 4 (510 ohms to 1Meg) we get different ratios of volts per amp (so with a  1Meg shunt, if we're putting in 1uA, we'll see 1V across it, and thus R15, and thus 0.145V across R16).  The voltage across R16 is what goes into the ADC as measured current.  

• Ohms is kinda working

  John Duffy • 09/02/2023 at 04:39 • 0 comments

  Ohms range is turning out to be a pain.  To have some measure of input protection, I'm basiclaly doing a 3-wire sense with the juntion at the positive jack.  The ohms "force" has a ~1K resistor, switch, ssr, small fuse, and some low voltage movs.  Getting that to be really well controlled would be difficult, so instead I have a known current going into that, the voltage path is high-impedance so most of that goes through the dut, and we just measure the voltage.  Instead of an actual current source, it effectively just uses a resistor going to a boosted voltage (~8V above common, but there's significant drop before the output), measure the voltage across said resistor, then we know the current.  Hopefully that made some sense, I'll post schematics soon.  

  I am working to keep down the number of opamps and other actives, kinda for price kinda for accuracy, kinda just because.  This has made measuring the voltage drop failrly difficult, the adc only has a range of +-1.5V from common, so I have to do a differential measurement of one low and one high-Z node, which can be from 0 to almost 9V apart, then shift that ~9V down to ground and put it within the adcs range.  And the high voltage supply is noisy because it's switched. All of these are fairly simple individually, but getting a setup to handle everything well, without like seven opamps, is challenging (which is half the point of this project anyway, so I'm not taking the easy way out, dammit!). 

  Anyway it's mostly working using an array of resistors and pfets, and a single opamp and pfet to source a current proportional to the voltage across one of those resistors.  That current goes through a smaller resistor to common, which both puts it in the right range and relative to common.  Problem is that if there's high voltage across the high-side resistor, there's not enough overhead for both.  This still works but requires more range resistors.

  Any case I'm mostly accepting ohms range as is for now and moving to putting it all into KiCad, I'll finalize the design and put up schematics soon.  

  Mean time does anyone knows of a component with a roughly constant voltage drop (looking for about 3V, but could chain a few) even down to the uA range?  That would be helpful for this.  So like an ideal diode (where "ideal" includes a ~0.7V drop) would work fine by just putting a few in series, problem is real diodes drop goes down close to 0 once you get below a few dozen uA.  

View all 12 project logs