A builder shaped by electronics, machines and the maker scene.
My background is Industrial Electronics and Automation Engineering, but most of my work has grown outside a single discipline. I started in the maker/open-hardware world, building things because I wanted to understand them from the inside: electronics, mechanics, firmware, 3D printed parts, software tools and the documentation needed to make a project repeatable.
That way of working still defines the site. I am not trying to present a polished agency profile. I want this to be a clear technical archive of what I build, what I have learned, and how different layers of a system connect when the project has to work in the real world.
Open hardware roots, Game Boy hardware, automation and internal tools.
A strong part of my public work comes from open hardware and physical prototypes: projects like Little PnP, Mobility Shield, FaxiDraw, 3D printed mechanisms and electronics boards. Those projects are not just portfolio pieces; they are the path that taught me to connect mechanical constraints, PCB design, firmware, assembly, testing and documentation.
The Game Boy hardware ecosystem is one of the clearest examples of that mix. Cartridge flashers, flash carts, FRAM saves, RTC behavior, MBC mapper logic and CPLD/VHDL experiments all sit in the same space: old hardware, modern components, real users, small production and lots of practical debugging.
The private side of my work is more operational: inventory systems, barcode workflows, PHP/MySQL tools, automation prototypes, PLC/CAN/NMEA integrations and AI-assisted documentation workflows. I describe that work carefully, because some of it is internal or under NDA, but it is part of the same profile: making systems understandable and usable.
The useful work happens where disciplines overlap.
I like projects where the boundary is not clean. A cartridge is not only a PCB. A machine is not only mechanics. An inventory tool is not only a web app. The interesting part is usually the interface between the physical object, the control logic, the workflow around it and the documentation that keeps it maintainable.
That is why the same project can involve reading an old hardware bus, choosing modern memory, writing firmware, designing a small board, testing edge cases, preparing labels or fixtures, and then turning the result into notes that are useful months later.
Prototype honestly, then document what is worth keeping.
I am more interested in useful proof than in perfect presentation. A good prototype answers a specific question: does the circuit behave, does the mechanism move, does the bus communicate, does the workflow survive repetition, does the tool reduce friction?
- 01 Start from constraints. Power, space, timing, cost, tools, available components, maintainability and failure modes decide more than aesthetics.
- 02 Test one layer at a time. A small verified slice is better than a complete-looking system where the fault is hidden.
- 03 Make the next iteration easier. Notes, labels, measurements, revision history and checklists are part of the build, not paperwork after the fact.
Some projects can be opened. Some can only be explained safely.
Public projects can show details: revisions, circuits, decisions, failures, constraints and what changed over time. That is the ideal case, especially for open hardware and Game Boy work where the technical path is useful to others.
Private tools, client work and NDA automation projects are different. I can talk about the type of engineering involved — inventory systems, PLC logic, CAN/NMEA communication, sensors, actuators, internal workflows — but not expose client context, proprietary architecture or operational details.
JRodrigo.com is where scattered work becomes a coherent lab archive.
Some of my work has lived across old websites, GitHub repositories, Hackaday logs, Tindie products, local notes and private tools. This site is the attempt to bring that material into a clearer structure: Projects for builds, Notes for process, Wiki for references, and About for the context that connects it all.
I want the site to feel technical, personal and useful. Not a generic portfolio, not a startup landing page, not a fake command center. A place where someone can understand what I build, how I think, and why a small hardware project can involve electronics, automation, software and documentation at the same time.
