12/20/2025 - Started building RotorRig test bench and first prototype

The idea for this project started about a month and a half ago, when I began seriously exploring custom BLDC motors—specifically alternative core materials. I quickly realized that producing custom ferrite motor cores is extremely expensive, which pushed me to look for other technologies. That’s when I discovered Soft Magnetic Composites (SMC) and decided to experiment with recreating them on a small, DIY scale.

Very early on, it became clear that none of this would make sense without a proper way to measure and compare motors objectively. Around a month ago, I decided that I needed to build a dedicated BLDC motor test bench to validate any future work on custom stators, winding schemes, and motor geometry.

About three weeks ago, I officially started working on what later became RotorRig. The first step was defining what the platform actually needed: which parameters to measure, which components to use, and how to keep the design as simple and cost-effective as possible. I spent roughly 10 hours researching sensors, measurement methods, ESC communication, and overall system architecture.

Once the concept was clear, I designed the full electrical schematic in KiCad, covering all required connections and interfaces. From there, I moved on to designing the PCB. The board was then hand-assembled, hand-wired where necessary, carefully soldered, and mechanically finished.

With the electronics complete, I designed a dedicated enclosure in Fusion 360. The enclosure was sliced, 3D printed, post-processed, and assembled together with the electronics, resulting in the first physical prototype of the RotorRig platform.

At this stage, the build mainly serves as the electronic and structural foundation of the system. The next step is to design the mechanical test stand itself: a rigid structure that integrates the load cell, motor mount, and thrust arm into a single, well-defined geometry. This part of the system is critical for achieving accurate and repeatable thrust measurements, as it ensures that different motors can be tested under identical conditions.

Once the mechanical test stand is complete, the focus will shift to firmware development—bringing together sensor data, ESC communication, and automated test routines to turn RotorRig into a fully repeatable and objective BLDC motor testing platform.

12/23/2025 - Built load cell mount and motor test stand structure

This update focuses on the mechanical side of the RotorRig test bench.

I started by sourcing metal scrap—three steel pieces—which I then machined into the required shapes.

After cutting, drilling mounting holes, and welding the parts together, I created a rigid steel base intended to support the load cell assembly. This structure forms the foundation of the thrust measurement system.

Next, I designed the interface between the steel base and the load cell itself. This included the load cell mount, a sub-mount to properly constrain the beam, and the mechanical connection that transfers thrust forces accurately into the sensor. I also designed the motor mounting components that attach to the load cell assembly while maintaining a well-defined and repeatable geometry.

All required mechanical parts were modeled, 3D printed, and test-fitted to ensure proper alignment between the steel base, load cell, and motor mount. This step was crucial to verify that the mechanical load path is clean and that unwanted flex or misalignment is minimized.

The next steps are to finish the steel base (surface preparation and painting) and to refine the lower printed components for better airflow and cleaner aerodynamics. I will also finalize the mechanical connection between the steel structure and the load cell assembly to prepare the system for calibration and firmware integration.

12/25/2025 2 PM - Painted and protected steel base; planned next steps

In this update, I focused on finishing and protecting the mechanical base of the test stand.

The steel structure forming the foundation of the load cell assembly was surface-prepared and painted using a protective metal coating. This step improves corrosion resistance and ensures long-term durability of the test stand during repeated motor testing.

With the steel base finished, the next step is to refine the lower 3D-printed part that interfaces with the load cell. The goal is to improve its geometry for better airflow and a cleaner aerodynamic profile, while also finalizing the mechanical connection between the printed components and the steel structure.

After completing these mechanical refinements, I will move on to firmware development, integrating sensor readings and preparing the system for calibration and automated motor testing.

12/25/2025 8 PM - Finalized lower mount and assembled full test stand

In this update, I finalized the mechanical assembly of the RotorRig test stand.

I redesigned the lower 3D-printed component that interfaces with the load cell, improving its geometry and overall fit within the test stand. The updated part was printed, test-fitted, and fully assembled together with the steel base, load cell, and motor mount.

