Project update #31415

September 7th, 2015 4 min read


This post is part of the Automatic Curtains series. Check out the other posts here:


    Ads via Carbon

    Without a doubt my automatic curtain project is the project I underestimated most. While most of the mechanical challenges are solved, the electronics part also has it’s hurdles. Time to give you an update …

    Fine-tuning the mechanics

    3 weeks ago I’ve mounted the Proof of Concept to test my mechanical design. While most if it functions great (and even better than expected), I found some minor issues …


    The endstop mounts get some heavy beating from time to time. Since I designed a mount that is only fixed on one side, the mounds tend to pivot. This eventually resulted in a fatal collision between one of the endstops and the belt tensioner.


    Luckily this is easy to solve, by designing an endstop that can’t pivot. I’ll also look into an rod mount which incorporates the endstop. Since that endstop doesn’t need to be adjustable.

    Sourcing the parts

    One of the tasks that takes up most of the time is sourcing all the parts needed for the final 4 units. Since a lot of the parts are ordered at Chinese suppliers (via eBay and AliExpress), delivery times are somewhat unpredictable.


    Using a Excel sheet, I keep an eye I everything I need to order, and what the state of the delivery is. It’s also is a good way to keep an eye on the cost. Of course, I’ll share my total costs list in the final post of this project.

    #Working on the electronics Two weeks ago I wrote about the issue on the communication between the motor controllers and the control unit. Since I2C wasn’t going to work, I opted to try out a ESP8266 powered motor controller.


    After playing around with this setup, I ran into a few issues:

    • I constantly run into the resets of the ESP8266. If you’ve ever played around with the ESP8266, you probably ran into this issue as well. rst cause:4 / wdt reset simply drive you nuts. There are many possible reasons for it, but not at all is this issue easy to solve.
    • The ESP8266 has a limited number of GPIO pins. I could solve this by hard wiring some of the stepper driver features, but this really limits me in possible changes to the software. (For instance: changing the step mode programmatically.)
    • Uploading to the ESP8266 is slow. And although this isn’t really an technical problem, it really slows down the development part of the project. It is just annoying.

    For now, I’ve set aside the idea of using the ESP8266 as the main motor controllers MCU’s. Especially since I want the system to be extremely stable. It must work by Apple’s philosophy:

    It just works

    Readers Tim and Mrik suggested to look into a RS485 line driver. Allowing up to 1 master and 10 slave units over a distance of up to 4000 ft. Additionally I still want to play around with the nRF24L01. In both cases I need to order some of these modules and IC’s. But as written before, the delivery of these parts could take a while …

    The way forward

    Since the sourcing of all the parts might take a while, and I still need to do some testing and prototyping before I finish up the final design of the motor controllers, It might take a while before I wrap up this project. But no worries, I promise to keep you up to date as soon as there is any progress.

    Luckily, in a few days or weeks my other project (probably my most impressive project ever) will need some extra time … But of course, I’ll keep you up to date on that as well. ;)

    Loading comments …
    ©2021 -