So, this year, when I was taking the heater out of storage, I accidentally dropped it on the floor, and after that it wouldn’t turn on again. Clumsiness is not covered by warranty, so that’s a loss, right? Nope! I actually managed to fix the unit myself, and I also replaced the thermostat with a much better one while I was at it! This is an account of how it went.

Disclaimers

THIS ARTICLE IS PROVIDED “AS-IS” AND IS MEANT FOR EDUCATIONAL PURPOSES ONLY. IT IS AN ACCOUNT OF EVENTS AND NOT A GUIDE TO BE FOLLOWED. THE AUTHOR OF THIS ARTICLE DOES NOT TAKE RESPONSIBILITY FOR ANY DAMAGE CAUSED BY ATTEMPTS TO REPLICATE THE EVENTS DESCRIBED IN IT.

HANDLING HIGH VOLTAGE WITHOUT SPECIAL TRAINING CAN CAUSE DEATH OR SERIOUS INJURY. DO NOT OPEN THE CASE OF A HIGH-VOLTAGE DEVICE IF YOU DO NOT HAVE SPECIAL TRAINING.

OPENING THE CASE OF ANY ELECTRONIC DEVICE WILL VOID ITS WARRANTY.

Assessing the damage

Opening the case reveals two printed circuit boards, a temperature sensor, and a power switch. Additionally, there are two thick wires that disappear into a glue-covered hole leading into the depth of the device. This must be the heating element connection. We’ll be observing both circuit boards in detail after removing them from the casing. But first…

Does the heating work?

If the heating element doesn’t work anymore, then the entire project is pointless, so that’s the first thing to check. I removed both PCBs, and then spent a little time studying them to verify my assumption: that unaltered mains voltage was meant to be applied to the heater. It was. I therefore temporarily connected both mains wires to the heater wires, held my breath, and then flipped the power switch. After a couple seconds, the surface of the device started getting warm, proving that the heating element had indeed survived the crash. Success!

Power PCB

Most of the surface area of the large square board is dedicated to a power supply unit. It also contains a relay for toggling the heating element electronically, and a small buzzer, which acts as a source of annoying beeps. There is also a rainbow cable connection to the other PCB, and another two-wire connection to the temperature sensor.

The underside is a bit busy, so let’s take it section by section:

Mains voltage section

We’ll start with the high voltage input in the lower-left, where you can see the purple “Mains” labels. One phase, marked “L” goes through a fuse (dashed line) and then branches off to become an input for the relay, and, through a thermistor, to a rectifier bridge in the bottom right. The other phase, marked “N”, goes to the other bridge input, passing through a resistor on the way.

When the relay coil is energized, the purple input path is connected to the thick bright green output path. When the board inside the device, this bright green path is then connected to the heating element. This is how we know that the heater is operating at mains voltage.

Switching power supply section

The bottom-right quarter of the board holds a switching power supply unit, which converts the rectified mains voltage (thick lines) to a smaller voltage (thin lines). I think this smaller voltage should be at around 5V level, as that is what the relay wants on its coils. The reason for my uncertainty will become apparent shortly.

Starting with the purple rectifier in the bottom right, on its right side are two DC current outputs, which go to the switching circuit, which consists of a chopper MOSFET, labelled KP2161SD, and a small transformer coil, labelled EPC13. The MOSFET “chops” the input voltage into a great number of tiny pulses, which allows the transformer to scale this signal down to a much smaller voltage. On the other side of transformer coils, only a simple capacitor is needed to convert this chopped signal back into a steady level DC that electronic components can use as power supply.

The low voltage section

The upper-right part of the board contains the two connectors, one to the other PCB (I labelled its terminals from 1 through 6), and another for the temperature sensor. In the top-center there is also an LM117-33, a very common voltage converter that creates the 3.3V power for the MCU board (orange line).

If you follow the thin red line from its source at the transformer, you will notice that it goes to the relay coil, and also to the input of the LM117-33. The corresponding white line serves as a ground reference for this converter, and also for many other parts of the circuit. The thin green line goes straight from the other PCB connector to the other side of the relay coil, and is most likely used for toggling the relay. There is also a diode to protect this 3.3V line from the higher voltage of the red line. When this line is pulled high (to 3.3V), then there is only 1.7V on the relay coil, which is not enough to close the switch. When the line is pulled low, then there is a full 5V across the coils, and the switch can close. The cyan line goes straight from the connector to the buzzer, and is certainly used to make infernal noises. Last but not least, there is a magenta line going from connector terminals #4 and #5, to the temperature sensor, and with a weak 22kΩ pull-up to the 3.3V line. This line is definitely used for getting the temperature, and the sensor itself is probably an analog resistive one.

