There was a several-years-long period of my life when I spent money to build a home theater. This was sometime after DVD became popular, because the motivation was my realization of how much superior DVD picture quality was over VHS. With movies on VHS, noisy visual artifacts were a limitation of the analog magnetic medium. With movies on DVD, the media-imposed limitations were gone and now there are all these other limitations I could remove by spending money, lots of it, to do things like upgrade from composite video to S-Video connections.
Eventually home theater moved to all digital HDMI, and I stopped spending big money because even the cheapest flat panels could completely eliminate classic CRT problems like color convergence. (My personal peeve.) I thought I have left the era of CRT and composite video behind, but throwing out my pile of analog interconnects and video equipment turned out to be premature.
Now I’ve found an interest in old school video again, because they are accessible for the electronics hobbyist. It is much easier to build something to output a composite video signal rather than HDMI. Local fellow maker and tinkerer Emily likes the old school tech for aesthetics reasons in addition to accessibility. So one day we got together at one of our regular SGVTech meets to dig a little deeper into this world.
All three were able to get the little TV to show a picture. However, they looked very different under the oscilloscope. The [name will be filled in once I remember] sketch had the wildest waveform whose oscilloscope trace didn’t look anything like a composite video signal, but the proof is in the fact an animated 3D vector graphic cube showed up on the TV anyway. The waveform generated by arduino-tvout was a little rougher than expected, but unlike the previous, it was clearly recognizable as a composite video waveform on the oscilloscope and accepted by the TV. Waveform generated by Bitluni is the best fit with we expected to see, and matched most closely with output generated by the composite video camera.
Knowledge from tonight’s investigation will inform several of our project candidates.
Lessons learned tonight:
– An analog video camera makes the platonic ideal of a composite video signal
– ESP32 makes a very respectable composite signal
– Arduino makes a terrible composite signal, but it totally works anyway because analog video is like that
An ESP32 plus Grbl motion control software seems like a good candidate for running an old industrial XY table, definitely promising enough to move forward with prototyping. I had originally intended to use an Olimex ESP32 DevKitC (*) as it was equipped with two rows of sockets. This is easy to connect with jumper wires while not leave pins exposed to risk of short circuits.
This plan was short lived, because I quickly ran into a problem: The ATmega at the heart of an Arduino is a beefy 5V part that can supply up to 40 mA per pin. In contrast, the ESP32 is rather delicate 3.3V part that should not exceed 12 mA per pin. The data sheet for the ZETA4 controller I want to connect to this board expects a minimum of 3.5V to signal step and direction, which means I need external components to shift the ESP32 voltage level up to what the ZETA4 expects. When I made this discovery I was momentarily tempted to switch back to an ATmega solution, but the siren call of higher performance carried me forward.
Since I would need external components, the project brain switched to my HiLetgo ESP32 development board (*) which is mostly identical but came equipped with two rows of pins appropriate for a breadboard. Four level-shifting units were installed, each built around a 2N2222A transistor. They were connected to the step and direction pins for X and Y axis, and each received a LED (and corresponding current-limiting resistor) to indicate activity.
Staying consistent with the system I used for Glow Flow, red LEDs indicate X axis activity and green LEDs indicate Y. These LEDs allowed me to perform a quick test to verify the presence of blinking activity. Next step: connected them to ZETA4 controller to see if the motors move as commanded.
(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.
I considered driving an old industrial XY table from a 3D printer controller board. I have a Melzi board on hand to use but its onboard stepper drivers were too well integrated to be easily adapted to this project. I considered running Marlin on an Arduino directly, but if I’m going to start building my own control board instead of one already tailored for Marlin, it makes sense to look at other options. Given the popularity of the Arduino platform, there’s more than one motion control project out there for me to consider.
Unlike Marlin, which is primarily focused on 3D printing, Grbl offers a more generalized motion control platform. Provisions already in the code include pen plotting, laser cutting, and 3-axis CNC milling. All of which could be done with Marlin as well, but with different amount of code modifications necessary.
But an even bigger advantage in favor of Grbl is the existence of an ESP32 port. Marlin’s development team is working on a 32-bit hardware abstraction layer (HAL) to take it beyond ATmega chips. It looks like they’re up and running ARM Cortex boards and have ambition to bring it to ESP32. But a Grbl ESP32 port is available today and stable enough for people to use in their projects.
The headline feature is, of course, speed. While AccelStepper topped out around 4 kHz pulses, Grbl on ATmega is good for approximately 30 kHz. Grbl on ESP32 claims “at least 4x the step rates” which is likely a very conservative claim. After all, we’re comparing an 8 MHz 8-bit chip to a 240 MHz 32-bit chip. Though running on the ESP32 does incur more overhead than bare-metal code running on an ATmega, which is important in time-sensitive applications like motion control.
There are upsides for this real time operating system (FreeRTOS) overhead, as it allows the ESP32 to handle things beyond motion control. The best part employs its WiFi module to present a web-based control interface. A control interface would have required additional hardware in a Grbl machine built around an ATmega, but with Grbl on ESP32 I just need a web browser to start testing.
As a thanks for participating in the ESP32 mesh network project by Morgan and Ben, people whose badges became nodes on the network were generously gifted the ESP32 module mounted to each of our badges. Unfortunately, I managed to damage mine before the big stage demo so sadly I didn’t put in the honest work to earn that ESP32. Still, I now have a damaged ESP32 that I can try to fix.
Before I start trying to fix it, though, I should have a better idea on how to tell if a ESP32 is up and running. The only mechanism I had before was to run the badge mesh network app and see if there’s any response, but I want to know more about how a ESP32 works in order to better tell what’s broken from what’s working. Also – since I’ve desoldered my ESP32 from the carrier board, it is not nearly as easy to test it against the badge.
I’ve read about a lot of projects built using the ESP32 on Hackaday, so I know it’s popular for and it would be cool to add it to my own project toolbox. Given its popularity, I thought it wouldn’t be a problem to find resource on the internet to get started.
I was right, and wrong. There is no shortage of information on the internet, the problem is that there’s too muchinformation. A beginner like myself gets easily disoriented with the fire hose of data presented by ESP32.net.
How about other individual tinkerer’s adventures on their own blogs? Here’s one person’s initial report poking around an ESP32, including using an oscilloscope to see how quickly it can change output based on input. And here’s another Hello World, and there are many more blogs covering ESP32. (Soon including this one, I suspect.)
It’s going to take a while for me to get oriented, but it should be fun.
In the pre-Superconference badge hacking call to action, wireless badge communication was raised as a specific challenge laid out for attendees to tackle. One particularly ambitious effort was to build a mesh network for wireless communication using ESP32 modules mounted to the badge expansion header. The ESP32 mounting system is straightforward, it was the software that would prove to be tricky.
At the end of the weekend, Morgan and Ben got the network up and running with just over an hour to spare. They started recruiting people to join their IRC-style chat network for the final demo, and I signed up. In the test session I was able to see messages sent over the network, and send a few myself. But when it came time for the actual demo on stage, my badge was unable to connect! Fortunately they had enough other participants so my participation was not critical, but I was sad to have missed out. After the presentation (and winning a prize) the team told everyone on the network we could keep the ESP32 as a token of thanks.
After the conference I examined my ESP32 mount and found a few cracked solder joints. It looks like I had accidentally smashed my ESP32 module sometime between the test session and the presentation. Looking on the Hackaday.io project page, I found the simple schematic and tested connections using my multimeter. Several connections were indeed severed between the badge header and the mounting circuit board. I tried the easy thing first by reheating all the solder to see if they could bridge the gaps. This helped, but two lines remain faulty and were patched with wires.
After this patch, I tested with [mle_makes] ESP32-equipped badge and we could not communicate, indicating further problems with my ESP32. The next step is to desolder it from the board to see if I could use the ESP32 as a standalone module. Once the module was removed from the carrier board, I saw a problem: three of the pads had separated from the module, one of them being the EN(able) pin critical to a healthy ESP32. The other two damaged pads (IO34 and IO35) I hope I could live without.
Is this the end of the road for my gifted ESP32? I thought it was, but [mle_makes] disagrees. The next experiment is to try soldering to the trace leading to EN pad, or the via further inboard. This will be a significant challenge – that via is smaller than the tip of my soldering iron!