ParaView

The first thing we need to do is open our .vtu result file.

1. Load the file. In the Pipeline Browser (the menu on the left), ParaView will show the file with a green box next to it, indicating it hasn’t been applied yet.

2. Below that, in the Properties panel, you will see the configuration options. This is where we adjust our results.

3. Click the Apply button, and the geometry will appear in the Render View.

4. Now, in the top toolbar (or the Properties window), change the visualization representation from Solid Color to magnetic flux density e.

You will notice that the magnetic flux is displayed in the form of elements (triangles) or nodes. The triangle view often looks a bit sharper because the data is self-contained within the boundaries of each element. The node view, on the other hand, averages the values of adjacent elements. If you play around with it, you will notice a blurring effect across the entire geometry.

Conclusion

There are far more powerful tools and filters inside ParaView, but these are the most relevant ones for a basic post-processing evaluation of our 2D model.

Now, we need to step back into Elmer and start playing serious, but that will be the topic for another discussion!

ElmerGrid

The first thing we need to do is convert the .unv file to Elmer format. To perform that, we use ElmerGrid.

$ ElmerGrid 8 2 EIcore-FEMMeshGmsh.unv -autoclean

It will generate a lot of files as follows:

$ tree
.
├── EIcore-FEMMeshGmsh
│   ├── entities.sif
│   ├── mesh.boundary
│   ├── mesh.elements
│   ├── mesh.header
│   ├── mesh.names
│   └── mesh.nodes
└── EIcore-FEMMeshGmsh.unv

If you look inside the .sif file, you will notice that now it uses the same name that you created in FreeCAD. That one will help us a lot.

!------ Skeleton for body section -----
Body 1
    Name = Air
End

Body 2
  Name = Iron_Faces
End

Body 3
  Name = coil_a_minus_Faces
End
.
.

Now, we fill out the rest.

Sif Editing

Let’s break the sif editing into different parts. The first one is the variables.

$ N = 217
$ I = 0.74
$ NI = N*I
$ A_coil = 0.035 * 0.07 
$ J = N * I / A_coil

Header
  CHECK KEYWORDS Warn
  Mesh DB "." "."
  Include Path ""
  Results Directory ""
End

Simulation
  Max Output Level = 5
  Coordinate System = Cartesian
  Coordinate Mapping(3) = 1 2 3
  Simulation Type = Steady state
  Steady State Max Iterations = 1
  Output Intervals(1) = 1
  ! Solver Input File = case.sif
  Coordinate Scaling = Real 0.001
End

Constants
  Gravity(4) = 0 -1 0 9.82
  Stefan Boltzmann = 5.670374419e-08
  Permittivity of Vacuum = 8.85418781e-12
  Permeability of Vacuum = 1.25663706e-6
  Boltzmann Constant = 1.380649e-23
  Unit Charge = 1.6021766e-19
End

Equation 1
  Name = "MgDyn2D"
  Active Solvers(3) = 1 2 3 ! <-- Here you define the number of solvers and the execution order.
End

Solver 1
  Equation = MgDyn2D
  Variable = Potential
  Procedure = "MagnetoDynamics2D" "MagnetoDynamics2D"
  Exec Solver = Always
  Optimize Bandwidth = True
  Steady State Convergence Tolerance = 1.0e-5
  Nonlinear System Convergence Tolerance = 1.0e-7
  Nonlinear System Max Iterations = 20
  Nonlinear System Newton After Iterations = 3
  Nonlinear System Newton After Tolerance = 1.0e-3
  Nonlinear System Relaxation Factor = 1
  Linear System Solver = Iterative
  Linear System Iterative Method = BiCGStab
  Linear System Max Iterations = 500
  Linear System Convergence Tolerance = 1.0e-10
  BiCGstabl polynomial degree = 2
  Linear System Preconditioning = ILU0
  Linear System Abort Not Converged = False
  Linear System Residual Output = 10
End

Solver 2
  Equation = MgDynPost
  Procedure = "MagnetoDynamics" "MagnetoDynamicsCalcFields"
  Target Variable = Potential
  Exec Solver = Always
  Steady State Convergence Tolerance = 1.0e-5
  Linear System Solver = Iterative
  Linear System Iterative Method = BiCGStab
  Linear System Max Iterations = 500
  Linear System Convergence Tolerance = 1.0e-10
  Linear System Preconditioning = ILU0
  Calculate Magnetic Field Strength = Logical True
  Calculate Magnetic Flux Density = Logical True
  Calculate Current Density = Logical True
End

Solver 3
  Exec Solver = After saving
  Equation = "ResultOutput"
  Procedure = "ResultOutputSolve" "ResultOutputSolver"
  Output File Name = "results"
  Vtu Format = Logical True
  Vtu Part Collection = Logical True
  Vtu Multiblock = Logical True
