Project Logs

Collapse

• Towards Telemetry

  Jon Kunkee • 11/29/2023 at 04:27 • 0 comments

  If you try to use a TLS network connection on an ESP8266, you'll find you rapidly run out of RAM and flash--at least, if you program it using the Arduino tools. Crypto like that is pretty big, especially if you're using a properly sized set of TLS certs. (My foray into this world was primarily with the Azure IoT Hub SDK.)
  

  So, I'm doing what I did on my AirQualSniff project: Unencrypted and insecurely authenticated MQTT over my LAN. It's not ideal, but it'll work for now and means I don't have to worry about code size or cert rotation.

  I really like Particle.io's solution, but it's tied to their hardware and has pretty severe payload size limitations. While not an issue for a Geiger counter, it hurt when working on AirQualSniff.
  

• Enclosure Rule of Thirds?

  Jon Kunkee • 11/26/2020 at 17:04 • 0 comments

  Now that all the circuit boards are mounted in my enclosure and are wired up...well, it won't close. The wires are too bulky. I'm thinking for future projects like this, the "haphazard wiring" solution will trigger a sort of rule-of-thirds: Leave about a third of the volume for wiring.

  This isn't the first time I've hit this problem; my Eve pendant project should(TM) fit in the tiny pendant the way I designed it, but only if wiring is infinitesimally thin. That project will require some serious iteration; this one can probably get away with a 3-D printed spacer shell until I have the chutzpah to work on the next iteration.
  

• An Enclosure for Closure

  Jon Kunkee • 11/16/2020 at 07:41 • 0 comments

  My friend, [Ramjet], has a workshop with many tools for the shaping of matter and he knows how to use them. He is also leaving my area soon to make a COVID-safe months-long visit to family, rendering that expertise out of reach. Fortunately, he agreed to spend an entire Saturday helping me get my collection of loose circuit boards mounted in the project enclosure.
  

  Twelve hours of masked work (less a short break or two) paid off!

  (Pictures and details after the break)

  Read more »

