Well, the above video is the result of the last few weeks of rapid prototyping, analysis and iterations. This has been one of the most satisfying streak of engineering I've undertaken in the recent past, with a mix of DIY/Maker approach and also meticulous measurements, analysis, optimizations and automation. The journey took me through characterizing the magnetic field of the coil, correlating it with theoretical equations and making web calculators, making the coils, automating the coil manufacturing and designing and implementing various embedded algorithms for magnetic motion.

Although there are a lot of engineering challenges ahead, these experiments did certainly move the project closer to completion.

The Approach

The final product is intended to be made on a PCB with integrated coil, drivers and embedded logic. Before committing to PCB based coils, I wanted to do a discrete level prototyping to understand what challenges lay ahead. There were multiple parameters to be understood about electromagnetism. What I was interested in here was an analogue of force between an electromagnet and a permanent magnet. Which parameters affects this force and how to optimize them?

Per Biot-Savart law, the electromagnetic field would be affected by current, number of turns, wire thickness, inner diameter, outer diameter, height of the coil and distance at which measurement is being made. Next, often these parameters would be inversely related to each other or would have an unintentional outcome like heat or would have law of diminishing returns. Understanding this would point me in direction of optimal parameters to tune.

Test Bench

The only way to validate a theory is by data collection, probing and measurements. So, I started by listing down the measurements that would be needed for the project and then selecting instrumentation for the same.

First, the basics, the instruments needed by almost all electromechanical projects. A multimeter, power supply and a caliper.

Then few things slightly more advanced, these are the tools which a serious project might utilize at some point in time. An oscilloscope and a current probe, a thermal camera, an LCR meter.

Picoscope and current probe to observe the voltage and current waveforms. This would help analyze protection circuit needed

A thermal camera to see heating of the coils and drivers and evaluate various cooling mechanisms in the future.

The LCR meter was used to validate coil manufacturing and also to corelate coil electrical properties like current, rise time, total current, fall time etc. as function of inductance, resistance of the coil, frequency, duty cycle and voltage of applied input.

Finally something exotic, unlikely to be used by any project which doesn't use magnetism.

The magnetic field viewing film has been super helpful for understanding the field patterns throughout the data collection stage.

To put numbers on the measurements and calculations and correlating it with theoretical calculations, I got a Tesla Meter.

Theoretical Calculations

Well, we can go into the derivation, but it's unlikely most of the readers would be interested in that. If you're one of the few interested, you can contact me and I can send you the link to the derivation.

In short though, consider the coil to be a series of circle. The radius of each circle is Ri where i is the layer count. The distance of the circle from measurement point is Zj where j is the turn count.

The support has inner diameter Di, height h. Also the wire has thickness t. There is no space between the layers or turns.

1 - Inner Diameter (Di)
2 - Height of coil
3 - 1st Turn
4 - nth turn
5 - 1st layer
6 - lth layer

Then the magnetic field strength contribution by that loop is given by

\[B = \frac{\mu_0 \cdot I \cdot R_i^2}{2 \cdot (R_i^2 + Z_j^2 )^\frac{3}{2}}\]

Now, there are few inferences I can make out of this.

\(B \propto I\)
\(B \propto \frac{1}{R}\)
\(B \propto \frac{1}{z^3}\)

If we approximate spiral as multiple circles, magnetic field will be sum of all rings.

\[B = \sum_{i=0}^n \sum_{j=0}^l \frac{\mu_0 \cdot I \cdot R_i^2}{2 \cdot (R_i^2 + Z_j^2 )^\frac{3}{2}}\]
\[l = \frac{h}{t}\]
\[R_i = \frac{D+t}{2} + i \cdot t\]
\[Z_j = Z_0 + \frac{t}{2} + j \cdot t\]

BUT, not all circles are made equal.

The top turns are much more closer to the measurement point and thus contribute exponentially more to the final result. The inner layer has smaller radius and thus contribute more to the measurement. Intuitively, adding more turns or layers should atleast mean we are adding more to the field although in smaller amount with expanding layers or further away turns but it comes at a cost and trade off.

Increasing the number of turns or layers also needs more length of wire thus increasing wire resistance and needing more voltage to force same current and increasing power required. Furthermore, the size of the coil (external diameter and height) also increases.

So, deducing what geometry of coil to use also depends on whether we are operating in constant current mode, constant power mode or constant voltage mode. If we operate at constant voltage mode, lower number of turns is beneficial as it increases current drastically and removes lower contributing coil passing higher current through a single coil. At constant current mode, more number of turns will contribute more. Practically, there would be a limit to max voltage we can apply, max current we can supply and max heat we can sink. If we operate at constant power or bring these constraints in, there would be an optimal point below which adding coils is still better but above which adding coils decreases the performance.

So, the next task would be design of experiments and simulations to understand these better. Then collect data and prove or disprove the hypothesis and see if it matches theoretical understanding of the system.

Design of Experiments

Now that instrumentation was taken care of, I started by designing the set of experiments. To quickly initiate things, I started with buying few off the shelf coils, few MOSFET drivers and an ESP32-S3 board (later replaced by RPi2040) and breakouts for proof of concept. This got me started on the first path of understanding electromagnetism.

Now as per the formula in theoretical calculation, I was interested in studying various effect on magnetic field by varying parameters like current, voltage, power, number of layers, number of turns, inner diameter, height of coil etc. Then, I want to see undesired effects like heat, sound these parameters might have. Finally, come up with algorithms to make various motions.

Experiment 1: Current vs Magnetic Field

Experiment 2: Coil Geometry vs Magnetic Field (simulation)

Experiment 3: PWM vs Magnetic Field

Experiment 4: Linear Motion

Experiment 5: Self made coils

Experiment 5a: Automating Coil Assembly: The side quest

Experiment 6: Coil Grid

Experiment 7: Centering Algorithm

Experiment 8: Linear Motion

Experiments

Experiment 1: Current vs Magnetic Field

In a single coil, keeping all other parameters like geometry and measurement distance constant, vary the current and note down the magnetic field strength.

Result, the magnetic field is directly proportional to current as expected

Experiment 2: Coil Geometry vs Magnetic Field (simulation)

Next, if I was going to design my own coils, I needed to understand how does increasing number of turns, layers affect my magnetic field performance. I started by creating a Jupyter notebook for my calculations. Here I can play with number of turns, layers, wire thickness etc. and see what helps and what doesn't.

Keeping
Inner Diameter (Di) = 4mm
Wire Diameter (t) = 0.33mm
Measurement Distance (z) = 1mm
Number of turns per layer (n) = 1
Number of layers (l) = 10
Current (I) = 1 Amp

We get
Outer Diameter (Do) = 10.6mm

Total wire length: 182.68 mm = 0.18 m

DC Resistance: 0.047 Ω
Voltage drop at 1 A: 0.047 V
Power dissipation: 0.047 W

Keeping other things same, just changing the number of turns to 10 and changing number of layers to 1

So, at constant current, increasing the number of layers is more beneficial than increasing the number of turns per layer since increasing the number of turns takes the coils further away from measurement point and it's contribution decays exponentially while by increasing the radius, the contribution decreases linearly.

After adding the practical limits of voltage and current and then operating the coil at constant power, the magnetic field strength will have a optimum number of turns and layers post which the strength reduces since the added turns consumes power and decreases current without adding sufficient contribution to magnetic field.

Experiment 3: PWM vs Magnetic Field

Next, I need to be able to control the current through each coil programmatically. I assumed (wrongly) that this should be simple. I can put a MOSFET in between the coil and microcontroller and control the current through coil via PWM by changing the duty cycle of the input.

On collecting the data, I was able to control the frequency and duty cycle through coil, keeping the voltage constant, the current seems to increase with duty cycle with a slight twist. The relationship was not linear.

So I decided to get the big guns out. Took LCR measurements and captured the current waveforms through the coil with some explained and some unexplained behavior.

The current seems to be function of voltage, frequency, duty cycle and circuit elements like freewheeling diode, capacitor etc. The waveform can be split into 4 parts, the rising edge (till it becomes static), the stable part, the falling edge and the off curve.

100Hz, 30% Duty, 5V, 3Amp, no freewheeling diode

1KHz, 30%, 5V, 3Amp, no freewheeling diode

I've yet been unable to put a equation controlling the both as well and decided to park this problem for later. This is a parked problem for now and if anyone wants to collaborate and help me put this relationship together, I'd be very much interested in any help I can get.

But even if I'm not able to put a theoretical equation together and although not linear, I can collect data and put together a curve which works for me by trial and error. So, this should not be a show stopped.

Experiment 4: Linear Motion

Next, I took some of these coils and created a 3D printed fixture to hold them in place. Putting a magnet on the track, turning the coils on and off, I was trying to move the magnet on the track. After few attempts, it did succeed but with few tweaks and learnings.

The major learning were

1. The magnet diameter has to be bigger and coil geometry needs to support it such that a magnet covers atleast 1 full and 1 partial coil at the same time.
2. Having a ferrite material closer by, the attraction between magnet and the ferrite is more than strength of attraction between electromagnet slightly ( few mm) further away and the motion would stop.

Experiment 5: Self made coils

After above learning, it became important for me to create my own coils. This would help me optimize the geometry for my application. Thus I got copper wire and 3D printed a spool to start winding my own coil. Although tedious, the data collection here would help the project further. This would also give me ability to control the geometry and iterate quickly if things don't work out

Experiment 5a: Automating Coil Assembly: The side quest

After winding a few coils myself, I needed something more consistent. I started looking for quick machines I can buy. There were few options but all of those needed hollow core which I didn't want. So, while looking for more options, I gazed over my old 3D printer which has all the components I need. So, I decided to embark on a side quest and build my own coil winding machine.

I took the extruder motor and built a fixture around it. This would be the motor which pulls wire for me onto the spool. Then I synced X motion with extruder turns so that when the wire is being pulled, the head moves horizontally providing clean and evenly spaced coil. Built a fixture to dispense the wire. And iterated over few fixtures, solving problems like pointing accuracy needed (using dispensing needles from syringe), wire tension (using multiple pulley turns) and hacking the gcode to allow cold extrude, long extrude and syncing the exact turns needed. I was able to get something which works consistently.

Now, I had a machine to which I can say, here, this is my 3D printed spool, make a coil with 28AWG wire, 30 turns per layer and 12 layers and it'd do the same for me almost consistently.

Experiment 6: Coil Grid

Finally, I had enough coils (after weeks of iteration) to put in a 3D printed grid. Organizing the wiring, soldering together the wires and connecting it to the controller. Finally I had the setup to start playing with.

Experiment 7: Centering Algorithm

Placing the magnet manually anywhere on the grid, I wanted to pull center it on a coil.

Just turning the center coil on didn't have enough pull to bring the magnet to it and center it.

Next, making a 3x3 grid on had enough pull (almost) to being the magnet in though it would not center the magnet. Making the center magnet strongest and surrounding ones weaker worked better. Then it was a matter of finding the correct strengths for them. Although, there was one issue, the magnet would still move around if forces slightly. The strength of the permanent magnet is not centered strongly.

Turning on the 2x2 coils had a better result and constrained the magnet better.

Experiment 8: Linear Motion

Finally, the motion. Increasing the current through coil in direction of motion and simultaneously decreasing the previous coil results in the motion. Although, initially there was a audible noise which could be heard. The frequency which I was operating in (the frequency range of ESP32-S3) overlaps audible frequency. In order to get rid of this noise, I needed to operate above the audible frequency range. Well, ESP32-S3 doesn't support that frequency range. So, I had to migrate the microcontroller to something that does (and also which hopefully exists in my grab bag). This turned out to be RPi 2040. Also, the MOSFET needs to support faster switching, although my current of the shelf kit doesn't specify it, they were able to turn on at the higher frequencies. When I migrate to a custom driver board, I'll need to select one which has faster response time, atleast 30KHz i.e. above the audible frequency range.

Next Steps

This was a long stretch of data collection and analysis. There are still unanswered questions and puzzles to be solved. I'll be working on those in the comings weeks and hopefully, given that there are no major roadblocks, I'm targeting to have a working prototype by September.

Few of the next things to work on are

1. Collect data with PCB based coils. I bought some from microbot.io to experiment with
2. Design a PCB for coils and drivers. Move these to a PCB and experiment with coil geometries. Check if the field is sufficient for motion.
3. Piece detection i.e. when user manually moves a piece, identify which piece is kept on which square.
4. Board and piece geometry. How big do I want the board and pieces?
5. Heat sinking i.e. keeping the product at manageable temperatures
6. Power management
7. Knight's motion
8. Chess engine and software
9. Cost optimization