End

Material 1
  Name = "Air (room temperature)"
  Heat Conductivity = 0.0257
  Relative Permeability = 1.00000037
  Viscosity = 1.983e-5
  Heat expansion Coefficient = 3.43e-3
  Density = 1.205
  Relative Permittivity = 1.00059
  Sound speed = 343.0
  Heat Capacity = 1005.0
End

Material 2
  Name = "Iron (generic)"
  Sound speed = 5000.0
  ! Relative Permeability = 4000
  H-B Curve = Variable "dummy"
    Real Cubic
      Include "hb_iron.txt"
    End

  Poisson ratio = 0.29
  Density = 7870.0
  Heat Capacity = 449.0
  Heat Conductivity = 80.2
  Youngs modulus = 193.053e9
  Electric Conductivity = 10.30e6
  Heat expansion Coefficient = 11.8e-6
End

0 0
0.05 19.96533
0.1 29.906288
0.15 36.398771
0.2 41.371669
0.25 45.590262
0.3 49.424859
0.35 53.08228
0.4 56.692664
0.45 60.347374
0.5 64.117637
0.55 68.064755
0.6 72.246371
0.65 76.720886
0.7 81.551123
0.75 86.807959
0.8 92.574503
0.85 98.95152
0.9 106.065047
0.95 114.077777
1 123.206911
1.05 133.753385
1.1 146.151738
1.15 161.058668
1.2 179.516634
1.25 203.267945
1.3 235.379748
1.35 281.524948
1.4 352.648412
1.45 470.426179
1.5 677.451541
1.55 1051.068036
1.6 1703.275165
1.65 2726.517959
1.7 4137.981052
1.75 5832.619704
1.8 7939.55294
1.85 10565.294335
1.9 13843.912965
1.95 17970.359698
2 23423.776432
2.05 32234.32596
2.1 51366.778967
2.15 84577.843501
2.2 121162.493322
2.25 160127.812767
2.3 202470.282245

Body Force 1
  Name = "Circuit_A"
  Current Density = -distribute $ NI
  ! Current Density = $ J
End

Body Force 2
  Name = "Circuit_a"
  Current Density = -distribute $ -NI
  ! Current Density = $ -J
End

Body Force 3
  Name = "Circuit_b"
  Current Density = Real 0.0 ! $ NI
End

Body Force 4
  Name = "Circuit_B"
  Current Density = Real 0.0 ! $ -NI
End

Boundary Condition 1
  Target Boundaries(1) = 19 
  Name = "Zero"
  Potential = Real 0.0
End

Body 1
  Name = Air
  Equation = 1
  Material = 1
End

Body 2
  Name = Iron_Faces
  Equation = 1
  Material = 2
End

Body 3
  Name = coil_a_minus_Faces
  Equation = 1
  Material = 1
  Body Force = 1
End

Body 4
  Name = coil_a_plus_Faces
  Equation = 1
  Material = 1
  Body Force = 2
End

Body 5
  Name = coil_b_minus_Faces
  Equation = 1
  Material = 1
  Body Force = 3
End

Body 6
  Name = coil_b_plus_Faces
  Equation = 1
  Material = 1
  Body Force = 4
End

$ N = 217
$ I = 0.74
$ NI = N*I
$ A_coil = 0.035 * 0.07 
$ J = N * I / A_coil

Header
  CHECK KEYWORDS Warn
  Mesh DB "." "."
  Include Path ""
  Results Directory ""
End

Simulation
  Max Output Level = 5
  Coordinate System = Cartesian
  Coordinate Mapping(3) = 1 2 3
  Simulation Type = Steady state
  Steady State Max Iterations = 1
  Output Intervals(1) = 1
  ! Solver Input File = case.sif
  Coordinate Scaling = Real 0.001
End

Constants
  Gravity(4) = 0 -1 0 9.82
  Stefan Boltzmann = 5.670374419e-08
  Permittivity of Vacuum = 8.85418781e-12
  Permeability of Vacuum = 1.25663706e-6
  Boltzmann Constant = 1.380649e-23
  Unit Charge = 1.6021766e-19
End

!------ Skeleton for body section -----
Body 1
  Name = Air
  Equation = 1
  Material = 1
End

Body 2
  Name = Iron_Faces
  Equation = 1
  Material = 2
End

Body 3
  Name = coil_a_minus_Faces
  Equation = 1
  Material = 1
  Body Force = 1
End

Body 4
  Name = coil_a_plus_Faces
  Equation = 1
  Material = 1
  Body Force = 2
End

Body 5
  Name = coil_b_minus_Faces
  Equation = 1
  Material = 1
  Body Force = 3
End

Body 6
  Name = coil_b_plus_Faces
  Equation = 1
  Material = 1
  Body Force = 4