With all mechanical components now installed and aligned, the physical structure of the test stand is complete. This marks the end of the main mechanical development phase and provides a stable, repeatable platform for thrust measurements.

The next step is to begin firmware development. This will involve bringing up sensor interfaces, implementing measurement logic, and preparing the system for calibration and automated BLDC motor testing.

12/28/2025 - Started firmware development and sensor data logging

In this update, I started working on the firmware for RotorRig.

While firmware development is not my primary background, I began by focusing on building a clear and reliable software foundation. With iterative development and assisted problem-solving, I implemented an initial firmware version that periodically reads all required sensors and outputs their values to the serial monitor.

At the current stage, the system logs all available measurement data at a fixed interval (approximately every 100 ms). This confirms that sensor communication, timing, and data flow are working as expected. Although the sensors are not yet calibrated, the firmware already provides a complete overview of all raw measurements needed for the test bench.

The next steps are to implement proper calibration routines for each sensor and improve measurement stability and accuracy. Once reliable and repeatable readings are achieved, the firmware will be extended to log structured data to CSV files, enabling automated analysis and comparison of BLDC motor performance.

12/29/2025 - Load cell calibration attempt and firmware issues

In this update, I worked on calibrating the load cell, which was the first sensor I focused on in firmware.

I am not very experienced with firmware development, so most of the code was written using an AI-assisted, “vibe coding” approach. I worked by experimenting, modifying the code step by step, and checking results directly in the serial output.

I implemented two basic commands: TARE, which zeroes the load cell, and CAL, which applies a known reference weight. Using a 1000 g calibration mass, I was able to issue a calibration command while the weight was applied and scale the load cell accordingly.

At first, the calibration did not behave correctly. Even after taring and calibrating, measurements would drift, return negative values after removing the load, or scale incorrectly when different weights were applied. After spending more time adjusting the code with AI assistance, I eventually reached a point where the load cell readings were very close to those of a precision jewelry scale.

Later, I noticed that calibration values were not being saved. After power cycling the device, both TARE and CAL had to be repeated, which was not practical for a test stand intended to operate under consistent conditions. I then tried to add saving of calibration data, again with AI-assisted code changes.

During this process, parts of the firmware became misconfigured. Calibration values were written incorrectly, sensor logs became unstable, and eventually the firmware stopped working as intended.

On the image above, the load cell log columns marked in red show NA values, meaning the data was not logged at all.

At that point, only some values, such as input voltage, were still logged correctly, while the load cell outputs appeared intermittently or produced invalid data.

On the image above, the load cell values marked in red appear inconsistently and do not match the applied load, even when calibration and taring were previously correct.

I attempted to recover an earlier working version of the code, but since it had not been saved properly, I was unable to restore it. After several hours of trying to fix the broken state, I decided to stop and restart the firmware development from scratch, this time rebuilding the system step by step.

1/15/2026 - Recovered firmware readings and saved baseline

After a short break, I managed to restore stable readings from all sensors except the load cell.

I rebuilt the firmware to a point where all non-load-cell data is being read correctly again. Once the readings were working as expected, I created a clean copy of the code and saved it as a baseline to avoid losing a working state again.

At this stage, the focus shifts back to the load cell. The next step is to reimplement proper calibration, verify correct and repeatable readings, and add reliable saving of calibration data. I plan to fully refine the load cell handling before integrating it back into the rest of the firmware.

For now, the load cell shows incorrect behavior. On the image above, a large load value is displayed even with no weight applied, indicating an invalid or uncalibrated reading.

Further development steps will depend on how this calibration process goes.

1/16/2026 - Improved load cell accuracy and calibration storage

In this update, I focused on improving the accuracy and stability of the load cell measurements.

After several hours of tuning and testing, I managed to reach a point where the load cell readings are stable and consistent. While not perfectly constant, the measurements now fluctuate within a small range of about 3–4 grams. With higher applied loads, the deviation is even smaller, dropping to around 2 grams.

I also finalized calibration storage, so the calibration values are now preserved after reconnecting or restarting the device. This means the load cell no longer needs to be recalibrated every time. Taring also works reliably and behaves as expected.

