Services

I design boards in KiCad, with full ERC and DRC sign-off before anything leaves my hands. I lay out components with pinout and final routing in mind from the start — fewer vias, shorter loops, current paths that make sense without forcing signals, power, and ground onto a single layer.

Most of my work is at JLCPCB — design rules and constraints are already set up, CPL files come out with correct orientations, and I’ve been through enough orders to know when to ping their support and what to ask. Components are sourced from LCSC, Mouser, or DigiKey depending on stock and lead time.

For mixed-signal designs I pay close attention to plane geometry and how different return currents move — analog and digital separation, where to stitch grounds, where not to. When a circuit has anything ambiguous — power stages, sensor conditioning, ADC front-ends, filters — I simulate it in LTspice before committing to layout.

What I work with:

• 2–6 layer stackups, FR-4
• Impedance-controlled traces where needed (RF, differential pairs)
• Mixed-signal layouts — analog/digital separation, return current management
• LTspice simulation for ambiguous circuits before fab

Deliverables:

• Schematic with full ERC sign-off
• PCB layout with DRC clean
• Production-ready Gerbers and drill files
• BOM and CPL formatted for JLCPCB PCBA
• Component sourcing from LCSC, Mouser, or DigiKey

I write firmware for Espressif chips in ESP-IDF, Nordic nRF52 in Zephyr, and STM32 bare metal when the project calls for minimal overhead — no need to drag in an RTOS or unused peripherals when a tight bare-metal implementation does the job for less money and less complexity.

Code is organized as components and libraries with clear task structure, real synchronization primitives, and attention to memory and stack usage. Logging is built in with proper levels so the device can actually be debugged in the field.

When the project is large enough and the logic is separable from hardware, I split it out and cover it with ctest unit tests on the host. On-device testing is rarely worth the effort for the kinds of projects I work on — testable architecture on the host gets you most of the benefit without the pain.

Platforms and protocols:

• ESP32 in ESP-IDF, nRF52 in Zephyr, STM32 bare metal
• BLE, WiFi, Zigbee, Thread, Matter, HomeKit, NFC, 433MHz
• LTE/GSM, Ethernet, CAN, I2C, SPI, UART

Beyond the basics:

• OTA update mechanisms
• WiFi onboarding through built-in web interfaces
• On-chip computer vision under tight memory/MCU constraints
• Host-side unit tests with ctest for separable logic

If you have a specific concern, that’s where I start. If the review is open-ended, I work through the design checking against component datasheets, manufacturer layout recommendations, and the usual failure points — wrong pinouts, broken impedance matching, missing decoupling, weak ground returns, footprints that don’t match the part, silkscreen that’ll be unreadable after assembly.

When a specific net or stage looks ambiguous, I’ll pull it into LTspice to confirm rather than guess.

You get a written report tied to your actual design — annotated screenshots, specific net and component callouts, and concrete suggested fixes. Not a generic checklist.

Most useful before:

• Placing a production order
• Tapeout or first prototype run
• Sign-off on a design from another engineer
• Debugging a board where you suspect a design issue

After review, the next question is usually whether the design works in copper. I can take that next step: order the board, bring it up on my bench, and verify the circuits behave as designed.

Bring-up means power-on sequencing checks, rail measurements under load, signal integrity on critical lines, peripheral validation, and chasing down anything that doesn’t match expectations. If a component value or pad needs adjustment, I tune it in place — full rework station, hot air, soldering iron, all the usual gear.

Equipment on bench:

• Oscilloscope with differential probe
• Logic analyzer
• Lab power supply with time-series logging
• Multimeter with data logging
• Rework station (iron, hot air, preheater)

Deliverables:

• Bring-up report with measurements and findings
• Annotated schematic/layout with recommended changes
• Validated board ready for production order

I model enclosures in Fusion 360 around your actual board — real dimensions, connector positions, mounting holes — measured from your design files or a physical sample. Complex parts get broken down into separate components that fit together, and everything is parametric — no hardcoded numbers, so dimensions can be adjusted later without rebuilding the model.

The design accounts for what FDM printing can actually do with the material you’re using. Clearances, wall thicknesses, snap fit geometry, and overhangs are tuned to the print. I work with PLA, TPU in different shores, PETG and its variants (HF, CF, translucent), and PCTG when you need real optical clarity. Nozzle selection depends on what the part needs: 0.2 for fine detail, 0.4 as default, 0.6 or 0.8 when speed and strength matter more than resolution.

I print test prototypes locally on a Bambu Lab P2S before declaring anything done. If you need printed parts shipped, I can hand off STLs or send them printed — by me directly or by courier in Serbia, internationally by courier service.

Deliverables:

• Fusion 360 source file (editable, parametric)
• STL and STEP exports
• Configured 3MF for slicing if requested
• Optional: printed parts shipped to you

I bring two angles to consulting work — deep technical experience across embedded systems, and years of running projects, managing teams, and launching products in corporate and startup environments.

On the technical side, I help with feature feasibility, chip selection, wireless protocol tradeoffs, power architecture, firmware approach, and manufacturing strategy. On the project side, I help scope what a project actually needs — which specialists you’ll have to bring in, whether certification applies, realistic timelines, and where the budget is going to land.

Useful for founders deciding whether to commit to a project, or for teams trying to figure out if their roadmap actually fits the resources they have.

Good for:

• Pre-project feasibility and scoping
• Architecture review before development starts
• Chip, protocol, and power decisions
• Team and timeline planning
• Pressure-testing a roadmap or existing approach