End

Solver 1
  Equation = MgDyn2D
  Variable = Potential
  Procedure = "MagnetoDynamics2D" "MagnetoDynamics2D"
  Exec Solver = Always
  Optimize Bandwidth = True
  Steady State Convergence Tolerance = 1.0e-5
  Nonlinear System Convergence Tolerance = 1.0e-7
  Nonlinear System Max Iterations = 20
  Nonlinear System Newton After Iterations = 3
  Nonlinear System Newton After Tolerance = 1.0e-3
  Nonlinear System Relaxation Factor = 1
  Linear System Solver = Iterative
  Linear System Iterative Method = BiCGStab
  Linear System Max Iterations = 500
  Linear System Convergence Tolerance = 1.0e-10
  BiCGstabl polynomial degree = 2
  Linear System Preconditioning = ILU0
  Linear System Abort Not Converged = False
  Linear System Residual Output = 10
End

Solver 2
  Equation = MgDynPost
  Procedure = "MagnetoDynamics" "MagnetoDynamicsCalcFields"
  Target Variable = Potential
  Exec Solver = Always
  Steady State Convergence Tolerance = 1.0e-5
  Linear System Solver = Iterative
  Linear System Iterative Method = BiCGStab
  Linear System Max Iterations = 500
  Linear System Convergence Tolerance = 1.0e-10
  Linear System Preconditioning = ILU0
  Calculate Magnetic Field Strength = Logical True
  Calculate Magnetic Flux Density = Logical True
  Calculate Current Density = Logical True
End

Solver 3
  Exec Solver = After saving
  Equation = "ResultOutput"
  Procedure = "ResultOutputSolve" "ResultOutputSolver"
  Output File Name = "results"
  Vtu Format = Logical True
  Vtu Part Collection = Logical True
  Vtu Multiblock = Logical True
End

Equation 1
  Name = "MgDyn2D"
  Active Solvers(3) = 1 2 3
End

Material 1
  Name = "Air (room temperature)"
  Heat Conductivity = 0.0257
  Relative Permeability = 1.00000037
  Viscosity = 1.983e-5
  Heat expansion Coefficient = 3.43e-3
  Density = 1.205
  Relative Permittivity = 1.00059
  Sound speed = 343.0
  Heat Capacity = 1005.0
End

Material 2
  Name = "Iron (generic)"
  Sound speed = 5000.0
  ! Relative Permeability = 4000
  H-B Curve = Variable "dummy"
    Real Cubic
      Include "bh_iron.txt"
    End

  Poisson ratio = 0.29
  Density = 7870.0
  Heat Capacity = 449.0
  Heat Conductivity = 80.2
  Youngs modulus = 193.053e9
  Electric Conductivity = 10.30e6
  Heat expansion Coefficient = 11.8e-6
End

Body Force 1
  Name = "Circuit_A"
  Current Density = -distribute $ NI
  ! Current Density = $ J
End

Body Force 2
  Name = "Circuit_a"
  Current Density = -distribute $ -NI
  ! Current Density = $ -J
End

Body Force 3
  Name = "Circuit_b"
  Current Density = Real 0.0 ! $ NI
End

Body Force 4
  Name = "Circuit_B"
  Current Density = Real 0.0 ! $ -NI
End

Boundary Condition 1
  Target Boundaries(1) = 19
  Name = zerobound_Edges
  Name = "Zero"
  Potential = Real 0.0
End

Simulation

Now we run the simulation.

$ ElmerSolver my_first_sif_file.sif 

Paraview

Now, inside paraview, you will notice a .vtu file. It has now different blocks that can be evaluated in paraview. It will be easier for post-processing. For now, let’s just see the expected result.

The total magnetic length is 420mm.

Lookig the HB curve, that gives us aroung 1.43T.

The surface current integral shows 160.58 A.e and 1.48 T of normal flux density.

Post-processing

One last thing before we close this post, we can also perform post-processing natively using Elmer. Sometimes it is better to evaluate outside ParaView. For us, it is better just to compare both results. We are going to add plot over line flux, calculate the coil’s Area, and the Potential integral (Flux Linkage). With current and flux, we get inductance.

To achieve this, we need to add two internal solvers to our .sif file: SaveLine and SaveScalars.

Solver 4
  Equation = SaveLine
  Procedure = "SaveData" "SaveLine"
  Filename = "linha_fluxo.dat"
  File Append = Logical False
  Polyline Coordinates(2,2) = Real -0.14 0.0  0.14 0.0 
End

Solver 5
  Equation = "SaveScalars"
  Procedure = "SaveData" "SaveScalars"
  Filename = "integrais_bobina.dat"
  File Append = Logical False

  ! 1. Area validation
  Variable 1 = Coordinate 1
  Operator 1 = volume

  ! 2. Potential Integral for Flux Linkage
  Variable 2 = Potential
  Operator 2 = int

  ! Apply exactly to the bodies marked with this tag
  Mask Name 1 = "Integrar Corrente"
  Mask Name 2 = "Integrar Corrente"
