Imagine an encrypted text communication network that is owned by you and your community, one that requires no subscription fees, works with little or no connection to the power grid, while serving as a gateway into meeting interesting new people and building skills in electronics. This is mesh radio!

With mesh radio, you can send and receive text messages across a city - not by relying on a cell company or service providers, but instead by bouncing messages between other low cost, license-free radios operated by members of your community. Your message takes multiple hops between other users’ devices, and the contents remain encrypted all the way to the recipient.

Meshtastic and Meshcore are two common mesh radio systems you can get into today, with minimal upfront cost and experience. Read on to learn more!

Table of Contents

Why Mesh Radio?

Mesh radios can be used as a primary communication method between groups while hiking, sailing or operating in an area with no cell coverage. During natural disasters or other emergencies where cell services or the power grid are down, mesh radio can serve as a backup communication method, especially since the infrastructure to run it is decentralized and can even be run on solar energy.

Meshtastic and/or Meshcore may already have a large existing community near you! Once you’ve decided to buy some low-cost hardware, you can easily swap between firmware to test each system out.

Starter Hardware for Meshtastic and Meshcore

Mesh communications take place with a radio system called LoRa (LongRange). Cell phones don’t have this type of radio circuitry, so you need special hardware to send messages from your phone. Here are some products that are ready-to-go. (I’m not affiliated with any of the manufacturers linked in this article).

• The SenseCap Card Tracker is a low profile, weather-resistant, battery-powered node that you can clip to your backpack and connect to with an app on your phone.
• The LILYGO T-Deck is like an off-grid Blackberry. Instead of connecting your phone to a board, you can compose and read messages directly on the device.

If you want to jump right in, pick up one of these and check out the getting started guides for Meshtastic or the Meshcore FAQ .

While the products above are pretty plug-and-play and might work out of the box for some, there’s a huge ecosystem of DIY options for customizing, making and personalizing your own systems. If you’re interested in technical details about radio, and building your own hardware appeals to you, the rest of this article is for you!

Meshtastic vs Meshcore

Meshtastic and Meshcore are two implementations of the mesh radio concept. Fundamentally, they both bounce messages between multiple devices in order to reach a recipient who may be out of direct radio range.

• With Meshtastic, every device can re-transmit any message it hears in order to extend its reach. Because messages flood the mesh, the geographical structure of the nodes within can change - if one node moves out of range, another may take its place to deliver the message via an alternate path.
• With Meshcore, devices are explicitly assigned to one of two roles. Repeaters are geographically static, and will repeat any transmission they hear. They can’t send messages on their own. Companions are mobile, and used to send and receive messages. They can’t re-transmit messages.

Meshtastic is more flexible, especially when the mesh moves dynamically, such as a group on a hike. On the other hand, with many devices flooding the network by re-transmitting everything they hear, network congestion can become an issue for larger groups.

Meshcore trades some geographical flexibility for more efficient message routing. When repeaters are static, reliable message paths can be determined, reducing the need for flood messages. In practice, this allows for meshes that can span larger geographic areas.

I have tried both, and I found Meshcore to have a stronger, more focused community and better infrastructure in my area.

Build and Own Your Hardware

All the off-the-shelf products listed earlier share common components - a LoRa radio and a microcontroller that allows you to connect with your phone and send messages over the LoRa radio. The same is true for boards in a development form factor.

The most common LoRa radio is the SX1262. It operates at 22dBm (0.16W), but some hardware boards integrate radio amplifiers to bring this up to 28dBm (0.63W) or even 30dBm (1W - the maximum power allowed in Canada).

Boards I currently run:

• Heltec V3 : low cost ESP32-based, 22dBm. Not the most power efficient, but good for a hardwired HQ node that lives at home or your office and communicates directly with a nearby repeater. If I were starting again I’d probably go straight to the Heltec V4.3 instead of the V3.
• Heltec T114 : based on the nrf52, this radio is much more efficient than ESP32 radios, making it great as a portable companion. It also has a much sharper screen than the Heltec V3 but still only runs at 22dBm.

I’ve also ordered the higher power boards below.

• Heltec V4.3 : Nearly equivalent to the V3 but boosted to 28dBm (0.6W) for basically the same price. Make sure you get the V4.3 version - the V4.2 board had hardware issues related to receiver sensitivity . Buying a V4.3 direct from Heltec guarantees you don’t get old stock.
• Heltec T096 : A new release, with 28dBm (0.6W) and additional integrated GPS. I’m looking forward to getting the T096 - it could be perfect for a small yet capable solar node or handheld.
• RAK 1W : At 30dBm (1W) it’s one of the most powerful boards available. I’m planning to build a solar-powered, minimal maintenance rooftop node that will expand Meshcore into my area.

With development boards, you can decide how to build your own power and antenna systems.

A Note on Antennas

Powering on a board without an antenna attached will burn the LoRa transceiver! This is because the radio energy has nowhere to go, and instead is reflected back into the device. The device does not like this.

If your hardware is from a kit, it probably came with a poor quality antenna. For good performance, you should consider buying an UF.L to SMA adapter cable, and a half-wave SMA whip antenna. If you’re planning to build an outdoor node, you can buy UF.L to SMA adapters with O-rings. Consider also N-Type connectors and antennas, which are designed to be more durable against the elements.

Keep any coax cable as short as possible. At these low power levels even “low-loss” coax longer than a decimetre can have a noticeable negative impact on power output.

Ensure your antenna is tuned to the specific LoRa frequency range in your region . You can test how well your antenna will transmit at a given frequency by using a Vector Network Analyzer (VNA) and checking for the Standing Wave Ratio (SWR) - the ideal antenna is near 1 but most antennas land within 1.5 and still work fine. Not all antennas are created equal! I bought 3 “identical” antennas online, but one of them had much worse SWR than the other two.

Setting Up Your Node

The power level allowed for unlicensed broadcast at LoRa frequencies is 1W or less, depending on your region. This is quite low, relative to what an amateur radio operator may be used to. Therefore, it’s less possible to achieve good contact through brute-force power output.

The best predictor of success for reception is line-of-sight. This means you’ll get best results by setting up your antenna as high up and with as large of a view as you can. The website SCADACore has a cool utility for visualizing topographical line-of-sight between two points .

Avoid mounting antennas horizontally. Imagine a doughnut, with the antenna sticking up through the hole. The further the edge of the doughnut the stronger the emitted radio signal. With the antenna pointing up (doughnut in eating orientation), you get good 360 degree coverage. With it horizontally (doughnut in rolling orientation), most of your radio energy is directed into the ground and sky. Wikipedia has a good image that demonstrates the radio energy distribution of a monopole antenna , though I don’t know why you’d need it considering visual power of my doughnut analogy. Also, radios can hear each other better when their antennas are in the same orientation (due to polarization).

Also avoid placing the antenna next to other metal, especially if it’s grounded. Other metal will absorb or distort the radio energy pattern.

Basic “Weather Resistant” Design

You’ll find many designs online for outdoor nodes. Some are 3D printed, others use off-the-shelf weatherproof enclosures. What do you do if you want to get started right away and don’t have anything like that?

Well, the little box the device comes in kinda works? I drilled some holes to zip tie it to a horizontal pole mount, drilled more for the SMA connector and USB cable, and then slipped it into a small plastic sandwich bag. An elastic band or zip tie closing up the bag completes the build. The USB cable runs through my balcony window into a power supply in my living room.

It’s pretty sketchy, and probably won’t hold out the weather for long, but I’ve had two of these nodes on my balcony for a few weeks now, and they have survived a few rainy days.

It works best if you mount it antenna-down, and make sure that the transceiver is slightly angled upwards from the mounting point so that water doesn’t run down the stick into the bag. Finally, putting a dip in the cable just before it enters your window will prevent water from running along the cable and dripping inside your house.

Projects

Like any good hobby, once you get into it there are many possible paths and projects you can explore. Here’s a few that are on my list.

3D Printed Handheld and Base Station Nodes

I printed a body for a Heltec T114 to be my mobile Meshcore companion device.

I’ve delegated a Heltec V3 to be my Meshcore home base station. It works alongside the repeater out on the balcony to receive public messages reliably, regardless of if I have reception on my handheld. It’s hard-powered, but also has a small rechargeable battery that gives about a day of use if unplugged.

The designs in this photo are the H2T and the Bender , available on Printables.

Weatherproof DIY Solar Mesh Node

Sandwich bags are not known for their long-term resistance to the elements. I also still need to have my window cracked open to run power to the nodes, and I don’t know how much longer my wife Joyce will tolerate the tripping hazards while she’s gardening.

A small solar panel (1-5W) can be sufficient to run a repeater node indefinitely, in combination with rechargeable batteries. Some boards, such as the Heltec T114 or T096, have solar power input and battery charge controllers built directly onto the board.

A proper weatherproof setup and a solar panel allow installation in more remote areas, and can help you and your community maintain a communication channel even in the event that severe weather affects the power grid in your area.

Use caution when running lithium-ion or lithium-polymer batteries, as they can fail spectacularly if overcharged, overheated, or short-circuited.

Camping or Wilderness Mesh Networks

When I go camping, I’m usually at the edge of, or outside of cellphone reception. This makes it difficult to communicate with friends, and also tends to drain my phone battery as it struggles to try to connect to the cell network.

Next time I go camping, I’ll hang a battery-powered repeater node from a tree, and give companion nodes to my friends. We should be able to keep our phones on airplane mode to preserve battery, yet remain in contact over long distances via the mesh.

This seems like a good use-case for Meshtastic’s store-and-forward mode , and Meshcore’s room servers , where a limited number of messages can be asynchronously retrieved by a client node that may have been out of range at the time they were sent.