The terminals of the connector that goes to the other PCB are described as follows:

1. 3.3V power line for the other board,
2. a control line for the infernal buzzer,
3. relay control line (active low),
4. a signal line for the temperature sensor,
5. connected to #4,
6. Ground power line.

MCU PCB

We will not be diving too deep into this board, as that’s not where the fault was, but I think it’s still pretty interesting.

The top side doesn’t that have much going on. We can see the LCD screen on the left, and some capacitive touch controls in the middle. A part of the WIFI+Bluetooth module is visible through a cut-out on the right, most likely its 2.4GHz antenna.

The bottom part features a big, unlabelled integrated circuit on the left. The number of lines coming from it to the LCD display leaves no doubt that this is a display driver. In the middle we have the logical brain of the device, a chip labeled “ME32F030C8T6”. It’s most likely an STM32F030xC, a 32-bit Cortex-M0-based ARM microcontroller. Above the MCU we can see a debugging header that is connected to the MCU’s serial wire debug port (SW-DP). It can apparently be used for programming the device, as well as troubleshooting its operation. On the right side of the board we have a connector that leads to the Power PCB, as well as the WIFI+Bluetooth module labeled WBR3.

Discovering the fault

Let’s take another look at the Power PCB:

I started my fault-searching procedure by measuring the voltage in several parts of the circuit. I started with the high-voltage lines, which indeed read as 230V AC. Past the rectifier bridge, the voltage became 320V DC, as expected. I didn’t have any tools to measure the performance of the chopper MOSFET, so I left it alone. Instead, I measured the voltage at the low-voltage side of the transformer, and it was 1.6V. Far cry from the expected 5V. This can mean that either the power supply itself is broken, or one of the 5V devices is drawing more current than the power supply can deliver, basically causing a brown-out. To eliminate the latter scenario, we have to take a look at two suspects: the LM117-33, and the relay.

I removed the relay from the board and tested again. The voltage level did not change, so the relay was not at fault. I then used hot air to remove the LM117-33, but it did not help either. Therefore, the fault must be either in the transformer core, or the chopper MOSFET. I would point out the transformer as the likely culprit, as coils made of thin wire tend to be susceptible to impact damage.

Unfortunately, this specific core is very hard to get where I live (in retail quantities), so it may not be possible to replace it. At this point, the project of repairing the device turned into a project of replacing its electronics. I will write more about it in part 2.

Capital ship demo is back!

The scenario where you pilot a light destroyer in a battle against a heavy destroyer is making its first appearance since 2019. It lets you try out all the new features that were made for ship-to-ship combat.

Custom battles!

Two fleets meet in battle. You decide what ships there are, how they are equipped, which one you’re piloting, and you can give orders to allied ships too!

Tactical map!

The map gives you an overview of the current situation and also lets you give orders to allied ships.

Subsystem targeting!

You can now select a specific part of an opponent ship for your guns and turrets to aim for. This is especially useful for disarming capital ships of their turrets.

Smarter turrets!

Turrets now have several modes of operation: they can attack your current target, defend the ship, or track your target while letting you pull the trigger yourself! These modes can be set per turret, but also temporarily overridden by quick command shortcuts.
Additionally, a whole new rail-gun turret has been added to the light destroyer ship to give it that extra oomph that it always lacked.

A whole new camera system

External cameras were the most universally disliked feature by all play-testers, so the camera system has been redone completely. You can now select from several camera modes, including a free camera, chase camera, or target padlock camera. The external camera is finally useful for fighters too!

Download links

1. 🠯 for Windows 
2. 🠯 for Linux
3. Please contact me if you want a Mac version.

Download size: ~400MB

Future plans and the fate of Exploration demo

Exploration demo is gone for good, as it was universally thought to be incredibly boring. I want exploration to be a of core mechanic of ATW, so I have reimagined it completely. This new exploration mechanic is currently being implemented, but it will not be included in Tech Demos. It will instead be a part of “All These Worlds: Prelude”, a future game that I plan to publish on GoG and Steam.

Mac version

The Mac version is no longer being actively released due to lack of interest from Mac users. If you’d like to play ATW on a Mac, please let me know and I’ll build it for you. The last version built is from 2019 and you can 🠯 download it here. I don’t even know if it works since the person who requested it never got back to me.

The libraries

