High-power consumers like GPS, the LoRa module, and the SD card reader are completely off by default. They’re behind voltage regulators (LDOs) that are controlled by the XL9555 I/O expander chip on the I2C bus.

To handle this cleanly, I wrote a dedicated PowerManager class. During the boot sequence, this manager initializes the I2C bus, connects to the I/O expander, and configures the appropriate pins as outputs.

I’ve written specific functions to turn different sections of the board on and off. For initial boot, I’ve programmed it to turn on the LDOs for the GPS and LoRa modules so they can wake up. I’ve also added a function to turn the reset pin on the OLED display off and on, allowing it to perform a hard hardware reset.

for more in info you can se full chnge log link

firmwaRE build 3

ESP32-S3 has two cores
and I want to take full advantage of this so the device doesn’t lag. I’ve set up a FreeRTOS structure in the main file. I’ve placed all communication tasks (like listening for LoRa packets and parsing GPS data) on Core 0. Then, I’ve placed UI tasks (rendering the OLED screen and reading buttons) on Core 1. This means that even if the GPS is processing a lot of data, the screen will never freeze.

example connection for basic understanding

For screen navigation, I’ve created a state machine (FSM). This is essentially a map of all the menus on the device, such as the boot logo, main dashboard, LoRa settings menu, and GPS view.

To switch between these screens, I’ve integrated the OneButton library.

Lora signal transmission ways

firmware build 2

Because the schematics and hardware is done.
I can create the entire core architecture right away. This way, when the boards arrive(i dont know when may bbe before stardance), I’ll only be testing and debugging, not writing code from scratch.

I’m using an ESP32-S3 module (specifically, the WROOM-1U-N16R8), which has 16MB of Flash and 8MB of PSRAM. The standard Arduino IDE wouldn’t work for such a complex project, so I set up a PlatformIO project in VS Code. I first configured the platformio.ini file to ensure the compiler knew how to use the extra memory.

Next, I created a hardware abstraction layer (HAL). Instead of randomly typing pin numbers throughout the code, I went through my schematics page by page and mapped each connection in the hal_pins.h file. I recorded the SPI pins, I2C bus, LoRa and GPS connections, I2S audio pins, and physical buttons.

I also mapped I2C addresses for all the chips on the board and specific ports on the XL9555 I/O expander. Having a single file as the “source of truth” for the hardware makes things much easier to manage.

firmware build 1

feat: add terminal boot sequence, main menu, and LoRa sniffer

• Implemented animated terminal boot sequence for UI feedback.
• Added interactive navigation menu for system modules.
• Integrated LoRa sniffer functionality for packet monitoring.
• Configured hardware abstraction layer

I’m finally done with my PCB design.

I ran the Design Rule Check (DRC) in the software. It scans the entire board, looking for small shorts, too-close copper lines, or missing connections that I wouldn’t be able to see with my eyes. After fixing some minor spacing warnings, the board passed without any problems.

This is the white text printed on the top of the board. I looked at the entire layout and removed all the part numbers (like R1, C4, U2) so they were clearly visible. If you leave the text directly under the chips, you won’t be able to see the labels later when you try to solder the parts together by hand.

From the next devlog we will work on the firmware add UI

Let’s move on to the final radio in the system.
I need to route the ST25R3916 NFC controller so that Cirrus can share data via physical tap.

Instead of building a large copper coil directly on the board, I decided to use an external NFC antenna. This saved a lot of space on the PCB and allowed me to fit the flexible antenna perfectly inside the final plastic case.

Here’s how I routed the connection from the chip to the external connector.
for this antenna

Between the ST25R3916 and the connector, I need to install a special network of capacitors and inductors. This is the matching circuit. I placed these small components very close to the chip’s output pins. I made the traces connecting them as short and thick as possible to minimize power loss before the signal leaves the board.

This completes the RF routing phase. The LoRa, GPS, and NFC modules are completely connected.

Like the LoRa module, I placed the MAX-M10S-00B and its metal U.FL connector on the bottom layer of the board.

I routed the LoRa radio. Now I need to route the second radio to the on board GPS.

GPS signals coming from satellites are incredibly attenuated by the time they reach the ground. If there is any electrical noise on board, the MAX-M10S-00B chip will not be able to hear satellites at all. I have to protect its antenna trace at all costs.

digital data wire

The MAX-M10S-00B sends its location data to the ESP32-S3 using two simple UART wires (TX and RX).

I routed these digital wires on the bottom layer, and pulled them completely away from the antenna area. Once they were far enough away from the sensitive analog section, I dropped the vias to get them up to the top layer, and connected them cleanly to the main processor.

I made the antenna trace as short and straight as possible. I made sure there were no sharp 90-degree corners, as sharp corners can cause radio frequencies to leak out the edges.

Once the thick 50-ohm line was created, I created a shield around it. I placed a tight line of ground vias on the left side of the trace and another tight line on the right side. This creates a physical tunnel of copper inside the board. This traps the LoRa signal inside the tunnel and prevents any outside electrical noise from entering.

this is the Impedance Calculator i used for this design link

E22-900M22S LoRa module.

If I mess this up, our miles of range will drop to a few feet. i am pretty scared .
i read like 10 rf design doc to make my design.

dude, this video is by Zachariah Peterson, who understands RF design very well. I like it very much. If you are also interested in hardware, then you can watch this video. video like

The copper line connecting the E22-900M22S to the metal SMA/U.Fl antenna connector isn’t just a normal wire. It acts as a pipe for radio waves.

If this pipe is the wrong size, radio waves will hit the antenna, bounce off the chip, and turn into heat instead of being broadcast into the air. To prevent this reflection, the trace’s impedance must be exactly 50 ohms.

These are switching regulators. They manage voltage by turning it on and off very quickly. This rapid switching creates a hot loop of loud electrical noise. If the copper lines connecting these chips are very long, they act like tiny radio antennas and broadcast that noise directly to the GPS and LoRa modules.

not exactly but look this img

Now, I need to take that clean 3.3V power and distribute it to the most power-intensive parts of the board: the radios and local storage.

This is where the RT9080(if you remember i ues 3 of them in my schematic) power switches come in handy. I use them to completely cut off power to the radios when they’re not in use. I’ve routed them as follows.

I didn’t group all the RT9080 switches together. Instead, I placed each switch next to the module it controls.( you can see in img , blue component is RT9080 LDO)

I am starting PCB design development.

With all the parts placed and the 4-layer structure locked in, it is time to start drawing the actual copper connections .

I started with the main power chips: the BQ25896 USB charger, the BQ25570 solar harvester, and the SY8089 buck converter.

These are switching regulators. They manage voltage by turning on and off incredibly fast.

Finally, check before moving to next steps.

• DRC rules complete
• Track rules complete
• Carrier plane for all layers complete
  Layer Stackup: A 4-layer PCB is strictly required.
• Layer 1: Signals
• Layer 2: Solid GND Plane (Do not route traces here)
• Layer 3: Power Plane (VDD3V3, VBAT, VSYS)
• Layer 4: Signals
  Impedance Matching: The traces connecting the ESP32, LoRa module, and GPS module to their respective U.FL connectors must be calculated to exactly 50 ohms based on your manufacturer’s specific prepreg thickness.
  Antenna Placement: Ensure no copper exists on any of the 4 layers directly beneath the U.FL connectors or the NFC antenna header

Setting the Design Rules

I set up trace widths for data, thick lines for power, and the minimum spacing (clearance) so the factory does not accidentally melt traces together.

Via at: Tools > Design Rule…, or Via: right-click the canvas - Design Rule… to open the Design Rule setting dialog:

The unit follow the canvas unit.

• Rule: The default rule named “Default”, you can add the new rule you can rename and set parameters for it. Each net can be set a rule.

• Track Width: Current rule’s track width. The PCB track width can not less than this value.

• Clearance: The clearance of different objects which have different net. The clearance of the PCB can not less than this value.

• Via Diameter: The via diameter of current rule. The via diameter of the PCB can not less than this value. Such as the Hole/Multi-layer Pad’s diameter.

• Via Drill Diameter: The via drill diameter of current rule. The via drill diameter of the PCB can not less than this value.

• Track Length: All track length of current rule. The length of tracks belong to a same net should not be longer than this value.Including the arc lenghth. When the input box is empty the length will be unlimited.

There is too much going on, and the electrical noise would ruin the radio signals.

I have to use a 4-layer PCB.

Here is exactly how I am setting up the stack-up to keep the board clean.

• Layer 1: The Top Signal Layer ; This is the top surface where the ESP32-S3 brain and the screen connector sit. I will use this layer to route the most critical and fast data lines, like the SPI bus for the screen and the I2S audio lines.

• Layer 2: The Solid Ground Plane; Right beneath the top layer is Layer 2. I am making this solid sheet of ground copper.

• Layer 3: The Power Distribution Plane; Moving down, Layer 3 is dedicated to power