If a base station or repeater device isn’t available, Meshtastic’s ad-hoc routing is naturally suited for a mesh where participants move. Meshcore users can enable client repeat mode which does the same thing. Note that client repeat mode uses a secondary frequency so you’ll be disconnected from normal mesh repeaters while it’s active.

Mesh Transceiver as a Drone Payload

Few radio towers can beat the line-of-sight achieved by zip-tying a transceiver to a drone - that is, if you only need it for the 20 minutes that the drone battery lasts. Zip-tying nearly anything to a micro drone powerful enough to lift the transceiver (e.g. a Mavic Mini) might push the takeoff weight over 250g, so in Canada you’d need a small basic drone operations license . If you land the drone on a structure to enable longer mesh operations, ensure you have permission from the property owner.

Avoid mounting the transceiver on the bottom of the drone if it has downward facing collision sensors, as the drone may interpret this as an obstacle and prevent you from descending. Avoid covering any sensors when zip-tying for the same reason.

“Wardriving” and Mesh Mapping

The Meshcore community has developed MeshMapper , which aims to document the reach of the Mesh network. Volunteers bring their nodes with them in their car, and the MeshMapper app automatically searches for repeaters and attempts mesh communications along their journey. It’s a fun way to contribute to the mesh, even if you can’t run a repeater yourself. If you do run a repeater, valuable data showing the real-world range of your repeater will become available.

It’s really cool to see how connected my city of Toronto is!

Participating in the Community, and Expanding the Network

In the past, radio technologies and amateur radio groups have assisted in emergency situations where modern local communication infrastructure is overwhelmed or unavailable. As a more mundane example, in 2022, the major Canadian telecom company Rogers experienced a service outage that left 25% of Canada without internet connectivity for nearly a day.

Some envision blanketing entire towns, cities, states, or even entire countries with a mesh communication network as a backup to primary services. Others just enjoy building nodes, testing new hardware, or just chatting with others on the public channel.

Share this article with a friend and get them into the Mesh! Search for groups in your area, or start one of your own. You may also have some luck if you talk to your local ham radio club.

Finally, both Meshtastic firmware and Meshcore firmware are open-source, meaning you can build upon and improve the code for everyone.

Conclusion

I hope this article has piqued your interest in this cool technology! There’s something that’s so intriguing to me about this little radio that can send and receive direct transmissions 10’s of kilometres away, using less energy than the LED in your TV remote. I also love that using this technology unveils a hidden world - the apartment you walk by every day might have a Meshcore repeater on the roof. With so many connections to other STEM hobbies like 3D printing, electronics, and more, there’s so much to uncover.

If you’ve gotten into the mesh, or are working on any projects, reach out to me ! I’d love to hear about it.

I’m working on a 3D printed project that requires rotational motion. With purely 3D printed parts, options for creating smooth rotation are limited. Layer lines and print orientation limit the strength and smoothness of a pivot. Ball bearings can be integrated into a printed part but are large and expensive. Simple materials like toothpicks may not rotate easily or can be weak.

A simple and cost-effective solution I discovered is to use the parts from a BIC mechanical pencil . You can buy these for cents, but you probably have dozens just lying around!

Each pencil can make two pivots - one made of the inner and outer body tubes, and another out of the components that make up the nose mechanism. These pieces are made of glossy plastic and slide very smoothly on each other. You can easily press-fit or glue the parts into a 3d printed model.

Dismantle the pencil by pulling off the front cap. Carefully snip off the flange keeping the black collar in place (the flange pieces like to fly off at high speed so protect your eyes). The little spring isn’t used here, but they can come in handy for other projects.

You can use the black collar and the remaining piece of the tip of the pencil as a small pivot. Despite its size, it’s surprisingly strong. The black collar has been press fit into the round piece, and the tip was cut off the pencil and press fit into the long piece.

You can also use the inner and outer body pieces as a larger pivot for both rotational and linear motion. Cutting can be done with a saw, or with strong scissors or flush cutters. If using a pinching tool, you may need to reform the cut outer cylinder before the inner will rotate smoothly.

When press-fitting into a part, you may wish to heat the print slightly first to allow it to conform easier, otherwise you risk the insertion force causing cracks or separation of the layers. Here I use a hot air station set to 100°C. The glass transition (softening) temperature of PLA is around 60°C, so the air hitting the part only needs to be warm, just bordering on hot.

I created the nested gimbal ring you saw above as a demonstration model, which you can download for free on Printables . A small M3 screw with a weight on the end is attached to the center ring, and will always remain parallel to the ground as the outer ring is rotated around it. The pivots allow for smooth operation even with an extremely light balancing weight thanks to their low friction.

I also designed this marble labyrinth game which uses the small and large BIC pivots! It is also available for download on Printables . I’ve submitted it to the Balancing Games contest, so give it a like, download and make if you enjoyed it!

Hope you find this trick useful! I haven’t seen this published anywhere else online. Try it out in on your own 3D printed projects and let me know what you make!

I found a marine-rated digital ammeter at a thrift store, but when I got home I was disappointed to find it wasn’t working. In this article I’ll show how I found the problem and repaired it.

Table of Contents

Safety First

This article is presented for informational purposes only. Dismantling and handling electronic devices can be dangerous. Never dismantle or handle a mains-powered circuit while it is connected to power. Components of circuits, even ones with low input voltage (such as disposable camera flashes) can generate hazardous voltages during operation. Capacitors can store large amounts of energy at hazardous voltage even after input power to a circuit is removed, and discharging them manually can generate burns or sparks.

Issue Investigation

The meter is a DM-730E4A by a company called Chitai Electronic Corp, made in Taiwan. It converts a 0-50mV signal obtained from a shunt resistor into a current measurement from 0-250A. I powered on the device at its rated voltage of 24V to find it consumed about 30mA, but the LED display didn’t light up.

Circuit Analysis

The first step of the repair is to analyse the circuit to get a rough idea of how it works. No schematics or any other details about this product are available online. Some reverse engineering is needed to find out how the circuit works in order to begin diagnosing it.

I like to web search the part numbers of all the visible integrated circuits on the board and look for datasheets. Datasheets tell us important info about the parts such as their purpose, what different pins do, and important ratings such as operating voltages and currents, signal thresholds, etc. Good datasheets also contain detailed feature descriptions and example application circuits. Here are the datasheets of the two most prominent chips on the board:

• TNY280 Off-line flyback converter controller
• AME7107R All-in-one ADC + LED Driver

I examined some of the traces and connections around the power converter and could then draw a simplified circuit diagram, shown below.

The TNY280 controls an isolated flyback converter, which changes an input voltage on one side of a transformer into a isolated, variable voltage on the other. The secondary side of the transformer has two half-bridge rectifiers each about a centre tap. The centre tap acts as the 0V reference on the secondary side, and the two half-bridge rectifiers produce a positive and negative DC voltage relative to the 0V reference. The positive and negative voltages are then passed to linear regulators, before continuing on to power the rest of the circuit.

The second major component of the circuit, AME7107R is an all-in-one chip that integrates an analog-to-digital converter and a seven-segment LED driver. According to the datasheet, it operates with a split-supply of 6V, 0V and -6V. The voltage created by the flyback converter should be at least this amount.

Taking Measurements

I first ensured that the input voltage actually made it to the first converter stage by using my multimeter to verify the 24V input voltage was present at different points along the board leading up to the transformer.

I then measured the secondary side voltages relative to the 0V centre tap point. The positive voltage was only about 1V, while the negative voltage measured -9V. The low positive voltage was probably preventing the rest of the circuit from working properly.

I soldered a wire to the 0V point on the secondary side, and hooked my oscilloscope ground to it. I scoped the positive and negative voltages just past the rectifying diode at the anode of the 470uF smoothing capacitors. If the circuit was operating correctly, I would expect to see a fairly constant DC voltage, with a repeating pattern on top of it containing regular blips of voltage followed by longer periods where the voltage drops slightly.

To understand why this pattern would exist, imagine two buckets - one small and one large. The large one has a hole drilled in the bottom, so it constantly leaks a bit. The circuit begins by filling a small bucket with water from a tap. Then, it dumps the small bucketful of water into the large one. It repeats this process until the large bucket is full. As the water drains out of the hole in the large bucket, the circuit will occasionally top off the large water bucket by dumping another small bucket of water in. The water level represents the voltage, and the flow out of the hole represents the power consumption of the rest of the circuit.

What I observed on the meter was instead that the positive rail displayed a short spike followed by a fast decay to a low voltage.

To me, this indicated that the energy from the transformer was very quickly filling the capacitor but only a small amount of energy was actually stored. It was like the large bucket had become tiny, and all the bucketfuls dumped into it mostly spilled out.

It seemed that this 13 year old electrolytic capacitor had lost much of its capacitance. I made a note of the position and polarity of all the electrolytic capacitors on the board, then desoldered them.

With the capacitors desoldered, I tested them with an LCR meter. The 470uF rated capacitor probed earlier measured only 8-10uF and >100 ohms of equivalent series resistance (ESR). Yes, that’s a 50x reduction in capacitance, and about 1000x times the ESR of a new equivalent part.

This is not a surprising result, and in fact it was the first thing I suspected when I looked at this old circuit. The quality of the electrolyte in the capacitor directly affects the capacitance and ESR, and the electrolyte quality degrades over time and especially when exposed to heat. When the capacitance drops out of spec, critical functions of the circuit stop working properly.

Repairing the Unit

Near exact drop-in replacements were available on Digikey. I searched for new electrolytic capacitors with the following criteria:

• Match original capacitance ratings
• Match or exceed the maximum voltage rating
• Ensure fitment by filtering by the same diameter (or smaller) while maintaining a max height that would fit in the enclosure
• AEC-Q200 automotive qualification

Parts certified for automotive use are a bit more expensive but are often rated for longer lifetimes at higher temperatures.