Here are the contents of library.properties file of both libraries. I omitted the e-mail addresses of the authors to prevent spammers from getting hold of them. You can find the addresses in the actual library.properties files when you download the libraries.

name=WebServer
version=2.0.0
author=Ivan Grokhotkov
maintainer=Ivan Grokhtkov <(...)>
sentence=Simple web server library
paragraph=The library supports HTTP GET and POST requests, provides argument parsing, handles one client at a time.
category=Communication
url=
architectures=esp32

name=ArduinoHttpServer
version=0.10.0
author=Sander van Woensel <(...)>
maintainer=Sander van Woensel <(...)>
sentence=Server side minimalistic HTTP protocol implementation.
paragraph=Just the raw HTTP server protocol for the Arduino platform, the rest is left to your imagination.
category=Communication
url=https://github.com/QuickSander/ArduinoHttpServer
architectures=*
repository=https://github.com/QuickSander/ArduinoHttpServer.git
depends=Base64

Methodology

I created a very simple web application for the ESP-32, which has a testing endpoint that simply replies “OK” to every request, and also serves an index page with some JavaScript to generate a large number of requests for that endpoint. The script uses one of the two libraries depending on how you compile it. HTTPS was not used for testing.

The script was uploaded from a PC to my ESP-32-S2 Devkit, which was connected to my home WiFi. I ran the benchmark by navigating to the index page in Firefox on the PC. Both devices are about 25m away from the router, and the network environment is very much congested, which definitely impacted the results (this is not exact science).

I performed the benchmark by first compiling the script to use WebServer, and uploading it to the devkit module, then making two measurements: about 200 requests with interval 100ms, and then about 600 requests with interval 50ms. I later repeated the same steps with ArduinoHttpServer version of the script. I did not restart the module between 50ms and 100ms tests, but it was restarted between WebServer and ArduinoHttpServer due to a new script being flashed.

Results

Here is the combined screenshot of all the tests. It has one extra case, when I accidentally uploaded the WebServer version of the script with debug logging set to “Verbose”. I decided to include it just to show how much writing to the serial port can slow down the application. The benchmark script collected the following data (all time values are in milliseconds):

1. Requests: the total number of requests made during the test.
2. Errors: how many errors (!response.ok) were recorded during the test.
3. Time min: the shortest response time recorded during the test.
4. Time max: the longest response time recorded during the test.
5. Time avg: the average response time from the last 1000ms of the test.
6. Reqs/s: how many requests were handled in the last 1000ms of the test.

Conclusion

It looks like WebServer is a bit faster for this one specific use case that I tested. However, this was just a quick and dirty test, and I did not account for basically anything. The results I got may be distorted by WiFi congestion, devkit firmware quirks, me using the ArduinoHttpServer library in a suboptimal way, or many other factors.

The script

Click the link below to download:

Thank you for reading.

Consequently, this version only includes the station defense scenario, previously known as “demo 1”, albeit in two different variants. The remaining demos will come back as scenarios in subsequent releases.

Download links

1. 🠯 for Windows 
2. 🠯 for Linux

Download size: ~350MB

What comes next?

The current scope is to do a quality pass on the capital ship scenario (previously known as demo 3). I’d like to redesign this scenario to have more strategic depth, a bigger playing area, and some allied ships that can be commanded from the map screen. As always, I make no promises for the release date, but hopefully less than three years

What if I want to play the other scenarios?

The previous version from 2019 has all three scenarios, and can be downloaded here:
( 🠯 for Windows | 🠯 for Linux | 🠯 for Mac ) [~120MB]

Where’s the Mac version?

The Mac version is no longer being actively released due to lack of interest. If you’d like to play ATW on a Mac, please let me know and I’ll build it for you.

Why no release?

The latest version of ATW was released in May 2019. That’s really a long time ago. The year 2019 saw a lot of major new features, like for example the new AI, sensor & comms systems re-work, introduction of the map view, and many graphical upgrades. In contrast, 2020 and 2021 were very difficult years for me personally, so little work was done. What’s worse, all those major new features brought new bugs, broke existing missions, and the new “command demo” turned out to be no fun after all. To be honest, I believe that all of the missions are pretty underwhelming. They were good content placeholders while the game was new, but they need major re-work to be actually engaging. So, even though I started 2022 with some good progress on stabilizing the game, as of today it still remains un-releasable.

When release?

I intend to move forward with the following plan:

1. Finish up the work on the “missiles” milestone,
2. re-work all 3 missions,
3. stabilize and release.

