Old-School Maps

Thanks to the August 2nd RPGaDay2021 prompt, I’ve been looking at art in RPG books a little more, and specifically maps. I love those old-school black and white drawings, and was quite pleased when Fub introduced me to the Trilemma blog a while back. I’d mentioned how I enjoyed this one-page dungeon I was introduced to via the Torchbearer 2nd Edition Kickstarter campaign, and he managed to link me to the Trilemma blog that was just filled with more such one-page dungeons. What joy! Not only that, but the art on them was just so evocative.

With a little bit of browsing this evening, I ran into a blog called “Paths Peculiar” that has a couple of lovely tutorials on how to make basic maps. It’s exactly the style that I’d like to be able to make (despite not taking any time to practice drawing, but I’ll “cross that bridge when I burn it”, as a colleague used to mangle that saying). The tutorials are so accessible that maybe I’ll try my hand at a little drawing after all. I couldn’t leave it without spreading the word, so please find below a link to the blog:

The lovely “Paths Peculiar” blog. It has some easy-to-follow tutorials on how to make some basic maps.

FreeCAD Tutorial

Over the past week or so, I’ve been following a YouTube tutorial for FreeCAD by a YouTuber calling himself Adventures in Creation. It’s been an amazing set of videos so far that starts all the way from how to download the program to the latest video, dealing with making a small engine out of individual components. I’ve gotten all the way from not knowing how the program works to being able to set up a basic part, ready for 3D printing. If, you know, I had a 3D printer (someday, printer . . . someday).

In any case, I wanted to link to that tutorial here, for anybody who wants to have a great introduction to FreeCAD:

Adjusting my Knowledge of Schematics

A little while ago, I posted about learning new things about schematic design. In short, I followed a tutorial that encouraged clear schematics by using many net labels in the place of drawing out wires. In particular, they connected net labels directly to the PCB, and had everything defined separately from that. However, I’ve come to find out that this is a bit of a debate in the hobbyist electronics world. I was reading the following post on Reddit that shows an example of the discussion in the comments:

A Reddit thread where someone posts their schematic, which makes heavy use of net labels. The discussion about this in the comments was quite educational for me.

The discussion centered around the balance between clean and clear schematics. Separating everything out with net labels will certainly make schematics clean, as there will be a minimum of crossed wires or cramped symbols. However, the downside is that this will reduce clarity. I followed a suggestion in the comments and tried to trace a signal through the schematic. I have to admit, it was pretty tricky – I checked a pin, and then read the net label, followed by having to scan the schematic to find that net label again, only to see that there were two other net labels involved. As a result, it was pretty tricky to see what the internal connections were.

It seems there’s a pretty clear divide on the topic, as evident in the discussion as well. Some people will say that leaving as many wires in the schematic will aid readability, although they’ll also say a schematic should have as few crossed wires as possible. The consensus seems to be that some common sense should be applied in choosing when to use labels. In the case of this schematic, there’s an example of a label being used for no reason at all, apparently, as this person points out:

This user identifies three components that are right next to each other on the schematic, but connected via labels rather than wires.

I can wholly understand their comment here. These components were literally adjacent to each other and nothing else, and connecting them via cables would cause very little trouble at all (one connection to ground would have crossed over a signal wire but that’s it).

In the case of my Pomdoro schematic, I’m thinking that I may have doubled up on methods to clean up my schematic. For instance, I used both buses, wire labels, and global labels. I could have stuck with only wire labels, and perhaps adding buses to still draw a line but collate the five wires into one. Furthermore, it makes sense to me to separate out the power section of the schematic. It’s a functionally separate part from the main schematic. The same goes for the ISP programmer – it’s a side issue to the main function of my device. However, I’d also separated out the LEDs from the microcontroller, even though that’s the main point of my entire Pomodoro timer.

Figure 1: The Pomodoro Schematic

It’s a good lesson for when I make the hamster cage lighting system. I’m not bothering to rework this schematic again, but if I would, I now know what I’d do better.

  1. I’d edit the ATtiny84 symbol to put PB3 on the left side of the symbol. After all, it’s an input to the microcontroller, so it makes sense to me that the signal goes from left to right.
  2. I’d not use net labels for TimerLeds and PomodoroLeds, but rather use the bus wire to connect the LEDs somewhere to the right of the ATtiny84.
  3. I’d use the small versions of the symbols to create a little more space on the schematic.
  4. I’d have the wires on PA5 and PA6 connect directly to the relevant switches. Those are their main functions, after all, whereas the MISO and MOSI are secondary connections and should be branches off that.
  5. Similarly for PB3, where I’d have it connect directly to the RST label, and have the pull-up resistor be a branch upwards.