End

Understanding ElmerGUI

Before we start, it is important to understand that ElmerGUI is a great tool for those starting with Elmer. However, you will soon find that the core configuration eventually leads back to the .sif file, which we will learn to edit in this post.

Parameters

This step is not mandatory, and you can play with constraints for the parametric design as you wish. However, establishing parameters is a fundamental habit for me. I will draw an E-core with a center length of 70mm and lateral legs of 35mm. In total, the height is 140mm, and the coils are fully fitted within a 35mm window.

1. Create a new document.

2. Switch to the Spreadsheet workbench.

3. Create a New Spreadsheet. You can rename it (by pressing F2) as you like. Mine is named vars.

After filling out the spreadsheet, you should add aliases to the cells. This creates a global variable that is easy to access during the drawing phase. Just right-click on the value cell » Properties » Alias tab, and type the variable name.

The Sketch

1. Switch to the Part Design (or Sketcher) workbench.

2. Create a New Sketch.

3. Select any plane you prefer. You will likely see a window similar to the one below.

After that, draw the model, apply the geometric constraints, and link your spreadsheet variables by clicking the small f(x) icon in the dimension input boxes or just type =.

Generating the Faces (Surface)

With the 2D geometry ready, it’s time to route it to Gmsh. Inside FreeCAD’s FEM workbench, meshing works reliably on solid bodies or faces, not directly on 2D wireframe sketches. Therefore, we must convert our sketch into 2D faces.

• Select your sketch and use tools to generate flat faces. You will need distinct faces for the Air, the Core, and the Coils.

• If you end up with overlapping faces, they must be broken into their own specific, non-overlapping domains.

• This part can be tricky: using the Part workbench, you must select the surfaces (from the outermost to the innermost) and use the Slice Apart (or Boolean Fragments) tool.

Once properly sliced, use the Connect tool to ensure all adjacent faces share the same boundary edges.

Meshing with Gmsh

Now it’s time to mesh the model.

1. Switch to the FEM workbench.

2. Select your Connect (or Fragment) group in the tree view and click FEM mesh from shape by Gmsh.

In the configuration panel, you can choose the element dimension as From Shape or 2D, select 2nd order elements, and define the maximum and minimum mesh sizes based on your design requirements.

If you need to improve the mesh density in specific areas, use the Mesh Refinement tool, select the target surface, and adjust as needed. To apply the changes, double-click the Gmsh object in the tree and hit apply to re-mesh.

Exporting to Elmer

The model must now be exported for Elmer to understand. Select your Gmsh mesh object in the tree, go to File » Export…, and save it as an I-DEAS Universal (.unv) file.

Open ElmerGUI, go to File » Open, select your .unv file, and check the final imported mesh. You should see your named physical groups translated perfectly into Body Properties and Boundary Properties.

Now it’s time to assign the electromagnetic equations, materials, and start the Elmer simulation— but that is a topic for the next post.

The Invisible Knowledge Barrier

I remember the first time I encountered digital control. Programming embedded systems in C seemed much harder than theoretical programming classes. Peripherals, timers, memory allocation… I remember thinking: “I’ll need to study a lot, and there won’t be enough time to learn it all during undergrad.”

This is the classic illusion of the knowledge barrier. When we don’t master a subject, we imagine the learning curve is insurmountable. I was inexperienced and junior.

At the same time, I interned at a university lab where several students shared the same fears. The magic solution they found? “You already know MATLAB and Simulink, why learn C/C++? Use MATLAB Coder! It converts your simulation automatically.”

Long story short: I spent the next three weeks learning how to “tweak” my simulation in Simulink just to make the code generator work. By the end, I had a strange feeling of having worked hard but evolved little. The code worked, but I remained a hostage to the tool.

The C2000 Saga and the Cost of “Tradition”

Still in my naivety, I asked colleagues which controller I should use. The answer was unanimous: Texas Instruments C2000 Series (TMS320F28335).

When, thirsty for information, I timidly asked, “Why not a PIC?” (at the time so famous that Motorola didn’t even worry about the 8-bit market), the answer came recited from the datasheet. The final argument? “It was the processor the professor used in his PhD.”

I was convinced I knew everything. After all, I knew how to use MATLAB.

After graduating, I received my first consulting demand: develop a simple embedded instrumentation system. “Easy,” I thought. “I just need to pull what I’ve already done out of the drawer.” I went to draft the budget for the client:

• Annual MATLAB + Coder License: ~USD 4,500.00 / year.

• TI TMS320F28335 Dev Board: ~USD 100.00.