At this stage, the measurement quality is good enough to move forward, although I may still attempt small refinements to further reduce deviation if needed.

On the image above, the serial log shows a test with a known load of 1057 g placed on the load cell.

The next step is to integrate this finalized load cell handling back into the main firmware, which also reads the remaining sensors. So far, this work was done in isolation on the HX711 interface, and now it needs to be merged into the full system.

1/18/2026 - Integrated load cell and ESC data into full firmware

In this update, I integrated the load cell readings back into the main firmware and connected them with the rest of the system.

The firmware now combines load cell measurements with motor control and telemetry from the ESC. This includes reading electronic RPM (eRPM) directly from the ESC, alongside the previously implemented sensor data. At this stage, all required values are being read correctly within a single program.

Due to the increased amount of data being processed and transmitted, some measurements—especially from the load cell—are now updated more slowly than before. The next step is to review timing, data flow, and update rates to ensure that all values are transmitted reliably and without unintended delays, misalignment, or data corruption.

Overall, the system is now functionally complete in terms of data acquisition. The remaining tasks are to stabilize update timing and implement structured logging of all measurements into CSV files for later analysis.

1/29/2026 - Stabilized data, added CSV logging, ran first test

In this update, I focused on improving data stability, adding CSV logging, and running the first automated test cycle.

First, I worked on making the sensor readings more stable by reorganizing parts of the firmware so different tasks and readings don’t interfere with each other. After these changes, the values looked consistent and the previous issues with unstable updates were largely gone.

Once the data was stable, I moved to logging. I implemented sending and saving measurements into CSV files, with organized file naming so each run is saved separately with its own date/time. I also added proper CSV headers with column names so the logs are readable immediately.

On the image above, you can see an example of the logged data from the test run.

After that, I added an automatic test cycle intended to be reusable for any motor. I refined how the cycle runs to minimize disturbances in the measurements and make results easier to compare across different motors.

When everything looked stable, I ran the cycle on a motor and checked safety behavior (stop commands, shutdown logic, etc.). The automated ramp-up and the cycle itself worked, but during a high-RPM stop test I saw a spark and immediately cut power. I suspect that stopping too aggressively from a high speed caused a voltage spike that stressed the ESC and likely finished off a capacitor that was already slightly weakened.

At first I didn’t know what failed, but after checking the ESC I found a damaged capacitor by doing a short/continuity check. On the image above, the failed capacitor is marked and shown removed (desoldered). The ESC initially appeared shorted, but after identifying the faulty part and removing it, the short was no longer present.

I have already ordered a new ESC for proper future testing. For “rough” tests I may still use the old ESC carefully, but before continuing with serious runs I want to confirm the platform is safe. The next step is to improve the stopping behavior by adding a buffer/soft-stop so excess energy is handled more safely, and to review other protections before running more repeated tests.

After that, I plan to run many real tests to verify repeatability, compare motors properly, and build a workflow that makes analyzing and comparing results fast and reliable.

1/31/2026 - Reinforced mount, added soft stop, first test

In this update, I focused on mechanical reinforcement, improving the stop behavior, and running the first test.

Yesterday, I worked on improving the lower part of the base that holds the load cell. I adjusted the model to strengthen the structure without increasing its size in critical areas. As part of this change, I added two holes and inserted metal pins to reinforce the lower section. This reinforcement was not strictly necessary, but it improves overall rigidity and safety.

Today, I focused on fixing the stop behavior to prevent a repeat of the ESC failure caused by a current or voltage spike. I changed the stop function from an abrupt shutdown to a smooth deceleration over approximately 2.5 seconds. After testing, this approach appears to be safer both for the electronics and for the surrounding hardware.

I also ran the first full platform test with a propeller installed. During this test, I encountered an important limitation that I had not considered earlier: the power supply is not able to deliver enough current for proper motor operation. At around 70% throttle, the motor reaches the maximum current the power supply can provide. This is especially important because the motor currently used for testing is weaker than the motor planned for final use.