Learning About KiCad and Schematic Design

The next project I’m going to be looking into is the RGB lighting for the hamster cage project (post about the cage; post about the intended design). I’m now back at the usual first stage of my projects: experimentation. This is usually the time where I just hook things up, see how things work, and generally mess around. To give you a rough idea, my experimentation now will be getting the ESP32 to connect to the WiFi; then, I’ll try and get an LED to blink; lastly, I’ll try and get the LED to blink depending on whether I’ve sent a command over WiFi. As you can see, it’s step-by-step increasing the complexity, until I am where I need to be.

The next step, usually, is design. Once I’ve tested out all the individual bits of my final project, and I have a rough idea of how to do it, it’s the time to bring it all together. My first step is always to make a schematic in KiCad. As usual, before I start I try to learn a little bit more and apply at least one new thing before I get started. That’s why I was so happy that I found this video:

A video by Phil’s Lab, showing the full process of hardware design

I’m only about half an hour in so far, and I’ve already learned a tremendous amount about net labels and sectioning off components, as well as just some handy KiCad tricks. Just for that alone it was useful to me, and I still have two more hours of the video to go right now!

Aside from that, I wanted to find a good solution to the mess of wires I had in the Pomodoro design. The outputs for the ATtiny84 were all so close to each other, and some had to move upwards while others moved down – it ended up as a large bowl of spaghetti (a tangled, disordered mess of wires or connections are often informally called spaghetti, for obvious reasons). Yet, there are two clear bundles of data in the Pomodoro timer: the two sets of LEDs. So, I looked up how to do bus wires, leading me to this post. It’s an explanation of how to apply bus wires in KiCad, and using wire labels to connect everything together. That way, you can get a clear schematic, and KiCad can still read it and build a rat’s nest out of it.

When I learned these things, I just had to stop the video and apply this right away. The only schematic I had lying around was the pomodoro one, so I figured to just test out the process:

Figure 1: The original Pomodoro r2 schematic

Now compare the old schematic to this new one that has all the lessons applied:

Figure 2: A revised Pomodoro r2 schematic, applying net labels, bus wires, and outlines for sections

What a difference in clarity! No more crossed wires, and several subsystems are clearly separated out to their own space. I greatly prefer this schematic. The only downside I found was that the labels are later on also used in the PCBNew program to label the actual traces. Now, that may be quite a useful feature later on, but it also causes a little confusion. Take a look, for instance, at pin 7 (PA6): it’s both MOSI as well as the Pause/Reset switch. Now, since I applied the MOSI label to it to connect it to the ISP, the whole trace was called “MOSI”. However, I’d much rather apply that label only to the trace leading to the ISP, and Pause/Reset only to the trace leading to the button. Maybe that’ll be possible, maybe it won’t. More to learn!

Pause Button Problem Solving

As I posted before, I’m working on trying to get the pause button working on the pomodoro device. There were two issues: firstly, the button needed debouncing, and I had to decide whether I wanted that in hardware or software; and, secondly, I was using a interrupt for the pause button that didn’t work correctly. Specifically, the hardware interrupt I was using activated on a pin state change, resulting in two activations per press (pressing down as well as letting go). Now, there was a potential to use another hardware interrupt, but that involved some rewiring.

As far as the debouncing goes, I found out that the usual solution involves an RC network (a resistor-capacitor network), which essentially provides a bit of a buffer by smoothing out the signal. It works, but as I mentioned before, isn’t done much anymore. In a previous post, I mentioned that reducing cost was a main consideration, but a more important reason turns out to be that there is no point in doing it in hardware when you already have a microcontroller with enough space to do it in software. Or, in other words: why do it the hard way when you already have everything you need in the microcontroller? So, I’ll have to see about implementing a software solution.

As for the other issue – how to handle the button press – I’m considering not using a hardware interrupt. One problem is that the hardware interrupt would require a hardware debounce, because debouncing it in software requires a degree of waiting for it to settle, which you can’t do if your interrupt is getting interrupted because the button keeps bouncing (very Catch-22, right?). What I’m considering now is using Timer B to regularly poll the button and debounce it in software when needed. The microcontroller is running at 250kHz to begin with, to that’s plenty of time to check for a button press. With the /1024 prescaler, that still ends up at 244.140625Hz. That’s plenty of time to check for a button press, though I will need to implement around a 50ms delay to hold off the debouncing (according to my reading).

Pomodoro r2 Timer/Counter Interrupt Figured Out

I was struggling a bit with getting the timer of the ATtiny84 working correctly. After having set it up, setting a prescaler for the microchip as well as a prescaler for the timer itself, it still wouldn’t quite time to 1 second intervals as I thought it should have. It certainly was timing something, as my countdown did display, and the prescalers were working, because changing those changed the timing of the countdown, but still it didn’t turn out to be 1 second per interval. It took a lot of reading through the datasheet to solve this issue.