• Development Hours: Mobilization costs only (since the code “already existed”).

Obviously, the client would never accept that recurring initial cost. National Instruments, for instance, already offered complete solutions cheaper than just the software license I was proposing.

I tried a workaround: I called friends to use their licenses for the preliminary design. Upon trying to open my simulation, MATLAB blocked me—incompatible version. I wasted 4 hours, skipping lunch, waiting for MATLAB and Code Composer Studio to reinstall. I took a deep breath and had a moment of sanity: “It is impossible that this is more efficient than learning to program the hardware for real.”

The Breakthrough: The Arduino Effect and Hardware Choice

Around that time, the Arduino project appeared. Open-source, Atmega328p, costing less than USD 20.00, with a vibrant community. Why not?

Here is where most engineers stumble: Choosing the hardware.

The question is simple, but the answer requires competence: You need to design.

I already had the requirements and the math. That “cheap” processor would solve it. I consulted colleagues and heard: “But the Texas DSP is better, it has feature X, Y, Z…”

True. It is an incredible machine. I would be stupid not to use the Ferrari, right? Wrong.

Let’s use an analogy: You have a Ferrari and an Economy Hatchback. Do you use the Ferrari to buy bread at the corner bakery every day?

It made no technical or economic sense. I refused the advice, wrote the code in C, and delivered the project. Client satisfied, zero license costs. I adopted the Atmega as my standard solution for years.

Real Engineering: The Open-Loop Inverter

Demands increased. I needed to develop a sinusoidal modulator to magnetize a ferromagnetic core. I accepted the challenge: I implemented a 3-level converter (H-bridge) in open loop, manually manipulating registers on the Atmega328p. This was in 2014, during my PhD. Believe it or not, 12 years later, it still works. No licensing, no complicated installations—just editing a few lines of code.

I was fully aware of the hardware limitations. The Atmega physically couldn’t handle the math for closed-loop control. However, solving this was trivial. The next step was obvious: upgrade to a 32-bit MCU with a better clock. It wasn’t a lack of tools that stopped the Arduino; it was just physics. And fixing it was just a matter of choosing the right chip.

(I share the repository for this project at the end of this post for those interested).

Conclusion: The Message for 2026

In the last 12 years, the market has shifted. STMicroelectronics and Espressif Systems have democratized access to high-end hardware.

I no longer see technical sense in keeping complex projects on 8-bits, but I also see no financial sense in maintaining expensive licenses to generate inefficient code. The ESP32 (S and C Series) and STM32 (F and G Series) families offer absurd processing power for a fraction of the cost.

While Espressif dominates IoT communication, STM offers industrial robustness. Today, the best designers—myself included—adopt hybrid solutions. We use the best of both worlds to create real-time systems (HW Timers/RTOS) with IIoT connectivity, without paying a “toll” to simulation software vendors.

Code generators (whether from MATLAB, PLECS, or PSIM) are excellent tools for academic rapid prototyping. But if your company bases its final product on these tools simply because the engineering team “learned it that way in college” and is afraid to code, you are not innovating. You are paying an incompetence tax.

It is time to take the training wheels off.

Get the Source Code on GitHub

The Daisy Chain in Industrial Environments

The Daisy Chain (or Line Topology) is arguably the most elegant solution for covering distances. A single cable carries both communication and power, hopping from one node to the next. This topology drove the success of technologies like RS-485 (Modbus), CAN (DeviceNet), Profibus (Siemens), and EtherCAT.

Fig. 3 - Standard Daisy Chain Topology.

However, in a market flooded with options, the choice isn’t purely technical—it’s strategic. In 90% of cases, engineers lock themselves into a single vendor ecosystem, such as Siemens (Profinet) or Rockwell Automation/Allen-Bradley (EtherNet/IP). While reputable, this creates “Vendor Lock-in.” Any future adaptation requires proprietary hardware, often leading to obsolescence management nightmares.

For this reason, major players are moving towards interoperability. My Golden Rule for new projects is simple: Stay Open, Stay Solid.

Protocols like EtherNet/IP, Modbus, EtherCAT, and CANOpen sustain this rule. Among these, CANOpen shines for its balance of robustness, low cost, and ease of implementation in embedded systems.

But, to use an idiom, it’s not all sunshine and rainbows. The classic Daisy Chain has a fatal flaw: Single Point of Failure. If a cable breaks or a device fails at the beginning of the chain, every downstream device loses communication and power.

Fig. 4 - Illustration of the effect of cable disconnection.

Distributed Power Architecture

This “interruption problem” was solved decades ago in high-availability sectors like Telecom and Data Centers using the concept of Distributed Power Architecture (DPA). Instead of relying on a single massive power supply, they use redundant, parallel modules sharing the load.

Why aren’t we doing this for industrial control power? We should be.

