Close

Wiring Module Boundaries

A project log for My Very Own Geiger Counter

Fulfilling a childhood dream

jon-kunkeeJon Kunkee 07/18/2020 at 00:373 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 GK Plus. The GK WiFi contains a diode on its RX line to make it 5V "tolerant".

Discussions

Patrick Van Oosterwijck wrote 10/09/2020 at 18:37 point

Hi John,

Creator of the LiFePO4wered/Pi+ here.  Cool to see someone use it with something other than a Pi. :)  To answer the thing you were wondering about: the I2C and shutdown detection input are definitely NOT 5 V tolerant, sorry!

  Are you sure? yes | no

Jon Kunkee wrote 10/09/2020 at 22:32 point

Thanks! It's really a nice UPS in general, not to mention the better-suited battery chemistry for this use. In my very simple and non-rigorous testing I got 9-15h of runtime depending on how often I had it fire up WiFi, and with a little more work on power management I expect it to do even better. (back-of-the-envelope was 19h, IIRC)

My brother took the time to help me understand the I2C buss topology, and I probably could have solved this one with a simple diode--but I ended up using the ESP8266, which is also 3.3V, rather than mess with that or level shifters.

It made more sense for me to write my own driver for the Arduino environment than reuse your Linux code given my time constraints, but I definitely read your code to make sure I was doing things right. At some point I'll make sure my Arduino sketch is clean and publish it on GitHub, maybe even cleaned up to use your headers. Of course, by then I might have moved to the Espressif IDF which would make that even easier.

I may end up getting two more, budget permitting--one for my Pi and one for an air analyzer where I think the switched 3.3V rail and 5V power availability would be quite useful.

  Are you sure? yes | no

Jon Kunkee wrote 10/10/2020 at 06:33 point

Source is linked on the project page. Post is updated to reflect Patrick's comments.

  Are you sure? yes | no