So, specifically, my timer ran just a little slower than 1 second. I took a stopwatch app on my phone and timed out 20 intervals (i.e. LED changes), and found that it ended up being 17% slow. Not a staggering amount, but counting for that over 25 minutes it would end up being over a minute slow per pomodoro count. Given that my current firmware somewhat skips over the first count, it would still end up okay, but that’s just sloppy programming!

The solution to my problem lay in reviewing step-by-step the process of the timer as described in the datasheet. Reading though the Timer/Counter Interrupt Mask Register 1 section explained what the Timer/Counter1 Control Register A did, which helped me relate the Timer/Counter Register to the Output Compare Register A. As you can imagine, it was a lot of juggling of registers and bits. However, going through that step-by-step helped me track down my issue. As it turns out, the Compare Match A Interrupts (OCIE0A in register TIMSK0) was dependent on the bit setting of WGM01 in register TCCR0A. In other words, I had set everything up to compare the timer to the value I’d set, except for the actual register that tells the chip to make that comparison. No wonder it didn’t work!

Reading up on the datasheet also explained why I got the exact mistimed count that I did. Without setting WGM01 in TCCR0A, the timer is in “normal” mode, where it doesn’t compare but just checks to see if its in overflow. Overflow is defined as maxing out the register at oxFF in hexadecimal, or count 256 in decimal numbers. I’d set up the prescalers so that the timer was just over a second for a full count (so 256 cycles took 1.045 seconds), which is why I needed to compare it not to 255 but to 243 cycles: 8,000,000Mhz / 32 (prescaler) = 250,000 cycles/sec. 250,000/1024 (timer prescaler) = 244.14 cycles/sec. However, we start counting at 0, so it’s a count of 243 that’s almost exactly one second. As a result, waiting for the overflow rather than the compare made my timer slow.

This leaves me with one last thing to figure out: the pause button. Last time, I mentioned that buttons are, apparently, usually polled instead of checked via interrupt. Furthermore, they are usually debounced in firmware rather than hardware. After reading more, I now know the reason for the latter. Even though the components needed for debouncing are quite cheap (we’re literally talking a couple of cents here), production rules are usually made by large companies who produce tens of thousands of boards per product. So, an addition of even a few components of a couple of cents still add up to a hefty cost when multiplied by thousands to millions of components. On top of this, each component added adds a production step, as they will need to be mounted to the board, again leading to higher costs. Firmware, on the other hand, is programmed once (hence only paid for once), and can be copied indefinitely. In my case, this just doesn’t apply, so why not hardware debounce if that meets my needs?

The other problem lies with checking the functions. In my original design, a short press pauses, but a long press reset a timer. I did that using the millis() function in Arduino, which I now realize was just a timer used to count milliseconds. However, that also involves polling that at a regular interval, whereas my goal was to have the microchip sleep most of the time to save on energy. I’ll have to figure out how to approach this. I’ve read two completely opposite points of view on this: a chip can be set to work slowly, sleeping most of the time to save as much energy in sleep states; alternatively, the chip can be set at a high frequency, so when it is awake, it does whatever it needs to as quickly as it can, so it can return to sleep as quickly as it can. Right now, I don’t know what’s best, but it’ll be fun to figure that out.

Revising the HV Programmer

A key way I try to solve problems in general is to see where and how they can be simplified (I guess that must be a leftover from highschool math classes). After all, the fewer moving parts, the less that can go wrong. On top of that, if you keep building on a smaller thing that works and test it incrementally, you can tell when things start going wrong, which leads to a much narrower problem to solve. In the case of the HV programmer, that firstly meant to remove the secondary header. I only need to reprogram a 14-pin IC right now in any case, and I’d much rather have a working HV programmer for that, than a general one for a future use case that I don’t know about yet.

A quick retooling in KiCad leads me to the following schematic:

Figure 1: A renewed and simplified schematic

Now, ideally, if I wanted to be very specific about how I make schematics, I would much rather have the master IC to the left of the target IC, so that my input pins are always on the left and the output pins are always on the right. Ideally, I want power to run from top to bottom in a schematic, and the signal to run left to right. It just makes things easier to read for me. However, this is supposed to be a quick tool that helps me do another thing that I’d like to do, so I’m not going to polish this up too much. I’ll work on KiCad library management some other day.

Fortunately, the simplified schematic leads to a far simpler perfboard design with fewer connections:

Figure 2: The resulting design for the perfboard. Once more, a lot of solder lines on the underside