Interested in collaboration, discussion or feedback? I'd be happy to strike a conversation. Ping me on Linkedin or send me an email.

At the start of the year, I found myself thinking about what kind of project would be worth committing to—something challenging, educational, and fun to build. After brainstorming multiple ideas and after much deliberation, I decided; the project that gets to take resource out of me to be automatic chess board. It'd be fun to play physical chess with computer or people sitting at the other side of the world. It'd be fun to see pieces move magically by themselves like in Harry Potter.

This article is the part one of build log and discusses the design exploration, architecture and project breakdown for an automatic chess board.

Defining the Requirements

The overall requirements for the projects are simple. I want a chess board where we play the pieces on the one side, the pieces for the other side move by themselves. Our movement is recognized by the computer, analyzed and it plays the next move.

It should also have a manual mode where other user is able to play a move online and it gets reflected on the board here.

The product should look like a finished product, standalone without requirement of external computer, Wi-Fi and such. Some features might need Wi-Fi like online play but the minimal version should not. At most, a USB C based power cable would be allowed. The board should be self contained, should not have camera, robotic arm etc sticking out and should not need a mobile app, it could be needed for some additional features but should not be a compulsory requirement.

Additionally, a stretch goal for the project would be doing chess puzzles and non standard chess games where rules are different and initial positions might be unknown.

And at least, project should also be economical. Definition for this is not strict but sub $1000 is must, ideally sub $500.

Breaking down the project

Moving on to the architecture of the project, the project requirement can be broadly divided into 3 major sub systems.

1. Piece motion i.e. how the computer moves its pieces
2. Piece Detection i.e. how the computer identifies my moves that is which piece has been moved and where
3. Chess Engine and software integration i.e. how does the system calculate it's next move, the UI frontend etc.

Market Research

Chess as a game has existed for 1500 years. Automation has existed atleast for 200 years. Given that humans love to make interesting things, it's almost a fact that someone has built this earlier. Let's start by understanding how others are tackling this project.

Commercially, there are 2 categories of products. First, which recognizes your moves and shows their move using indicators like LED or on app which then would be played by you. Second, which plays their move using internal mechanisms. While there are a ton of first category boards, I could find only 2 major boards in the second category; Square off (now miko) Grand and Chessnut Move. To complete the list, there is also senserobot.

Apart from commercial products, there are multiple DIY projects doing the same on instructables, hacksterio, hackaday and personal blogs.

Mechanisms for movement

The first piece of the puzzle, how do the pieces move by themselves. This in itself is a big challenge but doing this eloquently, reliably and cost effectively pose another set of engineering challenges. As is usually the case with engineering, there are multiple designs to consider, trade offs to make and calculations to run. Let's list them down and then elaborate and compare them.

1. Robotic Arm
2. Robotic Pieces
3. Subsurface XY Gantry
4. Electromagnetic array

Robotic Arm

While technically feasible, this approach conflicts with the goal of a fully self-contained board and is therefore excluded from further consideration. I'd like everything to be self contained in the board and pieces. I'd like to avoid anything sticking out of the board. If I do decide to go with this approach later, all we need is a off the shelf robotic arm or build one of our own. Either way it is a no for this approach for now.

Commercially, SenseRobot Chess and Cynus by Manya does take this approach.

Robotic Pieces

If designed well, we can also put motors and wheels on the pieces themselves. This is what ChessNut Move does. While possible, the mechanism itself is quite complicated for it to be a short term DIY project. Also, the pieces would now need a battery and charging which is more hassle than I'm willing to handle for current scheme. Also, personally for me, the motion doesn't seem

Subsurface XY Gantry

Next idea comes by first embedding a magnet in each piece and then to have a robotic gantry below the surface and use electromagnet to drag the pieces to their position. This method is commercially being used by Square off Grand. Apart from this, this method is quite common in the DIY community. This is a good option to consider. The slight disadvantages of the method though is there is mechanical motion involved with motors which would be susceptible to damages when subjected to vibrations.

Electromagnetic Grid

The idea here would be to have magnet embedded within a piece again but instead of a mechanical motion, we'd have electromagnetic grid on the board and we turn on and off those to attract the pieces together. If we play with magnetic strength, we should be able to move the pieces on the grid. Now, this idea in concept should work but when we run the calculations, it seems to be on the border of possibility. Reason being, electromagnetic strengths are very weak and getting anything out of it needs high current and wire loops. But if achievable, it is an eloquent solution. Specially, if we are able to design these coils on the PCB, the manual labor for assembly also comes down significantly. Of course the trade off comes to design and engineering costs.

Commercially or DIY wise, I couldn't find a board which uses this concept, that may be for a good reason and it might not even be possible. Although, some project do explore the motion and make motors out of the same. This gives me some hope. I'd still like to give it a try.

Conclusion

Primarily, I'll be investigating the electromagnetic grid feasibility, do some prototypes and analyze the engineering challenges. If it doesn't work out, my backup method will be subsurface XY gantry.

Ideas for piece detection

The next challenge is for the board to detect which piece has been moved by the player and what is the new position.

Computer Vision

Similar to robotic arm during motion phase, certainly doable but not the approach I'd like to take. Having a camera sticking on the top is not desirable.

Position Change and Board State Machine

This method essentially consists of placing the pieces at a known starting position. Each square has a sensor, either magnetic switch or light based to detect only if a piece is present or absent on that square. Then by tracking which squares are turning off and which are turning on, we can deduce a piece from square X1Y1 has moved to X2Y2. After this move, computer can check what was the original piece at X1Y1 and whether the move was legal.

While being simple, there are 3 shortcomings of this system.

1. The initial position of the board has to be known. The squares by themselves can't detect which piece is kept there, only if a piece is kept there and it relies on initial position for the rest. This also means non standard games and chess puzzles are not possible with this approach unless it is accompanied by an app.
2. The board doesn't know by itself regarding piece promotion. Which piece has been moved to that position.
3. If the player cheats or moves two pieces at once, there is no way to deduce that.

NFC based ID detection

The next idea would be to have NFC sticker on each piece and NFC reader beneath each square. The reader can detect the NFC sticker and thus which piece is kept on which square.

In theory, this could work but there are 3 major challenges.

1. Cost, having one reader per block would be around $3 * 64 i.e. $150
2. Antenna design, designing wave shaping antenna such that nearby readers are not triggered during movement will be difficult
3. Antenna would need to work in EMI noise environment of switching coils

Board positioning

This would be something on the lines of co-ordinate tracking of the piece by some form of RF triangulation or microphone triangulation. It'd need a circuit and a battery on each piece and some detectors on board edges to find relative position of the piece.

I don't like the idea of putting a battery in each piece. This would bring maintenance concerns and the engineering behind this triangulation and filtering would be challenging for me considering the timeline. I'd explore this as a separate project.

Magnetic Signature Identification

Idea behind this is to put different strength of magnet in each kind of piece and then each square has a hall effect sensor which measures the magnetic field strength around that square. By isolating the magnetic field strength, we can classify the piece.

Challenge on this would be, magnetic strength is a very strong function of distance. So, a off centered strong piece could be identical to a centered weak piece which would be difficult to isolate.

Despite its challenges, the method is interesting enough to atleast simulate. The cost would be lower with just one sensor per square and engineering post simulation would be easier.

Electrical Identification

If we can make electrical contact between the pieces and the squares, we can make communication between the two. Something simplistic like measuring resistance between the terminal of piece or RC oscillations should be sufficient to identify the piece. The challenge though is making this contact while sliding the piece and making this contact reliably irrespective of how of orientation of how user places their piece.

Conclusion

For this, I'd start by exploring Magnetic Signature Identification. Based on if it works or not, my backup option would be electrical identification or at minimum position change and board state machine.

Other Considerations

Apart from the feasibility of these approaches, there are questions of geometry of the board and pieces, how would the knight move, construction methodology, manufacturability, cost, chess engine integration, UI integration, chess.com/lichess integration and such.

We'd keep these in back of our mind during the prototype and engineering stage and later do a formal study on these.

What's next?

Next phase for the project would be design calculations, simulations, engineering feasibility study. I'd run the numbers and simulations to figure out what could be worth exploring, what's the confidence range on the same and what are the dead ends. In the next 2 month, my target would be to complete this stage and move to engineering prototype of individual subsystem.

I plan to explore FEM for electromagnetic simulation, KiCAD for schematic and board design, some magnetic simulators by TI in the coming month.

I'd try my best to complete the project this year. Although as with many of long term endeavors, chances are I might abandon the project before I complete it. But even a partially completed project is a good learning opportunity. Hopefully, the journey matters more even if the destination is not reached.

Got feedback? Would love to hear them. Shoot them out at rishabhrkaushik@gmail.com

As a DIYer, I've been working on tens of projects since a decade now. The most common problem with many of the software projects is dependency management. Be it a python project, Web Dev or embedded system, the tools and libraries keeps on updating and they're unfortunately commonly not kept backward compatible. This means, if you update libraries, tools or other dependencies, your project would no longer work. If you change the system or are working in a team, the code becomes difficult to maintain and compile and then you're spending more time on figuring out these errors than actually something productive giving rise to cliche developer joke "It works on my system". Also, when you open the project after few years for a minor change, it no longer compiles and you're most likely gonna write the whole project again.

The Evolution

Thankfully, over the years, multiple systems have evolved to that care of this issue. The evolution till now has been broken into 4 stages and based on complexity of the project, we don't need to go all the way to the last stage.

1. Package Management
2. Virtual Toolchains
3. Containers, Stacks and Clusters
4. Dev Containers

Package Management

The first problem to solve was how do I list the dependencies to be installed along with version numbers of the same. This gave rise to package management solutions. From requirements.txt file for Python to package.json for node.js. Now you could atleast have your packages and dependencies listed and easily configured. List down the libraries and their version number in the files, and the collaborator or you after years would still know how to configure the same project.

Virtual Toolchains

What package management doesn't solve is the version of toolchain itself. What version of Python, nodejs was used for the project. Also, if I have multiple projects in same PC using different versions of tool chain, there would be conflicts and that would raise errors. This have rise to next step of evolution, virtual environments. From venv or anaconda for python to NVM (node version manager) for nodejs, as long as you could specify tool version to be used in README file, it was easy for others to replicate the similar environment.

Containers, Stack and Clusters

Next comes even tougher problem. How about projects where you need installations along side the toolchain for the project to work. Or if your project need OS level changes like opening a network port. For e.g., what if a project uses Python along side compiled C libraries? Or a Node project which needs database alongside installed and running and couple of ports opened on OS?

Here comes the next step, containerization. Have all toolchains needed installed on a virtual layer on top of your operating system so that when you want to share the project, you share a configuration file and all required tools, packages, OS configuration happens automatically. Almost like a magic. The step which used to take weeks earlier alongside tons of documentation, now can be done in minutes.

Docker makes it easier to run virtual OS layers alongside configuration to run on any machine in minutes. Furthermore, tool like docker compose could have these broken down into multiple images all running easily like a stack on single machine. Whereas tool like kubernetes makes it easier to deploy these in clusters across multiple servers. This makes it easier to manage workload across multiple machines simultaneously.

Dev Containers

Now comes the last piece of puzzle. How do I version control my development environment so that my IDE extensions can be version controlled and managed without making it too heavy for me to run another operating system itself for each project. Or avoid the clutter of extension in IDE since each project needs different kinds of extensions. Here drops in devcontainers. Not only are all your toolchains now inside a docker containers but also extensions for IDE. You can customize your host IDE (VS Code in this instance) with themes and UI but all compilation happens inside containers.

Conclusion

These solutions are not perfect and they do need attention to detail like mentioning proper version number, scripting and testing configuration itself and some other form of communication to run and configure these but they are damn good place to get you started for having replicable projects.

This only solves making compilation replicable. You still need to use proper tools like git to manage versioning your code itself. And then you need to have process and people on top of everything to make and maintain the software quality. Processes like formal review, unit testing, integration testing, documentation and release lifecycle. After all, getting things to work is easier than delivering maintainable quality software.

“Design is overrated, Manufacturing is underrated”

Though I might not agree with the first part of the statement, I definitely do agree with the second part. In this article, I would be talking about my learnings from transition from design world to manufacturing world for electronics products. I'll also cover importance of invoking design for manufacturability, testability and assembly failing which might drastically affect cost or performance of the product. Finally, I'll be taking few specific examples from my recent project. Also, it was amusing to relate the issues directly with first principles of physics.

The Background