Once the parts arrived I soldered the new capacitors to the board. When installing electrolytic capacitors one must be careful to install them with the correct polarity, otherwise they will explode when the circuit is powered on!

After the capacitors were replaced, the meter worked right away! I measured the positive and negative rails again and found that the waveform now resembled the pattern I had expected, short pulses where the converter “tops-off” the voltage, followed by longer periods where the voltage drops a bit as energy is consumed by the load.

I used a simple voltage divider and a potentiometer to generate a 0-50mV signal to calibrate the meter. As I turned the potentiometer, I observed the meter changing from 0-250, its full range. Mission success!

Lifetimes of Electrolytic Capacitors

The root cause of the failure in the meter was an end-of-life wear-out failure of the electrolytic capacitors on the board.

Electrolytic capacitors work by layering a metal-oxide anode layer with a liquid/solid electrolyte cathode layer. The oxide on the anode layer serves as the dielectric (energy storage media). The oxide dielectric is very thin, and is also “roughened up” to increase its surface area. An electrolyte is used for the cathode because they can fill in the nooks and crannies of the oxide’s rough surface. The combination of a very thin dielectric and a very large surface area gives electrolytic capacitors outstandingly high capacitance for their size.

A major trade-off is that over time and through exposure to high temperature the electrolyte cathode dries out, degrading the performance. The original capacitors on the meter were rated for 105 degrees Celsius, and usually this rating is tied to a lifetime - typically 2000 hours. That’s less than three months of continuous use at the rated temperature, but for every 10 degrees of temperature reduction, lifetime roughly doubles.

If this meter came out of a boat somewhere near the equator, an ambient temperature of 30-40 degrees could be expected indoors while the boat sits out in the sun. Operating inside an enclosed box and inside an enclosed power panel, combined with self-heating through voltage ripple could result in operating temperatures exceeding 50-60 degrees. No more than 8-12 years of life can be expected in these conditions if the panel meters are in use 24/7.

I don’t know exactly how long this meter was powered up, but the date code indicated the unit was from 2013. Also, if it’s any indication (no pun intended), the LEDs had run for long enough to discolor the tinted cover plate around certain digit segments. Neat!

You can learn more about capacitors and their lifetime characteristics in this paper by Dr. Arne Albertson .

Conclusion

Old devices that appear broken can sometimes be restored by replacing electrolytic capacitors that have degraded over time and use. These capacitors are in nearly all types of devices and have limited lifetimes especially when exposed to high operating temperature. When performing such repairs it can be fun to reverse-engineer an unknown board, and it’s a great opportunity to learn about new chips and circuits by researching datasheets and inspecting the circuit board.

100% of my English text is human-written and is comprised of my own opinions, thoughts and experiences, expressed in my own voice.

This includes any published and unpublished writing, as well as correspondence such as comments or emails. This policy applies to both my personal and professional life.

I may edit images or photographs from their raw form using industry-standard tools, which may have integrated AI features (e.g. generative fill) for spot editing. Any images that are created or substantially altered by generative AI will be watermarked or disclosed as such.

I use AI tools to search for and help me learn new information in both my personal and professional life. I believe that the ultimate responsibility for any actions taken in response to AI rests entirely with the human using the tool.

I strive to produce well-researched, high quality content that is worth your time, respects your attention, and earns your trust. Rest assured that any mistakes that remain are human errors, not AI hallucinations.

Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. - Blaise Pascal (1657)

Turkey dinners are a family tradition for Thanksgiving, Easter and Christmas. We typically make the turkey for a 1pm lunch for 4-8 people. Ingredient preparation starts around 7am, the turkey is prepped and into the oven by 9am, and usually comes out to rest around noon.

This is the recipe I’ve captured and formalized from collected recipe clippings, handwritten notes, and knowledge handed down. It’s a living document that I’ll update and add to as my process improves with each season.

Being able to follow a clear written process takes a lot of the stress out of the day! I’m less likely to forget or skip steps, especially while I’m waiting for my coffee to kick in, chatting with family, and/or after having a few glasses of wine!

Table of Contents

Equipment and Ingredients

Gathering and arranging everything ahead of time is called mise en place, and makes the process smoother and stress-free!

Preparation

1. Close the door of any room in your house you don’t want to smell like turkey for two days.
2. Remove the turkey from the fridge at least an hour before planning to roast (what if my turkey is still frozen? )
3. Set oven pre-heat to 425°F (220°C) with bottom heat only, and remove the oven rack.
4. Set up your workspace with the roasting pan, turkey rack, bowls of salt/oil, paper towels, basting brush and cooking twine.
5. Don your safety glasses and gloves
6. Carefully open turkey bag and drain, then discard the turkey bag. Tip: cut a flap and drain into a bowl while the turkey is still in the bag to make cleanup easier
7. Remove any giblet bags and neck if present, set aside for soup, stuffing, or congee.
8. Place turkey on the roasting rack in a deep roasting pan with the legs up
9. Pat the inside and outside of the turkey dry with paper towels.
10. Squeeze the lemon into the cavity and lather it in.
11. Sprinkle a handful of salt into the turkey and rub it in.
12. Add most of the onion, celery, carrots and a few sprigs of rosemary and parsley into the cavity. Cap off with tin foil.
13. Baste the turkey with oil then rub a generous amount of salt/pepper over the turkey skin. Don’t forget between the wings and legs.
14. Cross the leg ends over each other, and tie together tightly with twine.
15. Press some sprigs of herbs in between the leg creases.
16. Turn the turkey over so the legs pointing down and the wings are at the top.
17. Add the rest of the onion celery, carrots and sprigs of herbs into the neck cavity.
18. Fold the wings back on top of themselves, and tie the “elbows” tight to the breast with twine. Cut excess string, otherwise it burns.
19. Press some sprigs of rosemary between the wing creases.

You’ll notice at this point that the turkey is “upside down”! We’ve found that this helps the breast stay juicier because the juices will flow downwards.

Cooking the Turkey

1. Insert an in-oven thermometer into the thickest part of the breast meat but avoid touching bone.
2. Place the prepped turkey tray into the bottom rack of the oven.
3. Cook at 425°F (220°C) for 30 minutes.
4. After 30 minutes, reduce oven setpoint temperature to 325°F (160°C) but don’t open the door.
5. While the turkey is cooking, use this time to sharpen the knives to prepare for carving.
6. Continue to cook until thermometer reads 160°F (70°C), after around 3-4 hours depending on the size and how frozen the turkey is before going in.
7. Remove from the oven. Drain turkey drippings into a saucepan for gravy (see below), then cover the turkey with a layer of foil and a layer of towels, then allow to rest at least 20-30 minutes. The internal temperature will continue to rise another few degrees during this time. Other parts of the turkey may be 10°F hotter than the breast.
8. Use the resting time to prepare the gravy, then carve and serve hot!

Making the Gravy

1. Scrape all the turkey drippings into a big saucepan and heat on high until the oil starts to bubble (this happens quickly).
2. Add about 400mL of water and allow the mix to come to a boil again.
3. Reduce temperature to medium, and slowly add the first package of gravy powder while stirring.
4. When the mixture comes to a boil again, sprinkle in the second package of gravy powder while stirring vigorously.
5. Alternate between slowly adding water and flour, while stirring consistently to avoid lumps. After adding water, allow the gravy to return to a boil. If the heat is too low the flour wont cook, and it wil taste floury.
6. Continue until desired consistency, taste, and volume is achieved. Our gravy typically doubles or triples in volume from the original drippings, water and gravy mix.

Notes

My turkey is still frozen! What do I do?

Here’s what we did one year. Hopefully you have a sink that is large enough to fit an entire turkey.

1. Thoroughly clean out a large sink with soap and rinse. Fill it with water.
2. Unwrap the turkey, place it on the roasting rack, and then lower it into the sink.
3. Change the water in the sink every 15-30 minutes until thawed enough
4. Try to remove giblets as soon as possible. If they are still frozen in the turkey, pour hot water in the cavity to thaw it just to remove them, but don’t allow the warm water to sit for longer than a few minutes.

It’s best to continue with prepping the turkey and putting it in the oven as soon as possible after doing this. Remember to clean your sink again afterwards!

The tempered glass pane of my oven exploded!

Yup, that happened to us too the first time we made turkey after moving into our new house. I suppose we were either unlucky, or the previous owners hadn’t used the oven much…

My personal values and policies towards my online privacy, data sovereignty, and tolerance to advertising have evolved, especially since the beginning of 2025. After nearly 25 years as a Windows user, I decided to switch to an Ubuntu-based distribution called ZorinOS. I’ll explain why it improved my life, and how I’ve modified it to run better.

Table of Contents

A Weight Off My Shoulders

Moving to Linux had a pleasant and unexpected non-technical side-effect. I almost immediately felt a weight I was previously unaware of lift off my shoulders. I think the major reasons for this are that:

• My system asks me for permission to do things before doing them
• I know where all my files are, and where they aren’t (e.g. on a cloud I didn’t control)
• I haven’t been bothered by bloatware, an unsolicited AI feature, or an advertisement in the OS.

This PC feels like My Computer again.

Quality of Life Tweaks For Zorin

Below is a living document containing the list of tweaks I’ve made to my Zorin installation to make it more pleasant to use. Last Updated: September 2025.

Improve UI Scale

UI elements are either too big at 200% or too small at 100%, but using fractional scaling in GNOME results in blurriness. To make the interface more readable, I instead set resolution scaling to 100% and used gnome-tweaks to change text sizes. Specifically, I increased my interface text to 12pt and set the “scaling factor” to 1.25. This keeps elements like the task bar and title menus small and out of the way, while making the rest of the interface text large enough to read comfortably.