At this point, I am considering whether to switch to a higher-current bench power supply or move to a LiPo battery. Initially, the goal was to use a bench supply for more controlled and precise testing, but the cost of sufficiently powerful supplies makes the LiPo option increasingly attractive.

2/1/2026 - Chose a high-current PSU solution for RotorRig bench

Today I focused on finding a practical power source for the RotorRig test bench, and it turned out to be harder than expected.

I seriously considered using large LiPo batteries, but I don’t like the idea of charging packs after every test and waiting for charge cycles (and potentially needing faster chargers). I also looked at laboratory bench power supplies, but even the cheapest options I found that met my requirements (often from China) are around 900 PLN (~€210), which is simply too expensive for my budget.

After more searching, I started looking into server power supplies. There are many available on the used market, they’re relatively cheap, and they can deliver very high current. Typical prices are around 120 PLN (~€28), which makes them a much more attractive option compared to laboratory supplies. The main downside is that most of them output 12V, while my target test voltage is closer to a 4S LiPo equivalent.

I explored options like using a high-power DC-DC step-up converter, but it’s difficult to find reliable converters for this current range. I also considered running two server PSUs in series for ~24V, but that requires isolating ground from the chassis, which is not something I want to rely on for safety reasons.

Eventually, I found a repository that directly addresses the exact PSU model I was already planning to buy: HP HSTNS-PD30. It explains how to increase the output voltage and also how to deal with the over-voltage protection (OVP), which normally shuts the supply down when you try to raise the voltage. The repo includes calculations and a clear modification plan, which helped a lot.

https://github.com/darwinbeing/HPServerPSUHack

Based on this, I’m ordering the PSU today and my next step will be to modify it to match my test requirements (aiming for a 4S-equivalent voltage range) and then integrate it into the test bench for repeatable motor testing.

2/4/2026 - Brought up server PSU and completed full autotest

Today the server power supply arrived, and I focused on bringing it up and testing it with the platform.