To provide some background, for those who don't know me, I've been working in various stages of product development for about 7 years now. Till a couple of years back, the firm where I work had been outsourcing manufacturing of our designs to various 3rd party vendors who would do PCB fabrication, PCB assembly, enclosure manufacturing, cable harness manufacturing etc for us and then we made strategic decisions to invest and slowly bring some of these capabilities in house. Starting with CNC machining, cable harness, PCB assembly and a few other processes.

Recently I transitioned from designing products to managing inhouse manufacturing for a product. The first product was a power electronics evaluation kit, mostly containing few PCBs, some cable assembly, heatsinks, enclosure and such. We got to manufacturing and slowly the behemoth of manufacturing variables started appearing. Variables to which as a designer I had seldom paid attention to. Many of them are small but if not taken care would severely affect the manufacturability or performance of design. To be fair, the product was decently well designed, although when it comes to manufacturing, small parameters which designers might not even be aware about plays a big role. Design for manufacturability, design of testability, design for assembly are more often than not ignored, especially if the manufacturing volumes are not huge, but small decisions can severely affect the performance, ease and cost of product.

Case Studies

Let's take few examples, some of these are specific to power electronics but similar variables would be applicable for other designs as well

PCB Warpage

The first issue we observed was PCB warpage. One side of PCB was getting bent and creating a warpage of 150 microns. Now, I know it sounds small, but to put things in perspective, average solder paste thickness is just xxx micron, that means long components like PCIe connector would not lay flat on surface and middle pins would not even touch solder paste. The root cause, copper imbalance between layers combined with high copper thickness (4 ounce). This causes board to heat unevenly, causing uneven thermal expansion finally causing PCB to bend just like a bimetallic strip.

Solder Bridges

Second issue, this was caught and avoided early on. Solder joints between pins. Root cause, higher stencil thickness or higher stencil apperture opening based on thickness. Stencil thickness and apperture area finally determines the amount of solder paste that will be deposited at a pad. Have a bit more solder paste than required and it'll overflow to nearby pad and form a joint during reflow effectively shorting the pins.

Temperature Exposure

Another potential issue, although this wouldn't cause manufacturing problems but would result in degradation on product performance and reliability if not taken care during manufacturing is the reflow temperature. Usually reflow temperature in manufacturing is dictated by the metal composition in solder paste used. During design, the designers might be unaware about the temperatures and duration for which the parts on the board will be exposed to. Every semiconductor part has a recommended reflow temperature and duration beyond which part performance would be affected. As a part of the previous project for a semiconductor firm, we performed studies correlating device performance of high precision clocks by the effect which multiple reflow cycles has on the design. This is where right integration of manufacturing and design comes into play since each team is generally not aware or concerned about the parameter consideration by other team and might cause negative impact on product performance.

Solder Paste Selection

Few critical designs like power or high speed would even call for careful consideration of Solder paste or flux to be used. Water soluble flux are generally preferable for high speed designs and needs to be properly cleaned off after manufacturing else could cause issues with PLL locking specially for high precision clocks. Whereas no clean flux would be preferred for other designs as they leave less residue and reduces cleaning step needed during assembly.

Conclusion and Resources

I had fun learning and correlating these seemingly small and numerous variables then correlating them with issues observed or forecasted. As a engineer or project managers managing variables is all we do and understanding variables and constraints from different domains would make the final product better.

To highlight some gorgeous resources, huge shout-out to below resources detailing fabrication and assembly steps and processes in detail.

Interested in learning more about the PCB Fabrication process? I came across this awesome detailed video

How about common assembly issues?

Also the below blog is rich with manufacturing resources

https://www.4pcb.com/blog/

I hope this article was as interesting for you as it was for me learning these parameters.

Until next time. Signing off.

This article is continuation of the product development journey series. While Part 1 deals with the concept design and decisions, Part 2 dives into schematic design. This part will dive into 3D modelling of enclosure using Fusion 360. Along with design and some learnings along the way, one major learning was using Fusion API to dynamically create the model using programming. This can be used to repeatedly create similar structures or repeat a part of the process.

Tool

For CAD modelling, I used Fusion 360. While there are few too many tools out there from Solidworks, OnShape, Fusion 360 along with some open source tools like FreeCAD and OpenScad. I explored FreeCAD first and found it to be lacking in features and had a non intuitive UI. Onshape though had a good offering was lacking a private project trial feature. Finally, I found Fusion360 to be a viable option with good features, 10 private projects to try things out and intuitive UI.

Thanks for reading Rishabh’s Substack! Subscribe for free to receive new posts and support my work.

Trying things out and learnings early on

Trying 3D CAD for the first time, the journey had quite a lot to teach me. Like every skill, the journey started with couple of youtube videos and examples out. I was equally focused on processes and design for this project. After mockups and failures, the two most important lessons learnt were

1. Make design parametric.
2. Select constraints and dependent dimensions carefully

The biggest decision in your project is going to be the initial sketch, what might need to be changed in future and what dimension or constraint will depend what. After few rough concept designs and dirty mockups, we need to define the parameters. Parameters are variables that can change in future and the design updates automatically (only if constraints are well defined)

After defining the parameters, we start the sketch. But before that, we need to decide on reference planes. This depends a lot on the direction of features that you want. Generally your sketch would have multiple sketches on various faces. For e.g. my simple base sketch look like this.

And even though it seems like all dimensions are hard coded, they are variables coming from well calculated parameters.

The outer border over here (3mm) is the side wall projection.

After the sketch, we extrude various features to create base and walls.

Then taking left wall as reference, create and extrude slots and snap.

And then similarly comes top plate, snaps, magnet insertions, PCB base, threads, USB C. Also, pattern repeat parametrically.

Finally, we get something like …….

First Prototype printing

Here comes most interesting part for an engineer in any project “Does it work?”. With a friend’s Bamboo X1 Carbon, I went for my first 3D print. Using Bamboo Slicer, I played around with various support structures and parameters to fine tune how I want the 3D print to come out. The model being multifilament, gave me freedom to actually print the item in multicolor.

Lessons from first print

Well, that turned out slightly worse than fine. There were few mistakes clearly visible, like warping around the magnet cut, snap being too small and thin and magnet not fitting the slots.

Major lessons learnt from the first print

1. Remember to consider nozzle diameter while designing, any feature less than twice the nozzle width in horizontal direction is going to be omitted. Better, make this as parameter and use it in design because your 3D printer might change and during design you might not be aware of the printer you’ll get to manufacture this on.
2. CAD is infinitely zoomable but real world is not. Things seems big or small based on zoom level in CAD. Though the snap and details looked fine in CAD, they were too small to be printed.
3. Remember and account for tolerances. Specially if you’re designing for snap fits which is super neat but needs experimentation.
4. Warpage and overhangs do affect the quality
5. Some post processing might be needed before using this as final enclosure for surface finish

After going back to design board and fixing these, comes the next version which turned out a LOT better than first being very close to how I want my final box to look and feel. I also included chamfers, round cuts in the design for it to feel much better.

And Repeat (Thanks API)

Now that I have the base ready, I had three conundrums.

1. I need to repeat this base for every module which I make which is boring and repetitive
2. The design is not finalized, so anything even if it’s small, if it changes in early sketches will affect the complete design and might break stuff
3. Any change which I make to one model will have to be repeated for all modules consistently

And the solution? Fusion 360 API to create the design programmatically.

Now, even though the API is well documented, it’s a bit counter intuitive to get used to. Also, it’s penetration is not too high in community since the mechanical engineer or CAD engineer primary using the tool are not very active programmers and CAD design is a very visual process. Because of less penetration, the number of tutorials or user developed material on the topic is a bit less. Luckily, I’m decently good at Python and programming and thankfully, it’s 2024 so we have ChatGPT for help.

I broke down the model into steps

1. Create user parameters
2. Create Base sketch
3. Extrude base and walls, PCB holder
4. Create left wall sketch (with slots, snaps and magnet cuts)
5. Create front wall sketch (with slots and magnet cuts)
6. Cut necessary sections from sketch to create openings and slots
7. Create PCB holder sketch
8. Create chamfers and round cuts
9. Create patterns for repeating the cuts multiple times
10. Create reference planes and mirror the sections
11. Create top plate
12. Create snap cuts on top plate

All of these could be done programmatically, although slow, this makes the process much more systematic. The few benefits this offers are

1. Any change you want to make in the design, using programming can be used to generate all models within minutes rather than repeating the complete process from start
2. The code can be version controlled making debugging considerably simpler and easy to fix

Downsides of API Approach

Yes, I found API approach a lot interesting but there are couples of downsides to the approach.

First, the approach is not suitable for all processes, in fact this is only useful if you want designs to be repeatable. Some examples could be PCB enclosures, motor cores etc. Having said that, this the approach is also useful if you want to automate partial processes which are repeated in a single design. Something like adding holes of particular dimension at various places or clubbing couple of processes which always follow one another in single click.

Second, it’s difficult to select an object or see selections since rarely are those named and it’s difficult to see visually what is getting selected. Generally selections like faces, profiles, planes, extrudes are indexed i.e. they have a number in the array instead of named i.e. having unique name. This makes the selection a little tricky and finding the index is a bit troublesome. Some features can be named and selections can be made using name but others, you have to try indexes till one fit. Thankfully this is generally repeatable and just depends of sequence of operation. The easiest solution is to have some of the selections manual i.e. prompt user to select the profile which they want to cut or face where they want sketch to be made.

Using hybrid approach works best for the design where you automate only repetitive processes but keep selections and unique designs still manual.

Getting started with the approach

Where do we even find the option?

Next, how do I get started.

I referred the following resources

1. Youtube playlist by Learn Everything About Design
2. Documentation by Autodesk
3. ChatGPT (GPT4 over 3.5 is HIGHLY preferred)

Using it in my design

Since for me the steps were very clear. I started writing, playing around with the scripts. Though the design is still only 30% done, the approach is quite clear.

There is individual script for each of the step listed above and you approach them one after other. First create the user parameters, then base sketch, walls, left wall sketch, front wall sketch, patterns and so on.

What’s next

Till now, we have explored parts of the concept, system design, schematic design and 3D modelling. The untouched topics till now are PCB design, firmware design, manufacturing parts of which I plan on getting to next. Then I’ll reiterate few of the already covered topics for revisions and modifications made.

In next article, I’ll probably be covering my journey of PCB designing for this project.

Thanks for reading Rishabh’s Substack! Subscribe for free to receive new posts and support my work.

Continuation of Part 1 of the series to design and build an end to end product. This week I’ll be diving into designing the schematic for the system. This will include part selection, various microcontrollers families, Kicad process and few tricks learnt along the way. The schematic can be found below.

Tiledflexikeys Draft 12.76MB ∙ PDF fileDownloadDownload

Defining the system

To begin with, I decided to break down the system into six modules. Each module with it’s own set of control and user can decide which modules does he need in his workflow. Further, we can add more modules as the project progresses.

Thanks for reading Rishabh’s Substack! Subscribe for free to receive new posts and support my work.

There modules would be

1. Base Module
2. Rotor x1 Module
3. Slider x2 Module
4. Knobs x3 Module
5. Keys x12 Module
6. Joystick x1 Module

The modules would look something like this but in an enclosure.

Base Module

The primary responsibility of base module would be PC communication, power, profile selection and communication with child unit. Based on these requirement, the design could further be broken down into blocks, major ones being USB, Power and Battery, Screen, Rotary Switch, Child Communication Interface. Alongside this, debug and programming interface for the microcontroller, block isolation and test points for debug and expandability were also considered in design process.

Microcontroller

Choosing the microcontroller was the first part of the project. As one of the aspect of this project was to familiarize myself with different development environments and processes, I chose different MCU for each module. For this module though, I decided to choose something I’m more familiar with and which is powerful enough for future expansion.

I decided to go with ESP32-S3 Wroom module. This module along with having enough processing power to run micropython also has WiFi and BLE for wireless communication. Plus it has enough memory to have different user profiles loaded into the same along side firmware. Another handy feature is support for USB and other peripherals like GPIO, ADC, I2C, UART, SPI, QSPI plus tons of resources online to get started with.

For minimal schematic, it’s best to look at the schematic of dev kit along with datasheet to understand the logic behind the design. References to design and schematic can be found here. One major change I made though was add USB C instead of microusb.

USB C

USB C, the boon and curse of electronic connectors. The boon part is the connector and protocols have tons of consideration put into them to support high data rates, power negotiations which also being backward compatible with older or slower and less power consuming applications. The curse rises out of exactly the same consideration, being so feature rich, the connector cost, cable cost become high and manufacturers came up with 10 different variations of connectors with different capabilities not to mention 10 different cable types not everything supports every feature. And there is less uniformity on these connectors to make them replaceable if they go out of stick since footprint are not one to one compatible before analysing them in detail.