This is a lot of work, so no promises on when that happens.

What’s wrong with the missions?

For starters, the AI improvements made the missions much more difficult, as the computer opponent can do much more damage even with the pitiful ships it’s given. It doesn’t help that many of the game features are still in placeholder state, and that some of them are poorly written, make incorrect assumptions, or are just really old.

The fighter demo simply spawns new foes until either the player’s ship or the space station is destroyed. It gets pretty boring after a minute or so. I’d like to have more types of enemies, and for them to come in increasingly stronger waves, and for the player to be able to repair and upgrade their ship between the waves.

The exploration demo is just plain boring, and that’s a huge disappointment given the amount of time and work that went into making it. The exploration ship should be made much faster, and the solar system more lively, with more clues for finding things, and the pirates should also be more pro-active in preventing the player from finding their base.

The capital ship combat demo needs a lot of re-balancing. While the mission itself is pretty fun, the uphill battle against the pirate cruiser is still not quite living up to my original vision. The bigger ships and their turrets should have more health, and I’d like to increase the scale of the battle too.

That’s it. Thanks for reading.

This game wasn’t my idea

So, a while ago (9 years to be exact) I wrote a browser game to teach myself JavaScript. It was a remake/re-interpretation of a text mode game “ATC” written by Ed James in 1987. It was about controlling air traffic in a given area. Planes would enter the game board through exits or spawn at airports. Each plane had to be carefully guided to its destination, which could be either an airport or an exit. The player command the planes, so that they would reach their destinations, without crashing into each other. The game was remarkably fun, and can still be played today. If you happen to be on a Debian-like operating system, you can get it by installing the bsdgames package.

The 2011 remake

My 2011 remake was a browser game written in JavaScript, and I based it around the Canvas element, which was a very new thing back then. It followed the original gameplay very closely, while introducing very simple graphics and small quality-of-life improvements. The game was controlled exclusively with keyboard, just like the original.

While I did learn a lot about writing JavaScript while making the game, I was never truly happy with how it turned out. The graphics was plain ugly, with small hard-to-read labels. When two or more planes got on top of each other, it was impossible to know which ones they were and where they were headed. The keyboard input system was very confusing to modern players, who were used to clicking everything with mouse. There was also no visual indication of which plane you were commanding, and if the command was actually accepted. Combine this with lack of tutorial, and the only way to learn this game was to have someone standing over your shoulder explaining the game as you played it. The code itself wasn’t that horrible for someone self-taught, but it didn’t escape from some anti-patterns, which made it difficult to find and fix bugs. Two major bugs remain up to this day: it’s possible for a plane to leave the game area through its southern edge and keep flying until it runs out of gas; it’s also possible for planes named “I” and “l” (capital “i” and lowercase “L” respectively) to both appear on the board at the same time, confusing the players. I attempted to fix the problem twice, both times without success. The game can still be played here.

The 2020 remake

My motivation for re-making this game again was mostly because I really liked the idea (which by the way is attributed entirely to Ed James), and I thought the game deserved a remake that was actually good. Therefore, I decided to spend a couple of days recreating the game from scratch, using modern technology.

The 2020 version features improved graphics with animations, a mouse-controlled interface that’s hopefully easy to understand, and several tutorial scenarios that gradually introduce all gameplay aspects and rules. One very big change is that airplanes actually fly across the board in real-time, rather than making chess-like movements that were characteristic to the original game. As a consequence of this, it’s possible to have many different kinds of airplanes that cruise at different speeds. The game is still based on a square grid, though unlike the original, planes travelling diagonally will take more time to reach the next square than those travelling horizontally or vertically.

Another big thing is a white line that predicts the path that an airplane will take. It’s only displayed for the currently selected airplane and goes through all squares the plane will travel through in the future. It’s also used for issuing delayed commands for planes passing over radio beacons and airfields. The line makes it easy to see whether a diagonally-travelling plane is actually lined up with its exit or not. The line is so useful in fact, that it made me realize some things about the default map from the original game that I hadn’t known about, like for example that airport A0 is located diagonally from beacon B0. Its most important advantage however, is that it shows you immediately how your commands affect a plane’s path.

I realize of course, that to make it a true product of 2020, I should’ve made it into a mobile game with touchscreen controls. I chose not to do so because a) I’m not very fond of mobile games, and b) real-time strategy games such as this one work very poorly on small screens with touch controls. Therefore, I envisioned this game to be played exclusively on a computer with mouse. Of course it’s theoretically possible to load it on a mobile browser, but I imagine the experience would be nothing but frustrating.