The scaling factor in tweaks sets the magnitude of the Large Text accessibility option and then enables it. Sometimes the Large Text option interferes with legacy apps, resulting in text that is too big and cut off. I set the Accessibility menu to always stay visible in the taskbar so it can be easily toggled on and off.

Reduce Trackpad Scroll Speed

My Framework laptop’s two-finger trackpad scrolling was much too sensitive. I installed libinput-config (which first requires meson, libc-dev, and libinput-dev to build). I followed the readme and created a config file in which I set the scroll-factor to 0.25.

Libinput will eventually add a Lua plugin system that will make libinput-config unnecessary (slated for version 1.29).

Fix Garbled Bluetooth Sound

I had issues with bluetooth audio getting corrupted every few seconds, making videos unwatchable. I fixed this by installing the blueman bluetooth manager from the package store and connected to my headphone with that app instead of the system bluetooth interface.

Add GNOME ExtensionManager

There are plenty of extensions that you can use with GNOME to modify and add functionality to your desktop environment. The GNOME Extensions website relies on a Firefox plug-in to install the extensions, but Zorin comes with Brave. Installing Extension Manager from the Software app allows you to browse and install extensions without Firefox.

Zorin even recommends it for advanced users on their website: Zorin Docs - Install Third Party GNOME Shell Extensions .

Here are the extensions I’m running:

• Burn My Windows (Glitch Effect, 500ms) for a neat, subtle flare when opening and closing windows.
• Arc Menu and Dash to Panel - Set up to nearly exactly match Zorin’s default UI, but I specifically wanted the Framework logo as my “start” button. Here you can downloaded a padded and cropped version of that icon.

Gaming Tweaks for Zorin

Using an eGPU with Linux and a Framework Laptop