For my application, I didn’t need high bandwidth or power delivery. 5-10W of default power would be more than enough for the application and since the need for USB is only USB 2.0, I can get rid of most of the differential pins for USB 3.0 and above.

I decided to select the connector GSB1C411111DS1HR. This had just enough pins to support my application further reducing soldering complexity as well. Another consideration would be to have footprint compatible part from lcsc which would give a good cost advantage. The problem though was scrubbing through datasheet written in language I don’t understand. I was able to select something though.

Connections to USB C includes,

1. 5.1K pull down resistor on CC1 and CC2 pin which instructs the power network that it needs to drain 5V power. VBUS
2. ESD protection diode of communication and power pins
3. Reverse Power protection diode on VBUS.

Power and Battery Management

Power design for the system includes taking power from USB when available, scaling it down 4.2V to charge the Li Ion battery. Then either taking power from USB or Li Ion and converting it to 3.3V using buck convertor to supply to microcontrollers also scaling it up to 5V using boost converter for some peripherals like addressable RGB Led.

The major IC’s selected were

1. MCP73831-2-OT for battery charging
2. MIC2288YD5-TR for boost converter
3. TLV62568DBV for buck converter

The power design calculations are not completed yet but I found a awesome video by Phil’s lab explaining the sizing of components.

Rotary Switch

I wanted an interface which could act as continuous scrolling through profiles and also click to select a particular profile. Rotary encoder fits the application. I seldcted PEC12R-4125F-S0012 for the application. One thing to consider when using these is the shaft size does need to fit your mechanical design constraints as well to come out of enclosure, so you might have to come back to this part after the mechanical design is under way.

Screen

Finding a colored screen for the application around 1 inch was a challenge. Although there are multiple options available, most of them are either costly or had constraints on features I wanted like color and size. Finally, I decided to choose this screen from aliexpress. Although risky, one reason for the same was to explore aliexpress as sourcing channel for certain components. Also, since the interface is I2C, I could replace it with a known screen if I wanted at a later stage as it is not necessarily tied to PCB footprint.

Child Communication Interface

The module would communicate with child module using I2C along with a interrupt line. Each module would have a pogo interface on two sides and landing pads on other two sides. These modules would snap together using magnets and link to each other for communication. The interrupt would be issued by the child module on user action which would then result in base module polling the modules for event and transmitting it to PC.

Other Parts

One consideration in the design was to add 0 ohm resistor and test point between each major block for isolating them and testing them. USB to UART was also added using CP2102N-A02-GQFN28 for debugging if needed. Top touch down pads were added to the product to streamline programming and testing in production environment.

Rotor x1 Module

The next module and the simplest one is Rotor x1 Module which as the name suggest contains one rotary switch. This module can be linked to any application where continuous scrolling is needed. e.g. of such would be continuous zoom in/out, scroll etc.

For this module, the microcontroller chosen was PIC18LF4331-IML. Although the microcontroller is way more powerful and feature rich then it needs to be, it does have rotary encoder reader as peripheral which I wanted to look into. Also, this would give me option to look into PIC development environment.

Slider x2 Module

This module would contain 2x linear sliders. This could be linked to operations on PC which has upper and lower limit. Something like brightness, volume, transparency or MIDI controls etc.

As for the linear slider, I selected a linear potentiometer PTA4543-2015DPB103. Interfacing this with microcontroller would be a simple ADC reads.

For the microcontroller, I selected CH32V003JxMx controller. Although completely new for me, the controller is the most cost effective solution available in market costing just 20 cents while being programmable and based on RISC V plus having most necessary peripherals.

Knobs x3 Module

Knobs module is similar to linear slider in application but provides rotational interface instead of sliding it. The application could be something like setting RGB in photoshop using physical knobs.

For this module, I chose STM32F103C8T6 MCU. Again, the controller itself is overkill for application but would give me more exposure into STM32 controllers. Another reason for the same is it has a bluepill development board readily available to test firmware even before receiving boards.

Keys x12 Module

This module would have 12 mechanical keys which could be mapped to any keyboard shortcut based on the workflow, something as simple as copy using single key or tool change while using CAD or compile and deploy code with single button.

For this, I chose RP2040 microcontroller just for exploration and since the microcontroller has a package which is not all that simple to solder plus the mcu needs few external components more than other counterparts.

Joystick x1 Module

Joystick or Thumbstick module could be used where we need more degree of freedom like spacemouse for rotating 3D models or scrolling 2 directions at once.

The joystick selected was THB001P. Similar to other modules, one thing to consider would be mechanical constraints to expose out of enclosure.

The microcontroller selected for this is ATtiny841-SS. Having just enough pins and features while being cost controlled.

Schematics Tips

For designing schematic, here are some tips and good practices learnt along the way.

1. Use Hierarchical sheets, start with defining blocks, with systematic purpose and I/O for each module. This doesn’t just makes schematic easy to read but also gives a top level view into planning tests, isolations, mapping for signals.
2. Use SnapEDA or online libraries for symbol, footprint and 3D model. These modules would need cleaning up for part numbers and BoM generation. Also, you might want to edit local symbol for easier flow of signals.
3. Use version control using git. Store all needed resources like additional symbols, models in the same directory.
4. Leave notes and design calculations in schematic. This makes schematic one source of truth for most needed items.

What’s Next?

Next week, I plan to dig into mechanical enclosure design aspect of the project. This would first explore the mechanical design in Fusion 360 and 3D printing it. Also, tips and tricks for parametric designs. And then also diving into automating design generation in Fusion 360 using Python which was super fun and exciting to play with to automate multiple of such enclosures.

Thanks for reading Rishabh’s Substack! Subscribe for free to receive new posts and support my work.

Part one of journey to build a modular macropad. This week include initial design concept, some design decisions and peek into various toolchain selection and experiences.

The Inspiration

For last couple of months, I’ve been meaning to start a product development exercise where I start from scratch and develop a design process and workflows for all aspects on product development. The workflow and process needs to encompass all the stages right from concept design to manufacturing and deployment. Further, it needs to encompass all horizontals for the product development as well, including electronics, firmware, mechanical and software along with operations.

Thanks for reading Rishabh’s Substack! Subscribe for free to receive new posts and support my work.

Looking for the project to start, I had different ideas and finally decided to make a macropad as first project in this series. I had started this project a while back and then parked it due to constraint on time. I decided to restart the project from scratch after coming across an amazing project by Salim Benbouziyane - ocreeb-mk2. There are multiple awesome commercially available products available with same concept as well like modue but the idea was to build something from scratch going through all the hoops and loops of the development process. Another idea was to explore various and get exposure to a variety of tools instead of sticking with just something I’m already familiar with.

The Product

The concept of macropad is having a custom input device for your computer which assists your workflow while working with various software tools. Visualize working on microsoft word and being able to switch to regularly used text type like heading, bold, highlight with a single button without having to navigate the toolbar and then selecting button individually; or working on photoshop and having physical knobs on your desk to adjust RGB individually; or working on CAD software and using various keys to change the tools.

Something like link

System Requirements

Another process I wanted to fix with this project was documentation. I decided to use Notion for maintaining the notebook. Loved the interface, if I ever move to my own server, I might use outline. Proceeding to defining system level requirements and introducing constraints on designs.

Again, taking inspiration from ocreeb-mk2 for many of these requirements and then adding few additional requirements and changing some, spanning across domains, let me list them down.

1. Grid and modular inputs - I wanted the product to be modular in grid pattern where user can add or remove module as per his product requirement. The module needs to snap to neighboring modules using magnets and communicate with pogo interface on the side.
2. Mappable Inputs - The inputs needs to be mappable to various software either in foreground or background.
3. PC Interface - PC interface needs to be both USB C and Bluetooth.
4. Modules - Various inputs including keys, knobs, rotors, sliders, joystick and being able to have future expandability.

Taking these into consideration, I went into detail designs. Before moving to detail design, let’s take a list of software tool I’ll be using first.

Tools

Electronics CAD

For Electronics CAD, exploring the options there were multiple aspects to choose from. Should I go with professional tools like Altium, Allegro? How about open source tool like KiCad? How about upcoming cloud based tools like Flux.io? Taking them into account, Altium and Allegro were too costly for a simple project like this. I did like Flux.io and started designing there first, but soon I realized that the tool was buggy since they’re in beta at the moment and continuously evolving. Although I agree with the design specially for maker projects like these, but not wanting to deal with bugs at the moment, I finally decided to move to KiCad.

KiCad, had most of the features needed for my development including hierarchical sheets, BoM generation, PCB design, 3D CAD export. Plus being open source, there are tons of resources, plugins and symbol library to use for almost any part.

Talking about plugins and libraries, some of the plugins I found super useful are Kikit, Interactive PCB BoM and some plugins for arrangement of items on PCB and Schematic editor. Most of the symbol, footprint and 3D model library can be found at snapeda.

For version control, currently I’m just using github. There are tools for visual diff like kiri which I’d like to explore. Another tool to explore would be cadlab.io for cloud based visual diffs.

Mechanical CAD

For mechanical CAD, the 3 options to consider were onshape, Fusion 360 and freecad. I found Fusion 360 very user friendly to use. FreeCAD had a resistance and UI was to enter into the same and Onshape’s opening up the design in free version didn’t appeal to me since I wanted to experiment with lot of stuff.

After designing a version of enclosure, I realized that I’ll have the repeat the template for all modules and I found that Fusion 360 has API worth exploring. I’ll get into details of the API with pros and cons in another article.

Firmware

A design decision I took for the project was to select a controller for separate family for each module. The reason behind this was that one of the idea in the project is to explore various tools and environments so why not take the opportunity to get acquainted to different IDEs and microcontrollers and see how far I can go with each.

Some of the families I selected were, ESP32-S3, STM32F103, PIC18L433, ATtiny841, RP2040, CH32V003. This would give me exposure to various IDEs although at the trade off of project timeline.

It’s not finalized which toolchain and IDEs I’m going to be using at the moment and I’ll update the topic once I enter into that part of the project.

Software

I’m yet to decide of the software stack I’m going to be using at the moment. Personally I’m comfortable with Python and Javascript platforms but for this I’d like to use Flutter as front end and Python for parts of integration. This might change completely as at this moment I’ve not started working on software.

Some inspiration for the software can be found from software of modue. Although I’ll start with tools integration which are niche and relevant to me like KiCad, Fusion 360, VS Code, IDE etc.

Documentation

For documentation, I decided to go with notion and then move to outline in future if I decide to self host a similar app. For now, notion works great with hierarchical structure, clean design, embeds and couple of additional tools I love. I’ve started noting requirements, design calculations, links and resources in notion. Another thing to track would be timespent to get better estimates for such project in future. Plus this series of articles will act as go to guide for future. I’m looking for specialized tool to create QC checklists and manufacturing pipeline when I move to that part of project.

What’s Next?

In the next part, I plan to explore the schematic for the complete design. At the moment, since I’m starting this article series when I’ve already completed 30% of the project, I’ve enough content for 2 more parts which I need to catch up to which I’ll release each weekend for next 2 weeks. After that, the plan is to have article biweekly to update on the progress.

Thanks for reading Rishabh’s Substack! Subscribe for free to receive new posts and support my work.

So, you’re at your friend’s house and your phone battery is low, you start looking for a charger. There is a good news and there is a bad news.

Good news is for connectors, unlike 2008 when you had this mess and further

Now you only have

Bad news is, although you can probably charge your phone, it might not be fast charging because you still have to deal with various charging protocols, voltage levels, current levels, input supply and what not. But what the hell do these terms even mean? Let’s have an analogy and understand it better.

Broadly speaking, when you look at any phone charger specifications, there will be 6 most common parameters user will be looking at

1. Input Supply
2. Input Connector
3. Charging Protocol
4. Possible Output Voltages
5. Possible Output Currents
6. Output Connector

For the analogy, we would be taking the phone as a buyer who is looking to buy some charge and the charger would be the manufacturer and seller for the charge. Although, buyer won’t be paying anything (apart from good will).

For your charger to make the product being sold, it needs some raw material. This raw material comes as input supply through input connector. Mostly, the input supply is going to be AC supply coming through the wall socket. Good news is, charger manufacturers make the input supply widely compatible so that they work in most of the countries, accepting voltage range of 100-240V at 50-60Hz frequency and < 0.5A of current which is compatible with most of the electrical outlets. Bad news is, the electrical connector for many countries are different and that’s why we have various chargers which needs to fit into this mess.