• Layer 4: Low-Speed Routing ( mainly for the signle lines

The schematic is completely finished.
Every wire is drawn and every connection is checked. Now, I have to convert all those digital lines intoPCB design. This means starting the actual PCB layout.

I always start with the parts that connect to the outside world, because they have to be in exact physical locations.

• I locked the USB-C port to the top edge. Right below it, I placed the battery connector.

• I placed the LoRa module and the GPS module underneath.

• I also placed the metal SMA/UFL antenna connectors right on the edge next to them.

the DRV2605LDGSR. I downloaded a public symbol to save time, but the software started throwing errors immediately.

The pin connections on the screen did not match the physical metal pads on the real chip. If I had trusted that public file and sent the board to the factory, the chip would have shorted out and the board would be dead.

To fix this, I had to throw the public file away. I pulled up the official datasheet for the chip and rebuilt the entire footprint completely from scratch. I drew every single pad by hand to make sure it was perfect.

Drawing the 30-Pin Screen Connector
Because of that error, I decided I could not trust the public files for our OLED screen either. I sat down and built a custom footprint for the 30-pin FPC connector.

Drawing this is very stressful. You have to place 30 tiny metal rectangles right next to each other. The gap between them is almost invisible. If you make a pad just a fraction of a millimeter too wide, the melted solder will bridge across the pins during manufacturing, and the screen will not work. I spent a long time checking the official measurements to get the exact spacing right.

In the last few parts, we built our communications array. Cyrus can now talk over the LoRa radio, find satellites, and share files using NFC.

We need to give our pager a way to record voice messages or listen for audio triggers. To do this, I am adding the INMP441 digital microphone

The INMP441 is much smarter. It is a fully digital microphone. It translates the sound into ones and zeros right inside the microphone itself. This saves a massive amount of space on our board and makes the sound much cleaner because it does not pick up electrical noise from other chips.

Wiring the Sound Wires (I2S)
For this, the ESP32-S3 uses a special connection made just for audio, called I2S.
Here is how I am wiring the INMP441 directly to the ESP32-S3:

• Power: I am connecting it to our clean 3.3V main power line.

• SCK (Serial Clock): This keeps the digital sound data perfectly in time so it does not skip.

• WS (Word Select): This tells the main brain if the sound is meant to be the left channel or the right channel.

• SD (Serial Data): This is the main wire that carries the actual voice recording into the ESP32-S3.

• L/R (Left/Right Select): Because we only have one microphone, I am wiring this pin straight to ground. This locks the microphone to the “left” channel, which is all we need to record a clear voice.

MicroSD Card

We need a massive memory bank to save everything locally.

We already have the LoRa radio and the NFC chip using our fast SPI wires. You might wonder if adding a third thing will cause a traffic jam.

Thankfully, SPI is designed to be shared. I am connecting the MicroSD card to the exact same clock and data wires as our radios.

To stop them from talking over each other, I just need to add one unique wire. It is called the Chip Select (CS) wire. I am connecting this from the SD card straight to the ESP32-S3. Now, when the main brain wants to save a file, it pulls this specific wire. The radios ignore the traffic, and the SD card knows it is time to write the data.

MicroSD cards are notorious for draining batteries

To solve this problem, the SD card isn’t connected directly to the main 3.3V power line. Instead, it receives power entirely from one of the dedicated RT9080 power switches I previously installed in the power architecture.

Originally, my plan was to use a massive 50-pin LCD screen. But as I looked at the power numbers, I changed my mind.

An LCD screen needs a bright backlight running all the time, which eats a lot of battery. A 50-pin connection also takes up way too much space on our small board.

Instead, I am using a 30-pin FPC connector to drive an OLED display.

OLED is perfect for an off-grid device. It does not have a backlight. Every single dot (pixel) on the screen makes its own light. If the background of our menu is black, those black pixels are completely turned off and use absolutely zero power. This will save our battery tremendously.

I finally added the u-blox Mia-U10.

Originally, my plan was to use a very tiny GPS chip called a SiP (System-in-Package). A SiP is basically an entire circuit stuffed into one microscopic block. It is great for saving space, but it has a huge problem: the connection pads are hidden completely underneath the chip and are incredibly close together.
as you see in img

To save my sanity during the soldering phase, I changed my mind. I am now using the MAX-M10S-00B.

This chip still uses the same amazing, low-power U-blox brain to find satellites, but it comes in a slightly larger package with visible metal pads on the outside edges. It is much easier to solder to the board by hand without making mistakes.

Wiring the MAX-M10S-00B

• Just like our LoRa radio, the GPS uses a lot of battery. So, I am wiring its main power line to one of our RT9080 smart switches

• the GPS uses a simple two-wire connection called UART. There is a TX wire (Transmit) and an RX wire (Receive). When the GPS is on, it constantly sends plain text updates down these wires, telling the ESP32-S3 its exact coordinates.

Today, i am wiring up our main long-range communications module, the E22-900M22S.

This specific LoRa module is incredible. It is designed to send small packets of data (like text messages or GPS coordinates) over very long distances—sometimes miles—even if there are trees or buildings in the way. It does this while using a surprisingly small amount of battery.

Wiring the Data line (SPI)

• To make the radio work, the ESP32-S3 needs a very fast way to send data to it. We are using a connection called SPI.

I am drawing four specific wires between the ESP32-S3 and the E22-900M22S:

• SCK (Clock): This wire acts like a metronome. It keeps the ESP32-S3 and the radio perfectly in sync so they do not scramble the data.

• MOSI (Master Out): This is the wire where the ESP32-S3 sends the actual text message out to the radio.

• MISO (Master In): This is the wire where the radio sends information back to the main brain, like confirming a message was sent.

• CS (Chip Select): This is the “attention” wire. The ESP32-S3 uses this wire to tell the radio be like , “I am talking to you MF , listen closely.”

Sending messages is easy, but receiving messages is tricky.

When a new message arrives from the sky, the ESP32-S3 might be doing something else, or it might be completely asleep to save battery. The ESP32-S3 cannot stare at the radio all day waiting for a message.

To fix this, the E22-900M22S has special pins called DIO pins. I am wiring one of these DIO pins directly to a native pin on the ESP32-S3.

Because Cyrus is an off-grid device,
we are going to turn off the main ESP32-S3 chip as often as possible to save battery.
But when the ESP32-S3 goes to sleep, it loses track of exact time. When it wakes up, it won’t know if five minutes have passed or five hours.

To fix this, we are adding a dedicated clock that never sleeps: the PCF85063 Real-Time Clock (RTC).

I am wiring the power pin of the PCF85063 directly to that solar harvester output. This means the clock will run 24/7 on tiny amounts of harvested sunlight, completely bypassing our main battery reserves(it will use at night ).

Wiring the RTC

• The Crystal: A clock chip needs a heartbeat to tick. I am wiring a small 32.768 kHz crystal oscillator to the PCF85063.

• Load Capacitors: The crystal cannot work alone. It needs two very small ceramic capacitors connected to the ground.

• The I2C Bus: Just like our other smart chips, the PCF85063 connects to the exact same I2C bus (the SDA and SCL wires). The ESP32-S3 uses this bus to set the current time.

I solve one problem and another one is coming but it is good, I have a solution for it.

we added smart switches (the RT9080 LDOs) to turn our heavy power users on and off. But this created a new problem.

Our main brain, the ESP32-S3, needs to control those switches. It also needs to talk to the screen, read the buttons, play audio, and manage the radios. The ESP32-S3 is powerful, but it simply does not have enough physical pins for all of this. We have run out of connections.

The XL9555 is an I/O Expander(cheap copy of TCA9555);-

It uses our main I2C bus. This means it only takes up two pins on the ESP32-S3 (the SDA and SCL wires). In exchange for those two pins, the XL9555 gives us 16 brand new, fully working pins that we can control.

Adding this to our schematic is very clean and simple:

• Power: I am connecting the XL9555 to our rock-solid 3.3V main power line that we built back in Part 4.

• The I2C Connection: I am routing the SDA and SCL pins to the exact same I2C bus that our battery charger uses. The ESP32-S3 will use this single bus to talk to almost every smart chip on the board.

• The New Pins (The Outputs): Here is where the magic happens. Remember the “Enable” pins on the RT9080 LDOs from our last devlog? I am wiring those straight into the XL9555.

Here is how I am building this in LDO sys

• One LDO per Module: I am not sharing power. I put one RT9080 right next to the E22-900M22S LoRa module. I put another RT9080 next to the U-blox MIA-M10 GPS module. I put a third one next to the SD Card slot.

• Connecting the Enable Pin: I am wiring the Enable pin of each RT9080 so our main system can control it or turn it on and off.
  

How it Works
When the ESP32-S3 needs to send a message, it turns on the LDO for the E22-900M22S. The LoRa module wakes up, does its job, and goes back to sleep. Then, the ESP32-S3 turns the LDO completely off.

When the LDO is off, the E22-900M22S uses zero battery.

This method is called power gating. It is the best way to make sure our battery lasts as long as possible out in the field.

We now have a massive, highly efficient 3.3V pipeline ready to power the heavy lifters of the system.
But we have a new problem: our LoRa, GPS, and SD card modules are power-hungry, and we don’t want them drinking from the 3.3V main rail when they aren’t actively being used.

deploy strict power gating. I will show you how I am using dedicated RT9080 LDOs to create isolated, individually switchable power lines for our RF subsystems, ensuring they draw zero power until the ESP32-S3 explicitly calls upon them.

The E22-900M22S is a powerful radio. When it sends a message, it pulls a lot of energy. If we leave it and the other modules on all the time, our battery will drain very fast. Because this device lives off the grid, we need a way to completely turn them off when we are not using them.

Some parts of our board use a lot of power. This includes our main radio, the E22-900M22S LoRa module, the GPS module (U-blox MIA-M10), and the SD Card.

to fix this We are using the RT9080 as a smart switch. It takes power from our main battery line and passes it safely to our modules. But the most important part is the “Enable” pin.

We now have dual power inputs: USB fast-charging and solar micro-harvesting. But the ESP32-S3 and the rest of our logic chips run strictly on 3.3V, and they need a lot more current than the harvester’s nano-buck can provide.

now i am going to build the main power sys. I will walk through the schematic for the SY8089 buck converter and show how I’m setting up the central 3.3V supply that will drive the heavy-lifting core of Project Cyrus.

our main power line (VSYS) is floating anywhere between 3.0V (a nearly dead battery) up to around 5V (USB power). The ESP32-S3 and the vast majority of our logic chips run strictly on 3.3V. If we feed them VSYS directly, they will fry.

we have two options here buck converter and LDO (Low dropout regulators ).

A lot of simple dev boards use Low-Dropout Regulators (LDOs) to step 5V down to 3.3V. But LDOs bleed off the excess voltage as pure heat. If the ESP32-S3 pulls 500mA during a Wi-Fi transmission, an LDO would act like a tiny space heater.

heat is the enemy of efficiency and battery life.

The SY8089 is a high-efficiency, synchronous step-down switching regulator. Instead of burning off the excess voltage, it rapidly switches on and off, using an inductor to store and release energy. This means we get our 3.3V rail with over 90% efficiency, keeping the board cool and squeezing every last drop of current out of the battery.

Solar Harvesting

Standard chargers are terrible at handling small solar panels. If a cloud passes over, the voltage drops, the charger pulls too much current, the panel collapses to zero volts, and charging stops completely. (reference example )

The BQ25570 solves this with built-in Maximum Power Point Tracking (MPPT). It actively monitors the solar panel and dynamically adjusts how much current it pulls to keep the panel operating at its absolute peak efficiency, even in low light. Plus, it has an ultra-low quiescent current, meaning the IC itself consumes almost zero power while it works, a sudden voltage drop that shuts off the system mid-transmission is catastrophic nightmare.

The “RGRR” variant of the BQ25570 has a massive trick up its sleeve: an integrated nano-power buck converter.
Instead of just charging the battery, it can simultaneously step that battery voltage down to a highly efficient, regulated output. I am configuring this internal buck to output a steady voltage specifically to keep our always-on components alive—like the PCF85063 RTC—ensuring they draw practically nothing from the main battery reserves when the rest of the system is asleep.

Wiring the BQ27220:-

• BQ27220 relies on a precision sense resistor placed in series with the battery pack. I am wiring the IC’s sense pins directly across a low-ohmic shunt resistor.

I2C Control for Smart Charging

One of the main reasons I selected the BQ25896 is its I2C interface. I am routing its SDA and SCL lines straight to the primary I2C bus.

This is a massive advantage. It means the ESP32-S3 isn’t just relying on hardware defaults; it can actively talk to the charger. We can dynamically adjust the input current limit, change the fast-charge current on the fly, or read fault registers if something goes wrong.

Even though we are just in the schematic phase, you have to think about the physical PCB. The BQ25896 is going to handle a fair amount of current, which means heat. I am making specific notes on the schematic to remind myself to drop a solid array of thermal vias directly under the IC’s exposed pad when we move to the 4-layer layout later.

We have power entering the system and a battery charging safely. But an off-grid terminal is useless if it suddenly dies without warning.

I chose the BQ25896 because it is a highly integrated switch-mode battery charge management IC. It doesn’t just blindly dump current into a lithium cell; it actively manages the power path. This means it dynamically routes power between the USB input, the battery, and the rest of the system. (this is example from same series)

I am pulling power in through a standard USB-C receptacle. The first schematic step is handling the CC1 and CC2 pins with 5.1kΩ pull-down resistors. This is mandatory to ensure upstream power sources actually recognize Cyrus as a sink device and provide that 5V VBUS.

Once VBUS is established, it routes directly into the star of this subsystem: the BQ25896.

Here is how I am configuring the BQ25896

• VBUS Input: Tied directly to the USB-C 5V line with decoupling capacitors
• Battery Terminals (BAT): Routed to our battery connector. I am also wiring in the required NTC thermistor line so the charger can monitor battery temperature and cut off if things get dangerously hot in an off-grid environment.

The Master Bill of Materials (BOM)

Before wiring a single pin, I’ve spent hours agonizing over this component selection to balance power efficiency with performance.

Here is the exact silicon that will power Project Cyrus:

Power Management & Regulation

• BQ25896 (Charger): Manages the 5V USB-C input and the primary system voltage (VSYS).
  

• BQ27220 (Fuel Gauge): Provides precise, real-time battery health and capacity analytics.
  

• SY8089 (Buck Converter): Steps down VSYS to create our stable, central 3.3V main rail.
  

• RT9080 (LDOs): Dedicated low-dropout regulators to provide isolated, strictly power-gated lines to our RF and data subsystems.

Core Compute & Expansion

• ESP32-S3: The main microcontroller.

• XL9555 (I2C IO Expander): Offloads enable pins and secondary controls to free up the ESP32-S3’s native GPIOs.

• PCF85063 (RTC): Dedicated real-time clock to ensure accurate timekeeping and wake triggers while the main processor is in deep sleep.

RF & Communications

• HPB1683 (LoRa): The off-grid backbone, interfacing via SPI for long-range data.

• U-blox MIA-M10 (GPS): Ultra-low-power location tracking module via UART.
  

• ST25R3916 (NFC/RFID): Handles near-field data exchange and secure, close-range handshakes.

center of this build is the ESP32-S3

I needed a microcontroller with enough raw dual-core processing power to handle audio pipelines and RF encryption, but the real deciding factor was the routing flexibility. Between the SPI bus for the LoRa module, UART for the GPS, I2C for the sensors, and I2S for the audio codec, the ESP32-S3 allows me to matrix these interfaces exactly how I need them for a tight layout.

However, even the S3 has its limits.
Because we are relying on internal memory to save layout space, and with the sheer number of peripherals we are driving, we completely run out of native GPIOs. We’ll be solving that with a dedicated expansion layer later on.

I am keeping the workspace clean. I pull my few symbols and footprints strictly from SnapEDA (https://www.snapeda.com/parts/CN3791/Consonance/datasheet/) to ensure professional-grade accuracy, and I completely avoid pulling from SamacSys or Ultra Librarian. The goal is to maintain absolute control over the pad sizes and 3D models before we even think about routing the bottom-mounted SMA connectors.

my goal here is to build an off-grid communication terminal that doesn’t rely on traditional cellular networks, can survive completely off the grid, and packs a massive amount of functionality into a very tight form factor.

When I first sat down to map out Cyrus,
I knew exactly what it needed to do, but dont know figuring out how to fit it all together was the real challenge.
An off-grid communicator is useless if it dies in a few hours or can’t handle multiple data streams at once.

Here is what the architecture needs to support

• Long-Range Comms
• geo location
• Energy Independenc
• Environmental sensing
• main MCU The ESP32-S3

Finally the PCB is complete, everything is fine, zero DRC errors

With the routing complete, I ran the final Design Rule Check (DRC). Unlike the logical ERC run during the schematic phase, the DRC checks the physical manufacturing constraints. It verifies that no copper traces are too close together, that vias are the correct drill size, and that components do not physically overlap. The DRC returned zero errors, confirming the board was physically viable.

I didn’t want to drag out the PCB design too much, so I’m developing it all in one go.

80% of the routing is now complete, just a few things left like DRC checks and some cleanup for the trace

I configured a strict 4-Layer Stackup:

Layer 1 (Top Layer): Component placement and high-speed signal routing (USB differential pairs,QSPI memory lines).

Layer 2 (Inner Layer 1 - Ground Plane): A continuous, unbroken copper pour dedicated entirely to GND. This provides an immediate, low-impedance return path for every high-speed signal on Layer 1, strictly controlling trace impedance and minimizing EMI.

Layer 3 (Inner Layer 2 - Power Plane): A split copper pour handling the bulk power distribution Utilizing a plane instead of thin traces ensures stable power delivery under transient loads without starving the microcontrollers.

Layer 4 (Bottom Layer): Slower, low-priority signal routing (GPIO breakouts, LED traces, I2C) and debugging headers.

With the footprints verified, the logic checked, and the 4-layer physical foundation established, the architecture phase of the Lemon Pi is officially closed. The next engineering challenge is the physical puzzle: placing the components, respecting the galvanic isolation gap, and routing the high-speed copper.

schematic completed yeahhhhhhhhhh

By this point in the design process, every major functional block was successfully integrated into the schematic. The power delivery, memory, isolation, automotive, wireless, and vision systems were all logically wired.

When initially laying out a high-pin-count microcontroller like the RP2350B, it is common to break out every pin with generic labels (e.g., GP0 through GP47). While this prevents accidental pin overlap during layout, it is practically useless during firmware development. If a developer looks at the schematic six months later to write a camera driver, seeing GP15 tells them nothing.

To ensure the schematic was self-documenting, I refactored the generic GPIO labels into strict functional labels across the entire sheet.

• Generic SPI pins became WIFI_SCLK, WIFI_TX, WIFI_RX, and WIFI_CS.

• Generic parallel pins became CAM_D0 through CAM_D7.

• The CAN interface was explicitly tagged as CAN_TX and CAN_RX.

here are the final list of component;-

• Main MCU: Raspberry Pi RP2350B (QFN-80)

• Primary Storage: W25Q128JVSIQ (16MB QSPI Flash)

• Buffer Memory: APS1604M-3SQR-SN (8MB QSPI PSRAM)

• Debugger MCU: Raspberry Pi RP2040 (QFN-56)

• Debugger Storage: W25Q16JVUXIQ (2MB QSPI Flash)

• Digital Isolator: Analog Devices ADuM3160

• Isolated Power: Mornsun B0505S-1WR3 (5V-to-5V DC-DC)

• USB Hub Controller: Microchip USB2512B (2-Port)

• ESD Protection: TPD4S012 (Data line clamping)

• Main Logic Power: AP2112K-3.3 (3.3V LDO for MCUs and ICs)

• Camera Core Power: AP2112K-1.5 (Dedicated 1.5V LDO for OV5640)

• MCU Core Power: Internal RP2350 SMPS (Driven by 2.2µH Inductor)

Hardware SWD Misconception

A common routing mistake when implementing an onboard programmer is attempting to connect the physical SWCLK and SWDIO pins of the debugger MCU directly to the SWCLK and SWDIO pins of the target MCU.(I did the same thing many times lol )

During the schematic layout, I had to ensure this did not happen. The dedicated hardware SWD pins on the RP2040 (Pins 24 and 25) are strictly input pins meant for debugging the RP2040 itself. If I wired those to the RP2350, both chips would simply wait for an external host to provide a clock signal, resulting in a dead bus.

Routing the Picoprobe Interface

Instead of using hardware SWD peripherals, the Picoprobe firmware utilizes the RP2040’s Programmable I/O (PIO) blocks to “bit-bang” the SWD protocol out of standard general-purpose I/O pins.

To implement this, I established a dedicated 3-wire control bus between the two microcontrollers:

1. SWCLK_TARGET: Routed from RP2040 GPIO2 to RP2350 SWCLK. This provides the synchronization clock for the debug data.

2. SWDIO_TARGET: Routed from RP2040 GPIO3 to RP2350 SWDIO. This handles the bidirectional data transfer.

3. RP2350_RUN: Routed from RP2040 GPIO4 to the RP2350 RUN pin.

The third line (RP2350_RUN) is a critical addition for a reliable development cycle. By giving the RP2040 physical control over the RP2350’s hardware reset pin, the host PC can issue a command via OpenOCD to automatically halt and reset the target MCU immediately before and after flashing a new binary.

after the USB data was safely crossing into the board’s internal circuitry.
However, that single USB line now needed to communicate with both the RP2350 core and the RP2040 debugger simultaneously.
To multiplex this connection, I implemented a dedicated, embedded USB hub on the PCB using the Microchip USB2512B, a highly reliable 2-port USB 2.0 hub controller.

Routing the Upstream and Downstream Ports

The physical routing for the data lines was straightforward but required strict impedance control.

1. Upstream: The differential data lines exiting the ADuM3160 digital isolator were routed directly into the USBDP_UP and USBDM_UP (Upstream) pins of the USB2512B.

2. Downstream Port 1: Routed to the dedicated USB PHY pins on the main RP2350B.

3. Downstream Port 2: Routed to the dedicated USB PHY pins on the RP2040 Picoprobe.

To drive the internal PLLs required for USB 2.0 timing synchronization, I added a dedicated 24MHz crystal oscillator (X2) with 22pF load capacitors specifically for the hub controller.

The USB2512B is a highly programmable IC. In a complex commercial product, you might connect its SDA and SCL pins to a master microcontroller to write custom OEM descriptors or power profiles into the hub via SMBus/I2C.

Likewise, because our downstream devices (the two microcontrollers) are permanently soldered to the board and powered by the main 3.3V LDO, the hub does not need to switch physical port power on and off. Therefore, the Port Power Control (PRTPWR1, PRTPWR21) output pins were also left safely floating.

ADuM3160

Power is only half the equation; the USB data lines (D+ and D-) also require physical separation. Passing high-speed differential signals across an isolation gap requires specialized silicon.

I utilized the Analog Devices ADuM3160 full/low-speed USB digital isolator. Instead of optical isolation, this chip uses internal micro-transformers to pass the USB signals magnetically. The upstream side of the chip is powered by the raw USB VBUS and GND_USB, while the downstream side is powered by our isolated +5V_ISO and board GND. This guarantees that even if a catastrophic voltage spike hits the CAN transceiver and shifts the board’s entire ground plane, the energy cannot propagate backward into the host PC’s USB controller.

During the final schematic review of the isolation gap, I identified a critical layout oversight that would have bypassed the entire isolation barrier.

A standard USB Type-C receptacle requires two 5.1kΩ pull-down resistors on the CC1 and CC2 pins to signal the host PC to provide 5V power. In the initial layout, I routed these pull-down resistors to the main board GND.

B0505S-1WR3

First, I had to isolate the power delivery. You cannot power the onboard microcontrollers directly from the USB VBUS if you want to maintain an isolated ground plane.

To solve this, I routed the incoming USB power into a B0505S-1WR3 isolated DC-DC converter. This component takes the incoming 5V (VBUS) and USB ground (GND_USB) and transfers the energy magnetically across an internal transformer. It outputs a completely separate 5V supply (+5V_ISO) and establishes the main board-level GND.

This +5V_ISO net is then fed into an AP2112K-3.3 linear regulator to generate the clean +3V3 required by the microcontrollers, ensuring no direct electrical path exists between the PC’s power supply and the board’s logic.

Because the RP2040 is also a flashless microcontroller, it required its own dedicated memory to hold the probe firmware. I routed a 2MB W25Q16JVUXIQ QSPI Flash chip to the RP2040’s memory bus. To ensure there was no confusion during layout, I prefixed all of its QSPI Net Labels with DBG_ (e.g., DBG_FLASH_CS, DBG_QSPI_SCLK). This ensured the EDA software wouldn’t accidentally merge the debugger’s memory bus with the main processor’s memory bus.

While routing the core power for the RP2040, I ran into a critical architectural difference between the two generations of silicon.

Since I had just finished designing the 1.1V power supply for the RP2350B, my initial instinct was to duplicate that exact layout for the RP2040—including the 2.2µH external inductor for the Switched-Mode Power Supply (SMPS).

However, reviewing the datasheet revealed a major discrepancy. Unlike the newer RP2350, the older RP2040 does not utilize an internal SMPS. Instead, it relies on a much simpler internal Low-Dropout Regulator (LDO) to generate its 1.1V core voltage. Placing an inductor on the regulator output here would have caused severe voltage instability or failure to boot.

If you do any serious bare-metal firmware development, you know the frustration of the physical debug loop.
You end up with an ST-Link or J-Link dangling off the side of your desk, a fragile ribbon cable converting down to a 0.1” pitch header, and the constant fear of knocking a jumper wire loose while stepping through a critical hardware interrupt.
like this example :-

I wanted a true single-cable development experience. Plugging in one USB Type-C cable should simultaneously power the board, mount a serial console, and establish a high-speed Serial Wire Debug (SWD) connection to the primary core.

To achieve this, I decided to build a hardware programmer directly into the PCB using a second microcontroller: the RP2040.

The Raspberry Pi Foundation provides a firmware called “Picoprobe” (now transitioning to “Debugprobe”) that turns an RP2040 into a dedicated USB-to-SWD and USB-to-UART bridge.
check out here :- https://www.raspberrypi.com/documentation/microcontrollers/c_sdk.html

dual-chip memory architecture:

1. Primary Flash (U2): A W25Q128JVSIQ (16MB QSPI Flash) to hold the compiled firmware, the Rust-based CAN parsers, and the RTOS.
   

2. Buffer PSRAM (U3): An APS1604M-3SQR-SN (8MB QSPI PSRAM) to act as a massive, high-speed RAM drive for buffering video frames before they are piped out over Wi-Fi.
   

Both memory chips utilize a Quad Serial Peripheral Interface (QSPI), meaning they require six pins to operate: a clock (SCLK), four bidirectional data lines (SD0-SD3), and a Chip Enable/Select (CE#).

Because QSPI consumes a lot of high-speed routing space, you don’t want to wire two completely separate buses. Instead, I wired them in parallel. I routed the main clock and all four data lines directly from the RP2350 to both the Flash and the PSRAM simultaneously.

and also To prevent this, I split the Chip Select lines.

• The 16MB Flash is tied to the RP2350’s dedicated QSPI_SS pin.

• The 8MB PSRAM is routed to GPIO47.

schemtic is atteched see below

With the physical architecture defined.
The RP2350 requires two primary voltages: a standard 3.3V supply for its I/O pads (IOVDD), and a tightly regulated 1.1V supply for its internal digital core (DVDD).
3.3v

1.1v

Instead of dropping an external linear regulator (LDO) onto the board to generate the 1.1V—which would waste power as heat—the RP2350 includes a built-in Switched-Mode Power Supply (SMPS). To implement this, I routed the main +3V3 plane into VREG_VIN and placed a specific 2.2µH power inductor (L1) between the VREG_LX switching pin and the VREG_FB feedback pin.

This inductor is critical. It acts as the energy storage tank for the switching regulator, allowing the chip to efficiently step down the voltage without thermal throttling. I then routed the resulting 1.1V output to a dedicated +1V1 net, heavily decoupled it with a bank of 100nF MLCC capacitors, and fed it back into the array of DVDD pins.

also RP2350 is a flashless microcontroller; it relies entirely on external memory to boot and run code. Furthermore, because the Lemon Pi is designed to capture parallel video frames from camera and log high-speed CAN-FD telemetry, the internal 520KB of SRAM would be exhausted in milliseconds.
so for that i added dual-chip memory

I need an in build debugger on my Lemon Pi, which won’t cost much, only about $2.

This eliminates the need for external debuggers. There’s nothing worse than dealing with a loose jumper wire on the SWD header when trying to fix a hard fault in C++ or Rust.

I placed a second microcontroller—the RP2040 (in a QFN-56 package)—directly on the board.

This chip acts permanently as a “Picoprobe.” It sits on the clean side of the board, connects to the host PC via USB, and translates those USB signals into Serial Wire Debug (SWD) and UART console commands. It then bit-bangs those debugging signals across the isolation barrier directly into the main RP2350B.

By utilizing a dual-MCU architecture, the Lemon Pi becomes a true plug-and-play development platform. One USB-C cable provides power, a high-speed serial console, and a bare-metal hardware debugger, all while keeping the host machine physically protected from the automotive side of the board.

For the primary brain, I selected the newly released Raspberry Pi RP2350B.

While I frequently use STM32s (like the G431) and ESP32s for embedded projects, the RP2350Bis really cool mcu because its offered few distinct architectural advantages for the Lemon Pi

• The ‘B’ variant of the RP2350 has 48 GPIO pins. This was a non-negotiable option. I needed a large, continuous block of pins for the camera’s parallel data bus, leaving enough high-speed pins free for the SPI wireless module and external memory.
  

• he RP-series PIO state machines are perfect for offloading the heavy lifting of the DVP camera protocol and custom CAN engine timing without locking up the main ARM Cortex-M33 cores.
  

• this is a my most favorite , The RP2350 introduces advanced hardware security features (ARM TrustZone, OTP, secure boot), which aligns perfectly with the cybersecurity and hardware auditing focus of this platform.

I’m just starting a new project. I’m looking for a more powerful processor, not just one I can buy. I want something with an open community so I can ask questions if I encounter any obstacles. This helps a lot.
My initial plan is something like this:

• ARM Cortex-M7 processor, 600 MHz
• 8MB flash memory with EEPROM emulation
• 1024K RAM with 512K title-coupled for performance
• Built-in USB host port and microSD card socket
• 55 total I/O pins, including 42 breadboard-friendly
• 3 CAN buses (one CAN supports FD)
• Cryptographic engine and random number generator

This is just planning, let’s see what kind of reliability we get or not.

Finally my Hawk 3 fc design is complete with zero DRC errors and perfect differential pair routing.
here is the final look of the PCB(in attachment )

The Design Rule Check (DRC) is completely clear, which means the board is electrically perfect

I spent a couple of hours doing the tedious work of moving every single 0402 component designator so it is clearly readable. But more importantly, I added the user-facing labels. I made sure the 8-pin ESC cluster has clear, bold labels for VBAT, GND, and M1-M4. I labeled all the UARTs (TX1, RX1, etc.) and clearly marked the 5V and 9V test points.

Before hitting the export button, you always have to step out of the 2D routing matrix. I fired up the 3D viewer in the design software to see exactly what the manufactured board will look like in the real world.

The Infinite Loop in DRC

Here is exactly what the last 3 to 4 hours of my life looked like:

• Find the Error: The DRC flags a clearance violation on Layer 3. A trace is too close to a via, then i have to modify the rules

• The Fix: I grab the trace and nudge it slightly to the left to clear the via.

• like side Effect: I run the DRC again. The original error is gone, but the trace I just nudged is now 0.05mm too close to a different pad. New error generated.

• Polygon Problem: (5V 9V copper pour ) I nudge the trace again, pushing it into an empty space. I run the DRC. Now the trace has sliced through a 3.3V copper polygon, cutting off a section of the power plane and creating an “Unrouted Net” error.

• The Rebuild: I have to rip up the trace, delete the polygon, manually re-route the trace taking a completely different path around the entire block, and re-pour the copper.

I had to repeat this exact cycle dozens of times. Fix an error, create a new error, rip it up, route it again. Run DRC. Fail. Nudge. Run DRC. Fail. Shave copper. Run DRC. Pass one, fail another.

It is a brutal, repetitive grind. But after hours of micro-adjustments, nudging traces by fractions of a millimeter, and constantly re-running the checks, the list of red errors finally started to shrink.

I am currently down to the last 50 clearance violations you can see in attachment ( lol man if like really low number ).

For the rest of the connections—the UARTs, the receiver, the VTX, and the camera—I kept the layout strictly logical. Every communication lane (like UART1) gets its own dedicated 5V pad and GND pad placed directly next to the TX and RX pads.

This means when you wire up a receiver, all four wires go to one single, organized cluster. No more running a ground wire to one side of the board and a 5V wire to the complete opposite side just to power a single module.
Now 80% of the routing is done,
The STM32H743 is sitting pretty, the 5V and 9V power polygons are fully poured, the high-speed SPI lanes for the gyro and Blackbox are locked in, and the motor signals are routed to the edges. Visually, the board is about 80% routed but Once the critical, high-priority paths are laid down, you are left with the “junk” signals.

Eventually, I forced the last few traces through and hit 100% routed. Then, I made the mistake of hitting the Design Rule Check (DRC) button.

The screen exploded with red warning markers. I had over 367 clearance violations.

Even though you are surface-soldering your wires to them,
like this

having a plated hole in the center of the pad physically anchors the copper to all six layers of the fiberglass board. This means you can heat these pads up, solder heavy-gauge wires to them, and crash your quad into a concrete wall without the copper pad ripping right off the PCB.

I arranged the M1, M2, M3, M4, CURR, GND, and VBAT pads into a perfectly straight row to exactly match the standard 8-pin wiring harness used by modern 4-in-1 ESCs. It keeps the build hyper-clean.

I designed custom rectangular test points.

A rectangle gives your multimeter probe a flat, wide surface to rest against, making it ten times easier to check your voltages. I scattered these rectangular test points strategically across the top layer, tapping into the 5V rail, the 9V rail, the 3.3V logic line, and Ground. If your board ever stops working, you can diagnose the exact power failure in seconds.

I specifically isolated our 9V video power regulator in a corner so that its inductor wouldn’t introduce magnetic noise into our video feed. I had to carefully thread the video traces entirely within this designated clean zone. I made sure these traces never crossed the M1-M4 motor lines or came near the noisy 5V logic power inductor. Keeping these lines separate guarantees a static-free FPV feed.

after that I stepped away from drawing traces and focused entirely on designing the physical interface of the Hawk 3.

The main battery connection and the ESC pads take the most physical abuse during crashes and rebuilds. I didn’t use standard, generic circular pads from the library here. I designed custom, heavy-duty through-hole pads.

With the massive power polygons poured (you can see img or previous devlog )
I tackled the bulk of the actual wiring: getting the general signals out of the brain and across the board.
Because we set our strict 0.1mm clearance rules back in previous , I was able to carefully thread traces between the outer row of pads.
However, you simply cannot fit 100 traces on the top layer. To get the majority of the signals out, I dropped immediate vias right next to the MCU pins, diving down into Layer 3 (our dedicated Internal Signal layer). This allowed me to fan the traces

(also called fan out methods ) out safely underneath the top-layer components without creating a tangled mess.

I had to connect the MCU to our 8-pin ESC pad cluster on the edge of the board. The M1 through M4 traces carry the fast digital DShot signals that tell the motors exactly how fast to spin. I grouped these four traces together on Layer 3.

Finally I have completed the Copper Polygon, I have created a total of 4 zones.

• zone 1 :- for the VBAT (0 it will carry around 8v to 28v)
• zone 2 :- for the 9V power
• zone 3 :- for the 5V power
• zone 4 :- for the safe side , i also created 3v3 zone

ICM-42688-P gyro and the 32MB Blackbox flash memory chip incredibly fast. We are using SPI (Serial Peripheral Interface) buses for this.

• Because ash memory chip is on the top layer next to the MCU, routing this was about keeping it short and clean. I ran the Clock (SCK), MOSI, and MISO lines directly between the two chips. More importantly, I made sure there were zero vias on these traces.

• Because the gyro sits directly on the bottom layer, so these signals did have to drop through vias. The challenge here was making sure the SPI2 traces never crossed over the noisy inductors from our power regulators. I carefully snaked them down through our Internal Signal layer (Layer 3), safely shielded by the solid Ground planes above and below them.

USB-C: Differential Pair Routing

Let’s start with the USB-C connection. The data lines coming from the USB port (D+ and D-) don’t operate like normal traces. They carry high-frequency signals, and they act as a “differential pair.”

This means they send inverted versions of the exact same signal down two parallel wires to cancel out electrical noise.

here is the best example how to do this :-

The D+ and D- traces must be the exact same length down to the millimeter. If one trace is slightly longer, the signals arrive out of sync, and your PC will hit you with the dreaded “USB Device Not Recognized” error. Because this MCU is much faster than the Pico or PI Zero, you won’t notice it in that.

I routed these traces directly from the physical USB port straight into our PRTR5V0U2X ESD protection chip, and then to the MCU.

This is a continuation of my previous development because I couldn’t put that data there.
There’s one major problem with using large copper joints: they absorb heat. If I connect the main battery pad directly to a solid, unbroken copper plane, the plane will act as a heatsink. When you try to solder your battery wires to the Hawk 3, the copper will absorb heat from your soldering iron, leaving you with cold, weak solder joints.

To fix this, I turned on “thermal relief” on all the power pads. Instead of melting directly into the copper C of the pad, it connects to four small copper “spokes.” This causes a lot of current to flow, but it traps the heat from your soldering iron on the pad for a while so you can actually melt your solder and get a perfect, shiny joint

Now, it is time to actually connect the power.

But here is the thing: when you are dealing with a flight controller that pulls heavy amps, you don’t draw lines. You pour copper.( or Your tracks need to be thick to carry high current), like in img

If you try to push 3 Amps of current from our 5V or 9V regulators through a standard 0.1mm routing trace, that trace will instantly heat up and vaporize like a blown fuse.

TPS54335A buck converters are sitting on the bottom of the board (Layer 6). I started there, pouring thick, custom copper shapes to connect the raw VBAT power into the regulators, and then massive shapes to capture the 5V and 9V output from the inductors.

But that power needs to get to the rest of the board. That is where Layer 4 (our dedicated Internal Power layer) comes in. I sliced Layer 4 into massive copper regions. One huge region carries 5V to the MCU and the UARTs, while a strictly isolated region carries the 9V power straight to the video quadrant.

i forget to mention about ground rules for the board

starting with one of the most critical decisions of the entire project: the layer stackup.
Trying to route an STM32H743, two massive power regulators, and a high-speed gyro on just 4 layers would lead to crossed signals, electrical noise, and poor power delivery Because my STM32 alone is 14x14 mm in size And keeping the standard size in mind, I increased the size of the board a bit by keeping the mounting hole at 30.5 mm.
layer stackup :-

• Layer 1 (Top Signal): the H7 brain, the ICM-42688-P gyro, the USB-C port, and the short, critical high-speed traces connecting them

• Layer 2 (Internal Ground): Just beneath the surface is a solid, unbroken sheet of copper tied to Ground (GND).

• Layer 3 (Internal Signal): I will use this to snake the UARTs, motor signals, and general I/O across the board without cluttering the top surface.

• Layer 4 (Internal Power): This layer is entirely dedicated to power. carry the 3.3V, 5V, and 9V power rails smoothly across the entire board.

• Layer 5 (Internal Ground): Another solid sheet of Ground copper. This creates a sandwich effect
  
  (That's right, that's what it's called, I read it here ;- https://www.protoexpress.com/blog/prepreg-the-slice-of-cheese-in-your-pcb/), shielding the internal signal layers from the noisy power regulators sitting on the bottom of the board.

• Layer 6 (Bottom Signal): This layer holds the heavy lifters—the dual TPS54335A buck converters, the 32MB Blackbox flash, and the AT7456E OSD chip.

I always route the most sensitive stuff first. For the Hawk 3, that means the SPI1 bus for the ICM-42688-P gyro and the SPI2 bus for the 32MB Blackbox flash. it requires keeping traces short, direct, and under a continuous ground plane to manage high-speed signaling (typically >10 MHz) and minimize parasitic capacitance (unavoidable capacitance forming between conductive components)

,
I also made sure to route them away from any power components so we don’t pick up electromagnetic noise.

I’ve tried my best to route it so that the trace for the gyro is as short and straight as possible, but I don’t know how successful that was.

I want these data lanes to go in a perfectly straight line into the STM32H743 brain.

Changelog

• Revise README for Hawk 3 Flight Controller updates
  design and it simulation for PDN (poweer delivary network) is done go check out repository

Using the updated feedback calculation (R1 = 100k Ohm, R2 = 9.76k Ohm), the 9V rail regulates perfectly at 8.99V. Like the 5V rail, it achieves full regulation in 1.80 ms. This fast initialization ensures the VTX receives stable power before attempting to transmit, preventing initial boot-up static or channel drift. The inductor handles the peak inrush current smoothly at 3.85A.

With every component finally in place, my component placement is complete. With all the components finally locked into their exact, millimeter-perfect coordinates, the board is officially ready for the hardest part of the entire project: routing the copper traces.
I made sure to group the 5V and 9V power circuits tightly together in their own corner, creating a strict “quarantine zone.” i mean restricted zone

The dual TPS54335A buck converters are amazing for power delivery, but the inductors they use generate a lot of invisible magnetic noise.
this is great-resource if you wanna read about noise :- https://files.resources.altium.com/sites/default/files/uberflip_docs/file_731.pd

one of my friend told me about, so i want share with you all
https://www.connectortips.com/how-to-manage-emi-at-the-harness-to-pcb-interfaces/

In the last update, I did the b block-out—getting the MCU, USB port, and major pad clusters to their general neighborhoods.
Today was all about the meticulous “micro-placement” phase.
Here are the rules I had to follow to make sure this board actually work fine ok
The ICM-42688-P gyro is the most sensitive component on the board. I had to ensure it was placed as close to the absolute physical center of the PCB as possible.
If the gyro is rotated even a tiny fraction of a degree off-axis during placement, the flight controller will constantly mix up roll and pitch movements, making it a nightmare to tune.

I started dragging parts onto the actual board outline to figure out where everything should live. It is basically a high-stakes game. I dropped the STM32H743 chip dead in the center, since it is the bulky brain and needs to connect to literally everything else. Next, I placed the ICM-42688-P gyro right next to it, ensuring it sits as close to the center of gravity as possible so the quad flies locked-in.

From there, I pushed the USB-C port and all those heavy-duty motor and power pads out to the extreme edges where they will be easy to solder. Finally, I grouped the 5V and 9V power regulators and pushed them into their own isolated corner so their electrical noise stays far away from the sensitive video and gyro lines.

after finishing up the schematic and finally importing everything into the PCB layout editor, I immediately realize about: space constrains .
When you pack a giant STM32H743 bulky mind, two separate power regulators, and a massive 32MB flash chip onto a standard flight controller size, real estate disappears fast. I quickly realized that the standard 0603 and 0805 component sizes I had originally picked for my passives were just way too big. If I kept them, the board was going to be an overcrowded mess, and routing the traces would be impossible.
so, I went back through the entire schematic and changed the footprint of every single subcomponent—every capacitor, every resistor, and every inductor—down to the microscopic 0402 size.

Let me tell you, this was not the fun, creative part of designing a flight controller. It took me about an hour and a half of pure, tedious clicking. Going component by component, updating the part numbers, and verifying the new 0402 footprints was a total grind.

schematic is done finally

Finally, I added a few breakout pads for the LED strip and the Buzzer. Because let’s be honest, no build is complete without a loud buzzer to help you find it in the tall grass after a crash.
And with that, the full schematic, power calculations, and pad mapping for the Hawk 3 are officially done! Every pin on that H7 chip has a purpose.

Power Management Simulation

To make sure my 5 volt and 9 volt rails are working correctly, I used the Ti official simulator for my design and it is really impressive to me that I have designed and calculated the correct values ​​for registers, capacitors, an inductor.

simulation result:-

• The simulation confirms that with a 6.8uH inductor on both rails, the peak-to-peak ripple is well within tolerances.

• The next step is to ensure the TPS54335A’s Thermal Pad (Pin 11) is tied to a massive ground plane, because at 3A, those little chips are going to want to shed some heat!

• With the 100k resistors tied to ground, the internal oscillator is locked in. The primary goal here was to observe the PH (Phase) node switching waveform.

I looked for two specific things in the sim:

• Dead-time control: Ensuring the synchronous internal MOSFETs aren’t “shooting through” (turning on at the same time).
• BOOT-PH Voltage: Verifying that the 100nF bootstrap capacitors maintain enough charge to fully drive the high-side gate, even at high duty cycles.

I simulated a “step-load” (suddenly jumping from 1A to 3A). The goal was to ensure the VSENSE pin recovered quickly without ringing.

this is all about making this board talk to the outside world.
Your flight controller needs to constantly chat with :-

• your radio receiver
• your video transmitter
• your GPS
  It does this using hardware communication ports called UARTs. so i map them with JST ports

UART Map

• UART 1 (TX1 / RX1): I’ve designated this for the primary radio receiver link
• UART 2 (TX2 / RX2): I mapped this one out specifically for a GPS module
• UART 3 (TX3 / RX3): This lane is dedicated to the Video Transmitter
• UART 4 (TX4): I routed out a fourth, easily accessible UART just to have a spare (It’s always good to have an extra set of TX/RX pads for future expansions, like a Bluetooth module for wireless tuning or a compass.)

Motors Spinning and Reading the Amps

With both the 5V and 9V power delivery networks completely routed and calculated. I focused entirely on the motor outputs and the current sensing.

The STM32H743 it needs a direct way to yell instructions at the electronic speed controller (ESC).
I mapped out the signal lines for our four motor outputs—M1, M2, M3, and M4. These traces are the direct communication link that tells the 4-in-1 ESC exactly how fast to spin each motor.

I routed an analog current sensor line (labeled CURR on the schematic) straight from the ESC connector pad to a dedicated Analog-to-Digital Converter (ADC) pin on the H7 chip so i can know how much power they are sucking out of the battery.
This allows the flight controller to read the real-time amp draw from the main battery lead and display your total milliamp-hours (mAh) consumed right on your OSD.

9V Power Delivery Network (PDN)

Moving right along to the second half of the power system: the 9V rail.

You might be wondering, “Why do we need a completely separate 9V regulator if we already have 5V and raw battery power?”

The answer is video quality and raw power is 6S which mean 22.2 V .

If you power them directly from the battery, every time you throttle up, yuo will face mainly two problem according to my exprince :-

• you will see horizontal static lines across your goggles because the motors make the power dirty.

• If you power them from the 5V rail, the high current draw of a powerful VTX might starve the MCU and cause a mid-air reboot.

so that why i added a second, entirely separate TPS54335A buck regulator specifically to generate a clean 9V rail just for the VTX and camera.

Just like the 5V regulator, we have to calculate the feedback resistors to tell this second TPS54335A to output exactly 9V.

• Again, I use a 10k resistor for R_2 to keep the Bill of Materials (BOM) simple

5V Power Delivery Network (PDN)

I’ve been working on the Power Delivery Network (PDN), and I decided to split it into two completely separate systems.
Let’s talk about the first one: the 5V rail.:
To step down the raw, high voltage from the LiPo battery (VBAT which is 6s) to a clean usable 5V,
I am using the TPS54335A buck regulator.

It is highly efficient and can handle the current draw of all our onboard electronics without getting hot.

Before the power even reaches the regulator, it has to survive the motors. When you do a sharp flip and the motors brake, they shoot massive voltage spikes back into the battery line.

To protect the board, I wired a heavy-duty TVS diode across the VBAT pads. It acts like a shock absorber, clamping down on those spikes before they can fry the regulator.

i have do The Hall of Calculation for the 5V:

• I selected a standard 1% tolerance 52.3k resistor for R_1, which gives us a rock-solid, incredibly precise 5V ( exactly 4.98, i get this after a lots of calculation according to data sheet ) rail.
• To get our 5V output, I picked a standard 10k resistor for R_2

I caught a significant error in my initial instructions regarding the crystal oscillator setup
my originally connecting , the crystal between CLKIN and CLKOUT, but after a deeper dive into the manufacturer’s datasheet,
I realized that would have been a “no-boot” scenario.

CLKOUT (Pin 7) is actually a buffered logic-level output designed to drive other ICs on the PCB; it isn’t part of the resonant feedback loop for the crystal itself. To get the OSD chip to actually pulse, the crystal must bridge CLKIN (Pin 5) and XFB (Pin 6).

With the power sorted, I moved on to the analog video
’ve got the AT7456E OSD chip wired into the schematic and mapped it directly to the SPI4 bus on the STM32H743.

to make absolutely sure the video feed stays crystal clear even when the motors are pulling huge amps,
I’ve also designed a dedicated LC filter into the OSD circuit. Clean power plus filtered video means no more annoying horizontal lines in the goggles!

I spent a good chunk of time wiring up the STM 32 H7

• This involved getting all the necessary VCAP capacitors in place to stabilize the internal core voltage
• hooking up the 3.3V power rails
• wiring in an 8MHz external crystal so the timing is dead-on

I also finished the BOOT and RESET circuits—super important, because otherwise, we’d have no way to get Betaflight flashed onto this thing in the first place!

As I mentioned in the last log, we are going full USB-C. I got the D+ and D- data lines routed, but more importantly, I made sure to add a PRTR5V0U2X ESD protection chip,
about the ESD protection

Plugging and unplugging a flight controller in the field can easily send a nasty static shock into the board, and this little chip will act as a bodyguard to make sure we don’t accidentally fry the main MCU.

Lately, I’ve been staring at a screen for way too many hours, moving from the component phase right into the actual schematic

Clean power is probably one of the most essential parts of a good FC design.
so I spent a lot of time on this. I’m using dual TPS54335A buck converters.

This gives me two dedicated, clean power rails:

• a 5V rail for the standard electronics and receiver
• 9V rail specifically to run the video transmitter (VTX)
• 9V rail specifically to run camera without any noise or dropouts.

the component selection and core architecture are pretty much locked in. I’m really happy with how the feature set is coming together.

Here is what I’ve knocked out so far:

• I put the ICM-42688-P gyro on its own dedicated SPI1 bus. We want the fastest, lowest-latency path possible between the gyro and the MCU for those tight PID loop times.
• I put the massive (Blackbox)W25Q256JVEIQ 32MB flash memory chip on SPI2. This way, the FC can dump all that heavy tuning and logging data without fighting the gyro for bandwidth.

FC controller project: the Hawk 3. I wanted to put together a quick update to talk about what I’ve been working on and the design choices I’ve locked in so far.

If you’ve followed my older designs, you know I previously used the STM32F405 and F412 chips. They were great, but no longer supported by beta flight in future.

I decided to make the jump to

• the STM32H743VIT6 microcontroller.
  
• I went with the ICM-42688-P. It’s super fast, has great noise characteristics (bit expensive(13 usd), but i have made in china version only for 3 usd)
  
• I added the BMP388
• I am sticking with the tried-and-true AT7456E chip
• Tuning is everything, so I wanted to make sure there was plenty of room for Blackbox logging. I’ve routed in a W25Q256JVEIQ flash memory chip,(hell yeah 32 MB)

which gives the board a massive 32MB of onboard storage to capture flight data.

It’s very bad news for my FC that BetaFlight has changed its guidelines.My previous design, which I worked so hard to perfect, is now considered “legacy” hardware. While it may still fly today(still work ,also with INAV ), it is no longer compatible with the vision of Betaflight’s future updates. As performance demands grow, this board will eventually be left behind, unable to support the latest features and optimizations. so I’ll have to create a new one so that it can meet community standard and community can use it easily.

[!WARNING]

Betaflight Hardware Design Policy Update

Betaflight will no longer accept new flight controller designs using STM32 F4 and F7 series microcontrollers for boards requiring more than 4 motor outputs.

Why this change?

We strive to provide the best flight experience across a wide range of hardware. To maintain this standard, we must limit designs using older microcontrollers that suffer from restrictive timer and DMA resource limitations.

Design Recommendations

• STM32 F4/F7: Should now be reserved strictly for budget freestyle/racing designs and AIOs limited to 4 motor outputs.
• STM32 H743: With pricing now comparable to the F405, the H743 is the recommended choice for high-performance, high motor output, and high I/O designs.

Legacy Support

• Existing designs are not affected by this change.
• Future Note: Features may be restricted on older hardware in future firmware releases if performance overhead becomes a bottleneck.

Now I am making a 4 motor FC using STM H743, I have removed BMI270 so the whole design is almost changed but for the connecting part most of it will remain the same.

Changelog

• Update README with improved project description
• Refactor BOM table for improved clarity
• Enhance specifications and usage details
• first commit

I made one final, crucial addition to the PCB: Fiducial Markers.
DRC check and every thing is fine , all error solve
It was finally time to order the boards. but wait i need a PCb grant ohh man

I finally have my PCB routing complete, just a few DRC checks left to sort out.

• I’ll have to redesign half of my PCB because I overlooked differential impedance previously.
• When designing, you have to worry about high-speed lines where vias aren’t allowed.
• Every time a high-speed signal changes layers through a via, it changes impedance and can reflect the signal back at the source.
• By keeping them all on the Top Layer, the signals remain perfectly clean.

USB 2.0 full-speed signals operate at 12 Mbps ( dont know where i read it lol ) i have to re roaute every thing i am feeling sad.

• With power and USB handled, I moved to the RP2350’s external memory.
• The chip boots and runs code directly from the W25Q128JV QSPI flash memory.
• This interface runs incredibly fast (up to 133 MHz), meaning trace length and signal integrity are vital.
• I routed all six lines (QSPI_SS, QSPI_CLK, and the four QSPI_SD data lines) exclusively on the Top Layer.
• I roughly length-matched these traces. It doesn’t require millimeter-perfect meandering like a PC motherboard’s RAM

started routing the hardest traces first:

• the USB data lines
• the RP2350’s internal switching power supply (SMPS).

For the SMPS, the datasheet is incredibly strict. I placed the 3.3µH inductor on the top layer right next to the VREG_LX and VREG_FB pins.

• The switching node (VREG_LX) generates a lot of electrical noise,
• so I made that copper trace as short and fat as physically possible.
• I tied the 4.7µF filtering capacitors directly to the output of the inductor
• USB 2.0 requires the D+ and D- lines to have a differential impedance of 90 ohms
• I routed these traces together perfectly parallel, avoiding any sharp 90-degree corners.

I thought about doing this as a standard 2-layer board to save a few bucks, but I quickly realized that was a terrible idea.

• Between the high-speed USB lines, the switching inductor for the RP2350 core,
• the sensitive current measurements of the INA226,

I decided to upgrade to a 4-layer stackup. It makes routing infinitely easier
Here is how I defined my layer stack in EasyEDA:

• Layer 1 (Top): Signal and local component routing.

• Layer 2 (Inner 1 - GND): A solid, unbroken Ground plane.

• Layer 3 (Inner 2 - Power): I split this copper plane into two zones. The top half is my internal 3.3V net

• Layer 4 (Bottom): Mostly a secondary Ground pour, but reserved for longer, low-speed signal traces (like I2C and LED data) that need to cross the board without interrupting the top layer.

I decided not to stick to the standard Raspberry Pi Pico dimensions (21x51mm) because I wanted this board to be a bit more robust and easier to handle on a crowded desk. I grabbed the board outline tool and drew a clean rectangle, roughly 31mm by 83mm.

I decided to make the board a clean rectangular shape, roughly the size of a standard Raspberry Pi Pico, but slightly wider to accommodate the extra hardware

the schematic is officially locked in. I ran the Electrical Rules Check (ERC) and double-checked my USB differential pair traces to make sure they aren’t crossing anything weird.

Looking back, building a custom tool is a lot more complex than just wiring together breakout boards. You have to think about current flow, decoupling, and edge-case protection (like the ESD diodes and the level shifters). But knowing that I have a custom RP2350 design that handles its own switching core power, measures target telemetry via I2C, and safely shifts voltage levels feels incredible.

I wanted the ability to power the target board directly from my probe and measure its exact power consumption using an INA226 current monitor. This turned into the most frustrating—and educational—part of the schematic design.

I set up an LM317 linear regulator, calculating resistor values (240Ω and 390Ω) to output roughly 3.3V from the 5V USB line. I then added a 0.1Ω shunt resistor for the INA226 to measure across.

when I drew my nets, I accidentally created a parallel path. I had the power flowing straight out of the LM317 and into the target board, completely bypassing the shunt resistor. If I had fabricated it like this, the INA226 would have read a permanent 0mA.

I had to rip up my net labels and carefully redraw the logic: the power must flow out of the LM317, get tagged as IN+, force its way through the 0.1Ω resistor, and only then exit to the TARGET_VCC net. It was a subtle routing logic error that could have ruined the board’s best feature.

I needed physical buttons to interact with the RP2350’s boot cycle. I added a RESET tactile button tied directly between the RUN pin and ground. I added a BOOTSEL button tied between the QSPI_SS pin and ground (via a 1kΩ resistor)

I needed the probe to safely read and write SWD (Clock/Data) and UART (TX/RX) signals regardless of what voltage the target board operates at.
so i am using TXB0104PWR for this job. It’s a 4-channel bidirectional level shifter with auto-direction sensing.

This is crucial because the SWDIO (Data) line changes direction dynamically—sometimes the probe speaks, sometimes the target speaks. I hooked the A-side to my internal 3.3V net and the RP2350 GPIOs, and the B-side to a new net I called TARGET_VCC.

I also wanted the ability to force-reset the target board. Since the reset line only goes one way (Probe -> Target), I used a dual-channel GT74LVC2T45.

I tied the direction pin high to force data from A to B, giving me a rock-solid, level-shifted reset command.

The RP2350 doesn’t have internal flash memory, so I had to wire up an external QSPI chip.
I chose the trusty Winbond W25Q128JV (16MB).

I wired the six QSPI data/clock lines directly to the dedicated pins on the RP2350.

One interesting quirk of the Pi silicon architecture is that the QSPI_SS (Chip Select) pin is also used to trigger Bootloader mode, which I'll have to keep in mind when I add my physical buttons later.

I added a standard 12.000MHz SMD crystal oscillator.
I paired it with two 15pF load capacitors tied to ground. Between the crystal, the inductor, and my massive row of 100nF decoupling capacitors

My custom keyboards have failed due to poor USB-C implementation, so I made sure to include two 5.1kΩ pull-down resistors on the CC1 and CC2 pins. Without them, a smart host device (like a MacBook) won’t negotiate 5V power, and the board simply won’t turn on.

For protection, I routed the D+ and D- lines through a USBLC6-2SC6 ESD protection diode array before hitting the RP2350.to prevent from Static shocks

I dropped in an AP2112K-3.3 LDO to step the 5V USB power down to a rock-solid 3.3V for the RP2350

the logic chips.

The RP2350 upgraded from a simple internal LDO to a highly efficient Switched-Mode Power Supply (SMPS).

RP2350

old power core

To make the core boot, I had to completely redesign my power input block. I added a 3.3uH external power inductor between the VREG_LX pin and the VREG_FB/DVDD pins, along with a pair of 4.7uF filtering capacitors. If I had missed this detail, my board would have been completely dead on arrival.

With the core SMPS mapped out, I moved on to the USB interface. I opted for a 16-pin USB-C receptacle because it’s much easier to solder than the 24-pin variants, but it still gives me everything I need for USB 2.0 speeds.

I’ve been using standard Raspberry Pi Picos as debuggers for a while, but the jumper wire mess is getting old.

how to use as pico probe

I decided it was time to design a “Super Debug Probe” PCB from scratch, Instead of using the older RP2040, I decided to future-proof the tool and build it around the brand new RP2350A.

I started by mapping out the core RP2350A, but I immediately hit a wall that taught me my first major lesson about this new silicon.
On the old RP2040, providing the 1.1V core voltage was easy—you just hooked up a single capacitor to the VREG_VOUT pin.

I was searching everywhere in the RP2350 datasheet for that pin, only to realize it doesn’t exist.

finally my PCB is complete

I thought I had things handled well with my 4-layer stackup, but today I found out that routing 900 MHz (LoRa) and 1.5 GHz (GPS) signals is actually dark magic, I mean I spent an hour figuring it out, but it was worth it in the end..`

i learn how to create perfect clearances around my RF traces

(forming what I learned is called a “Coplanar Waveguide” to stop the signal from leaking sideways)

I was worried about how the RF signals would behave, but I pulled off a great trick: Edge-Launch SMA connectors. By placing the chips on the bottom and soldering the SMA center pins directly to the bottom layer

The final fix for this session was addressing the bottom layer itself. Looking at my layout, the area around the GPS chip and the U.FL connector was just empty black space. Furthermore, the massive mechanical ground pads for my edge-launch SMA connectors were only attached to the rest of the board by tiny, thin traces. If I screwed an antenna onto that, the connector would probably snap right off.
but at the end every thing is great.

I grouped the board into three strict physical zones to keep the noisy stuff far away from the quiet stuff.

• Zone 1: for the CN3791 solar MPPT charger and the battery connectors.

• the MAX-M10S (GPS) and the RA-01SH-P (LoRa) onto opposite edges of the board, pointing their antenna outputs outward.

• Zone 3: 3.3V LDO regulator to act as the bridge between power and communication.

I distributed the clean 3.3V out to the microcontroller, the LoRa module, and the Source pin of my GPS MOSFET switch. I made sure to keep the LoRa power trace relatively wide—when that SX1262 chip transmits.

I put the RA-01SH-P on the bottom layer to optimize the RF path.
The GPS was much easier. It’s just a simple UART connection (TX to RX, RX to TX)

I’m finally starting to design my PCB.

I was initially considering building it on a two-layer PCB,
but I’m skipping the two-layer hassle and going straight to a four-layer stack:-

• layer 1- signal
• layer 2 which is a inner one so it going to be Ground
• layer 3 power
• layer 4 is going to be signal) again .
  The MAX-M10S and SX1262 LoRa chips require a solid, unbroken ground plane beneath their RF traces to maintain a strict 50-ohm impedance.

Trying to stitch together a ground plane on a 2-layer board while avoiding the noise from the solar charger just sounds like a recipe for terrible signal integrity. 4-layer is the way to go.

For the radio, I’m using the RA-01SH-P (which rocks the SX1262 chip).

• I initially thought about power-gating this module with a MOSFET just like the GPS, but realized that’s a bad idea.

It risks back-powering the chip through the SPI data lines from the microcontroller. Plus, the SX1262 has a deep sleep mode that draws less than 1µA anyway.

• So, I am wiring it directly to the always-on 3.3V rail. It just needs the standard SPI bus, the critical control pins (CS, RESET, BUSY), and the DIO1 interrupt pin to wake the system up when a transmission finishes or a new packet arrives.

GPS Subsystem module (MAX-M10S)

The GPS wiring is finally complete.

• I routed a second SI2301 MOSFET (Q2) as a high-side load switch. Now, my microcontroller can physically cut the 3.3V power to the MAX-M10S when it isn’t tracking.

• I had a funny slip-up where I accidentally placed a thermistor as the gate pull-up resistor for Q2, but caught it and swapped it for a standard 10kΩ.

I completely forgot that the MPPT (in CN3791 IC )pin is completely floating! Since I’m using a 6V solar panel.

I calculated and added a voltage divider (a 402kΩ top resistor and a 100kΩ bottom resistor) to set the MPPT point to ~6V. This will ensure the charger reduces the voltage without draining maximum efficiency from the panel.

(Note to self: I still need to drop an ultra-low quiescent current 3.3V LDO regulator onto the board to safely step the 3.0V–4.2V LiPo voltage down for the logic chips).

By isolating the solar charging into its own dedicated MPPT chip which is our CN3791, I ensure that even if the panel is partially shaded, it will dynamically adjust to pull the maximum possible wattage into the battery.

• The LiPo battery connects to the output of both the MCP73871 and the CN3791.

• I need to add a Schottky diode to the solar panel input so power doesn’t flow backward into the panel at night. JUST like i added in img

• The XC6220 LDO still sits between the battery and the ESP32-S3, providing a rock-solid 3.3V

just finish the wiring up and calculate the exact resistor values for the CN3791 to set the Maximum Power Point (MPP) for a standard 6V solar panel, and set the charge current to something safe, like 500mA.

I’m keeping the MCP73871 for USB-C charging (because I still want to be able to plug it into my laptop to test), but I am adding the CN3791 chip specifically for a 6V solar panel.
The tricky part is making sure the USB charger and the Solar charger don’t fight each other when both are connected.
next step for this

• Integrating the CN3791 MPPT Solar Charger.

• Blending solar input with your existing USB-C (MCP73871) charger.

• Ensuring the XC6220 LDO is optimized for the absolute lowest quiescent current (the electrical current consumed by an integrated circuit (IC) or device when it is powered on and enabled but not actively driving a load or switching)

The schematic and PCB layout for Hardware Revision 1.0 are complete. The project is currently awaiting physical board fabrication. Firmware development tailored for FIDO2/U2F protocols will commence once the hardware is assembled and verified.

hardwere is release now
https://github.com/ego10-ai/ego-key/releases/tag/v1.0

The routing is finally done. Connecting the ESP32-S3 pins to the OLED and the buttons was satisfying, but managing the power traces took some patience. I made sure the 5V line from the USB-C to the MCP73871 is nice and thick to handle a full 1-amp charge rate without breaking a sweat.

I started by placing the ESP32-S3 and the USB-C port. I decided to put the RA-01SH module on the opposite edge of the board from the BME280.

I don’t want the heat from the LoRa transmissions or the ESP32’s Wi-Fi messing with my temperature readings.
I’m paying extra attention to the SMA connector.

I’m using a coplanar waveguide calculation to make sure my antenna trace is exactly 50 ohms. If I get this wrong, my Long Range device won’t be very Long Range.

Routing the USB-C connector. Those pins are tiny and very close together. I have to make sure my Differential Pairs (the data lines) are the same length so the computer can actually talk to the ESP32 without errors

I finally started routing my PCB, for a board with high-frequency LoRa signals, a sensitive BME280 sensor, and an ESP32-S3, component placement is everything.

for the esp32 smd module It is suggested to place the module’s on-board PCB antenna outside the base board, and the feed point of the antenna close to the edge of the base board.

The trace going from the RA-01SH to the SMA Connector must be a specific width. If it’s too thin or too wide, the radio signal will “bounce back” and you’ll lose range. for the 50-Ohm Path trace width is going to be .3mm

I’ve finally finished the full schematic. The last few hours were spent double-checking the RA-01SH-P LoRa module

pins and the SMA antenna path.

I’ve ensured that the SPI lines are short and direct to avoid signal interference.

I also mapped out the BME280 on the I2C bus.

Since it’s a 3.3V sensor, it sits perfectly on the same power rail as the ESP32-S3. I’ve included the necessary pull-up resistors for the I2C lines to ensure the communication is stable.

I’ve wired the XC6220 LDO(1A low-dropout) to take the output from the charger. I chose this specific LDO because it can handle up to 1A of current—more than enough for the ESP32-S3 even when the Wi-Fi and LoRa are both screaming at full power.

The XC6220 is a Low Dropout (LDO) regulator. Its job is simple: take the messy voltage from the charger and “shave it down” to a perfectly smooth 3.3V.

If I were to build this on a breadboard right now, plugging in the USB would give me a solid 3.3V rail, and the ESP32 would boot up and stay stable.

i almost finished MCP73871 implementation with usb Type C

Since I’m using a standard 10k NTC ( thermistor to monitor battery temperature, enabling safe charging by suspending operations if the temperature falls outside the set range),
I have to make sure the voltage divider circuit on that pin matches the datasheet, or the chip will think the battery is “too cold” and won’t charge at all.

I’m focusing on the MCP73871 implementation because i need fast charging ans t’s a bit more complex than a standard charger because it handles the Power Path.

I’ve decided to wire it so that the device always prioritizes USB power. I’m using a 1k resistor on PROG1, which means I’m aiming for a fast charge. I need to make sure my LiPo battery can handle that (usually a 1000mAh battery or larger is best for this setting).

you see schematic outline in img

I am very confused between these two IC

1. BME280

vs
2, BMP280

The primary difference is that the BME280 measures temperature, pressure, and humidity, while the BMP280 measures only temperature and pressure. The BME280 is an all-in-one environmental sensor suitable for weather monitoring, while the BMP280 is a low-cost, accurate option for barometric pressure and altitude tracking.

So I think I’ll have to go with the BME 280

my new project: a portable, LoRa-enabled environmental communication device

the Bill of Materials (BOM) I just finalized, this is going to be a dense build. I’m using the ESP32-S3 as the core—mostly because I need that extra PSRAM for future UI elements on the OLED, and the dual-core power for handling LoRa stacks and sensor polling simultaneously.

I’ve decided to start the assembly with the power management circuit. I’m using the MCP73871. I chose this chip specifically because it has System Power Path Management.

I am really telling you component placement is 90% of the battle. If you get the components in the right spots, the board practically routes itself.

I started by defining the board outline around the USB-A PCB-edge contacts. This dictated the width of the entire device.
then I placed the USBLC6-2SC6 ESD protection diode and the 500mA PTC fuse as close to the USB pads as physically possible. For ESD protection to actually work, it needs to intercept spikes before they travel deep into the board.

Once the last trace was connected, I flooded the top and bottom layers with a Ground copper pour. This ties everything together, provides a short return path for signals, and helps dissipate any heat from the LDO and MCU.

Just started designing the PCB for my Ego key
currently using a USB-A_PCB (where the PCB itself acts as the male USB-A plug)

FINALLY SCHEMETIC COMPLETE

• The RP2354A makes the initial wiring surprisingly straightforward.
• Because it has 2MB of flash memory stacked internally, I didn’t need to route an external QSPI flash chip. That alone saved a significant amount of space and component count.
  The base circuit came together quickly:
• the MCU, the required decoupling capacitors,
• a 12MHz crystal oscillator (ABM8-272-T3)

I’m using a new Raspberry Pi RP2354A For the brain of the operation It has 2MB of stacked flash built right into the chip and dual Hazard3 RISC-V / ARM cores, which makes it an absolute powerhouse for a EGO KEY project.

The hardware update is finally complete.
Check out the new release.
https://github.com/ego10-ai/flight-controller

I’m feeling very frustrated.

I hit a major wall trying to route traces for the STM32F405. With 64 pins and those 34 decoupling capacitors fighting for space, my screen resembled a bowl of digital spaghetti.

No matter how I moved the traces, I would repeatedly run into “collisions” or get stuck in a corner where I couldn’t send signals to the ICM-42688-P or AT7456E OSD chip.

Instead of forcing it and making a mess, I decided to do something tricky: I stopped and started “clearing” things. I deleted a large portion of the pre-arranged traces because I realized my component arrangement was actually working against me.

BELIVE ME hard way that PCB design isn’t just about connecting dots; it’s about traffic management

My PCB stack has 4 layers - top, ground, 3.3 power lines, and bottom.

I created “copper pores” or power planes for 3V3 and GND.

the entire layer of the board acts like a massive highway for the ground and 3.3V rails.
This helps keep the power stable for the DPS310 barometer and the MCU, especially since this new version runs so much faster.

I spent nearly thirty minutes just trying to route the traces out from under the LQFP-64 package without creating islands in my ground plane. It’s like a puzzle where every piece you move affects five other things.

Moving from the 48-pin chip to the 64-pin STM32F405 meant I had a literal spiderweb of connections to manage.
I focused first on the high-speed TRACE specifically the SPI lines that connect the brain to the

• ICM-42688-P gyro
• the AT7456E OSD.
  I learned that these lines need to be as short and direct as possible to prevent signal interference.

After the signal lines, I tackled the power distribution.

finallyyyyyy Component arrangement done

It’s finally starting to look like a real flight controller instead of just a mess of lines. Seeing the “brain( I MEAN STM32)” surrounded by its “nervous system(LOL)” of test points and filters is a huge confidence booster, even if I know the actual routing of all those traces is going to be my next big hurdle!

I also spent a lot of time strategically placing the 51( I know it’s excessive but it’s necessary and it’s also for connection) test points. also I know I’m going to need to troubleshoot, so I made sure to spread those pads out where I can actually reach them with a multimeter probe without shorting anything out.

PCB design

To be honest, seeing all those components scattered across my EasyEDA canvas was a bit intimidating at first. I spent a full hour and a half carefully grouping the parts, making sure the high-speed ICM-42688 gyro was right in the middle for optimal flight performance.

The biggest challenge was definitely those 34 tiny 100nF caps; I had to figure out how to squeeze them right in front of the MCU pins so that the power supply for that 168 MHz clock remained clean.
trying to fit a giant 64-pin brain and a mountain of new parts onto a tiny board.

Started PCB design

• I’m moving from a 7x7 mm QFN to a 10 x 10 mm LQFP-64. This chip will take up significantly more space on my PCB.

• The F405 has more power pins (VDD and VSS). We’ll need more 100nF capacitors (one for each VDD pin) to keep the power clean at 168MHz.

• LDO: The RT9193-33GB can still handle the 3.3V rail, but monitor the total current draw as the F405 consumes slightly more power at full speed.

Finally the SCHEMETIC is complete, now I have to design the PCB and start a peaceful day, I am attaching the img which you can see in full

Just complete the power supply for STM32.

Depending on the data set, I need to add more than 15 capacitors for decoupling. In my previous design, I used around 6 TO 8, but for this design,

I am using higher clock speed STM32. That’s why I need to add so many capacitors. As shown above, each power supply pair must be isolated with a filtering ceramic capacitor. These capacitors must be placed on or as close to the correct pins as possible on the bottom of the PCB for the device to function properly.

OSD for my flight controller

It essentially overlays flight information onto your FPV video feed.

OSD hardware can exist as an external device in the form of a small PCB board, or it can be integrated into another device, such as your flight controller, PDB, or FPV camera. This allows you to monitor your quadcopter’s status in real-time while flying FPV.

Some OSD allows you to set up alarms, to alert you when critical values are reached, such as the battery voltage level, or RSSI being too low and so on.

I’ve considered using an LMR 14030.
The LMR14030 is a 40V, 3.5A, step-down regulator with an integrated high-side MOSFET. With a wide input range of 4V to 40V, this device is designed for a variety of applications, from industrial to automotive BUT I AM using it for drone hehehe, for power conditioning from unregulated sources. The regulator’s quiescent current is 40µA in sleep mode, making it ideal for battery-powered systems. The ultra-low 1µA current in shutdown mode can further extend battery life.

Flight time matters, doesn’t it?

I’m upgrading my flight controller to the STM32F405

which is the most popular chip for analog flight controllers because it has a higher clock speed of 168 MHz and larger flash memory.

I’m also considering adding additional flash memory. Although this will increase the price, the upgrade is worth it. This allows for faster PID loop frequencies and more advanced features in Betaflight or INAV.

I’m also building this for FPV, which will include an ESC camera and video transmission, so a fast MCU is essential.

The project is now ready to move from the computer screen to the real world!

hardware is release go check out (https://github.com/ego10-ai/flight-controller/releases/tag/v1.0)
This is a compact, custom-designed flight controller project based on the STM32 architecture. It is designed for high-performance motion tracking and stable flight processing.

PCB Design Completed!

I finally crossed the finish line: the PCB layout for my STM32 flight controller is 100% complete with 0 drc error.
I spent the time making sure all the connections for the STM32F412CEU6 were solid and that my vias were correctly placed to bridge the different layers of the board. It was really satisfying to see the green lines turn into actual copper traces connecting the USB-C port, the test points, and the sensors like the ICM-42688-PC and BMP280.

I also finished the copper pours, which act like a big electrical ground for the whole board. seeing the layout go from a mess of “rat’s nest” lines to a clean, professional-looking circuit board feels like a huge accomplishment. I even did a final Design Rule Check (DRC) to make sure I didn’t have any overlapping traces or short circuits that would ruin the board once it’s manufactured.

Time to order the PCB for my flight controller

I successfully completed fan-out for STM32F411CEU6.

Since this is a high-density package, I had to be very precise with my vias to ensure that signals could run between the top and bottom layers of the board without interference. Routed USB-C data lines.

I learned that these lines need to be close to each other to maintain signal integrity, which is a bit of a challenge when you’re also trying to fit in the CC1 and CC2 resistors. Also, I have placed and added all 21 test points to the layout. From the BZ+ (buzzer) to the various I/O pins, these pads are now strategically located so I can easily check them after building the board.

I accidentally locked the wire speed, so I had to find a solution for a very long time.

Progress Check
MCU Vias: Complete

USB Routing: Complete

Test Point Placement: Complete
just for self remark

PCB routing

I have completed the wiring for the RT9193-33GB voltage regulator and the B5819WS Schottky diode. These components will stabilize the power supply and protect the board against accidental reverse-polarity faults.

also I have installed a set of 0402 LEDs (yellow and green) so that I can visually monitor the board’s status—such as when it powers up or if the MCU is signaling an error code.

I realized that the 0402 components—specifically the resistors and capacitors I selected—are truly tiny. Seeing them in the 3D view, situated right next to the 8MHz crystal and the USB-C connector, made me realize just how much precision I would need once I finally began the soldering process. Consequently, I decided to upgrade them to the 0603 package to make soldering significantly easier.

PCB layout start

I’ve just started the PCB layout and spent some time organizing my component list to make sure everything is ready for the PCB layout. My “brain” is the STM32F411CEU6, supported by a high-precision ICM-42688-PC (gyro/accel) and a BMP280 (barometer) for altitude sensing.

I’ve also added 21 test points across the board. As a beginner, I know I’ll need to troubleshoot, so having dedicated pads for BZ+, BZ-, and IO1 will make it much easier to use a multimeter or oscilloscope later.

https://www.lcsc.com/product-detail/C83291.html
https://www.lcsc.com/datasheet/C83291.pdf
https://www.lcsc.com/datasheet/C1337664.pdf

Re-routed internal GPIO mapping to safely isolate the RFM69HCW and IR systems from the Murata 1YN Wi-Fi/BT module.

Retains the 4-layer stackup requirement for proper 50-ohm RF impedance and solid ground shielding.

It took a long time to DEVLOG but it’s necessary because if I had stopped during my routing I might have forgotten where I left off so I thought let’s finish writing the DEVLOG after it’s complete

My PCB routing is complete except for grounding and other than that all routing is done so I can say that routing part is 90% complete. I will face a lot of problems during my routing process.

I struggled to manage the multiple layers in my design. With so many layers to keep track of, it was easy to get confused and make mistakes.

Ensuring that the grounding and power routing were done correctly was a challenge. I had to carefully plan and execute the routing to avoid any issues.

DRC Errors: The software’s DRC feature highlighted several errors in my design. I had to spend time identifying and resolving these errors to ensure that my design was correct.

layer stack up for my project :-
Layer 1: Top Signal
Layer 2: Ground Plane
Layer 3: Power Plane
Layer 4: Bottom Signal

What I learned:

The “Layer Filter” is my friend — toggled between top/bottom to avoid confusion lol
Need to be careful not to route signals over ground plane splits (mental note for later)

After adding the RF module, I’ll need to reroute the RP2350 because I need about 10 more pins for the RF module and the IR Blaster IR receiver.

I’ll also need to reposition my RP2350 for better routing because in the previous design, each GPIO pin can be connected to an internal peripheral via the GPIO function described below. Some internal peripheral connections appear in multiple locations for system-level flexibility.

I had no way to create a network between my RF module, the Air Blaster IR receiver, and the RP2350. I was trying to route as much as possible at the lower layers, but I think I’ll have to use the power out layer and the ground layer for this design.

I messed up with the E07-M1101D,

I thought it was a SMD component but, you thought that the through hole component would come out or the smd version of it would not be available, so I switched the module high RFM69HCW-915S2R 433MHz SPI 10dBm 1000m Wireless RF Transceiver Module RF Modulation, but I fixed it you can see it in the attachment below,

see you soon

I’ve just finished my schematic and reviewed every single net pin and passive component, including all the new components I just added. Now all that’s left is a drc check and some rearrangements because not every drawing is perfect.