As you can see, I still chose to keep a lot of solder lines in there rather than jumper wires. For one, I think that’s something of a guideline to begin with, but secondly I also just want to learn how to do that properly. The only way to learn is to keep on trying, so I may as well start here. This time, though, I think I may want to try out soldering the lines first and only adding the components later. That’ll allow me to mess up more and throw the board away if I really ruin it. The most I can lose is some perfboard and solder, at that point.

First Time Working with RGB

I did some research on the upcoming challenge of making a lighting system for the hamster cage. I have to admit it was a little bit intimidating, and part of me almost wanted to avoid the challenge. There’ll be a few new elements to this: firstly, I’ve never worked with RGB LEDs before; secondly, I’ve only once actually put a project in a project box, and I wasn’t happy with the results there; thirdly, this will be something I’ll end up plugging into a socket; and, lastly, it’ll be something that needs to be used via Wi-Fi and Android phones. That’s a lot of new things all at once. Part of me wanted to chicken out and buy some pre-made thing that could only do part of what we wanted it to do.

Tracy’s preferred solution for the hamster cage is to have consistent lighting that will mimic some sort of circadian rhythm for the (future) hamster. The cage we built is rather large, and because it’s made of wood it’s also quite dark. On top of that, we’ve put it in a corner away from the windows, which makes it even darker. So, she would like to have a lighting system that mimics daylight in a way, both in color and intensity. However, it will also need to be able to be overriden manually, so that we can put it on a bright white light in case we need to check inside the cage or clean it.

I’ve been trying to do some initial research and discovered that authentic daylight imitation is quite complex, even when simplified. Now, firstly, I’m not intending to mimic actual sunlight here, so I’m already side-stepping issues of infrared and ultraviolet, and the other qualities that actual sunlight has. I’m not looking to grow crops or to take care of fish, so that’s going too far. Even when just trying to imitate the color, however, there’s a deep rabbithole of color temperatures, color perception, white balances, and so on. The minimum we really need is just to have light differ over a 24-hour period. I think I’ll see if I can play a bit with making the light blueish or greenish at night, reddish at dusk, and white at noon.

This will certainly be the biggest electronics challenge I’m tackling to date. It’s scary and exciting at the same time. So, right now, I’m looking at the following rough specifications:

  • The light should illumate the three compartments of the hamster cage
  • The light should be automatically set
  • It should be possible to manually override the light
  • The light should be powered from a socket
  • The light should simulate a day/night rhythm in intensity
  • The light should simulate a day/night rhythm through color
  • The fixtures and cabling should be neatly tucked away
  • The light should be controlled from a distance

We’ll see where we end up with the project.

Pomodoro r2 – Update 5

I figured that my design was pretty much as done as I could make it, so I posted it on /r/PrintedCircuitBoard to see about getting some feedback. As always, the electronics subreddits tend to be quite wholesome and education, and full of supportive people willing to help out. Thankfully, they gave me a lot of good feedback, as you can see below:

The Reddit thread where I got my advice

I was happy to learn that KiCAD automatically takes thermal relief for pads into account, as before this thread I had no idea what this was. The other major thing I learned was that there is no reason not to increase trace thickness if you can. And, finally, I learned that there was such a thing as a decoupling capacitor to smoothe out power delivery to a microcontroller, and so I added one (and after advice moved it closed to the microcontroller). That all resulted in a slightly changed design. Furthermore, I solved my issue with the footprints by simply taking a digikey footprint directly from a component I am intending to buy, so that the problem solves itself. I am very excited to come to a close to this project, and seeing it in action!

An update of the board based on feedback from Reddit.

FreeCAD Modelling

So, today, I made my first thing in FreeCAD. When I was testing out some footprints and components for the Pomodoro Timer PCB, I noticed that none were exactly the type of buzzer that I had. Seeing as how my buzzer is pretty much a simple cylinder, I figured it was the perfect object to try and model in FreeCAD. In the end, I’d end up both with a working 3D model to use in KiCAD, as well as some basic experience with FreeCAD.

After quite some fiddling to get things working, and some initial experiments, I finally produced the part in 3D with exact measurements:

A FreeCAD model of the buzzer that I use

Importing that into KiCAD was actually super easy. There was literally a button to just locate any type of .step file and import it as the 3D model for a part that I had selected. So, happily, I put that part on my board. And, to my surprise, it unveiled a hidden error:

The pins didn’t fit!

When I checked the fit of the part, I could see that the actual pins didn’t fit! That sure would have been an issue had I ordered the PCB! I measured twice, and then another time; I checked my measurements in FreeCAD, and everything worked out well. The only outcome could be that the footprint in KiCAD wasn’t correct. Good thing to catch at this stage.