Anyway, now the charger needs raw material aka input power from one of the various supplies aka input connector. Phone i.e. the buyer comes along and asks for charge of a particular type. Of course, before even beginning the transaction, both of them needs to have an active communication medium which is taken care by the output connector and charging cable which should fit the phone before even starting the communication. The end connector would be hopefully one of the three standard types persisting today i.e. USB C, Lightning or MicroUSB. Next, the language that buyer speaks for asking for the charge is the charging protocol and there are various charging protocols in the world, each company adopting a proprietary or an open one. Some of the common protocols are USB Power Delivery, Quick Charge 1, 2 and 3 by Qualcomm, Warp Charging by OnePlus and others. Now, the seller also needs to speak the same language otherwise it won’t understand what does the buyer wants. Some buyers and sellers are multilingual and can understand couple of different protocols. And some of the languages are similar to one another so if the buyer speaks that, seller can sort of understand it even if not completely.

Now the buyer comes along and wants the best thing, so it starts asking the seller, can you provide X output voltage and A output current. If yes, then please do otherwise can you provide Y voltage and B current and so on. The higher the product of voltage and current aka power, the faster the phone will charge. i.e. if X * A > Y * B, X * A is better. There are various standard voltage and current levels possible defined by protocol but even if nothing works or the buyer and seller don’t speak the same language, there is a fixed 5V output voltage standard so that the phones could atleast charge slowly if nothing else.

There you have it, various charging terminologies and their analogies. To recap,

1. Input Supply i.e. raw material
2. Input Connector i.e. supplier
3. Output Connector i.e. communication medium
4. Communication Protocol i.e. language that the phone and charger speak
5. Output Power i.e. the product which buyer can use compromising of voltage and current

Now, let see if you can figure out those parameters on the charger labels at your house.

Hope the analogy makes sense. Until next time, Adios.

Recently, I was travelling from US to India. Stuck in a 22 hour long flight with no internet surely makes you think; think what all did it take to design the simple controller for in flight entertainment in front of me. Thinking about all the aspects of engineering that went into this designing and manufacturing this product, I started to list them down. To make it more graphic and understandable, I ordered a similar product to break it down and actually reverse engineer it. Let’s take a look.

Let’s look at the exploded view of the remote. Each field marked up in yellow is a niche engineering field in itself with a team of engineers working specifically on that. Along with the technical aspects, there are a ton of resources that goes into defining the product requirements, doing a business analysis, figuring out the logistics and shipments, packaging, supply chain, costs, finances of the product. All, so that you can buy this piece in less than $15 shipped which in itself is a marvel.

Opening the product out it majorly consists of

1. Mechanical Enclosure
2. Buttons
3. Circuit Board (Printed Circuit Board aka PCB)
4. Battery

To be fair, I’m no expert in most of these fields. I just am aware of them, I can probably only do justice to aspects of circuit board development and mention the other fields to the best of my knowledge. I’ll get to circuit board at the end after touching up on other aspects of the product.

Mechanical Enclosure

Starting with the mechanical enclosure, a group of engineers first did material engineering to select most cost effective, durable, easy to work with material to be used in the project. Another group of engineers did 3D modelling on how the remote should look and feel like keeping in mind the ergonomics of handling it, weight, space to actually accommodate the circuit board. Then another group of engineers worked on how this thing would be actually manufactured in the most cost effective way depending on the volume i.e. injection molding, designing tools, molds and manufacturing line for the same. That just cover a part of engineering that went into designing the enclosure which I’m aware about.

Rubber Keypad

When it comes to the rubber keyboard, I have almost no knowledge there. But for appreciation of the field, I found this article webpage just glancing at which is enough to appreciate the number of variables in even something this simple looking. https://www.rubber-keypad.com/Silicone-Keypad-Design-Guide.html

Battery

Battery, a lot of chemical engineering and material science went into finding and designing the group of material which can store, charge and discharge energy safely into the circuit.

Circuit Board

Now to the field which I can actually do a bit of justice to, circuit board designing.

It starts with architecting and selecting the proper set of components. Each component specially chips or IC designing takes multiple years and revision and investment to even get the simplest thing out. I’m not remotely capable of making you understand the intricate details of the process in an article, but take a look at the couple of videos in the last section to understand the process.

Next, various sections of circuits are designed. Each circuit needs specialists working in a particular field. In this board, there are 5 particular sections.

1. Power Management - Designing and converting the power received from battery so that it can be used by rest of the circuit. Also calculating battery life, charging circuits to safely operate the devices.
2. Sensor Design - Selecting the sensor based on what kind of inputs are to be detected. In this case, accelerometer to find if the remote has been moved in air to change the position of mouse on the screen
3. Microcontroller - AKA brain of the system which looks at which button has been pressed, reads the sensor to see what action has been performed. Then translates the button to something that can be understood by computer and sends it to the Bluetooth module. Microcontroller also takes care of LEDs to be lit up, signals to be sent via infrared to the TV and all of this is written in software (firmware) and programmed into the controller.
4. Wireless Communication and antenna design - Deciding the communication language which will be understood by both computer and the remote, encoding signals in invisible microwaves operating at particular frequency band, decoding the waves to find what signals were transmitted and what do they even mean. Designing antenna which can help transmit and receive these signals in such a fashion that they do not interfere with other electronics in the vicinity.
5. Electronic CAD Design - Taking the inputs from various blocks and integrating it into drawings using software which can be understood by other engineers and manufactured. The team outputs various files needed by different teams who will work on procuring the material, manufacturing the circuit board, testing it, engineers who’ll need to understand it to solve problems in future.

Post design and development comes manufacturing which is a BEAST. Finely tuned machines and humans working in unison to create a product intricate and sophisticated all for a couple of bucks.

Right from wires, enclosure, batteries, fasteners, Semiconductors and circuit boards. Each thing takes number of processes and steps to be manufactured. I’ll list down some of the videos for the field.

Manufacturing

Circuit Boards

Semiconductors

Injection Molding

Wires

Batteries

Hope this makes you appreciate the amount of effort that goes into a designing a simple product. Again, this article is only the tip of iceberg for the actual effort spent if you see these product from scratch. I didn’t even touch on various aspects like passives, fasteners, adhesives etc. which plays very important role in making the device work as well.

The exercise of reverse engineering and studying the remote raise more questions, learnings and appreciation for me which I hope to cover in future article. If someone is interested in finding answers to some of these questions and collaborating for a future article, ping me on LinkedIn. Curious about another object? Let me know and I’ll consider it for a future article.

Until next time, look around and stay curious.

Thanks for reading Rishabh’s Substack! Subscribe for free to receive new posts and support my work.

Last Sunday evening, I decided to take a break from screens around me and delve back into physical book reading. On hitting my small bookshelf, I selected revisiting "Wings of Fire" by APJ Abdul Kalam as the read for the evening.

Midway through the book, there was a text regarding development of an intermediate range missile and intercontinental missile whose range was described as 2780km. Now personally, numbers only make sense to me when they’re put in context of things that I can visualize. So, I decided to deduce what would 2780km look like, to make it interesting, do it without using internet or calculator. Visualizing scale of city (50km) is simple, but anything above which I tried to visualize, I couldn’t put a number to the scale. Another thing which I could visualize was the map of Earth, so I decided to take that as a scale and derive the rest, maybe as a scale of north to south length of India.

Now, I didn’t knew the numbers corresponding to size of country but I did remember from high school physics, thanks to the chapter on gravitation that the radius of Earth is around 6500km. Okay, so circumference would be 2*pi*r, North to South pole distance would be half of it and North Pole to Equator would reduce that by half further. So, pi*r/2 or 1.5 times 6500km → around 10000km. This bifurcated into 2 thoughts, one India is around less than 1/3rdish the length from Pole to Equator so around 3300km which was so surprisingly close to the actual answer (3214km) that it blew my mind. Second thought, this number came surprisingly close to round number, which on giving some thought reminded me from a documentary on measurement systems that this was no coincident; traditionally, the meter was defined as 1/10,000,000 of distance from North Pole to Equator. Which now made absolute sense of the closeness of these figures. Also, helped me put the range of the missile in perspective.

Expanding from the incident, made me revitalize the importance of visualizing numbers and scales of measurements, which are so different across domains. We can’t exaggerate the role this skill play, specially in the toolbox of an Engineer and Scientist.

There are so many vivid parameters one could measure or deduce. Few of these parameters like distance, time, speed are more vivid for a common person whereas others like voltage, wavelength are more abstract. Each parameter is important to a certain group of professionals or other. A Mechanical Engineer might be interested to know, calculate, measure, design parameters such as lengths, area, forces, volume, speed or weights. Electronics Engineer could be interested in voltage, current, capacitance, resistance, frequency or time. Physicist might be playing around with wavelengths, size, forces, energy and so on. Whereas accountants would be interested in monetary values, growth rate and such.

Even for a single parameter, the scales could be so so wide in sizes. A single number could be big or small depending on the frame of reference being considered. If we just take distance as parameter to be measured, a parameter so common and physical that anyone can relate to it.

1. A Mechanical Engineer designing enclosure of a everyday product, could be visualizing things in centimeters (or foot).
2. A Civil Engineer designing highways would be visualizing it in kilometers
3. An Astrophysicist would be measuring distance in lightyears
4. A particle physicist would be measuring atoms in nanometers and measuring diameter of proton in femtometers

If you can’t visualize these figures and scales, don’t worry. They’re really really hard to visualize. But let me give you some references to appreciate the scales of these. Note, these measurements are highly approximate and are only meant to visualize scale.

1. Well, we have to start somewhere, so let’s consider your arm length. A single arm length from center of your body to finger tip would be somewhere around 0.75 to 1 meter.
2. A pea, is of range 1cm. That means, if you close your eyes and lay 75 to 100 peas next to each other, it would span your arm length.
3. A tip of ball point pen is approximately 1mm. That is, you could have 10 such pen points across a pea
4. A soccer field may have a length of range 100 meters i.e. 50 individuals can lie next to each other fingertip to fingertip with arms stretched on a soccer field. (Yes, I do realize that’s not a standard American unit of measurement which would be American Football field)
5. And 10 such fields, length to length would give you 1km
6. Number of ballpoint pen tips which you could lay next to each other in 10 football fields (One million or 1,000, 000 or 10^6) is of the same magnitude as number of atoms next to each other in a ball point tip
7. And if atom was of size of a football field, nucleus would be of size of a pea kept on center point.

We can also go in the similar fashion to the other direction and so big. But, here is a better way to visualize the same. I recommend watching the video at half the speed to contemplate the size.

So, I leave you with this thought. Take your field, take any measurement you work with on a daily basis and try to extrapolate it to other fields. Whether you’re estimating computational resources needed for your application or amount, or force needed to move a car or how many iPhones can you simultaneously charge from your simple house plug in parallel. If the activity doesn’t apply to your profession, you can do the same with your income and spending. For e.g. Warren Buffet is so rich that him spending 700, 000 USD is equivalent to an average American buying a can of sprite. Frame your thoughts in these kind of analogies and I’d love to hear what you can come up with.

Till next time, happy thinking!

Look around! Unless you’re reading a printed version of this article in solitude on a mountain or beach, chances are you’re surrounded by products. Whether it’s hardware products like Microwave, Mobile Phones, Smart Watches, or Software Products like Medium App or Chrome where you’re reading this article, a lot of effort is put into making these products. Let’s explore the cycle that begins with gathering requirements and culminates in deployment and continuous support, revealing what it takes to make these products available to users. Note: Engineering is an iterative process, and chances are each step or sub step discussed below will go through multiple iterations, finding, fixing, optimizing product making it hopefully better throughout the journey.

Requirement Gathering

One of the most crucial steps in any product development is identifying the correct sets of requirements. Requirements dictate what the end product will look like. Each requirement costs time, effort, and complexity, hence keeping requirements simple is an essential part of requirement gathering, but missing requirements would result in product usage being compromised. Hence, it is a delicate balance of making sure just the right amount of requirements are being managed. Adding requirements at the later part of the project though possible will result in further complications like changing the architecture and additional development time.

The requirements will come from multiple sources. Three main factors contributing to requirements are Product Reach, Industry Standards and Business requirements.

Product Reach

Product reach simply means the number and persona diversity of the end user who are going to use the product. The broader the reach, the thorough the requirements needs to be. If every user of the product is a competitive engineer, the likelihood of mistakes is lower compared to a diverse user base with varied technical skills, age groups, and ethnicities. In case where the personas and number of users are smaller, requirements can focus more on solving the problem whereas, if the diversity and number of users are broader, focus needs to be shifted on User Experience, inclusivity and intuitiveness of the product.

Based on reach, product being developed can roughly be bifurcated into 3 categories.