The concept is to move away from a “single point of failure” PSU towards a robust 24V DC Shared Bus. Instead of segregating “AC Control / PSU / Loads,” we leverage the DC bus to create redundancy. Imagine replacing 220VAC contactors with 24VDC components: solenoids, valve islands, sensors, PLCs, and even high-power actuators.

The Advantages of a Redundant DC Architecture:

1. Safety (SELV): According to IEC 60364-4-41, circuits under 60V DC (Ripple-Free) are considered SELV (Safety Extra Low Voltage). This significantly simplifies maintenance procedures and safety requirements compared to working with AC mains voltage.

2. Redundancy (N+1): Multiple PSUs on the bus ensure that if one fails, others pick up the slack without system downtime.

3. Cable Efficiency: Distributing power injection points along the chain reduces voltage drop (IR Drop) issues common in long cables.

However, simply tying PSUs together is dangerous. Without proper isolation, a short circuit in one PSU’s output stage could drag down the entire bus or damage the other units. To do this safely, we need Active OR-ing.

The Solution: Active OR-ing

Fig. 5 - Daisy Chain with Multiple Redundant PSUs.

Paralleling DC power supplies is significantly easier than synchronizing AC generators. It operates similarly to a “battery pack” logic. To do this safely, we use an OR-ing circuit.

While simple diodes could be used, they introduce voltage drops (heat). My recommendation is to use an Active OR-ing Controller, such as the Texas Instruments LM5050-1.

Fig. 6 - LM5050-1 Typical Application Diagram.

This IC controls an external MOSFET to behave like an “ideal diode” with near-zero voltage drop. It automatically disconnects a faulty power supply from the bus, preventing the bus voltage from back-feeding into a shorted PSU. It effectively creates an N+1 redundant power bus where power flows seamlessly even if a source dies.

Note: For complete reverse polarity protection at the input, a “Back-to-Back” MOSFET topology is recommended, but OR-ing handles the critical bus redundancy.

The Protection: Smart eFuses

Fig. 7 - Daisy Chain with Multiple Redundant PSUs and eFuses.

Now that we have a robust power bus, how do we protect the individual loads? Standard glass fuses or Polyfuses in 24V systems are unreliable, slow, and hard to diagnose remotely.

The modern solution is the eFuse (Electronic Fuse). These are intelligent ICs that manage load protection. They are programmable, incredibly fast (<10µs response), and, most importantly, resettable. If a short occurs, the eFuse isolates only that specific load, leaving the rest of the Daisy Chain unaffected. Once the fault is cleared, the system can be reset remotely or automatically.

My component of choice for this architecture is the Maxic MX26631S (or the TI TPS2663x family).

Fig. 8 - MX26631S Typical Application Diagram.

Why the MX26631S?

• 40V Rated: Plenty of headroom for 24V industrial transients.

• High Current: Supports up to 3.5A, covering the majority of sensors and standard actuators for this Proof of Concept.

• Inrush Control: Soft-start capability prevents voltage dips on the bus when turning on capacitive loads.

Conclusion

It no longer makes sense to ignore the benefits of DC-based industrial networks. We don’t need over-complicated systems to start benefiting from available technology.

By combining the simplicity of the Daisy Chain topology with the resilience of Active OR-ing and the precision of eFuses, we transform a simple cable into a smart, redundant power and data backbone. I will continue to advocate for this approach: reducing CAPEX, simplifying maintenance, and ensuring that a single loose wire doesn’t shut down the entire factory.

IDE

During my journey, I’ve tried everything. From Eclipse and Arduino IDE to self-customized editors. By far, PlatformIO is the best solution. Not only for having a large community but also because it is simple, easy to install, lightweight, and best of all: it just works.

Using PlatformIO avoids the need for complex explanations. Starting to code and debug is extremely fast. The only thing I would like to add is that I prefer VSCodium over VSCode, a discussion for another time.

Semihosting

I was scratching some code a few days ago, and I just wanted to print something to the console. Since I was using ST-Link for programming and debugging, I thought it was going to be easy. Unfortunately, after thinking for a while, I realized it is not.

The standard printf function targets the standard output, which usually translates to a physical Serial Port (UART) on microcontrollers. While the ST-Link connects to the device via SWD (Serial Wire Debug) for flashing and controlling the core, it does not automatically forward the UART data to your PC unless you have specific hardware wiring (like connecting the RX/TX pins to a USB-to-TTL converter). Without Semihosting or a Virtual COM Port properly configured, your printf calls are essentially shouting into the void, as the debug probe is strictly listening for debug instructions, not standard I/O streams.

After some reading, I found an awesome document from Valerii Koval at PlatformIOLabs, which explained simply what I was looking for: Semihosting.