• Preparing for a proper enclosure

  Jon Kunkee • 11/09/2020 at 07:37 • 0 comments

  With the electronics successfully mounted to the foam board and a good chunk of the programming done, Version 1 is done.
  

  It is now time to face my nemesis, the enclosure, for Version 2.
  

  Some time ago, once I had the larger components figured out, I acquired a Hammond Manufacturing 1591XXESBK project box for this. (This is what provided the outline and size constraints in the v1 mounting post's pictures.) I also found a shiny power button, some nice tactile buttons, and a couple of switches to go with it. A few protoboards, some solid wire, the upcoming long absence of a friend with hand tools know-how, and the motivation of participating in the Hackaday Remoticon got me over the line to start prepping the project to get bolted into a proper home.

  Read more »

• Wiring Module Boundaries

  Jon Kunkee • 07/18/2020 at 00:37 • 3 comments

  (This post is more of a lab notebook page than a blog post.)
  

  Version 1 really only has two modules: the DIYGeiger kit w/WiFi and the battery management system. To properly play with it, though, there are several interconnects:

  1. USB power to BMS
  2. BMS power to DIYGeiger
  3. I2C data from DIYGeiger Atmel or ESP8266 to BMS
  4. Atmel programmer to DIYGeiger
  5. ESP8266 programmer to DIYGeiger

  Characterizing each of these will ensure I can easily perform maintenance tasks (reprogramming) and ensure safe interoperation (I2C voltage levels).

  USB power to BMS

  The LiFePO4wered BMS is designed to be pretty resilient to any USB power coming in on a micro USB connector.

  BMS power to DIYGeiger

  The VOUT pads and Pi connector pins 2 and 4 have regulated, switched 5V on them referenced to GND.

  Pi pins 6, 9, 14, 20, 25, 30, 34, 39 are GND.

  The VBSW pads have switched 3.2V (battery voltage) on them.
  

  I2C and other signals on BMS side

  Pi connector GPIO2 (pin 3) is I2C data.

  Pi connector GPIO3 (pin 5) is I2C clock.

  Pi connector GPIO14 (pin 8) is the shutdown complete signal receiver.

  Since this BMS is intended for use with a Raspberry Pi, all three of these pins must be 3.3V.

  The BMS as an I2C peripheral expects the I2C controller to provide the pull-up resistor. When I choose the new controller, I'll have to provision that.

  It is not clear from the docs if it is 5V-tolerant. [Edit: Per a comment below from the creator of the LiFePO4wered/Pi+ BMS (!!!), the I2C and GPIO pins on the BMS are decidedly *not* 5v-tolerant.]
  

  I2C and other signals on Atmel side

  (not what I went with)
  

  The DIYGeiger Plus kit uses most of its ATmega1284P pins, but a few are available for other uses.

  ATmega1284P GPIOs take inputs and outputs relative to Vcc as fed to the chip. Inputs can be 3.3V and Vcc 5V and it will register, but outputs are still Vcc-based and inputs cannot exceed Vcc+0.5V.

  The DIYGeiger Plus kit's Vcc is 5V, so its outputs to the BMS will have to be divided or shifted.

  The I2C Data line is bidirectional, so can it work through a voltage divider?

  Voltage divider ratio: 3.3V / 5V = 0.66

  Low-side output: 3.2V * 0.66 = 2.1V

  BMS hi/lo threshold: ???

  So: probably?
  

  Can the line survive the extra load on the line?

  ...should I just use the ESP8266?

  Are there spare lines on the hex buffer?

  What pins are accessible where?

  Can the ATmega do I2C? Yes, with software on top of the Two-Wire Interface peripheral.
  

  I2C and other signals on the ESP8266

  Using the ESP8266 means that the DIYGeiger Plus kit has to turn on its most power-consuming component to reconfigure the BMS and to tell the BMS it has gracefully shut down.
  

  The ESP8266 isn't that power hungry if the WiFi is off.

  It is generally known to be a 3.3V chip including its GPIOs.

  It does have one I2C peripheral. This would require some work to coordinate with an OLED screen.

  This is the option I went with to avoid the confusion that is evident in the previous section. It also avoids the need to reprogram the Atmel.

  The library I'm using to drive an OLED screen over this same connection seems to cause problems, but the next release will have some promising fixes.
  

  A Note To Self About I2C

  Talking this over with my brother, it seems that I2C is one of the easier protocols to cross voltage domains with. It's open-collector, so each end needs to be able to sink enough current to drop the line voltage across the pull-up resistor. They also need to not be cooked by the idle line voltage in the high-Z state. This is not specified for the BMS, so I'll have to re-read the spec sheet and maybe email the support line to figure this out.

  I also really like the idea of wiring the BMS control lines to the ESP8266, so this may be moot. (I do need to figure out where that pull-up resistor is no matter what.)
  

  Atmel Programmer

  (Only needed if BMS is to be run by it)

  ESP8266 Programmer

  A 5V UART connection allows for programming the GK WiFi ESP8266 when detached from the...

  Read more »

• Enclosures and Adam Savage's Advice

  Jon Kunkee • 07/05/2020 at 01:49 • 0 comments

  So far in my short making career I have stressed a lot about enclosures. For this project alone I have over a dozen sketches of five different designs from "Eberline Style" to "The Suitcase" to "Sample Analyzer" with crazy ideas like levered lead doors and smooth integration of USB and SD slots with case and a compartment for calibration controls--all of which are waaaaay beyond my current skill set.
  

  That was where I had stalled out on this project until I recently finished Adam Savage's book, Every Tool's a Hammer. One of the points he makes in it is to plan to build something multiple times before you're done with it, iterating as you go. Another point is that one can (and often should) use cheap, forgiving prototyping materials to make screwing up cheaper both in monetary and momentum/emotional terms.

  That's about when I decided to simply bolt the bits of kit I have assembled onto foam-core posterboard.

  Many holes need to be aligned? Punch pilot dents with the standoffs attached to the circuit board and drill them with my fingers and a drill bit.
  

  Did I misalign a hole? Meh, ream it out. It's just foam.

  Will this layout fit in my project box? Trace the box on the foam board and pretend it's the bottom or top of the box.

  Measure twice, cut once? When you have 10x more planar material than you need and cuts are just a knife stroke, cut twice.

  It turned out OK.

  This one shows the nylon standoff in the high voltage section with the traced outline of the case.

  The standoffs' threaded sections weren't quite long enough to get through the foam board.
  Here's the whole assembly.
  

  An overhead view:

  Note the gap between the WiFi and battery modules. This iteration helped me notice some layout constraints, like making sure the wifi module can slide in and out of place, realizing the SD card and RTC battery slots will probably be blocked by the sides, noticing that the some of the wiring will be a bit tight on the sides, and thinking about alternate layouts that might fit better.

  It's also nice that Version 1 is just a little wiring away from being done. :)
  

• A Note on Battery Systems

  Jon Kunkee • 10/22/2019 at 05:24 • 0 comments

  My previous post focused heavily on battery chemistry and sizing. As I looked at the available systems I thought the LifePo4wered/18650 would be perfect: it comes with a battery cell, it handles USB connection and charging, and I can use the raw battery output to power the Geiger counter. (It is not available to order, but if you talk to the seller they may be able to work something out with you. They were exceptionally helpful to me.)

  In this case, though, the /18650 is the same as a /USB: it's just the USB connector and charging IC--the lack of output regulation that I was excited about comes at a cost: no overdischarge protection. If a LiFePO4 cell is drained too far, it simply stops taking a charge.

  This doesn't sound so hard: set up a low-on-resistance FET in series with the raw battery output, then set the gate to turn off when the voltage falls below a certain threshold. This last part could be done with the AtMega on the Geiger counter board, since I'm pretty sure at least one ADC and one I/O pin are free and some creative wiring could get the AtMega to turn itself off reliably while the USB could override it to turn everything back on.

  I felt that solid-state relays are overkill (typical current ratings), so I did not consider them much. Some ICs that do the switching are called power switches and readily come with on resistances as low as 30 milliohms, but they don't come in maker-friendly modules that I could find rated for less than 20A. I could design a really small board for one, I could reconsider SSRs, or...

  I bought the LifePo4wered/Pi+. It does overdischarge protection and larger battery cells, all in a nice shiny package. I currently plan to reprogram the AtMega to use some of its spare I/Os to talk to the MSP430 on the battery management system, though I may reconsider getting an SSR module and using the /Pi+ with my Pi.

  I like to think of things as block diagrams. Here's how I ended up seeing the /18650 in terms of a full battery management system:

  • Battery cell
    • LiFePO4 18650
  • Battery charger
    • IC (noted in schematic)
  • Battery overdischarge protection
    • None
  • Battery output regulation
    • None (only needed to match sink characteristics)
  • External power source
    • USB
  • External power sink
    • Pololu 5V regulator

  Addendum 6-20-2020:

  The Pi+, on the other hand, sits only somewhat different in my mind:

  • Battery overdischarge protection
    • provided
  • Battery output regulation
    • 5V

  This may mean I drop the Pololu regulator and simply use the 5V from the Pi+.

• Power Source Selection

  Jon Kunkee • 09/26/2019 at 04:54 • 0 comments

  I debated with myself quite a bit about what kind of power source to use for this project.

  I do apologize for the rambling nature of this, but it does reflect my thinking. It was not a clean-cut engineering problem, but a mix of personal preferences and decisions made in the thick of learning the topics and discovering available solutions.
  

  AC

  Wall outlet power is nice when the power is on and can't be overcharged, but it is not useful wherever power is not available--whether during a blackout or hike.

  Batteries

  Batteries are mobile, right?

  Well, here's my train of thought. As I wrote it out, I noticed that it's chock-full of received wisdom, folklore, and places where actual numbers could be referenced instead of rough hand-waving. Still, here you have it documented so perhaps you won't make my mistakes. :)
  

  Alkaline batteries are ubiquitous, but they aren't reusable. They keep alright--if they're not rechargeable, they can't be overcharged, right?

  NiCad batteries lose capacity if kept charged.
  

  Lead-acid batteries have fairly low energy density and, depending on the design, venting issues. They tend to be large and don't handle deep discharge well, but they're incredibly well-studied and well-tested. They don't tend to come smaller than lantern batteries, and that's close to the size of the rest of the project combined.
  

  NiMH batteries don't handle overcharging well and, well, I don't like the chargers and usage patterns I've had experience with. If I could find a good charger+monitor circuit (I haven't looked), that combined with the easy availability of NiMH cells would make this my second choice.

  Lithium Ion and Lithium Polymer chemistries have incredible energy density, but I've had pouch cells swell before, they're known for capacity degradation on the order of 100s of cycles, and also don't handle staying charged very well.

  LiFePO4 batteries have a little more than half of the energy density of their LIon and LiPo cousins, but they don't have the safety issues and they handle constant top-offs (being plugged in for weeks at a time) well. Once I found a good charger circuit, the LiFePOwered/18650, this became my first choice.

  Power Requirements

  The highest sustained current the GK Plus kit (with display and even GPS) is stated in the kit assembly instructions as about 90 mA. Since it's a little unclear what voltage this was at, that doc later says that a 600mAh battery will yield about six hours of runtime, and the kit runs at 5V internally, I figured it was 90 mA at 5 V. That isn't a hard peak current to supply.

  The trick is that I am building in the GK WiFi kit with an ESP8266 on board. My rule of thumb for WiFi is peak 1A current draw, though one blog measured the ESP8266 peak current during startup at 480mA or so. Even if the battery won't last more than a few hours, the charger and chemistry and cell should all be able to handle that much current continuously.

  I do plan to be able to display the WiFi board when off AC, so it's more of the on-AC steady-state situation that governs my continuous 1A requirement.
  

  With this in mind, I figured something around 2000mAh would yield >12h of runtime without AC and with WiFI off, while it would still be ~2h with WiFi on. This was partially driven by LiFePO4 cell sizes, with 18650s being about this size. The next size smaller felt too small (too short of a runtime) and the next size up gets expensive, large, and beyond the convenience of the LiFePOwered kits' holder brackets.

  So...some technical reasons, many not-so-technical reasons. That seems to me to be much like commercial hardware and software development.
  