1. Consumer Product — This is the most challenging category since it contains the highest range of reach. Requirements needs to be collected by analyzing the market gap between the current offerings and user needs, identifying the problem to be solved and then making it accessible to end user. It is difficult to directly talk to end user, although you might be able to talk to a very small subset to capture the requirements and feedback. Indirect form of user engagement might be used like extracting data from online forums and comment.
2. Business Product — In case of business products, it is comparatively easier to gather requirements as the diversity of users are significantly small. Also, the end user is generally directly accessible which makes communication barrier far smaller. For business products, it’s essential to discern whether the user’s mentioned requirement is a genuine use case or merely a ‘nice-to-have'.
3. Sub System Product — Sub System Products are the ones which are not directly used by end user but are part of another bigger system. e.g. compressor which goes into a refrigerator. The end user for this is practically just the design team who are going to use this in their refrigerator. For this category, the focus is purely on technical specifications and meeting the requirements rather than ease of use.

Industry Requirements

Industry requirements are set by criticality factor of the end application and also the environment in which the system will be used and also the variations in them. These requirements are much more technical. They can originate from compliance and certifications needs such as if the end product is related to Aerospace, it needs to meet FAA compliance and testing. If it is a medical product, the guidelines will be set by another body. Whereas if it is a consumer product utilizing USB, USB communication compliance must be met to ensure it works with any set of certified hardware.

Some requirements also originate from variation in usage environment. A flight engine needs to work whether it’s -40 C or 80 C outside. It also needs to work at different pressure levels. Also, it needs to recover even if lightning strike hits it.

Regardless of the source, all requirements must be captured, prioritized, and assigned a budgetary value. Priority of requirement could decided based on whether the feature is “Must Have”, “Good to Have” to “Not Required”. Assigning budgetary cost to features might be difficult at this stage since it’d depend on product design and architecture, thus it could be assigned a temporary guesstimate which keeps getting revised.

It’s a good practice to make a requirement traceability matrix for all the requirements. This tracks the requirement throughout the development process as to which module encapsulate the requirement finally to be tested making the probability of missing the requirement lower.

Business Requirements

Business requirements consists of costing model, customer support, product logistics, product distribution, development budget, branding, marketing. Business requirements are essential marking the success of the product.

They also ensure de-risking supply chain, taxes structure, upfront investment and recollection.

Consumer product can generally be made cheaper if the number of users are large so that economy of masses comes into play.

System Architecture

Hardware Products have multiple aspects to them. Product designs encompass Electronic Design, Mechanical Design, Firmware, and Software, each of which can be further subdivided. At this stage, decisions are taken on the major blocks and systems which will be used in each area. This will depend on multiple factor like team’s past experience in the sector, cost, availability, modularity constraints etc. There could be several ways of realizing each requirement. It’s a good idea to test multiple of these quickly at this stage to find best suitable alternative. Development Kits, Clay Models, Open Source Examples should be used to get the feel of the final product.

The output of this stage should be blocks diagrams for Electronics/Software/Mechanical designs also ensuring they are cross compatible between domains. Make sure to check if all the requirements from Requirement Traceability is captured.

Module Designs

This stage is realization of each blocks captured in the block diagram. Each domain will have different steps and flows. Major ones of these are captured below. Note: Even though the domains are noted seperately, the design process of successful products are highly integrated. Each team ensures their constraints are communicated to other designs. Not just design teams, the same apply with logistics, procurement, finance to ensure success of the product. If you design a product and part can not be procured due to cross country regulations, or the product could not be shipped due to size, the process iteration becomes costly.

Electronic Design

The Electronic Design consists of various blocks starting from Power, Sensor, Decision, Actuation, Communication. All of these needs to be realized.

1. Hand Sketch — A rough idea of what each block is going to look like.
2. Design document — explanation of parts and consideration of design. Also contains design calculations if any.
3. Part Selection — Studying various datasheet parameters and alternative to decide on all of the major parts required. Along with technical parameter, de-risking the parts for supply chain, cost, availability is just as important.
4. Prototyping — Quick breadboarding/ barrow boarding new circuits with development kits to ensure and de-risk design before moving to actual manufacturing.
5. Schematic Design — Convert the hand sketch into design on CAD
6. PCB Design — Convert schematic to Printed Circuit Board which can be manufactured
7. 3D Model Design — Add 3D model to PCB Design to move it to Mechanical Design
8. System wiring diagram — How the PCB connects to external world or system

The output of this stage are

1. Electronic Schematic
2. PCB Design File
3. PCB manufacturing files (Gerber and pick and place file)
4. Netlist
5. Bill of material
6. 3D model
7. System wiring diagram
8. Design document

Mechanical Design

Depending on complexity, mechanical system could be static with no moving parts, merely having enclosure or it could have moving parts integrated with electronics. Mechanical system might even consist of moving parts with engine etc.

1. Manufacturing methodology — identifying major parts, which of those needs to be procured, which needs to have custom design
2. Design Calculations — For system with moving parts, various forces, moving systems needs to be designed and calculated. For enclosure, calculations might be smaller being restricted to material stiffness and other similar parameters
3. Custom part CAD — Parts which are custom designed needs to be drafted in CAD. The part can have different manufacturing method, starting from 3D printing, Sheet Metal, CNC, Injection Molding etc. Depending on the requirement, one or more of these could be selected
4. Prototypes — Prototyping mechanical designs are more complicated than Electronics or Software System. High risk items could be manufactured and tested using 3D printing, cardboard folding, clay models to evaluate the feel of physical bodies
5. Assembly Drawing — Assembly model or assembly drawing are system level assembly information for the team which depicts assembly of system either using animations, explode view etc.

The output of this stage would be

1. Design Document
2. Manufacturing Drawing
3. Assembly Drawing
4. Bill of Material

Firmware Development

The system containing one or more microcontroller needs to have firmware developed for them

1. Microcontroller Mapping — After controller selection, resources like I/O, ADC, Timer, Communication module etc. needs to be mapped to functionality and hardware interfaces
2. Modules — Implementation of modular code, which can be individually tested

The output of this stage would be

1. Firmware Source Code
2. Compiled Binaries
3. Design Document

Software Development

Depending on the product, the system might contain a software to interface with the device. These software might be a user interface or app to interact with device, a background service which monitors and analyses data sent by device or an active loop which controls the device based on certain parameter. For IoT devices, the interfaces could be multiple, and each one is a separate activity e.g. Alexa Interface, Web Interface, App etc. communicating with single device

1. Listing User Stories — for user facing software, user story are use cases or feature as seen from the perspective of user
2. Flow Chart — Making the logic flow of individual blocks
3. Implementation — Converting the logic to code which can be executed

The output of this stage would be

1. User Stories
2. Source Code
3. Design Document
4. Deployment Files

Module Verification

Module Verification step consist of validating each stage of design, be it schematic blocks, mechanical parts, software services, firmware blocks etc. Some blocks might be validated using simulations, some using electrical tests while few can not be verified before manufacturing.

Validation is a super important phase of quality product development. Making sure the parts are tested and have complete coverage. In order to test and verify the product, test points needs to be introduced in the design itself. Making a test plan ideally starts from requirement gathering phase, test plans are broken into verification plans, manufacturing plans, integration test plans.

Validation stage also incorporates ensuring you have proper instruments to perform the intended test. Some tests might be very specific needing specialized instruments which are not easily available.

I plan to expand on these activities further explained in future article.

Procurement

All BoM now for the PCB, System Wiring, Mechanical Design needs to be procured from various sources. For scaled operations, procurement team also deals for finding cheapest options for the material, validating quality before bulk purchases, dealing with taxes and clearances and receiving and binning the parts for the project.

Module Manufacturing

All the material is sent for various process whether internal or external shops. These shops include PCB Manufacturing, PCB assembly, CNC shops, Electrical wirings, 3D Printing, Sheet Metal, injection molding etc.

Specialized manufacturing operations would need specialized tools, during design phase, efforts should be put on how the designs would be realized.

For software modules, this stage represents hosting individual modules on various services.

Artifact Testing

Individual module created needs to be tested for manufacturing defects. Artifact testing is smaller subset of validation tests and ensures the product is free from manufacturing defects.

Electrical parts needs to have module testers to ensure manufacturing, BoM quality and make sure they need the decided specifications.

Mechanical manufactured material might be tested for dimensional accuracies, motions and forces.

Software and Firmware Modules are tested for edge cases. Software

Testing ensures product quality which is being delivered.

Assembly

All individual components are now put together as part of system. PCBs are wired together. Firmware is flashed wherever necessary. Enclosures are fixed around the units. Each artifact might be serialized for product tracking.

All Electrical, Mechanical, Software components all come together to work in unison, performing the tasks (or parts of) which were intended for them.

Depending on the product, the system might need calibration phase, or end user customization. E.g. of this could be a same part being sold in multiple configuration, where individual models are activated based on purchases.

Integration Test

Post assembly, each unit needs to pass through integration testing phase, making sure each unit manufactured performs to the standards set for them.

Again, the test design phase starts from requirement phase, not just here. Integration Test Equipment might need to be procured and developed which is a humongous activity in itself. Holding these activities till product design is completed is a horrible idea and will result in delays and cost overruns.

The end product is now inventoried. Entered into database with manufacturing details.

Deployment

Deployment phase consists from packaging, shipment, deployment in field, manual creation, product education.

For a consumer product, they are stored in warehouse. A tutorial or a guide on using the product needs to be created. Forums/FAQ are might be hosted.

For business product or sub system products, they’re generally installed in the end location by design firm or by end customer based on the complexity of installation.

Post deployment, tests might be performed to ensure acceptance of the product.

Support

On field, the products will have failures, users might break something. Support activity monitors the product, repairing them, finding replacements, maintaining the software and firmware. Chances are, there will be multiple versions of your product in field, support team also tracks performance data of each version, passing the information back to different teams working on it earlier for them to improve the process and design decisions for future products.

Conclusion

Hardware product development is highly integrated and complicated flow. The activities consist of unison of personals and teams ranging from Engineers, Finance, Logistics, Procurement, Compliance, Manufacturing. Each team as important as the next to ensure the success of the product. Even after awesome design, challenges might arise in manufacturing, testing or even end user usage which needs to be dealt with with agility.

I’m personally working on a hobby project navigating through each step myself, identifying good practices and learnings through each phase and implementing in newer projects.

I hope this article series will delve deeper into each phase, sharing insights and case studies. I’ve pipelined several articles focusing on Product Testing, Design for Excellence, Requirement Gathering, Embedded Design, 3D Modelling and PCB design in upcoming months. Hopefully, they’d bring education to the niche audience for the article and make their products better and avoiding the reinvention of wheel.

Let’s start this article by answering a simple question. What is the coastline of the United Kingdom? Let’s search for it.

Seems like it’s 12,429km as per CIA Factbook, but as per World Resources Institute, it’s 19,717km. Two reputable institutes and widely different answers, that’s absurd. Did one of them screw up this measurement?

The answer is no. The results persist for all the countries around the world. And it’s not just numbers, even the rankings are different for each country.

As to what’s going on here is known as Coastline Paradox. The short answer to why the two measurements are different is, it depends on what stroke length has been considered while making these measurements. The below example shows a simple example.

If we zoom in further, you can get even longer coastlines. Further, the precision of the measurement instrument is also going to change the readings, in extreme cases, even to the level of atoms. That might be the topic of another article.

Further to this, the coastline is going to be even ever-changing, due to tides, it’s going to be shortened during the high tide and more during low tide, due to increasing sea levels, coastlines will continue shrinking with time. If someone decides to build a shipping port, it’s going to be further affected.

Now that the coastline paradox is understood, the concept can be extrapolated to any kind of analog measurement. Especially in cases where the borders themselves are changing. Here is another example; Where does the atmosphere end and space begin?; What is the diameter of the sun?

Why it matters?

12000km or 20000km, why does it even matter? 12000km or 20000km make a huge difference when visualizing the size of the nation does affecting the geographical policies made for them. Imagine, a navy commander going to a meeting for war planning. The task is to form a blockade for the coast with one ship sanctioned per 10km. If the number in front of him is 12000km, he will need 1200 ship, whereas if the number in front of him is 20000km, he will need 2000 ship. These numbers will cause him to overestimate or underestimate the strength of the enemy.

Similarly, based on where “the space” starts, the number of people who can be called astronauts will vary.

Below are few more instances where numbers and figures can vary our perseptions

Size of Greenland

Here is another example of a similar fashion. Since we are so accustomed to seeing a flat map, which is a Mercator projection of the globe. We often overestimate the size of countries near the pole. Take Greenland for example in the below images. In the first image, it looks almost as big as Africa, but look at the second image or true comparison.

North can be down