(…) convenient way of sending status messages to a debug console on a host machine. This possibility can greatly help to less invasively monitor the behavior of an embedded application without stopping the whole program flow. (…)

The problem

After reading here and there, I took my Bluepill (STM32F103C6T8), plugged in my ST-Link adapter, and tried to replicate it without success. The main reasons were:

• C++

• Arduino Framework I wasn’t capable of finding the answer on my own. Maximilian Gerhardt pointed out the fix. In the end, I’m just the storyteller responsible for putting the information together. Hands-on

You need to configure two files: platformio.ini and extra_script.py.

[env:bluepill_f103c8]
platform = ststm32
board = bluepill_f103c8
framework = arduino
upload_protocol = stlink

upload_flags = -c set CPUTAPID 0            ; Allow Original and Clone STM32 to be detected by OpenOCD debugger.
debug_build_flags = -O0 -ggdb3              ; Apply no optimization to the code written.

build_unflags =
    --specs=nosys.specs 
    -lnosys

extra_scripts = extra_script.py              ; The "extra_script.py" file must be located in the main project folder

debug_extra_cmds =
    monitor arm semihosting enable
    monitor arm semihosting_fileio enable

test_testing_command =
    ${platformio.packages_dir}/tool-openocd/bin/openocd
    -s
    ${platformio.packages_dir}/tool-openocd
    -f
    openocd/scripts/board/stlink.cfg
    -c
    init
    -c
    arm semihosting enable
    -c
    reset run

Import("env")

env.Append(
    # Use the semihosted version of the syscalls
    LINKFLAGS=[
        "-Wl,--whole-archive",
        "-lrdimon_nano",
        "-Wl,--no-whole-archive"
    ],
)

Here is the magic trick. By default, the ARM toolchain uses nosys.specs (no system), which provides empty implementations for system calls like write or read. In platformio.ini, we instruct the build system to remove these default specs (build_unflags) and configure OpenOCD to enable semihosting monitoring.

The extra_script.py handles the linker phase. It forces the application to link against librdimon_nano. This library implements the necessary system calls to forward I/O operations (like printf) from the microcontroller through the debugger probe directly to the host machine’s console.

Now that everything is ready, you just need to call initialise_monitor_handles(void) before the print function.

#include <Arduino.h>
int count = 0;

extern "C" void initialise_monitor_handles(void);

void setup()
{
  initialise_monitor_handles();
  printf("Hello world!\n");
}

void loop() {
  delay(500);
  printf("count = %d\n", count++);
}

The files structure inside PlatformIO is as follow:

$ tree
.
├── extra_script.py
├── platformio.ini
└── src
    └── main.cpp

2 directories, 3 files

Now, you should be able to see the result in the debug console.

Fig. 1 - PlatformIO screenshot with printf output in the debug console.

Conclusion

At first sight, semihosting doesn’t seem that spectacular. However, it simplifies the workflow, mainly in combination with the debug device. Identifying some code condition without stopping the execution is valuable. In the end, doing all that without the need to configure the UART inter

Get the Source Code on GitHub

The Problem: CGNAT and IPv6

The number of connected devices has exploded, forcing ISPs to evolve from IPv4 to IPv6 or drop regular NAT in favor of CGNAT (Carrier-Grade NAT) to withstand the load. Because of this, VPNs are not always end-to-end anymore. Firewall rules also contribute to complicating things a bit more.

Even though I’m not a dedicated network expert, I faced this problem and discovered that a site-to-site connection could solve all these issues once and for all.

Based on this demand, new services like Tailscale arrived. Sure, they are good and easy—just a few clicks solve it. But is that the endgame? If you look at OpenVPN, they created an entire market based on old players that are not able to migrate (yet) to solutions like WireGuard. Soon enough, managed solutions might change their pricing or terms. Thus, I decided to build my own Site-to-Site tutorial using standard tools.

The Architecture

Hands-on

#!/bin/bash
# 1. Your Peer Database (Keep names readable here!)
# Syntax: ["READABLE_NAME"]="SITE_TO_SITE_SUBNET"
# If it is a simple client (like a phone), leave the subnet empty.
declare -A PEERS_DB
PEERS_DB["android"]=""
PEERS_DB["work"]="192.168.2.0/24"
PEERS_DB["home"]="192.168.3.0/24"

# 2. Global Configurations
OUTPUT_FILE="default.env"