The game is written in TypeScript, which is compiled and packed to a minified JavaScript file with webpack. Other than some webpack loaders for development, I did not use any libraries or frameworks, so the game is very light-weight. The minified .js file currently sits at 127KiB, and can likely be reduced further by cleaning up the SVG assets.

Enjoy playing.

Progress is slow but steady.

A map with RTS-like controls for allied ships is the main new feature. Making sure that various things work well with map (for example the nebula from Exploration Demo) is taking more time than anticipated.

I made a new “Command Demo” to showcase the map feature. It has the player use a small fleet to protect several unarmed ships that explore a star system. I’m not happy with how it turned out gameplay-wise, and now I’m considering extending the Starship Battle Demo with tactical elements instead.

Another big thing going on is integration with a graphics toolkit for greatly improved visuals of planets and the outer space. Also, some better music.

I’d like to make a new gameplay video soon, as the 2019 one is becoming quite outdated.

Missiles are next in the queue. I’m looking forward to making some highly destructive warp-capable torpedoes. These should be effective against very heavy and cumbersome ships, and maybe also some of the lighter ships that are caught with their warp power recharging.

That’s it for now. I’ll try to go for a less-than-one-year interval for future updates.

“…but then I noticed a stack of smoke coming up from behind the screen. I stood up and looked at the mill. The probe cable was melting before my eyes. I rushed screaming to the power switch…”

While playing around with mine, I managed to damage it by accidentally applying high voltage to the “probe” terminal of the module. This caused the module’s microcontroller chip, an ATmega 328P to malfunction, and no longer respond to GRBL commands, effectively turning the machine into quite an expensive paperweight. Thankfully, I was able to replace the broken chip, and even program the replacement with a more recent version of GRBL firmware.

The trouble started when I first attempted to use a probe to generate a height-map of a copper laminate board. When making circuit boards, we want the mill to remove the ultra-thin layer of copper in certain places, while leaving intact as much of the underlying laminate as possible. Moreover, the board is never laid exactly level on the machine’s working area because of clamps holding it down. The difference in height sometimes can’t be seen with naked eye, but is guaranteed to be much larger than the thickness of the layer of copper that we want to remove.

The height-map approach solves this problem by having the machine take very exact height measurements at multiple points across the board. During a single measurement, the machine’s head is descending very slowly until it touches the board. Then the software saves the exact height at which contact took place, and then the machine makes another such measurement in another place.

How does the machine tell that its tool is touching the board? The most common way is to attach electrodes to the tool and to the board itself. If the tool is touching the board, an electrical connection is made between the electrodes. This can be used to tell the machine that it’s reached the board. The woodpecker control module supports probing in a very simple way: one electrode is attached to the ground terminal, and the other one to the A5 pin on the module.

There’s a terrible catch however, and if unlike me you take the time to actually read the instructions, you’ll notice they want you to disconnect the spindle motor before attaching the probe electrodes. Why? Well, the spindle motor is connected in such a way that the positive terminal of its power line is connected to the motor’s casing. This means that the motor, its shaft, and the tool itself (!) has a potential difference of some +12V with respect to the module’s ground.

Now, what happens if you attach the probe in such conditions? The first thing that I noticed was that the spindle motor started spinning as soon as the alligator clip touched the tool. Thinking it was some software problem, I walked over to the computer intending to stop the spindle. I thought it was odd that bCNC claimed that the spindle was stationary, but then I noticed a stack of smoke coming up from behind the screen. I stood up and looked at the mill. The probe cable was melting before my eyes. I rushed screaming to the power switch. After ventilating the room, I ended up with melted isolation on the probe wires, and a non-responding control module.

What happened electrically was that the high voltage from the tool found its way to the ground through the alligator clip and the cable leading to the A5 pin on the control module, and finally through the microcontoller. The flow of current caused the motor to spin, even though it was not commanded to. Poor ATmega was not designed to have such high currents passing through it, so it must’ve broken down almost instantly. The current was also too high for the probe cable, which ran so hot the isolation was melting.

Lesson learned: Always check the voltage before making an arbitrary connection in a circuit you don’t know very well.

The good news was that the stepper motors, the spindle, and other parts of the control module appeared to be undamaged. So, I thought, perhaps the module could be saved by just replacing the ATmega? I’d have to program it though, but the Woodpecker is running GRBL, which is free software, and I found a discussion on the Internet (a gold mine of information, BTW) where people reported they were able to flash a more recent version of GRBL to the very same Woodpecker variant that I broke, so the plan didn’t seem impossible.