There are also, psychological biases that affect decisions. In the map, North is generally up even though there is no reason for it to be and it’s arbitrary. We are accustomed to correlating up, more or top with good and down, bottom as bad (similar to heaven and hell). So, even though there is no reason for the North to be on “up” in the map, we might subconsciously correlate Northern countries as superior.

Also, USA and Russia are geographically much more closer than we visualize (Specially with Alaska).

It’s very easy to lie or make false perceptions with number, images, and graphs if we are unaware of assumptions. Even if the details are not false, a skilled storyteller, can use the same number and make you believe in anything.

Manipulation with data

Here is a humorous example, Do you know 40% of marriages in US end up in divorce? The problem is, it’s even worse for the remaining 60%, they end up in death.

Toothpaste Advertisement

Another misleading example is of toothpaste companies with claims like 80% of the dentist recommend Colgate. Yes, it’s true but look at the image below. Based on the data, I can make any statement like 80% of Dentist recommend colgate. 100% of the dentist recommend Sensodyne, 60% dentist recommend Crest or Oral-B and they’d all be correct. (FYI, the advertisement was finally banned in 2007 in UK)

Extrapolating Prices

In a personal incident, a salesperson was trying to sell an electricity plan. She took my daily usage and extrapolated it to monthly usage. She then calculated the rate as per both my current provider and her plan to calculate the savings, then generously doubled the savings for usage in peak summer (August vs the current not-so-hot month of July) and then multiplied it by 24 to get savings for 2 years (because, you know, it’s peak summer 12 months a year). The final number, $2400 of savings was funnily around 70% of the amount I’d actually pay if I extrapolated the usage independently. And all of these savings was by an electricity rate difference of 3 cents per kW (13.9 cents per kW vs 16.8 cents per kW)

Minimize being manipulated

People have been using stats across marketing, geopolitics, news, engineering and everywhere to make all kind of perceptions. So, what can we do to minimize the manipulations?

Compare data from multiple sources

Check whether the data you’re referring to is consistent across multiple reputable organizations. Watch and read multiple news agencies to understand their biases.

Be aware of assumptions

Irrespective of whether the data is consistent or not, when presented with data, ask questions like baseline assumptions and methodology while gathering the data. In the coastline paradox, the questions could be How is the coastline defined? What is the measurement methodology of coastline lengths?

Compare similar sources of data

Single organization data is more likely to be consistent and follow a similar methodology.

Be Aware of data biases

Data collection systems have their own biases. These are affected by multiple factors, geopolitical, local extrapolation, news, personal beliefs etc. E.g. Psychological studies are more likely to be biased towards representing the demographic of young individuals in their 20s since that is the group of graduate students, far more easily available to university researchers.

Look at data from an alternate perspective

Beware of axis and scale while looking at a graph. Both of the below graphs show the same data but create far different perspective.

References and Credits

Wanna read more? Below are the sources of data presented in the article above for you to question and point out my assumptions and biases.

Coastline paradox - Wikipedia
The coastline paradox is the counterintuitive observation that the coastline of a landmass does not have a well-defined…en.wikipedia.org

This One Country Shows How Distorted Our Modern Map Is
Greenland and Africa aren't actually the size.www.businessinsider.com

Colgate's '80% of dentists recommend' claim under fire | marketinglaw
Colgate's '80% of dentists recommend' claim under fire, read now at Osborne Clarke's Marketing Law.marketinglaw.osborneclarke.com4.

In the previous article “Beyond the Black Box: The Risks and Rewards of Abstraction”, I talked about abstractions and how they affect us. Here, I’d like to talk about bottlenecks. I first explore a personal life story then extrapolate the concept to the professional and tech world.

The incident is a few years old now. I had recently shifted to Chennai (India), a new city for my job. Being new in the city, I didn’t know a lot of places, I didn’t speak the local language, I wasn’t acquainted with the local food taste, I didn’t have a personal mode of commute yet and I was staying alone. Having said that, this being 2020 it was still in liveable condition since I had the smartphone and there is a service for everything. I could order food that I liked online using multiple mobile apps like Swiggy/Zomato, I could book a cab using Uber/Ola, I could order groceries using Swiggy/Big Basket and I didn’t need to talk to the local population much when needed, I could try to talk in English or Hindi or use Google Translate in extreme conditions.

And then one day, my phone broke and all hell came loose. Let’s look at the repercussions.

Starting with essential, the food. I used to rely on Swiggy for my daily meals but Zomato and Swiggy are mobile-only platforms. Though both did have a web-based portal, they need mobile numbers and text message to sign in and didn’t support other kinds of sign-in. Okay, maybe I can contact one of my friends and ask them to order food for me. But how do I contact them? Can’t call or text or send Whatsapp text. e-mail? Social Media? Well, most of those needed 2FA, and the text or Authentication pin would come to my mobile. After some search, I was able to find that my laptop is already logged in to Instagram, and could contact one of my friends over there. He gave me his Swiggy credentials for login so that I could order food. After search and carting the items, comes the payment. Well, UPI apps are out of the question, I didn’t have cash, and Credit Cards need OTP. Finally, I asked the same fiend to pay for it and temperorily the food was taken care of.

Now, time to repair or find a new mobile. If I purchase one online, it’ll get delivered after a day or two which would be undesired. So, let’s find a local repair shop, preferably one where they could understand English or Hindi. Finding it wasn’t difficult, but commuting will be. No mobile for booking cab, no shops too close. I finally decide find a shop, couple of kilometres away then walk to it. Gave the mobile for repair and explained the problem. Went to pass time for 2 hours and got my mobile back.

On contemplating about the incident, I realized how much of our daily life is funneled through a single point. UPI need mobile devices, Credit Cards needs OTP for payments, many of the logins like email, social network requires 2FA either in form of a text message or Authenticator apps and many of the apps are mobile only. If the central device fails, you’re isolated from so many day-to-day activities which we just take for granted.

Extending the concept to tech, let’s discuss some of the case studies I came across

Network Infrastructure

Couple of years back, there was an outage in many Facebook services. Even though website outages are not uncommon, what made this outage stand out was there was a bug in backend of the system. This bug made DNS servers unavailable to rest of the system and many internal tools couldn’t work. This also meant, engineers could not log in remotely to the data centres because the remote login system works on DNS to resolve the names to IP address connection. A team on engineers were deployed physically to the data centre. To add more obstacles, the door access lock itself was RFID based and depended on backend servers to grant access to engineers; backend servers which were now inaccessible. Finally, they had to break the door physically in order to access the servers and fix the issue. Took some time but it got resolved. You can read about the complete technical article here — https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/

Cloudflare, a company which has multiple offerings. One of their popular offerings is CDN, a service on which half of the internet rely on. Due to a bug, the CDN service went down and multiple sites all over internet couldn’t render correctly

And there have been similar incidents across internet. Giants like GitHub, Gitlab, Google, Microsoft everyone has fallen victim to such incidents. There is an exhaustive link which people from the field might be interested towards over here — https://github.com/danluu/post-mortems

Open-Source Code

Yes, Open Source is awesome. But open source also builds on top of code contributed by multiple authors, in fact that’s why the model works. You don’t build the complete house yourself; you use the bricks and interiors designed and manufactured by others to build your house. Now what if someone took few of the bricks which make an essential layer? The house comes crumbling down.

A similar incident happened in 2016, when 11 lines of code took down the internet. A simple obscure code on npm called left-pad, which did nothing more than remove spaces from the start of a string. A function so simple and yet in the web of dependencies, some of the heavily used libraries used the same. At a time, the developer who wrote left-pad had also written a framework called kik. The problem, it shared the name with a messaging app kik based out of Canada which launched some legal troubles for him. In the quarrel, he decides to take down all the open-source projects written by him over the years, one of which was left-pad hosted on npm and thousands of websites came crashing down since the dependency couldn’t be found. The matter was resolved when npm decided to un unpublish the packages. If you’d like to read more, the article captures further details — https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code

Many developers have faced issues relating to versioning of the API or libraries which are under active development. The addition of features and security upgrades are the upsides to constantly updating systems, but also comes with a downside of the APIs or libraries not being backward compatible and developers constantly needing to maintain and test the software for each platform, each update and each change in dependency or API.

Electricity

Can you imagine your life without electricity? Today EVERYTHING depends on it. It’s not just lights to see in dark or fan/heaters/ACs to keep you comfortable or communication and entertainment devices. We are also moving towards commute using electric vehicles, and trying to convert almost everything to electricity. Now, similar to internet network, electricity is complex. There are production units, there are consumers and there are multiple levels of distribution, storage and conversion.

Imagine a catastrophe which takes down the electricity for a locality or a city or a state. It could be caused by solar flares, it could be caused by production units not having enough raw materials, it could be caused by strikes, it could be caused by overloading of grid. What if any of those occur? Well, you don’t need to imagine, you just need to hear/read/watch stories of 2019 Winter blackout in Texas, USA. In peak winter, everyone ramped up their heating systems causing grid to overload and issues to cascade resulting in 3 days without electricity for majority of the state.

Supply Chain

When in manufacturing, you work with multiple vendors to source multiple parts which are needed to build your product. Your manufacturing also depends on various machines and operators. If a critical part or machine is unavailable, your manufacturing line stops costing money, reputation and affecting further development down the line where your product will be used by customers.

Preventing the issues

The first question is can we even prevent these? My take is no, but we can work to minimize them. De risk our lives and our products so that these issues become less devastating. There are trade-offs to be considered, but carefully thought, we can build more reliable solutions, be in personal or professional life.

Looking back, mobile being a single point of failure could be still foreseeable, but what about variables not in our control? What if the government decides to shut off the internet of the complete region, which does happen on multiple occasions to prevent riots from extending? How would you carry out multiple activities which rely so much on internet? What if there is a power failure for a state due to any riots/war/technical failures? When a system grows or is used by large or critical number of users, each dependency and path need to be analysed. We need to analyse and have backups and replacement for critical choking points.

Be it hardware of software or supply chain, multiple services and vendors are essential for high performing systems which can’t be gotten rid of even if we tried. But, for every system, a fallback low-performing system can be planned and executed. The first thing neccesary for same is a dependency graph to nth level. Your deliverables depend on a, b, c, a depends on x, y, y depends on z and z might depend back on x and a. Then, a what-if study, asking question of what happens if a dependency fails be it vendor unable to fulfil your order, machine being powered down, software taken off the internet or internet and electricity being down and then planning backups for them which suits your needs carefully. Let’s look at specific examples

Software

1. Having code backups for open-source software locally on your server, relying less on hosting sites like pypi/npm/GitHub to retrieve them for you. This ensures that if the hosting site or developer takes it down. you still have something to fall back on, at least temporarily.
2. Fixing a version of dependency and API you’re working with. Most of the services which hosts the packages like npm/pypi/GitHub will these days allow you to retrieve a version of the dependency. Instead of choosing the latest version each time, use a version and freeze it till the project is complete. Then periodically update it on one system first, test it out before rolling it to production.
3. Freezing the system, if the solution is designed for a specific particular task, there is no need to upgrade it automatically. The operating system, hardware, software versions everything can be frozen in time and the system can be operated independently for years and decades. This does have downsides which I’ll be discussing in another article.
4. Feature flags, you should be able to able to turn on or off a feature without hassle. Writing software keeping that in mind is important.
5. Carrying it forward, just like you used dependencies to build your solution, your customers will be using your solution to build their systems. Remember to grant the same flexibility to them as you’d expect from your vendors. Make your software backward compatible, have it properly versioned, allow user to roll back a version, provide proper documentation. Build it to be sustained.

Hardware

1. While designing, try to select parts which has multiple drop-in replacements available, preferably from separate vendors.
2. Build your design modular, so that if there is a problem with one of the parts, it’s easier to isolate and only that section can be redesigned.
3. Ensure lifetime support for the parts. Make sure the part you’re using a strong supply chain and will be supported by the vendor and manufacturer for life of your product.
4. Build your design with software tools (CAD programs/ Simulators) which can be exported to another tool easily. Make sure you at least have a read-only version of your projects even if the software license expires.

Supply Chain

1. Find a vendor, and their replacement, and their replacement.
2. Find the manufacturer, and their replacement, and their replacement.
3. Make sure to diversify these enough across Region/ Quality/ Cost. If all your vendors are from same geographic location, if there is any natural disaster or political event, everything will be affected beyond recovery.

People

1. People and workforce are as important to your product as your tech and designs. Make sure the procedures are well documented so that if any person has a problem, the work can still be executed with others.
2. Avoiding process choke points, be it purchase approvals, design releases, customer communication or if these are heavily relied on a single person, their absence results in deliverables being choked or slips in schedule. It’s better to rely on a process and a team rather than single individual no matter how good they are.
3. Keeping the employees happy, it’s good to have backups, it’s better to not need them. No matter how good you do the documentation, each profession has intricacies which are ingrained in the person doing the job for years. Replacing the individual will always result in drop of information and quality.