echo "# File automatically generated at $(date)" > $OUTPUT_FILE
echo "# WARNING: Peer names sanitized (hyphens removed) for compatibility." >> $OUTPUT_FILE
echo "" >> $OUTPUT_FILE
echo "TIMEZONE=America/Sao_Paulo" >> $OUTPUT_FILE
echo "SERVERURL=mydomain-or-ip.com.br" >> $OUTPUT_FILE # CHANGE THIS
echo "PUID=1000" >> $OUTPUT_FILE
echo "PGID=1000" >> $OUTPUT_FILE
echo "SERVERPORT=51820" >> $OUTPUT_FILE
echo "PEERDNS=auto" >> $OUTPUT_FILE
echo "ALLOWEDIPS=0.0.0.0/0" >> $OUTPUT_FILE
echo "INTERNAL_SUBNET=10.22.22.0" >> $OUTPUT_FILE
echo "PERSISTENTKEEPALIVE_PEERS=all" >> $OUTPUT_FILE
echo "" >> $OUTPUT_FILE

# 3. Generation and Sanitization Logic
PEER_LIST=""
echo "# Routing Rules and Peers" >> $OUTPUT_FILE

for PEER in "${!PEERS_DB[@]}"; do
    # Remove special chars for safety
    SAFE_PEER=$(echo "$PEER" | sed 's/[^a-zA-Z0-9]//g')
    PEER_LIST+="$SAFE_PEER,"
    SUBNET="${PEERS_DB[$PEER]}"

    if [ ! -z "$SUBNET" ]; then
        echo "SERVER_ALLOWEDIPS_PEER_$SAFE_PEER=$SUBNET" >> $OUTPUT_FILE
    fi
done

PEER_LIST=${PEER_LIST%,}
echo "PEERS=$PEER_LIST" >> $OUTPUT_FILE

echo "File $OUTPUT_FILE generated successfully!"

$ ./generate_env.sh

# Arquivo gerado automaticamente em Sat Dec 20 01:39:31 UTC 2025
# ATENCAO: Os nomes dos peers foram sanitizados (hifens removidos) para compatibilidade.

TIMEZONE=America/Sao_Paulo
SERVERURL=mydomain-or-ip.com.br
PUID=1000
PGID=1000
SERVERPORT=51820
PEERDNS=auto
ALLOWEDIPS=0.0.0.0/0
INTERNAL_SUBNET=10.22.22.0
PERSISTENTKEEPALIVE_PEERS=all

# Regras de Roteamento e Peers
SERVER_ALLOWEDIPS_PEER_work=192.168.3.0/24
SERVER_ALLOWEDIPS_PEER_home=192.168.2.0/24
PEERS=android,work,home

$ ./generate_env.sh

services:
  wireguard:
    image: linuxserver/wireguard
    container_name: wireguard-server
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    env_file:
      - default.env
    volumes:
      - ./config:/config
      - /usr/src:/usr/src # location of kernel headers
      - /lib/modules:/lib/modules
    ports:
      - 51820:51820/udp
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv4.ip_forward=1
      - net.ipv6.conf.all.disable_ipv6=1
      - net.ipv6.conf.default.disable_ipv6=1
    restart: unless-stopped
    networks:
      default:
        ipv4_address: 172.70.0.2

networks:
  default:
    driver: bridge
    ipam:
      config:
        - subnet: 172.70.0.0/24
          gateway: 172.70.0.1

$ docker compose up -d

$ docker compose up -d

[Interface]
# Masquerade traffic leaving the VPN interface and add route to remote subnet
PostUp = iptables -t nat -A POSTROUTING -o eth+ -j MASQUERADE && ip route add 192.168.2.0/24 via 172.70.0.1
PreDown = iptables -t nat -D POSTROUTING -o eth+ -j MASQUERADE && ip route del 192.168.2.0/24 via 172.70.0.1
Address = 10.222.222.3
PrivateKey = <super_secret_hash>
ListenPort = 51820
DNS = 10.222.222.1

[Peer]
PersistentKeepalive = 15
PublicKey = <super_secret_hash>
PresharedKey = <super_secret_hash>
Endpoint = mydomain-or-ip.com.br:51820
AllowedIPs = 0.0.0.0/0

services:
  wireguard:
    image: linuxserver/wireguard
    container_name: wireguard-client
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/Sao_Paulo
    volumes:
      - ./config:/config
      - /usr/src:/usr/src # location of kernel headers
      - /lib/modules:/lib/modules
    logging:
      options:
        max-size: "100m"
        max-file: "3"
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped
    networks:
      default:
        ipv4_address: 172.70.0.2   # <-- Update

networks:
  default:
    driver: bridge
    ipam:
      config:
        - subnet: 172.70.0.0/24
          gateway: 172.70.0.1

Conclusion

At first glance, networking can be scary—believe me, I was there. But after some time, things start to make sense. This setup bypasses CGNAT and complex firewall rules using standard, open-source tools. I hope this guide helps you reclaim control over your networks!

Source Code & Scripts

To make this setup easier, I’ve organized all the scripts mentioned in this guide (environment generation, route injection, and client packaging) into a public repository.

You can clone it and start your own VPN gateway in minutes:

Get the Source Code on GitHub