The first thing I did was disassemble the PSU to verify whether its internal electronics matched the revision described in the repository I had been referencing earlier. It turned out that the internal PCB layout was different. However, I managed to find forum post (https://www.eevblog.com/forum/projects/hp-hstns-pd30-voltage-mod/msg4677619/#msg4677619) that documented the same PSU model but in a different revision, including a method to bypass the protection I’m interested in.

For now, I did not modify the protection circuitry and kept the power supply running at its nominal 12.3V output. I started by soldering an xt-90 power connector and adding a 10 ohm resistor required to put the PSU into the enabled state. After that, I performed basic checks and measurements to confirm that the supply was operating correctly.

I also prepared dedicated power cables for the test bench and moved on to testing. Initially, I ran manual checks, and later I enabled the automated test routine. The full autotest completed successfully. During the test, the maximum current draw reached around 16 A, corresponding to roughly 200 W, and the power supply maintained a stable output voltage without any issues.

Compared to my previous power source, this PSU performed significantly better. After the test, I reviewed all recorded data, looking for warnings, flags, or signs of unstable measurements, but I didn’t notice anything concerning. The results look stable and very promising.

I still need to decide whether it makes sense to increase the output voltage by bypassing the over-voltage protection. Doing so carries some risk of damaging the power supply, but reaching a 4S-equivalent nominal voltage would allow more accurate and representative motor tests. For now, this is something I need to think through before deciding whether to modify the PSU further or keep it at the stock voltage.

Next, I plan to add a few small improvements to the firmware and design an enclosure for the power supply, since the positive and negative bus bars are currently exposed. I also plan to replace the previously damaged ESC with a new one that has already arrived, which will be used for future tests.

Here is the full log file from a complete test run.
195836_s002

2/7/2026 - Designed and built enclosure for server power supply

Today I focused on designing, printing, and assembling an enclosure for the server power supply.

The main goal was to protect the PSU from accidental shorts and external contact. I didn’t want any exposed terminals or conductors that could be shorted or damaged, so enclosing the power supply was an important safety step.

I started by designing small test parts to check fit and clearances before committing to a full print. These smaller prints helped me verify tolerances and adjust the model without wasting material or time. Once the fit was correct, I designed the complete enclosure and printed all remaining parts.

After printing, I assembled the enclosure and added a rocker switch wired in series with a 10 ohm resistor. The switch was soldered to pins 33 and 36 and allows the power supply to be enabled or disabled without physically unplugging it from mains power. After assembly, I closed the enclosure and verified that everything worked correctly.

At this point, the PSU is mechanically protected and safer to use during testing. I’m still considering whether to increase the output voltage by modifying the power supply, and I haven’t made a final decision on that yet.

As mentioned earlier, there are also a few small firmware improvements still left to do. With those remaining tasks, the test bench is getting close to its final form.

2/10/2026 - Raised server PSU output to 4S-equivalent voltage

In this update, I worked on increasing the output voltage of the server power supply to better match a 4S battery configuration.

Initially, the PSU was running at its nominal 12.3 V output, which is slightly too low for representative 4S testing. I wanted to get as close as possible to real battery conditions while avoiding unnecessary risk. After reading forum discussions and datasheets, I decided to target 14.8 V, which corresponds to the nominal voltage of a 4S LiPo pack (3.7 V per cell). This voltage is also safely below 16 V, which is important since some PSU components, such as capacitors, may be rated close to that limit.

I started by disassembling the power supply and reviewing the documentation and forum posts related to this specific model. First, I tried using the same resistor values described by another author, but the over-voltage protection (OVP) kept triggering immediately. Each time, the PSU had to be manually reset before it could start again.

Next, I connected a potentiometer to experiment with the voltage-setting network. Even then, I couldn’t push the output beyond about 13.4–13.8 V, despite multiple attempts with different resistor values. After around fifteen tries, it became clear that something was still wrong with the OVP circuit.

At that point, I discovered that a resistor connected to the LM393 comparator had been accidentally wired to pin 4 (ground) instead of pin 3. Fortunately, this mistake didn’t damage anything. After correcting the connection and power-cycling the PSU, the OVP threshold shifted and I was able to reach around 14.2V.

From there, I ran a few more tests with different resistor values between ground and pin 3 of the comparator to fine-tune the OVP behavior. Once the protection threshold was set correctly, I manually adjusted the voltage using the potentiometer, measured its final resistance, and replaced it with a fixed resistor. With this setup, the PSU now reliably outputs a stable 14.8 V after each power-up.

I haven’t tested the power supply under higher load yet, so that will most likely be done next. Aside from that, only a few small firmware tweaks remain.

2/11/2026 3 PM - Load test revealed PSU shutdown under load

In this update, I tested the modified power supply at the new 14.8 V output under load.

During testing at close to 30% throttle, with current draw around 2 A (from what I observed), the PSU began shutting down. Each time this happened, the power supply had to be manually reset before it could be started again. I repeated the test several times, and the shutdown occurred consistently under similar conditions.

At this stage, I am investigating the possible cause of the issue. It could be related to voltage spikes or drops under load, or possibly transient behavior during motor acceleration. Another possibility is that the relatively long power cables are introducing instability or unwanted voltage fluctuations.

For now, I need to run additional tests and measurements to determine what exactly is triggering the shutdown and then attempt to correct it.

2/11/2026 10 PM - Fixed PSU shutdown and stabilized voltage under load

In this update, I focused on solving the issue where the modified 14.8 V server PSU was shutting down during load tests.

The investigation started unintentionally. While measuring different parameters with a multimeter, I connected the PSU to the resistive load using thinner wires than before. Surprisingly, the shutdown issue disappeared. The PSU no longer turned off at the point where it had previously failed.

After analyzing the situation, the most reasonable explanation was that the thinner wires introduced additional resistance, which helped damp voltage spikes generated by the test platform. Originally, when the PSU was running at 12.3 V, the over-voltage protection (OVP) was set around 13.4 V — leaving more than 1 V of headroom. After increasing the output to 14.8 V, the margin between nominal voltage and OVP was only about 0.1 V. This made the system very sensitive to transient voltage spikes, causing repeated shutdowns.

To address this, I adjusted the OVP threshold by changing the resistor value on the comparator circuit from 51 k ohm to 47 k ohm. This increased the margin to about 0.4–0.5 V above the 14.8 V output. I deliberately avoided increasing it further, since going too close to 16 V would be risky — the PSU capacitors are rated at 16 V.

After this change, I tested the platform without a propeller, and the PSU no longer shut down under conditions that previously caused failure. However, during the first propeller test, the PSU shut down again, this time at higher RPM than before.

Since raising the OVP threshold further was not a safe option, I explored another solution: adding output capacitance to reduce voltage spikes. I installed two 1000 µF, 25 V electrolytic capacitors at the PSU output. During the next test run, the platform completed the full measurement cycle without any shutdowns. Voltage remained stable and no irregularities were observed in the data.

At this stage, the system appears stable under load.

Next, I plan to redesign the electronics enclosure to accommodate additional capacitors. I also want to purchase higher-quality capacitors with lower ESR, as the current ones are not ideal. I am also considering adding active cooling for the ESC. Additionally, I still need to replace the previously damaged ESC and program it properly.

The platform is getting very close to completion.

If anyone is interested, the full log from the successful test run is attached below.
194447_s003

2/17/2026 - New enclosure for capacitors and ESC cooling

In this update, I focused on redesigning the enclosure to accommodate the upgraded power stage.

The new high-quality capacitors I ordered finally arrived, and integrating them required significantly more space than the previous enclosure allowed. Because of this, I had to design a completely new housing for the electronics.

The redesign was more complex than expected. I had to consider multiple constraints at once:
– proper distance between power connectors and internal wiring,
– positioning of the capacitors relative to the ESC,
– adding cooling for the ESC,
– introducing separate connectors so the load cell and motors can be connected and disconnected independently.

Combining all of these requirements into a single enclosure made the design process challenging. The final model is not the simplest design, and I’m not completely satisfied with its form, but it should meet the functional requirements.

A significant amount of time went into simply figuring out how to arrange everything inside the enclosure before even starting detailed modeling. The planning alone took several hours, followed by modeling and iterative adjustments.

The print has just started, and by tonight I should know whether everything fits as intended. If the enclosure works, the next steps are to test the system with the new capacitors under load, program the new ESC, reassemble the platform, and apply final firmware refinements.

The platform is getting very close to its final form.

2/20/2026 - Final assembly with low-ESR caps and full test

In this update, I completed the new enclosure assembly and tested the system with the upgraded capacitors.

The enclosure finished printing, and I cleaned and prepared all parts before assembling the electronics. I soldered the new low-ESR capacitors onto a dedicated board and integrated everything into the new housing.

During assembly, I realized that a few elements did not fit exactly as planned. The capacitors were slightly larger than expected, so I had to modify the enclosure to create additional clearance. After making those adjustments, I reassembled the entire system.

I also removed the previously damaged ESC and replaced it with a new one. The new ESC was flashed with the appropriate firmware and prepared for testing. Additionally, I attached a heatsink to improve heat dissipation during higher load tests.

With everything installed, I began testing the platform to evaluate how the new capacitors perform under load. I ran a full test cycle, and the results were very stable. There were no PSU shutdowns and no over-voltage protection triggers. The voltage remained stable throughout the test.

The low-ESR capacitors appear to be doing their job effectively, and at this point the power stage looks much more reliable than before.

The new enclosure also includes dedicated connectors for the motor and a separate connector for the electronics, which allows me to disconnect components independently instead of having fixed wiring. This makes the system more modular and easier to work with.

The test results look promising. The next steps are small firmware refinements, adding configuration options, and including motor/test metadata in the logs.

2/22/2026 - Final firmware updates and metadata system added

In this update, I completed what I consider to be the final firmware refinements for RotorRig v1.

I added a setmeta function that allows storing structured metadata about each test. This includes information such as motor ID, component identifiers, propeller configuration, and other relevant test parameters. The metadata can be configured and is saved together with the test data, making each log self-contained and easier to analyze later.

At this point, the firmware feels complete and stable.

The next step is to create a proper GitHub repository, organize the full project structure, make the CAD files look just right, prepare renders, and document everything clearly before submitting the project.

RotorRig is now very close to its first complete release.

2/24/2026 - Completed full CAD assembly and final renders

Over the past two days, I focused on preparing a complete CAD assembly of the entire RotorRig platform.

I created a full assembly model including all major components: mechanical structure, electronics, connectors, power stage, and mounting elements.

After completing the assembly, I moved on to rendering. I learned the full rendering workflow and created high-quality renders of the project. These visuals will be used for documentation and presentation.

With the CAD model and renders complete, the next step is to prepare a full BOM (Bill of Materials) and organize the project files into clean repositories. I will also structure the remaining documentation to make the project clear and reproducible.

The project is now transitioning from development to documentation and final packaging.

2/25/2026 - Prepared full BOM and refined wiring layout

In this update, I focused on documentation and electrical refinement of the platform.

I started preparing a complete BOM file, including all components used in the build. The goal is to list every part with proper specifications and links, so the system can be reproduced or modified more easily.

At the same time, I refined the wiring layout of the platform. I reviewed all connections and organized the power and signal wiring to make the system clearer and more structured.

The next stage will focus on final polishing, minor improvements, and preparing everything for submission.

2/26/2026 - Published full repository and completed RotorRig v1

This marks the completion of RotorRig v1.

Today I finalized and published the full GitHub repository. The repository includes firmware, CAD files, documentation, BOM, wiring overview, and all relevant project information. I structured everything to be as clear and reproducible as possible so that someone else could rebuild or study the system without missing key details.

https://github.com/GrzegorzG7/RotorRig-V1.0

At this point, the platform is fully functional:

• stable power stage at 14.8 V,
• load cell measurement with persistent calibration,
• ESC control and eRPM reading,
• automated test cycles,
• structured CSV logging with metadata,
• documented hardware and wiring.

Although the system works and performs reliably, I am not fully satisfied with its overall form and flexibility. If I were to redesign it from scratch, I would aim for a more modular and universal structure, capable of handling a wider range of motor sizes and power levels more cleanly.

Because of that, I am already thinking about a future RotorRig v2, which would include structural improvements, better scalability, and design optimizations based on everything learned during this build.

For now, RotorRig v1 is complete.

3/27/2026 - Final demo of completed RotorRig v1

RotorRig v1 is now physically completed, assembled, and tested.

This entry serves as the final build confirmation for Blueprint ticket review.

I added a working demo video showing the finished system in operation, including the measurement workflow and data logging behavior. The platform has been built, documented, and validated through repeated real tests.

Final demo:
https://www.youtube.com/watch?v=Id9lE1mXQ0A

At this point, the project includes:

• completed physical build,
• working firmware,
• functional thrust / RPM / voltage / current logging,
• automated test workflow,
• full documentation and repository.

This project was submitted as a completed build for tickets, with hands-on work logged in the journal across the full development process.

4/15/2026 - Validation tests with stock, hand-wound, and ABS-core motor

In this update, I used the finished RotorRig platform for one more practical validation step: comparing several motor variants that represent the exact type of work this tester was built for.

The main goal of RotorRig was never just to measure one stock motor, but to make repeatable comparisons between different winding approaches and stator designs. Because of that, I wanted to finish this stage of the project by running real comparison tests on three configurations:

• a stock purchased 3115 motor,
• a hand-wound motor built on an original steel stator,
• an experimental hand-wound motor built on a 3D-printed ABS stator core.

Before testing the custom variants, I first repeated the stock 3115 test three times to check repeatability of the platform itself. The results were very consistent across the three runs, with only small variation in RPM, power, and thrust. That gave me confidence that RotorRig is stable enough to make meaningful apples-to-apples comparisons rather than random one-off measurements.

For the custom variants, I had to create a way to mount and test my own wound motors on the same platform and with the same rotor bell. This took much more effort than it may seem from this single entry, and I am intentionally not describing that entire development process here because it could easily become a separate project on its own.

At first, I tried to go further and print the entire bell / rotor housing in ABS and fill it with magnets. In practice, that approach did not work well enough. The biggest issue was shaft alignment and runout — the assembly ended up too crooked to be useful for proper testing.

Because of that, I changed direction and decided to reuse the original bell from the purchased motor. That made the comparison more meaningful anyway, since the rotor geometry and magnet arrangement stayed closer to the stock configuration. From there, I focused only on building custom stator-side solutions: mounting structure, bearing support, and the stator variants themselves.

I prepared two custom comparison motors:
first, a hand-wound version on an original 3115 stator,
and second, a fully experimental ABS-core version with its own printed stator body and bearing support.

Getting the stator support to work reliably was not trivial. The part is small, thin, and must keep the bearings and shaft geometry aligned with tight tolerances. That is not an easy job for a printed part, especially when mechanical stiffness and heat resistance both matter. After several iterations, I finally arrived at a version that was usable for testing.

Once the comparison motors were assembled, I ran them on RotorRig and logged the measurements to CSV.

The stock 3115 motor served as the baseline. Averaged across three repeated runs, it produced about:

1461 RPM / 3.62 W / 10.84 g at 10% throttle,
2788 RPM / 9.89 W / 43.84 g at 20% throttle,
4030 RPM / 19.29 W / 97.93 g at 30% throttle.

The hand-wound motor on the original steel stator behaved in a very interesting way. Compared to the stock motor, it reached slightly higher RPM and thrust at the same throttle, but it also consumed more input power. For example, it produced about:

1498 RPM / 4.10 W / 16.41 g at 10%,
2860 RPM / 11.03 W / 49.64 g at 20%,
4151 RPM / 21.70 W / 111.28 g at 30%.

So the rewound version was clearly stronger, but not dramatically more efficient overall. In other words, the new winding improved output, but it did not create a free performance gain — the extra RPM and thrust came with a power cost. That is exactly the kind of tradeoff this platform is supposed to reveal.

The ABS-core motor was the most experimental and also the most surprising result.

Its startup behavior was already difficult. It needed much more help to start reliably, and the behavior was clearly very different from a motor built on a normal laminated steel stator. Once it did spin up, however, it accelerated much more aggressively than expected.

At 10% throttle it already reached about 4067 RPM while drawing 45.45 W and producing 91.11 g of thrust.
At 20% throttle it reached about 5892 RPM, 166.11 W, and 198.97 g.
At 30% throttle, during the first seconds before failure progressed, it was averaging roughly 6.7k RPM and about 339 W, with thrust climbing past 250 g.

That result was not sustainable. The current became very high, the windings had no good thermal path into a metal core, the ABS structure started softening, and the geometry of the stator began to deform. Eventually the motor effectively destroyed the ABS stator during the test.

My current interpretation is that two major issues caused this behavior:
first, the lack of a proper laminated ferromagnetic stator core changed the magnetic behavior of the motor dramatically, which likely contributed to the unusual startup and high-speed behavior;
second, the thermal situation was extremely poor, because the coil heat had nowhere meaningful to go. Instead of being conducted into a steel core, the heat stayed concentrated in and around the windings and printed structure until the ABS softened and failed.

Even though the ABS-core variant failed, I still consider this test valuable. In fact, it is one of the best demonstrations so far of why RotorRig is useful. The platform did not just show that one motor was “better” or “worse” — it exposed real differences in startup behavior, RPM, power draw, thrust, thermal limits, and failure mode between different stator approaches.

This is exactly the kind of data I wanted RotorRig to make accessible:
not just a bench for measuring thrust, but a tool for quickly validating ideas and seeing what changes in winding and stator geometry actually do in practice.

I attached the CSV logs from these tests below:

• three repeated baseline runs of the stock 3115 motor,

Stockpurchased3115motortest1

Stockpurchased3115motortest2

Stockpurchased3115motortest3

• one run of the hand-wound steel-stator motor,

Handwoundsteel

• one run of the ABS-core motor.

Abscorestator

At this point, the platform has already proven useful for real comparison work, and these results also point directly toward future experiments with other stator manufacturing approaches.