Since I didn’t have a spare ATmega on hand, I tried playing around with the broken chip first. I discovered that it was running very hot as a soon as power was switched on, suggesting a short-circuit. I guessed it was the pin that was connected to the probe when the accident happened, but I was too lazy to verify it with a meter. I extracted the ATmega from the module with the help of some hot air, and then managed to bend the offending pin slightly. Then I connected the power while pressing the chip to its footprint on the module. It became hot in an instant, so I decided to give up and wait for a replacement microcontroller.

When the replacement ATmega arrived, I promptly soldered it to the board, first with hot air and then touching every pin with soldering iron. I connected my Arduino Uno to act as a programmer, with connections just as shown in the blog post. I loaded the Adafruit In-system programming sketch, and tried to connect to the Atmega with avrdude. Unfortunately, avrdude could not read the device signature correctly: it was reading different gibberish for each attempt. I checked the connections with the meter and found a 100Ω resistor between the MISO pin and the connector. I wondered if it was messing up the timing.

I reloaded the Adafruit sketch with “slow mode” switched on and my suspicion proved to be correct – this time avrdude was able to read the device signature and even the fuse bits correctly. Unfortunately, the sketch did not support programming the flash memory with this speed, so I had to find something else. A brief search on GitHub turned up DEPlayground fork of ArduinoISP, which supports variable programming speed. Even its default setting was enough for the ATmega to catch up, and I was able to flash GRBL version 1.1 (an improvement over the board’s default v. 0.9) successfully. Now, what about the fuse bits?

Someone in the gold mine thread managed to read the fuses from an undamaged board, and the value was zero for both high and low fuses. This seems highly improbable, as such configuration would disable in-system programming, and also the reset pin. The presence of a reset button on the Woodpecker board strongly suggest a non-zero value for the high fuse at least. Perhaps some lock bit was making it impossible to read the fuses? I tried flashing various fuse bit combinations with various clock settings, but ATmega was showing no signs of life.

In desperation, I flashed the Arduino bootloader to the ATmega, followed by a sketch that would constantly output noise on the serial port, with various baud rates. None of it had any effect and the serial monitor remained stubbornly silent. In the end, I flashed the following values: 0xE2 for the L-fuse, and 0xDA for the H-fuse. This configuration used the microcontroller’s internal RC oscillator as the clock source, so it should “just work”. Then I flashed the GRBL again, disconnected the programmer and went to sleep.

The following day, when I got around to messing with the Woodpecker board again, I started with simply opening the serial port. Lo and behold, I was greeted with GRBL prompt! Perhaps severing all connections to the programmer board did the trick, I thought that just disconnecting the “slave reset” signal would’ve been enough.

Anyway, I reconnected the stepper motors and the spindle (gulp!), and ran some basic tests with bCNC. Everything turned out to be working fine, except for the x-axis motor – it was making noise, but not actually moving in either direction. Suspecting a cold solder, I’ve decided to reflow the ATmega. I applied generous amount of solder paste, and then proceeded to re-solder every single pin on the microcontroller with fresh tin. I made several short-circuits, and even partially melted the x-axis driver socket in the process. Oops. After fixing collecting the solder blobs and making sure the socket was still conductive, I reconnected the motors once again. This time everything was working correctly. What remained was the GRBL settings.

Someone posted the defaults for CNC1610, my model exactly, in the gold mine thread. I took the opportunity to modify them a bit: my machine is still new and not oiled very well, so the motors tend to skip during acceleration and deceleration. The problem was fixed by applying more conservative top speed and acceleration limits.

So, in the end I was able to not only recover my Woodpecker module, but also improve it with a more recent version of GRBL as well. In the process I learned a lot about using an Arduino for programming another board. I also managed to get the probe working, and I won’t be forgetting to disconnect the spindle before attaching the probe any time soon!

Resources

1. [INFO] The gold mine thread
2. [INFO] Connecting Arduino to Woodpecker CNC
3. [LISTING] My GRBL settings
4. [LISTING] DEPlayground’s Arduino in-system programming sketch
5. [TOOL] Atmel AVR fuse calculator
6. [DOCS] ATmega 328P datasheet
7. [DOCS] Arduino Uno pinout
8. [INFO] Upgrade your CNC
9. [INFO] AVR Programming with Arduino
10. [INFO] About Arduino ISP and bootloaders

Download:
All These Worlds Tech Demo collection (for Windows | for Linux | for Mac ) [~120MB]