Unfortunately, eGPU usability is not seamless when running Zorin or other Linux distros on my system (Framework 13", 11th Gen Intel, Nvidia RTX3080 in Razer Core X).

If I boot the system with the eGPU attached, the BIOS is unable to find my M.2 drive; this did not occur with a Windows installation. When powering on, I must wait for the green light on the side of the laptop to go out before plugging in the eGPU. The drive is then recognized and the eGPU is usable in the OS. Unfortunately, hot-plugging does not work.

Running a second monitor via the GPU’s HDMI port resulted in stutters and poor performance on the monitor and the built-in display. I have to run the HDMI from a Framework HDMI expansion card. Theoretically this will degrade performance, but I have not experienced any notable difference in performance compared to Windows, at least when playing No Mans Sky.

Apps must be explicitly informed to offload graphics tasks to the eGPU. I wrote a bash script with the following contents that allows for easy invocation of the environment variables needed.

#!/bin/bash
exec env __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia “$@”

Save this to ~/.local/bin/prime-run, then make it executable with chmod +x, and add ~/.local/bin to the path by adding the following to .bashrc:

export PATH=”$HOME/.local/bin:$PATH”

Now just call prime-run instead of having to type the long variable names. This can be used in Steam launch options with prime-run %command%.

Installing Bazzite Alongside Zorin for Gaming

Actually, I had wiped my drive and installed Bazzite first, after I had further issues with gaming on Zorin. Bazzite did solve many gaming-related issues. I thought it would be my new daily driver distro, but unfortunately, the immutable system and necessity to use exclusively flatpaks turned out to be highly limiting for some of the other work I do. Bazzite also takes a long time to boot, almost 2 minutes, which was irritating.

After installing Bazzite on the whole drive, I resized the main partition and created a partition for Zorin. When I reinstalled Zorin I had to manually specify the new partion as the destination (the installer could not detect the Bazzite installation automatically), then formatted it and set the mount point in the new empty partition.

After installation, I ran ujust regenerate-grub, and the Zorin installation was added to the GRUB boot menu. Now, I boot into Bazzite for gaming, and Zorin for everything else.

Conclusion

Transitioning to Linux required me to learn new things and work around technical challenges. With these hurdles now crossed, I feel a tangible improvement to my overall quality of life in general, and have a new appreciation for how the systems I use daily can have the ability to influence my state of mind.

On April 8th, 2024, the shadow of a solar eclipse made its slow dance across North America.

The path of totality would pass tantalizingly close to my home city of Toronto, but from my home we would “only” see 99.56% occlusion. 99.56% is so close to 100%. If you were wealthier than 99.5% of Canadians you’d have nearly $10 million . But for a solar eclipse, that missing 0.44% separates a dark afternoon from a once-in-a-lifetime experience. Full, 100% occlusion is required to experience totality - the glowing halo you see always see featured in photos of solar eclipses.

Site Selection

In the weeks leading up to eclipse day, there were dozens of articles about the chaos and pandemonium that would be caused by “up to a million people” flooding into Kingston or Niagara Falls on eclipse day. Niagara Falls even preemptively declared a state of emergency in anticipation.

My partner Joyce and I watched the forecasts carefully. The forecast models turned sour late in the week before the eclipse. First, Niagara started looking cloudy. Just as I was mentally preparing myself to make the 3 hour trek to Kingston, the forecast turned cloudy there too! However, a small sliver of Ontario remained cloud-free - Essex County along Lake Erie.

We selected a few potential areas in advance. Some isolated country roads with a large shoulder and clear views of the sky were our backup plans, but we wanted somewhere nicer we could spend the day. Point Peele was an obvious choice, but we worried that despite an early start, long lines of cars from more local cities like Detroit and Windsor would beat us there.

An equally attractive location was Hillman Marsh , only about 20 minutes from Point Peele. Its a location well known to local birdwatchers and has a large pond, surrounded by a small woods and marshland.

With access to the same weather information I had, I assumed that the huge crowd of other eclipse hunters originally destined for Niagara and Kingston had turned their sights to Essex County as well. We packed water, snacks and gas and planned for at least 16 hours of round-trip traffic (1 million is a lot of people, after all). To mitigate some of the stress of driving there, I leveraged a tool I’m lucky to have as a morning person - the ability to wake up and function well at crazy early hours. This was entirely to the chagrin of night owl Joyce, and the opportunity to sleep in the car for three hours didn’t seem to make up for the fact that I dragged her out of bed at 4AM.

The Marsh

Arriving at 7:30, we were the first ones there. It turns out that neither Point Peele nor Hillman Marsh would reach parking lot capacity until 9-10AM, and traffic along the route we took didn’t begin building until that time either. So in retrospect, 4AM was probably a bit early. Still, our early start offered us good time to bask in the crisp, fresh morning air and explore the beautiful walking trails around the marsh.

Joyce had prepared us picnic lunches of sandwiches and fruit, which we ate at our selected spot by the pond. We had plenty of space to ourselves - although more people had arrived throughout the morning, the “park to parking lot” size ratio was so huge that we all could enjoy the space without crowding. It was a very relaxing and peaceful experience. Sitting by the water, I thought “we should remember this place and come back here next time”. Hmm. That’s not quite right, is it? If only eclipses were so frequent.

The Anticipation Grows

In preparation for the event I set up my DSLR camera, which I had packed entirely as an afterthought. It wasn’t until the previous night that I had researched how to photograph an eclipse . I didn’t have a tripod, so I had to fashion a bipod-like structure out of things I had lying around. After taping the eclipse glasses to the lens for some safe test-shots of the sun, I fine-tuned the “infinity” focus of my lens as recommended online; a critical adjustment, in fact. I taped my focus and locked my settings so I could spend as little time possible working the camera during totality.

We got our eclipse glasses from Joyce’s work. Only a few days before however, we received a caveat emptor email stating that the original vendor had issued a “stop sell order”, as they were not an authorized reseller… but that they were “probably fine”. Amid the talk of counterfeits , we had built some pinhole projectors to observe the sun with instead.

Mk. 1 - made from a tissue box - wasn’t long enough to comfortably focus on the projection screen. Mk. 2 - from the box previously occupied by our Easter turkey roasting pan - worked much better. We looked completely ridiculous but it worked great!

The Experience Begins

The eclipse began at around 2 PM. We turned our pinhole projectors skyward and took quick glances through the sketchy eclipse glasses, watching as the moon took its first bite from the sun. As the occlusion progressed, the temperature dropped quite dramatically. Long-sleeve shirt weather turned into sweater weather, which turned into jacket weather. All the while, the world fell darker and darker, but in an unusual way. On a normal overcast day, the clouds diffuse the light from the sun, which softens or eliminates shadows. This was not the case today, our shadows remained just as sharp but were set against significant darkness. As the sun appeared dimmer and dimmer, our ocular instincts were often subverted - it became difficult not to take accidental unprotected glances at the sun!

About 10 minutes prior to the beginning of totality, silence set in. The background noise of traffic on a nearby highway had ceased. The birds, plentiful and vocal as they were mere minutes prior had stopped their singing. As darkness continued to fall the horizon embraced us with a warm orange glow from all directions.

In the last few moments before totality, I became hyper-aware of my surroundings, owing to the the absolute surrealism of the present experience. It reminded me of what it’s like to transition into a lucid dream - you realize that although your eyes were open before, suddenly and strikingly you now can truly see.

We watched through the projection box as the last sliver of sun was consumed by the moon, and then we looked skyward.

Totality.

A hole punched straight through the sky. The darkest void surrounded by a supremely brilliant shimmering halo. Bright beads of light danced around its perimeter. The wispy, high-altitude clouds were no match for the luminance, and they faded away into the night-light sky. Venus glowed faintly nearby. It was surreal - like nothing I had ever seen in my life.

It’s difficult to describe how I felt in that moment, and perhaps no words ever fully can. I thought about the rarity of these events, and how awesome it is that the lunar and solar geometry enables such stunning total eclipses. I reflected on the privilege I had to live so close and have the means to travel to see it.

I thought about how I almost didn’t travel to see it. My tendency to overthink and plan for the worst means my brain has no difficulty developing compelling reasons (large crowds, getting stranded in traffic, etc) against doing things I actually want to do. Joyce helped me realize it would be worth the risks I had conjured up. Without her encouragement, I would have just watched the sky darken from our balcony.

With this in mind, I reflected on my earlier thoughts about how there would never be a “next time” for us to return here for another eclipse. 125 seconds was all we had. There are so many incredible things to see in the world. We should count ourselves lucky for all of those that we may choose to experience for longer, experience again, or defer for another time. Eventually, we will all run out of “next times”, and it will be sooner than we’d like.

I cleared a few tears from my eyes and hugged Joyce as we continued to watch. Much too soon, the sun broke free from the edge of the void. Time was up, time to look away.

The chorus of birdsong began again, as if they had awoken from sleep (perhaps they really had). The golden horizon faded away as the sky brightened, first on one side, followed by the other. We stood for a few more moments, quietly processing and burning in the experience to our memories - a memory that will surely last a lifetime.

Introduction

After cleaning and reassembling my TWSBI ECO for the first time, I found that the cap wouldn’t stay on the tail while writing. It was very loose and would fall off easily. If you find yourself struggling with the same problem you’ll learn how to fix it in this article.

If you’d like to watch me perform this fix, check out the video I made on this topic. Otherwise read on for the tutorial.

The Problem

It turns out that proper assembly of the pen isn’t intuitive. Like me, you might be tempted to insert the Plunger into the body first, followed by the rest of the parts. Everything would go fine until you try to prop the pen cap on the tail - it won’t stay on. You’ll find that the Plunger will fully retract before the Tailcap can snug up, leading to a gap between the Tailcap and the Body.

This gap prevents the cap from making contact with the o-ring that holds it when you place it on the tail. Without the snug seal of the o-ring, the cap sits loosely and will fall off during writing.

The Solution

To fix this, you’ll need to reassemble your pen in the proper order. I recommend draining and rinsing your pen of ink, otherwise things will get pretty messy.

Insert the red TWSBI wrench into the gap between the Tailcap and the Body. If the gap isn’t big enough, turn the Tailcap counterclockwise to extend the Plunger. Turn the wrench clockwise until the Threaded Collar and Plunger assembly can be removed.

The trick to properly reassembling the pen is to put together the Plunger/Collar/Tailcap mechanism first. Begin by inserting the Tail Tube into the Threaded Collar. Next, place the Tailcap over top of the Tail Tube and screw it in about halfway. It doesn’t have to be exact - we’ll probably need to come back and make adjustments shortly.

Insert the Plunger into the other end of the Threaded Collar. Begin retracting the Plunger by rotating the Tailcap. If you’re lucky, the Plunger will be fully retracted at the same time that the Tailcap becomes tight against the Collar. This would give you the perfect fit after reassembling. If either the Plunger or the Tailcap still had a gap when the other became tight, you’ll need to make an adjustment.

Take note of where the gap was, and then extend the Plunger and carefully remove it. If the Plunger had a gap while the Tailcap was tight, you’ll need to loosen the Tailcap a few turns. If the Tailcap had a gap while the Plunger was tight, you’ll need to tighten the Tailcap a few turns. Once done, carefully re-insert the Plunger and test again.

Once you are happy with the fit, extend the Plunger just enough to give you enough room to fit the red wrench between the Collar and the Tailcap. You can apply a few drops of grease (supplied with your pen) to the Plunger seal if you’d like. Insert the Plunger assembly into the Body. Hold the Body and turn the wrench counter-clockwise until it is snug (be careful not to over-tighten).

If all went well, you should be able to fully retract the Plunger, and the cap should stay on the tail firmly.

In this tutorial, we’ll explore a method for organizing multiple revisions, creating backups, and allowing teams to collaborate effectively on PCB and schematic designs.

Table of Contents

What is Version Control?

Version control is like a file time machine. As you edit files, you can create checkpoints - known as commits - along the way. Later on, you can travel back in time and return to a previous commit. You can also review who changed a file and what they did.

Why should you use a version control system for your PCB designs? Isn’t it enough to archive old PCB revisions in a folder or create new files for each revision?

A version control system provides structure and organization to manage perhaps hundreds of revisions. Without the need to create multiple files and manually maintain backups, your project folder remains clean and organized. Production files are conveniently available but are unambiguously separated from development files.

A version control system allows effective collaboration by providing mechanisms to prevent data loss when multiple people try editing the same files. Further, any team member can check-out, review and edit the project if they have shared access to a repository.

Using a version control system is safer because you only modify your own local copy of the project. The entire history of the project is safely stored elsewhere. If you make a big mistake or corrupt a file, you can easily restore to the last commit. With this safety net, you can afford to take risks to solve circuit or routing problems without worrying that your previous work will be lost.

There are a few different options for version control systems, but I’ve found Subversion (SVN) to be useful and practical in a production environment, particularly because of its ability to enforce locks on files - we’ll learn more about these shortly.

Guide to Setting Up Version Control for your PCB Designs

Get Subversion

We’ll take a look at an example design process for a simple circuit and PCB using KiCAD, a powerful suite for schematic and PCB design. I’m assuming you have some background in KiCAD and have it already installed. To create and manage our SVN repositories we’ll use TortoiseSVN, a common GUI-based client for Windows that integrates nicely with the Explorer right-click menu. If you are using Mac or Linux, I’ve listed some SVN clients that appear similar (but I haven’t tested).

• Download TortoiseSVN for Windows: https://tortoisesvn.net/downloads.html
• Download SmartSVN for Mac: https://www.smartsvn.com/
• Download RabbitVCS for Linux: http://wiki.rabbitvcs.org/wiki/download

You can follow along with the command line - see the Appendix at the end of this article. You’ll need to first install SVN from Homebrew (Mac), your package manager (Linux), or by enabling the command line tools during TortoiseSVN installation (Windows).

Create and Setup A Subversion Repository

We’ll begin by creating a new SVN Repository. A repository is the database that stores information about file data, revision history, and various “rules” for the project. Make a new empty folder and name it BlinkyProject, then right-click the folder and click TortoiseSVN -> Create Repository Here. When prompted, click the “Create Folder Structure” button, then click OK to close all windows.

This repository folder only contains the raw database and not the actual files of your project, so don’t try and modify the files. Using the repository database, TortoiseSVN can create a local “working copy” folder. The working copy folder contains the actual project files. When project files are changed and committed, the working copy folder syncs information about the changes to the repository database.

Creating the working copy is known as “Checking Out” the repository. Right click on the repository folder, then click SVN Checkout. Change the working copy path to somewhere on your Desktop or Documents folder, if you wish. You can leave all the other settings the same and then click OK.

If you navigate into the working copy folder, you’ll see three folders - trunk, tags, and branches. Here’s briefly what we will use each folder for (don’t worry, each will be explained in the sections below).

• trunk: this contains all the living, in-development project files. Whenever you make fixes or edits to a schematic or board file, you’ll change the files in this directory.
• tags: this folder will contain “snapshots” of your project taken when you generate Gerber files for production.
• branches: miscellaneous boards based on tagged snapshots that may be customized, e.g for panelling.

There’s nothing special about these folders or their names, they are just SVN convention. You could rename them to something like “development”, “production”, and “variants” if you wanted.

Revision Tracking

Let’s explore SVN version tracking. Create a new KiCAD project inside the trunk folder, unchecking the box that says “Create a new Folder for this Project” so that project files are placed directly in the trunk. Open the .kicad_sch file and draw a simple circuit, such as a battery, resistor, and LED.

Our masterpiece is complete! Let’s commit our changes. Save and close the schematic, then right-click into the trunk folder, then click SVN Commit. Normally you would enter a brief message about your changes into the commit description section. For this commit write “Initial Commit”. Check the boxes next to the .kicad_pro, .kicad_pcb, and the .kicad_sch files in the area below to ensure they are included. Click OK, and the data will be sent to the repository database.

We didn’t check off the backup folder or the .kicad_prl file. This means that any changes to the files in the backup folder or the .kicad_prl file will not be captured during commits, nor will they appear when anyone else checks out the SVN repository. This is okay - we don’t need to store their changes in the repository because the .kicad_prl will regenerate, and the backups are only for short term use if KiCAD crashes and we forgot to save. Our commits will take care of backing up major changes.

Let’s say our requirements changed and we actually need two LEDs. Update the circuit now to add a second resistor and LED and when finished, save and close the file. Commit again, as described above.

At any time, we can review the entire history of our project by right-clicking the folder of interest, then clicking TortoiseSVN -> Show Log. By right-clicking a revision entry and clicking Browse Repository, you can open the files as they appeared at that point in history. Try opening the repository of revision 2 and viewing the .kicad_sch file. You should only see one LED present. If you would like to revert a file to how it appeared in a previous revision you can click the file, then right-click the revision and click Revert to Revision. If you open the schematic file from the file explorer, you’ll see the file is back to one LED.

Commits cost nothing, so it’s better to commit more often than less, creating checkpoints as you work. If you mess up and don’t know how to get back to your original state or you ran out of undos, you can always restore your last known-good commit.

When committing, remember to write descriptive change messages because - as we’ll soon see - trying to figure out what changes were made based on file differences alone is a major hassle.

File Locks and Collaboration

When multiple software developers work on the same file simultaneously, they can merge their changes together later. If the changes were in different sections of the file, merging is easy - both changes are incorporated. When multiple authors change the same lines however, a merge conflict occurs but can be resolved by rewriting the section of code in a way that maintains each change as required.

As PCB developers, we lack the critical tool that software developers take for granted here - the ability to read file differences to comprehend changes. To illustrate, right-click the .kicad_sch file and click TortoiseSVN -> Diff with Previous Version. Notice how a simple change - adding a second LED and resistor - created a file difference that is almost incomprehensible.

If you are working on a project alone and on a single computer, things are simple - you know that only you are editing any particular file at a time, so no merges are required. However, if you are collaborating with others and multiple people try editing the file, the result is effectively ‘all or nothing’. Because merging multiple changes in the traditional way is impractical, you could be forced to keep one version, and discard the other. I hope you’re good at rock-paper-scissors.

Luckily SVN has a tool to prevent this situation - enforceable file locks. When you enforce a lock on a file, it becomes read-only by default. You must “take” the lock before you can edit the file. If another collaborator has already taken the lock, the file will remain read-only. Otherwise the file becomes exclusively yours to edit. When you commit, the lock is (optionally) released, and others can work on it again.

I recommend enforcing locks on the .kicad_sch and .kicad_pcb files. Taking a lock on one won’t automatically take a lock on the other, which is fine because in most cases the PCB and schematic can be safely edited simultaneously by different people. To enforce a lock, select the .kicad_sch and the .kicad_pcb file, then right-click and click TortoiseSVN -> Properties. Click the arrow next to New, then click Needs-Lock, and check Locking Required, finally click OK to close all windows. Right-click and click SVN Commit to push the property change to the repository.

Notice now that if you open the .kicad_sch file, KiCAD now informs you that it is read-only. Close the file, then right-click it and select the new option SVN Get Lock. Enter a message - this will appear to anyone else that tries to take a lock on the same file - then click OK.

Well, well! The requirements changed again. You managed to take the lock before Bob (you want to impress the senior designer), so the file is yours to edit. Add a third LED, then finish the design by annotating and assigning footprints.

We’ll create the PCB now. Take a lock on the .kicad_pcb file, then open it and arrange the footprints, then connect them with traces and draw a closed shape around them on the EdgeCuts layer. Once you are happy, save and close the files, and commit them.

In the commit message window, you’ll notice an checkbox near the bottom left that says “Keep Locks”. If unchecked, the lock will be released after committing, but check the box if you plan to make more commits.

In rare cases, such as when Bob takes a lock but then goes on vacation (again) you can “steal” the lock. The lock transfers from Bob to you, but now you’ll have to figure out what happens when he returns and realizes he can’t commit his changes.

Tags and Production Revisions

One of the worst feelings is when your board arrives in the mail and after trying to debug it you realize the schematic or PCB files on your computer don’t quite match up. Perhaps you accidentally submitted an old Gerber file, or you made changes to the design files since submitting it for manufacturing. Even if you can access the Gerber files sent to the fab, they are of limited use because they lack any schematic or part information.

With version control, we can commit before generating Gerbers, then always be able to return to that revision for debugging purposes in the future. However, it can be a pain to switch back and fourth between revisions, so we can use an SVN tag to archive a copy of the production run directly in the repository and always have it available for review. Having an official “snapshotted” copy for each board version produced is useful during board bring-up and debugging, RMA repairs, and may be helpful for design traceability and compliance with regulations.

Our Blinky board is ready to be sent for fabrication. Right click on the trunk folder and click TortoiseSVN -> Branch/Tag. Change the ‘To path’ option to “/tags/V1”, and enter a message such as “snapshot production revision V1”. The tag has now been created, but you have to right-click the tags folder and click SVN Update for the new files to appear.

We will now generate Gerber files directly from the tag instead of the trunk. Having a Gerber folder alongside the development files in the trunk is dangerous - they don’t automatically update with the design and you can easily forget to regenerate them, leaving them out-of-date when you go to production. Open the .kicad_pcb file and click File -> Plot. Enter a path for the Gerbers, then click Plot. Click Generate Drill Files, then click Generate Drill File in the new window. Once you’ve reviewed the Gerber files with GerbView, run SVN Commit once more, making sure to check the new Gerber folder and the new Gerber files to include them. Write a commit message, such as ‘Create production files for revision V1’, then click Commit.

At this point TortoiseSVN will give you a warning about committing to a tag. By SVN convention, tags are read-only. We break this rule once to create production files, so click Commit now. If you see this warning at any other time take pause, as you may be trying to edit the tag folder instead of the trunk by mistake.

Now you are ready to submit the Gerber files to your PCB fabrication house of choice! At any point in the future, you can easily browse the files in this tag, which contains a guaranteed 1-to-1 link between the Gerber files and the schematic and pcb design files.

Branches for Manufacturing Variants

What if you need to panelize your boards before sending them for production? Panelizing boards often requires fancy PCB or Gerber editing, so it doesn’t really fit well with either the production revisions in the tags folder or the normal development files in the trunk folder. I recommend you use the branches folder to turn the production revision into a panelized board. Inside the branches folder create a new folder. Inside, create an empty .kicad_pcb and open it in standalone mode. Now you can append the board file from a tag and turn it into a panelized design.

Conclusion

In this article we’ve explored how to use the Subversion version control software with a KiCAD PCB project. After setting up the repository, we made some changes to the PCB and commit and saw how SVN tracks file history, and how you could review files as they appeared in the past. We also saw how SVN’s enforced file locks can help prevent conflicts or data loss if two people try to work on the same file at once. Finally, we took a snapshot of our project and created a tag to represent a production-ready revision, from which we derived the Gerber files.

Thanks for reading, and I hope you found this tutorial useful! Please feel free to reach out to me on the social links below if you have any comments or questions.

Appendix: SVN CLI Commands

Introduction

In this tutorial we’ll learn about how to make native unit testing easy for your embedded STM32 projects. We’ll start with a default installation of STM32CubeIDE - ST’s Cube-flavored distribution of Eclipse, and by the end of this article, you can begin writing unit tests or performing Test Driven Development on your STM32 project code directly in STM32CubeIDE.

Table of Contents

Benefits of Native Unit Testing For Embedded Systems

Why bother with unit testing on the development machine? Aren’t printf’s, debuggers, and on-target self-tests good enough?

The first advantage of native unit testing is speed. Cross-compilation is slower than native compilation, and flashing times increase as your codebase gets larger. Furthermore, in order to test a specific function you might need to manually bring the system into a particular state, set breakpoints, and examine outputs in the debugger. On an embedded system I worked on this build-flash-debug cycle could take between three and five minutes each time! Imagine realize you made a typo or a copy-paste mistake on the first line of the function and now you need to wait all over again.

Testing on target with the debugger is often not repeatable. It can be impractical to place the system in certain states, especially when dealing with edge-cases. With unit tests and loosely coupled code, you can craft isolated environments where you can initialize the system, inject specific inputs and review how the code reacts. You can inject rare or erroneous inputs that the real system may only seldom encounter. Every subsequent run will inject the same inputs and is not affected by any other tests.

Developing a system that can be tested on a native machine also improves your code by encouraging you to write in a loosely coupled and modular manner. In most cases, your unit testing won’t involve a full emulation of an RTOS or your microcontroller’s registers. This is a good thing - if the majority of your application code doesn’t rely on the specifics of those layers, you can more easily port the system to a new RTOS or microcontroller in the future.

The final benefit - it’s fun. It’s extremely satisfying to design code that snaps together like Lego, builds at twice the speed as the target compiler, and then runs hundreds of test cases in milliseconds. Having test cases reduces the anxiety of adding new features or refactoring, and the increased development speed reduces the anxiety of your looming deadlines.

Guide To Setting Up Native Unit Testing With STM32CubeIDE

This guide assumes you are working on Windows, and have STM32CubeIDE installed. If not, you can download it from ST’s website at https://www.st.com/en/development-tools/stm32cubeide.html .

Setting Up The Local Compiler

The easiest way to add a local unit testing configuration to an STM32 project is to create a native C/C++ project and use it as a template to create a build configuration in the STM32 project. We will use MSYS2’s package manager to download and install the MinGW64 C/C++ toolchain and GoogleTest libraries. If you already have a native C/C++ development environment installed, you can skip this section and download the GoogleTest library manually from your native toolchain’s repository.

Download and install MSYS2 from https://www.msys2.org/ . When installed run the MSYS2 shell (if it doesn’t open after installation, you can find it by searching “MSYS2 MSYS” in the Start Menu). Run the command pacman -Syu , which will start the first of two stages required to bring the package manager up to date. Allow the package manager to install the packages. Between stages, the terminal window will prompt you to close and manually reopen the terminal by clicking on the MSYS2 MSYS start menu or desktop icon. Complete the setup by running pacman -Syu a second time and accepting the package download when prompted.

Once MSYS2 is fully updated, you can begin installing the required development packages. Run the following command to install basic unix-like commands, the MinGW compiler and the GoogleTest libraries.

pacman -S base-devel mingw-w64-x86_64-toolchain mingw-w64-x86_64-gtest

Other packages and libraries you want can be installed later and will be made automatically available to the compiler.

Creating the Donor Project

Open STM32CubeIDE into a new or existing workspace.

From File→New→C/C++ Project, create a new C++ Managed Build project. On the next page, name it TestTemplate, select the Hello World C++ project type and use the MinGW GCC toolchain. The hello world project will let us make sure that our compiler is working;

Once created, verify that the project builds properly by right clicking the project in the Project Explorer and clicking Build Project. The output should appear as below.

21:07:39 **** Rebuild of configuration Debug for project TestTemplate ****
Info: Internal Builder is used for build
g++ -O0 -g3 -Wall -c -fmessage-length=0 -o "src\\TestTemplate.o" "..\\src\\TestTemplate.cpp" 
g++ -o TestTemplate.exe "src\\TestTemplate.o" 

21:07:41 Build Finished. 0 errors, 0 warnings. (took 1s.647ms)

Finally, click the dropdown next to the run icon in the menu bar and click the local C++ executable option.

!!!Hello World!!!

We are now ready to use this project as a template to build local C++ unit tests and files.

Integrating the Test Configuration From the Donor Project

Create or import an STM32 Project you would like to write unit tests for. In the filesystem root (in Explorer, not STM32CubeIDE), create two folders - one called Common and another called Testing. The Common folder is for unit testable (i.e. modular, loose-coupled, and cross platform) code and the Testing folder for the unit tests, doubles and mock objects. In STM32CubeIDE refresh the project so that the new folders appear - if they still don’t appear after a refresh, you may have to drag them from explorer into the project hierarchy and link them manually (this is the case with most TouchGFX application template projects).

Double check that the STM32 project and the TestTemplate project are both in the same workspace. Right click the STM32 project in the Project Explorer and then click Build Configurations → Manage… → New.

Create a new configuration with the name UnitTest, and in the “Copy settings from” section, select “Import from projects” then select the debug configuration of the TestTemplate project (this way the unit tests will have maximum debugging and no optimizations by default).

Click OK. Back in the Manage Configurations Window, select the new UnitTest configuration and click Set Active, then click OK.

Setting Up The Unit Test Configuration

Right click the STM32 project and click Properties, then in the sidebar select C/C++ General → Paths and Symbols. Ensure that the UnitTests configuration is selected at the top of the dialog box. In the Includes tab, click Add, and then add include paths for Common (apply to all languages and all configurations) and Testing (apply to all languages only).

In the Libraries tab, add entries for gtest and gmock.

In the Source Location tab, remove the (STM32ProjectName)/src filter, and add a filter for the Common and Testing folders.

Click OK to close the windows.

Building And Running Tests

In the Common folder, we’ll create a header-only class that could represent loosely coupled code that is also used in our STM32 project.

1/* Common/TrivialClass.hpp */
2class TrivialClass {
3public:
4	bool returnsTrue() { return true; }
5	bool returnsFalse() { return false; }
6};

In the Testings/ folder create a file called test_main.cpp, and copy the code below. The main method sets up the GoogleTest framework, and runs a trivial passing and failing test.

 1/* Testing/test_main.cpp */
 2#include "gtest/gtest.h"
 3#include "TrivialClass.hpp"
 4
 5int main(int ac, char* av[])
 6{
 7  testing::InitGoogleTest(&ac, av);
 8  return RUN_ALL_TESTS();
 9}
10
11TEST(BasicTest, PassingTest)
12{
13	TrivialClass t;
14	EXPECT_TRUE(t.returnsTrue());
15}
16
17TEST(BasicTest, FailingTest)
18{
19	TrivialClass t;
20	EXPECT_TRUE(t.returnsFalse());
21}

Right click the STM32 project and click Build Project. Assuming the build passes, right click the project again → Run As → Run Configurations. Highlight C/C++ Application and then tap the New Configuration button. Leave the settings as default and click Run.

If all goes well, you should see the following in the console:

[==========] Running 2 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 2 tests from BasicTest
[ RUN      ] BasicTest.PassingTest
[       OK ] BasicTest.PassingTest (0 ms)
[ RUN      ] BasicTest.FailingTest
../Testing/tests/test_main.cpp:19: Failure
Value of: t.returnsFalse()
  Actual: false
Expected: true
[  FAILED  ] BasicTest.FailingTest (0 ms)
[----------] 2 tests from BasicTest (0 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 1 test suite ran. (0 ms total)
[  PASSED  ] 1 test.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] BasicTest.FailingTest

 1 FAILED TEST

Because we deliberately wrote a passing test and a failing test, this is the output we expect.

If you’d like, you can try running the program using the debugger by clicking the dropdown beside the debugger icon in the menu bar and selecting the UnitTest executable.

Congratulations, you’re ready to begin unit testing or test driving your code right in STM32CubeIDE!

Cleaning Up and Next Steps

The last thing we need to do is ensure that we include our Common folder and exclude our testing directory when we are building for the STM32 target. Switch back to the Debug configuration, then open the project properties and navigate to C/C++ General → Paths and Sources. Select the Debug configuration. In the Source Filter tab, verify that the Testing directory isn’t on the list, but that Common, Drivers, Middleware, and any other target-specific folders are. In the Includes tab make sure that the Common folder is appended to the end of the existing list, but that Testing is not. Finally, the gtest and gmock entries should not be in the Libraries tab. Repeat these instructions for the Release configuration.

You can remove or close the TestTemplate project at any time if you wish.

As you begin writing loosely coupled and unit-tested code, place the source and header files in the Common folder where it is accessible to, and compiles nicely for both the unit tests and the target system.

I might make a future article that covers how I write loosely coupled, modular code that works great with unit testing. For now, I recommend the following resources:

• Test Driven Development for Embedded Systems by James Grenning
• Embedded Artistry: Musings on Tight Coupling Between Firmware and Hardware
• GoogleTest Primer

Fun Extras!

Use the C/C++ Unit Testing Plugin

The Eclipse CDT repository has a C/C++ Unit Testing Support plugin that ties into test runners like GoogleTest, and displays the output a little bit nicer than a console message. That can be installed by clicking Help → Install New Software, selecting the CDT repository in the “Work with” dropdown, and installing C/C++ Unit Testing Support from the CDT Optional Features section.

Once installed, open the project’s Run Configuration dialog. Select C/C++ Unit in the sidebar, then click the New Configuration button. In the C/C++ Application section, click the Search Project button and select the executable created by the Unit Test build. Finally, in the C/C++ Testing tab, select the Google Tests Runner from the dropdown. Click the Run button, and the C/C++ Unit tab will appear and display the test results.

Regular Testing With A Key Combination

A key benefit of writing code with Test Driven Development is that there is a tight feedback loop between writing code and testing it. Running tests regularly can help you spot bugs before they become masked. The best way to ensure that you remember to run tests regularly is to make it really easy to do. I like to assign a keyboard shortcut (such as Ctrl-R) to the Run command. When I hit the key combination my file changes are saved, the program builds, and the unit tests are run automatically.

To set this up, from the menu click Window → Preferences. Select the Keys submenu from the General section and search for “Run”. Select it and add your binding by clicking the Binding control and typing your desired key combination.

Next, in the General/Workspace/Build tab, check the box that says “Save automatically before manual build”.

Finally, in the “Run/Debug”/Launching tab, in the Launch Operation section (near the bottom) check the radio button that says “Always launch the previously launched application”.

Now when you press the key combination, your project will save, build and run the unit tests immediately. If the key combination started the run configuration for the console output and you wanted it to run the C/C++ Unit plugin configuration instead, manually run the C/C++ Unit plugin configuration from Run menu. STM32CubeIDE will remember that and run that configuration after the key combination in the future.

Conclusion

Unit testing on your native development machine is a great way to improve your embedded system development. It promotes modular code design, it is faster than target compilation, flashing and debugging, and it allows you to perform repeatable tests. In this article we explored how to set up the STM32CubeIDE to easily run unit tests against loosely-coupled STM32 project code.

Thank you for reading. I hope you found this article useful! I’d love to hear your thoughts or questions about this article - you can reach me on social using the links in the footer below.

Happy testing!

Introduction

In this tutorial, I’d like to introduce you to ST’s TouchGFX GUI framework, and get you started on building GUI applications with your own hardware. This is the beginning of a series of posts on TouchGFX and embedded system development. Each post will build on the previous - we’ll start from a simple demo using the TouchGFX designer, continuing with a more complex implementation using the built-in Model-View-Presenter pattern, and finally we’ll tie it all together with a practical project that interfaces with actual hardware.

What is TouchGFX?

In our smartphone and web app era, people are accustom to using devices with rich and intuitive graphical user interfaces. In many cases, a touchscreen is not only preferred, but expected. TouchGFX is a GUI framework that enables you to develop such interfaces for your products. It is built exclusively for STMicroelectronics family of processors. It features an easy to use drag-and-drop GUI builder tool called the TouchGFX designer that outputs a basic code structure upon which you can build your own application. The code is written in C++, so basic knowledge of the language is a prerequisite (although none will be required for this first tutorial!). Diving In

To follow along with this first tutorial, you won’t any need any hardware yet. The TouchGFX Designer can run a simulation of your code on your local machine, allowing for quick GUI development. However, we’ll set up our system for use with an STM32F469i Discovery Board, because we’ll be targeting that processor in future tutorials. You’ll need:

• About 30 minutes
• A Windows machine (although the framework is not platform dependent, the Designer is Windows-only)
• An account with STMicroelectronics to download the software (sign up here )
• TouchGFX Designer (Download Link )

Optionally, if you want to build with hardware, you also need:

• STM32CubeProgrammer (Download Link )
• STM32F469I Discovery Board

Installation

Unzip the X-Cube-TouchGFX file and run the TouchGFX-x.xx.msi file in Utilities/PC_Software/TouchGFXDesigner to install the designer.

If you have a discovery board, STM32CubeProgrammer allows you to flash the application to the hardware. Install it with the default install settings. Of note, it must be installed with the default installation path for the TouchGFX Designer to be able to use it. It may request a driver install - this is normal.

When installation is finished, open the TouchGFX Designer.

Hello World!

Welcome to the TouchGFX Designer! Create a new project targeting the STM32F469I Discovery Board by mousing over the Simulator box, clicking Change. Scroll nearly all the way to the right and click STM32F469I, then click Select. We’ll use a Blank UI template. Name your project and click Create.

The main TouchGFX window consists of 4 major parts - the left-hand Sidebar, the main Canvas View, the right-hand side Options Box, and the top Menu Bar. In the Sidebar you change tabs to select between displaying a palette of widgets, a list of screens and objects in your application, and any custom containers you’ve created (more on that in a future post). The main Canvas section shows the view of your application as if you were looking at it on the target screen. The Options box on the left will populate with options when you select an object.

TouchGFX starts us out with a default screen. An application can have a number of independent screens. We’ll start by adding a background to our default screen. Scroll down the widget window in the left Sidebar until you find a Box widget. Drag the box into the Canvas and grab the handles to scale it to the full size of the screen. Notice how the designer snaps your object to points of interest - namely the edges and middle of the screen. You’ll notice that because the box is selected, the Options Sidebar has lit up with a few options, such as the widget name (currently box1), its coordinates and size, and the color and opacity. Name your box something meaningful, like “background”. Let’s change the background color by clicking on the dropdown under Color and selecting your preferred color.

With our background in place, let’s add some text. Return to the widget menu of the left sidebar (the tab with the square and the +) and find the Text Area widget. Drag it into the middle of the view. If you select it, you’ll find options in the Option Sidebar that let you change the displayed text, the color, the alignment, etc. Change the color to something visible and the text to Hello World! or your test string of choice!

The text is looking a little bit small, so let’s change the style. Unfortunately, we can’t freely select different fonts and sizes for each textbox like we do in word processors*. This constraint stems from the way that graphics such as font glyphs are stored on resource limited systems. On your personal computer, the shapes and sizes of text are calculated on the fly using equations contained in font files. On most embedded systems the processing power required for this is too high, so the hard work has to be done upfront before the program ever runs. During the compile stage, each glyph that will be displayed on your screen is converted to a static, discrete image and stored with your program. Because of this requirement we have to specify in advance which glyphs we want and how large we want them, so that the compiler knows it needs to include them. These pre-specified sets of fonts are called Typographies. Although this may seem inconvenient, it has the upside of making it easier to maintain a consistent style between elements. For example, if you had a menu bar, all the textboxes in the menu bar could share the same typography. Down the line if you wanted to modify the fonts, all you would have to do is modify the menu font typography and all the elements assigned to it would reflect your changes.

If we wanted a different font for each textbox we would need to make a typography for each one individually.

You’ll notice that by default the TouchGFX designer generates three typographies - default, large and small. We can customize the font and size of each typography by clicking on Texts in the top menu bar, then clicking on the Typographies tab. If you wish, you can add your own.

Take this time to change the font and size of the typographies to whatever you would like. I changed the Large typography to Roboto Condensed, at 45 pixel size. The fonts that appear depend on what is available on your computer. Other settings, such as wildcards and fallbacks can be left as they are for now. We’ll cover them in a future tutorial, but try and guess what they do based on the explanation of typographies above. (Here’s a hint: by default, the TouchGFX designer will only generate glyphs for letters it knows for sure will be required).

When you finish, return to the main Canvas view and select your custom typography for your new text item. You may have to reposition it a little bit if the new typography changes the overall location.

Lets see it in action! Click the Run Simulator button, or if you have the dev board click Run Target. You should see your text front and center on the screen!

Diving a Little Deeper

Congratulations! You’ve learned how to do 80% of what you’ll normally be doing in the TouchGFX Designer (arranging widgets and setting text)! Let’s dive a little deeper.

We’ll continue by adding a button to our screen. Find the button section, then drag a Button (or Button with Label, or Button with Icon) into the view. You’ll see that the button has a few more options than the box, namely the images that it uses in its pressed and unpressed state, as well as the text (if you chose a label button) or an icon (if you chose an icon button).

Let’s make our button do something when its clicked, like fade in our hello world text. You can achieve some basic interactive functionality using the TouchGFX Designer Interactions tab. Access the Interactions menu it by clicking the second tab on the right-hand Options box. Click Add Interaction. For the first interaction we’ll tell the application to hide our text when we start the program. Set the trigger to be Screen is Entered. In the action pane, we’ll choose “Fade Widget”. We’ll select our hello world text object as the target, setting its opacity to 0 alpha over a duration of 0ms (instantly).

Add a second interaction, and choose the trigger to be Button is Clicked. Your button should be automatically selected (if you’ve added multiple buttons you can choose which one to bind the interaction to in the “Choose Clicked Source” dropdown. Set the action to Fade Widget again, targeting the text object, but this time set the alpha to 255, over a duration of 1000ms. The Easing setting will determine the rate that the alpha will change over the course of the fade. A great site to visualize these settings is easings.net.

The Tip of the Iceberg

You’ve successfully set up the TouchGFX designer and created a basic GUI application! There is so much more we can do - style our UI using the existing widgets, creating our own UI elements with custom containers, adding interactive functionality between multiple screens, interfacing with a backend system or hardware - the list goes on. In the next post we’ll dive deeper into our application and examine the code that will bring our system to life. In the meantime, try playing around with the different widgets and interactions available and see what you can create!

Conclusion and Footnotes

Thanks for reading! I hope this post was helpful in getting your feet wet with TouchGFX. If you have any thoughts you’d like to share about your experience, reach out at the social links below.

Here are some notes that may be of interest/use to you at this stage.

• If animations aren’t smooth on the target, it may be because optimizations are turned off! We’ll touch more on this in the next tutorial.

• I’ve encountered a bug where the simulator will work fine, but the target will refuse to display the screen on startup. Strangely, adding an invisible button tends to fix this issue, and I’m not sure why.

• If you have a font you would like to use that doesn’t show up in the list on the typographies page, place the TTF file in the TouchGFX/assets/fonts/ folder in the root of the project.

• The TouchGFX designer outputs project files compatible with a number of different IDEs. If you want to get a head start on further development, download STM32CubeIDE and explore the code.

Lately it’s been rare to see a product release that really wows people, but the Apple event yesterday came pretty close. Two points that I found pretty interesting were the new Touch Bar and the distinct lack of ports other than USB-C (and a 3.5mm audio jack). In this article I discuss my thoughts on the significance of these two changes.

That New Feature

The Touch Bar breaks the mold of each new model being “Apple’s Fastest/Thinnest/Lightest MacBook ever” which in recent times has been mostly viewed as lackluster as far as innovation goes. It’s a long touchscreen bar that replaces the function keys with interactive software buttons, which change depending on which application you are using. It’s a new and cool addition, and there are no other keyboards out there that feature an auxiliary touch screen.

Except… there are. Both the Razer Deathstalker and the Mad Catz Strike 7 keyboards have them and they were first released in 2012.

But the Touch Bar actually is still special.

Apple has the relatively unique position where their operating system (and all the apps that run on it) is limited to hardware which they have full design control over. What separates the Touch Bar from the Deathstalker or Strike 7 touchscreens is that unlike a relatively small keyboard manufacturer, Apple can effectively say to developers “Here is this new thing, here is the API to use it and its functionality will be available to hundreds of thousands of people simultaneously”.

As far as time invested versus return for developers, that sounds a whole lot better than “Here is a proprietary API to allow customers who have bought this single line of keyboards from a single manufacturer in a niche market to use this touchscreen” (repeated for each different keyboard brand with a touchscreen).

One API and instant widespread adoption of this new feature is a great selling point for app developers to begin using it right away.

Frustration Today, Convenience Tomorrow.

Apple doesn’t stop exercising their design control with the Touch Bar. A large source of controversy this year was the removal of the 3.5mm audio jack from the iPhone in favor of a single USB-C port. While (perhaps ironically) Apple has elected to keep the audio jack on the MacBook Pro, all other ports from previous models have disappeared in favor of 2-4 USB-C ports.

Lately the expression “dongle hell” is often used in referring to the compatibility issues that changing to USB-C will cause. Any device that uses the previous USB generation, SD cards, monitor plugs, Ethernet cables, or other types of connectors can no longer interface directly with the laptop. USB-C has implements many improvements over standard USB, including faster data transfer speeds and higher current ratings, however the new connector forces people to buy adapters to continue using their old equipment.

This has all happened before though – back in the 90’s the go-to standard was the RS-232 port, as well as various other serial, parallel, PS/2, and game connectors.

In the middle of 1996 the Universal Serial Bus (USB) standard was introduced. It bore many improvements over the many cables it was to replace, but it also required an entirely new connector and used an entirely different protocol, so it was sparsely implemented at first. Can you guess which company was noted for embracing it?

In a move criticized by many, Apple opted to exclude the then-ubiquitous floppy disk drive from their new 1998 iMac G3, included two USB ports and told anyone that wanted to continue using floppies to buy a external USB floppy drive. From then on, USB became more and more prevalent in PCs due to the growing market for devices that used it. Almost two decades later, USB is everywhere and floppies are known merely as ‘the save button’. It may be reasonably assumed that a similar criticism and subsequent stubborn yet inevitable adoption may follow Apple’s decision to push USB-C on the 2017 MacBook Models.

Wrap-Up

An occasional refresher of standards is arguably a good thing – designs plagued by feature creep can be redesigned and streamlined, multiple implementations of the standard can be combined into an overall superior implementation, and nagging issues of the previous generation can be efficiently fixed. This of course comes at the cost of discomfort among users during the transition phase.

Overall, the new MacBook Pro seems to be a step in the right direction for Apple. Motivation for developers to implement functionality for a new peripheral exists because of the large number of people it will reach due to Apple’s design control of their hardware. The radical and sudden adoption of USB-C has the potential to disrupt the market and increase the demand for USB-C devices, which will allow consumers to reap the benefits of it in the future.

Where would we be without change, after all?

–

The following articles were referenced in the writing of this post to get a sense for the original public reception of USB adoption and the removal of the floppy drive from the iMac:

Charles Pillar. “The ‘i’ in IMac Doesn’t Stand for Inferior . . . or Floppy Drive.” Los Angeles Times, 11 May 1998. Web. 28 Oct. 2016.

Vogt, James D. “The IMac and the Floppy Drive: A Conspiracy Theory.” (Opinion Piece) OSNews. 3 Aug. 1998. Web. 28 Oct. 2016.

Garfinkel, Simson L. “USB Deserves More Support.” Boston Globe Online, 20 May 1999. Web. 28 Oct. 2016.