Personal life

1. Similar to professional, build a dependency graph periodically, maybe once in six months or year to analyse if you’re depending too much on something.
2. Reduce the dependency on tech. It’s good to enjoy tech, it’s bad to depend on it. Have life skills that could be used without tech. Some of them could be cooking without electricity, washing without machines, being comfortable with heat and cold without depending on HVAC systems, or navigating without mobile maps.
3. Have distributed and local backups. Small scale generator or power storage for times when grid fails, cash for when payment system fails, stored water for when pipelines burst, bicycles when there is a gas shortage.
4. Financial safety. Don’t rely explicitly on single source of income, be it job or business or investment. Diversify the portfolio and have backups for when systems collapse.
5. Emotional Safety. Friends and family are an immense part of anyone’s life. But relying heavily on them can be a mistake, may it be your friends, girlfriend, spouse or parents. Mishaps can happen anytime, there might be an accident and you might not see them tomorrow or there might be a fight and you might not end up on good terms, whatever it is cherish those relationships while they last but prepare and be comfortable with your own company for when things go wrong.

In conclusion, I’d like to modify a quote by Mel Brooks. He said, “Hope for the best, expect the worst” which I would reword just a bit to “Hope for the best, prepare for the worst”.

Programmers are no strangers to the concept of abstraction and while another field might not know it as a word, I’m sure they use it every day. Abstraction is the concept of building a black box and reusing it, building on top of it while hiding information underneath. Think of it as a black box where you know what the inputs and outputs are, and you’re free to use it without needing to know what’s happening inside them. In Electronics, you don’t need to exactly know what’s happening inside an IC in order to use it as long as you know what it does and how to use it. For manufacturing, you don’t need to know how the machine exactly works in order to use it. In cooking, I don’t need to know the exact spice mix as long as I know how it’ll generically make my food taste.

It’s fair to say, without abstraction we would still be hunter’s gatherers. If you need to know exactly how each thing works, there is not much you can comprehend in your short lifetime.

This reminds me on an incident. I was on a trip recently with a couple of my friends when we were discussing the subject of cooking. One of my friends comment on my cooking style saying “You don’t exactly cook, you assemble. You get premixed spices, pre-cut veggies, pre-baked bread, and sauces; all you do is mix and heat those. That’s not cooking.”. To this, my other friend replies “Okay then, tomorrow onwards we will go to the farm and grow our own cereals, spices, and veggies.”.

Abstraction is basically a trade-off someone chooses for “Time and Effort” vs “Performance”. If you build everything from scratch, you might have the most performant system but you’ll also spend so much time and effort creating and optimizing something which already exists. Having said that, many times you might need to reinvent the wheel and build a couple of blocks for performance optimization. Also, it is just fun to understand how each block work and make it. There is fun in cooking from scratch and writing small problems in assembly and building computers from gates not to mention, it gives a very detailed understanding of things that might be used somewhere in the future.

Checkpoints when using abstractions

When you work in System’s Engineering, integrating various blocks and solutions developed by multiple entities and creating a few of your own, few things become important.

1. Determining which parameter is important for your application and which parameter you can let go of.
2. Evaluating the performance of various blocks so that when you do have to optimize your application, you know replacing or modifying which block will give most drastic effect.
3. Using generic blocks which are available from various vendors/sources to derisk them going out of stock or losing support.

Abstractions as source of bugs

Abstraction introduces bugs when we don’t know what’s happening under the hood. If you just deal with abstractions, not knowing how things work can leave you in dark for the performance matrix and a solution that is highly suboptimal.

Recently I was working on an Embedded C project where I was facing a bug. My uint16 type variable was getting coupled with another uint16 variable, whenever the second variable changed, the first variable also unwantedly changed. The root cause turned out to be compiler optimization settings where the compiler was bit squeezing these two variables into a single 32-bit register to save memory. Closed source software/blocks are a huge source of bugs that can leave you debugging for a good amount of time without even concluding the root cause.

Dark Side of Ease of Use

There are two general approaches when someone starts to learn programming. One is to start with lower level programming language like C and build there way slowly to C++ and Python. Another is to directly learn Python. There have been debates on which of the approach is better with relevant points raised from pro Python side like “Why should I learn C if I’m just going to use Python here after?”, “It’s so difficult to understand the syntax of C compared to Python”. To answer this, learning from scratch does give programmer overview of how things happen under the hood giving them better chances of solving bugs like

These issue are further amplified by the rise of graphical programming platforms like LabVIEW, NodeRED etc. Where things are even more abstracted.

With the rising age of AI, there have been increasing debates around the pros and cons of it. Though I am pro AI, one issue I do see if we become increasingly reliant on AI is the future generation won’t know how things work at all and will introduce tons of bugs and sub-optimal applications in the market. As the barrier to entry in any market become low, the number of low-quality applications increases drastically. This is evident enough on the play store with 1000’s of apps to do the same task making the paradox of choice even greater not having any metric for the quality of the app.

Conclusion and Call to Action

I watched a video recently on how all of the human race forgot the method of creating an important compound for decades and had to spend millions in recreating it. Though the root cause over there was a lack of documentation, I could potentially see similar incidents rising in frequency in the future. There was an article mentioning recently how only a couple of dozen people around the world truly understand how RSA encryption works. The algorithm, is so important that our whole internet infrastructure is based on it, if something goes wrong, there soon might not be anyone who knows enough to fix it.

With the rise of ease of use tool, educating the next generation for basics is becoming increasingly difficult and is a problem which needs to be solved soon.

Another shift in mindset would be on moving towards more open source software giving developers further understanding of what’s happening under the hood.

Finally, without black boxes, no development would be completed. Having said that the performance matrix and test results while releasing any block would be essential to ensure that the abstraction layer is working as intended. The trade-off between the convenience of abstraction and the necessity of understanding the underlying mechanisms must be carefully managed to prevent potential system failures or inefficiencies. The performance metrics and testing outcomes not only validate the functionality and efficiency of these ‘black boxes’, but they also provide valuable insights for future improvements and adaptations. Therefore, although abstraction can significantly accelerate development processes, rigorous testing and comprehensive understanding of performance data should never be overlooked.

Credits and References

1. A blog on Embedded System optimization where closed source software cost a company lots of effort in optimizing their solution

1 Month Battery Life with Firmware Update
We are proud to announce that starting the firmware version 0.82, your Flipper Zero's battery life will last up to 1…blog.flipperzero.one

Voyager 1 and Voyager 2 spacecraft launched in 1977 are at the moment the farthest man-made objects in space (from Earth). At the time of writing this article (11th June 2023), Voyager 1 is 23,832,997,181 Km from Earth whereas Voyager 2 is 19,881,531,586 Km from Earth. To put it into perspective, you can go to Pluto, come back, and go back again and the distance traveled by you will be still lower than the distance to Voyager 2. In spite of the distance, these space crafts are still communicable (WAY beyond their planned mission may I add) even though it takes us 46 hr to send a signal and receive the signal back from the spacecraft (assuming everything goes well, else we won’t even know if there is any problem for the next 46 hr, then it’s debugging and run again). These long-distance calls are operated by NASA Deep Space Network Telescope located around the Earth.
Let’s take a walk through the precision and accuracy it takes to communicate with these objects.

Orientation and Direction

Visualize pointing a laser pointer at a distance of 10m, now if you’re off by one degree, the point will be off by 0.17m from the target. Scale this up to 1km, you’ll be off by 17m. Scale this off to 20 billion km, and you’re off by 349,101,298 km.

Now thankfully communication with Voyager doesn’t work like a laser pointer, instead, it works like a narrow beam flashlight, still, the precision required to communicate with Voyager is around 130 arcseconds i.e. 0.036 degrees. (Note: Answer produced by GPT4 and Wolfram Alpha, might be factually incorrect — https://chat.openai.com/share/f6daa166-5888-44e9-82fe-1629ba68906c/).

This accuracy needs to encapsulate the results of everything including the accuracy of manufactured mechanical components, sensors, control electronics, and software systems, and even needs to compensate for vibrations in the ground due to the passing of vehicles or earthquakes.

On the other side, the orientation also needs to be matched by Voyager autonomously, which means it needs to look at known stars and calculate and orient itself so that its antenna is always pointing at Earth. Else, we won’t even be able to command it to point to Earth if we lose communication.

Amplification

Even after highly precise orientation, the signals received by these antennas are very faint. High gain amplification is required to gather something meaningful out of this interaction.

Noise Rejection

When we do amplification, along with symbols the other thing that gets amplified is the noise. The sources of noise could be many, apart from natural sources, the instrument capturing and amplifying the signal themselves produces noise. One clever engineering technique in order to reduce instrument noise is to operate the instruments at extremely cold temperatures. How cold? Around 255 degrees Celcius below zero or 18 degree Kelvin. That way, we minimize thermal noise.

Another way is to use clever filtering techniques to remove the randomness of data.

Yet another is to use encoding techniques so that we increase Signal to Noise Ratio. Sometimes we even trade off Symbol Signal to Noise Ratio for Bit Signal to Noise Ratio.

Astronomically Precise Calculations

None of the above matters if we are not able to precisely locate the Voyager WRT Earth in the first place. That involves a whole lot of Math and Physics, to begin with. The trajectory of the spacecraft not only depends on the fuel it burns and thrusts it produces, but also on the effect of gravitation of the nearby and farther-off objects. Not only that but also the effect of incalculable solar winds. Also the changing position of the telescope due to rotation and revolution of Earth.

Being launched in the 1970s also means that most of the calculations were done by hand and mechanical or huge electrical calculators introduced manual and technical sources of errors.

Even with modern computers, if you use the incorrect tools, the results are dramatic e.g. in regular programming language 0.1 + 0.2 is not equal to 0.3 So if we are not aware of the underlying abstractions, results can be catastrophic.

Weather

While some of the above parameters are in our control, the weather is truly not. Forecasting, compensating, and accepting the effects of weather is all we can do.

Cloud coverage results in losing the strength of the signal being received. Rain and snow result in signals being refracted. Sunny day results in higher noise in electronics. Lightning produces signals and noise which might have been unanticipated. Earthquakes and ground vibrations result in calibration and compensation being required for orientation.

There will be times when for days we just won’t be able to communicate with the probes for days.

Technological Downtimes and Maintainance

These spacecraft were manufactured and launched in the 1970s. Imagine creating something with the technology available 50 years in the past with no way of upgrading it since it is launched. Not only that, most of the ground systems hardware and software needs to be frozen in that era. All components needed for upgrades for all the planned mission time and beyond the need to be planned for the supply chain and well-documented for the manufacturing process.

Moreover, any maintenance for ground equipment means no communication with a probe for that amount of time. Sometimes it can be months. Any firmware update over the air also means if something goes wrong, there is no way to reset it.

Conclusion

The efforts that go into precise study fields are beyond comprehension. Scientist spends years and decades studying and calculating variables for such missions. Engineers spend the same amount of time finding clever solutions to realize those calculations and convert them to something achievable. Manufacturing team on finding solutions to create components with a small level of tolerance for failures. Test teams on finding and simulating infinite possible variables that could deter the mission. Even after that, a simple components failure let it be as simple as a capacitor or screw or scratch can result in a catastrophic mission failure for all the time and resources being put into the missions. A simple math error, human or calculator, or theoretical error can result in the same error. As disheartening as the mission failure could be, they don’t mean effort failure. These learnings are constantly incorporated for future missions. Processes are streamlined and we build and stand on top of giants for the next missions. Onwards and upwards.

Note: Precision and Accuracy are not the same

Credit where it is due

1. AWESOME video discussing all the factors discussed above in detail and with visible enthusiasm by Dave of channel EEVblog with Richard Stephenson from Deep Space Network, NASA.

2. Awesome website for tracking live space objects

TheSkyLive - Your Guide to the Solar System and the Night Sky
This interactive 3D view shows the current positions of the major bodies of the Solar System and the brightest comets…theskylive.com

3. Website for calculating deep math questions

https://www.wolframalpha.com

Post Script

This is the first article in the series I’m planning to discuss similar challenges in other precise engineering fields like Electronics, Semiconductors, Space, Computer Science, and Quantum Physics.

Some of the planned articles include Relativistic Timekeeping of GPS, LIGO, Semiconductor Fabrication, Electronics Design and Testing.

Would love to chat about similar topics if someone is interested in one on one discussion on the same.