• Kit Assembly

  Jon Kunkee • 09/22/2019 at 05:15 • 0 comments

  In three sessions of a few hours each, I followed DIYGeiger's excellent instructions to assemble the kits. This post is really about the finished kit, so it has only a little bit about the process.
  

  Here's the GK Plus with the Display Adapter, stacked with full headers:

  This is not a beginner project, but it was doable with my limited experience. Please don't notice my mistakes, like the fat solder joints on the Pololu regulator (small green board in bottom right) or the obvious water spots where my alcohol-based cleaning wasn't super thorough. :)

  Read more »

• Kit Selection

  Jon Kunkee • 09/19/2019 at 05:55 • 0 comments

  As far as Geiger counter kits go, I did a bit of trawling around before settling on one.

  If memory serves, my criteria ended up going something like this:

  • Affordable (for me this meant < $100 USD)
  • Comprehensible
  • Documented
  • Open Source
  • Attributed
  • Quality
  • Bring Your Own Tube (I have the one from my dad)

  Searching on the web led to several kits of varying documentation and quality. One in particular stood out to me:

  https://mightyohm.com/blog/products/geiger-counter/

  (Note that this is also sold by AdaFruit.)

  I very nearly bought this one, and it is a wonderfully straightforward design. One of the most amazingly human and connective things MightyOhm does is to acknowledge a source of inspiration for the design: DIYGeiger.

  When I followed that lead, I found a much more sophisticated set of kits that are under active development by person with passion for the projects and a predilection for documentation.

  When I was a kid, i wanted a box that clicked around radiation, allowing me to peer into the unseen world of nuclear physics. MightyOhm's kits do just that.

  DIYGeiger's kits add to that the worlds of WiFi connectivity, signal analysis, colorful GUIs, useful DC input ranges, SD card logging, microcontroller programming, and GPS tracking. Source code is available and documentation doesn't stop with 'put 1/8W 1Kohm resistor in slot R5'--it goes on to talk about power supply selection, schematics, and instructions for tweaking the high voltage along with background information about making HV measurements and characterizing GM tubes. On top of that, the kits did not necessarily come with a GM tube and were adjustable to work with whatever tube is available.
  

  I went with the GK Plus (with Display Adapter), Pololu regulator, and GK WiFi Kit. I think I'll add a GPS module eventually. Note that at this point I had not really settled on a power source beyond using a battery. I got the Pololu as a matter of flexibililty.
  

  BroHogan's customer service was responsive and helpful when I had a problem with the shipping address, and he threw in a couple of amazing little freebies that I expect to put to good use.

View all 11 project logs