XpandShield MK I

It started 2020 winter when things start to get cold. How cold? We do not have a good thermometer at home. The one on the alarm clock is 10 degrees away from what it is, and the one on the air-con controller jumps around. The mechanical one is broken and the "Galileo thermometer" only had such a limited range.

So instead of buying a thermometer, I went out and purchased a temperature sensor. And I want a good sensor, because bad sensors like the ones in my alarm clock doesn't even do a good job being a "reference". So I went out, and got myself a SHT-30.

Then I started to hook it up to the board. All of my projects revolved around the Arduino Leonardo, and, with its many pins (and functionality), along with direct USB, it's a good place to start.

About half a year earlier than that, I had put together a "Arduboy hat" for the leonardo with a "proto shield".

Being a absolute nightmare to wire even without the expansion port, I decided to sit back and draw a PCB instead.

On a whole, the board feature places for 6 buttons (input), a display (output), beeper(output), led(output), which form a decent interface. The "expansion connector" in the middle uses the "Arducart" wiring and have pins for power, SPI, I2C, serial and a analog pin to connect other things -- such as the SHT-30.

But hey, the Arduboy library is designed for ATmega32U4 and thus won't work with the Arduino Due I wanted. And this is the single largest problem in the entire project -- where I had to come up with the code for the display (which include the font and function for displaying numbers and numbers with digits), the code for the buttons, and the code for the SHT-30.

Back before the board is up, I had the Leonardo listen to Serial over USB for the commands to send to the sensor, and send the readings from the sensor back over to Serial, where the Arduino IDE then listens to. Then I do the data conversion with my Ti-84 CSE hand-held calculator to get the temperature reading.

This is before the ordered PCB had been delivered.

Eventually the PCB is fabricated and delivered, and a (optional) case is made from a piece of wiring duct.

And since the PCB is here I decided to put the display on and start working on the display code. Then I decided to automate the code for the data conversion from the sensor.

Well, almost.

Notice how I used separate RGB LEDs instead of a common anode RGB LED (instead of the more common common cathode RGB LED) because the very slight difference between the two can cause issues with "why is my RGB led not working?"

It also only work when plugged in, so I started to think of a way to power it with a battery. But having a second port just so you can charge the battery sound utterly stupid to me, so I thought of a way to power the board with the power pins while there is no USB power, and charge the battery via the power pin when the USB power is on.

But voltage-regulated switch is difficult to find and complicated to work with. So I made the compromise by ensuring that the battery will not explode from over-charging when the voltage from the power pin rises, and add in a switch for manual toggle between the two.

The charging module I settled on is the TP-4056, however, good luck finding one with DIP packaging. So you will likely be buying modules. Good luck finding one with 2.54mm-spaced breakouts. You can bend the pins that connect the two, or use wires, but it's not sturdy.

Luckily I was in china and we had a place called Shenzhen. And over there, there is a cool dude that thought about making something other than those (utterly stupid and repetitive) blue boards with a connector at one end and two pins at the other.

And THOSE pins, are 2.54mm spaced.

Technically I can use something as simple as a resistor-pair voltage divider, but it isn't too good for the battery in the long term and it varies with load.

I guess we can have the TP4056 as the single surface-mount item we have to solder, as I had recently soldered a SOP-8 amplifier for a cheap DIY USB speaker kit, and I think it is not something overly difficult to pull off with a generic soldering iron. The other resistors and capacitors can be swapped for thru-hole ones. Much like the speaker kit.

So eventually I fixed the display code and get the numbers showing up. It's time to jump back to hardware and add the charging circuit.

And I am in a BIG rush to see whether that scratchy circuit that I had drawn above actually work, so I didn't bother with things for too much.

Ok. Before we move on to the rest, allow me to jump in and explain why this thing will even work.

The Atmel Mega32U4, or, the Arduino Leonardo (or at least, most of it), "runs on 5V". So when you plug it in via USB, the current flows from the USB to a regulator. Then, because the mcu "runs on 5V", it connects to the 5V pin. Then it goes to the mcu.
(note: on the Arduino Leonardo, the 5V pin is closer to the regulator (length over pcb tracing) than the mcu.)

But when you go look at the datasheet of the Atmel Mega32U4, it says:

6.2 ATmega32U4

Speed(MHz)  Power Supply  Ordering Code    Default Oscillator
                          ATmega32U4-AU      External XTAL
    16       2.7 - 5.5V  ATmega32U4RC-AU    Internal Calib. RC
                          ATmega32U4-MU      External XTAL
                         ATmega32U4RC-MU    Internal Calib. RC

... and this is a very generous range, since the voltage for the Lithium batteries are 3.7 - 4.2V.

The LEDS, buttons and beepers are easy, but the display goes a bit more complicated ...

Because as you can see, in the SSD1306 datasheet, the voltage for driving the panel is between 7V to 15V.

But it also have a configurable built-in charge pump. And it looks like that as long as the voltage is higher than the logic voltage (3.3V) it should be good.

And we are not driving the voltage down to below ... say, 3.5V because it will hurt the battery. Or the listed 3.7V because you find out that your battery have a protection circuit.

So that's why it's supposed to work.

Ah. Here I actually had it run my first Arduboy game -- the Breakout.

By this point, all we had remaining is a little bit cleanup of the mess, and that will be the XpandShield v1.0.

Ignore that 5354B diode. That will eventually be replaced by the one in the parts list -- the SN240.

I was very happy at this point. I even bundled stuff as "kits" and started asking my friends if they would want one for $20. Of course, no one is interested.

PROJECT COMPLETE!

______

But what about the possibility of using other Arduino boards?

Well, first off, I don't like the idea that the battery circuit must be connected by soldering jumper wires. So the PCB is updated.

Secondly, we have to accommodate the fact that the Arduino Due have different I2C locations. So a "version selector" is implemented on the board.

Then, because the Arduino Due runs on 3v3, and the LED the Arduboy uses means that the LEDs are pulled LOW by the controller to light rather than being pulled HIGH. So the LEDs need to switch from 5V to 3v3 rail. This also need a redesigned PCB.

The added wires, as well as the "need" of making space for the digital pins at the bottom and making the "expansion area" as large as possible, meant a lot of changes need to happen to the PCB.

I decided to add a pin next to 5V for 3v3 breakout. Because why not?

As much as I think Fritzing is a more powerful tool to draw PCBs with, it forces you to donate some dollars in ways that I could not. It is also a hassle to build Fritzing on my own (not including the time it will take to actually build the dependency and the entire application, which could be 15+ hours). So I went with KiKad and ... so far so good.

Around the same time, I started to look at what exactly are the footprints in the PCB editor, and found that everything I did is "wrong".

But it is perhaps too late.

And so the new PCBs arrived. I soldered it together, and thought "man, it look dang petty.". By that I mean it look *REALLY* good. Handsome, if you will.

Some days ago, I figured that one SHT-30 is too few. And I need a bit more. So I ordered two SHT-31 breakouts. And I made .... little "cartridges", if you will, that fit the expansion header.

The left one is ... well, it look like ... stuff. The right one look pretty neat.

Why? They are made with the same soldering iron on the same board (that i cut into the two) with the same components.

Because the one on the left side used lead-free solder tin while the one on the right side used some "high-tech solder tin" that contain fancy things -- probably just lead, but maybe silver, too.

So here it is, with my temperature sketch running on Arduino Due.

(attempting to find a rechargeable battery with headers to plug it to the board)

(accidentally sat on top of it)

ah. here.

The Due had a on-board step-down voltage regulator sourcing from 5V and driving 3v3. The requirement ask for typical input to be at 5V but the block diagram and minimum ratings did not say that the regulator will fail to output 3v3 when the input is above 3v3 but below 4.5V.

And Arduino Due is a 32 bit ARM M3 too. This shield sure will open up new possibilities.

PROJECT COMPLETE!

___
___
___

As it happened, it might be EXTREMELY difficult to acquire the charging module I had obtained, so I have decided to update the design with pads for the TP-4056.

However, as it turns out that the TP-4056 is from a relatively small company based in China, so the charging ICs will eventually became a MAX1811.

___

You will NOT get standardized 16340 battery holders, despite their excellence size and general availability. Connect the Li-ion/Li-Po battery of your preference at the connector.

That's it for part one, I guess. Thanks for swinging by.