Update 6 on ESP32-based 3D printer control board

Finally managed to test the updated control board.

The MRR ESPA (3D printer control board based on an ESP32 microcontroller) is finally in the final stages of development. Features include:
- Built-in WiFi, which allows a 3D printer to be controlled via an online web interface if the appropriate Marlin firmware (luc-github's Marlin fork) is used. The web interface is basically his ESP3D. There is even support for push notifications but I have not tested this out yet.
- 4 stepper drivers ready for standard A4988 drivers, but with jumper pins which will allow easier connection of TMC2130 drivers in SPI mode. With the jumpers in the right positions, you will only need to use jumper wires for the CS pins (one per stepper driver board).
- Opto-isolated bed heating rail, so that you can use a separate power supply unit of a different voltage (up to 24V) to heat the bed.
- Support for single hotend with part cooling fan.

Here is a test print. A quick one.

The main change from update 5 is that traces carrying high currents were widened and placed on both top and bottom copper layers. The bottom traces are also exposed to help with cooling. I had originally thought the heating problem near the 20A fuse was because the fuse was being used at close to 100% rated current, but I think it is more a case of the traces being too thin for the amount of current being carried. Anyway, after the changes, that area of the board no longer seems to be going above 100 degC when I am heating the bed using 12V (which translated to about 15A of current). When used with a 24V system, it is not a problem at all since the current is much lower, and therefore less heat is being dissipated.

Besides the MRR ESPA, I have also been working on a more advanced version of the board which uses I2S for stepper stream control. This is the MRR ESPE, which will feature the use of serial shift registers (74HC595) to convert an I2S stream into parallel outputs, which can then be used for the step, direction, and enable pins of the stepper drivers. The outputs from the shift register should also work for PWM control of MOSFETs and LCD data, and I will be testing them out. Meanwhile, here is a prototype of the MRR ESPE using I2S for stepper driver control.

It is not doing much, just doing a first-layer test print to help me make sure my bed mesh data is still good.

Anyway, future updates will probably be using the names of these boards in the title to better differentiate between the two (related) projects.

Note: Pre-launch version now available here. Some information on this has been updated here.

Sequel to the Tonkin Gulf Incident?

US Navy: Mine in tanker attack bears Iran hallmarks

Two ships were attacked in the Strait of Hormuz. Such attacks bring back memories of the 1980s, when Iran was attacking shipping in that very same location during its war with Iraq. And now, the US is saying that these recent attacks were conducted by Iran.

The US Navy, which said that North Vietnam attacked them in the Gulf of Tonkin in 1965, sparking the Vietnam War, is saying that Iran attacked innocent shipping in 2019. And just like 1965, the evidence is sketchy. The evidence is circumstantial; there is no "smoking gun," or "caught in the act" stuff here.

This is all the more worrying because witness accounts from the Japanese ship attacked stated the ship was hit by flying objects. Implying an attack either by projectile shells from a naval gun, or a missile. Both scenarios are not anywhere near to the limpet mine scenario being painted by the US Navy.

Even if we assume that the US Navy is being honest and that the attacks were caused by limpet mines. It was reported that they had a hard time trying to pry the magnets off the ship. If the magnets are so strong, it is going to be really hard for a boat to close the ship at sea, travel alongside it while braving the waves to place those mines. That implies the mines were planted in harbor. And if the mines were planted in harbor, it can be anyone who has access to that harbor. Not just the geographical neighbor of Iran where the explosion actually took place.

Whatever it is you choose to believe, a few pieces of magnets is not a smoking gun. Before going off on another Vietnam as "retaliation" or another Iraq to find "WMDs" based on how we feel about who the perpetrators may be, we should be asking ourselves, "What are the facts?"

Let's judge and act based on facts, not feelings.

What is the limit of personal land ownership?

Sky's the limit: Rise of delivery drones has U.S. cities asking who owns airspace

With technology moving much faster than laws, we are now caught up with this question: who owns the air above a piece of land, and how far up (or down) does that ownership extend?

When we started digging pipes and subways, the question of land ownership below the surface was more or less addressed. Most, if not all countries have laws in place delineating how deep land ownership goes.

But now, we start to have things flying over our heads, above our houses, over our yards. Yet, the legislation regarding ownership of space over a piece of land is still very much in its infancy, if born at all. Nations have such a definition for delineating between territorial airspace and outer space. But such a definition cannot serve private use. We can't have private ownership extending into the stratosphere; how can commercial aircraft fly if they have to get permission to fly over every piece of privately owned land?

So what is a realistic height for private ownership? We really need to answer this question NOW. Not just because of delivery drones. There are already companies working on the next step: flying Uber. Before we know it, there will be flying cars, and we will need to have boundaries in place for these flying cars because, unlike land-based cars, there are no physical roads to show them where they can and cannot go.

Just like we need rules to govern AI, we also need rules to govern this new dimension of personal mobility. I hope the relevant people get to work on this soon, because it is never good to be lagging behind. Companies should have the rules in place before they start research and development within those rules. Once they have come up with something, spending all that money, it is difficult to draw rules that will limit use of new technologies. If we try to do so, we can expect those companies, who have invested so much, to invest in lobbying to prevent such restrictions on what they have spent money on trying to earn more money. That's a sad fact of life.

Building Visual Studio Code on the Jetson Nano

After fixing my firewall, I tried to install Visual Studio Code on the Jetson Nano.

Following
Quick build guide for visual studio code on the nano
didn't really work out that well, with errors running gyp.

Searching around, I found this post (Building Visual Studio Code on Jetson Nano) and managed to build and install Visual Studio Code by merging the commands from the two posts.

The series of commands used:
curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -
sudo apt-get install -y nodejs
curl -sL https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list

sudo apt update
sudo apt install -y libx11-dev libxkbfile-dev libsecret-1-dev fakeroot npm curl nodejs nodejs-dev yarn

git clone https://github.com/Microsoft/vscode.git
pushd vscode
sed -i 's/4095/2048/g' package.json
scripts/npm.sh install
yarn
yarn run gulp vscode-linux-arm64-min
yarn run gulp vscode-linux-arm64-build-deb
sudo dpkg -i ./.build/linux/deb/arm64/deb/code-oss_1.??.?-*_arm64.deb

Then, to add the extensions manager, I followed this post.
Basically,
sudo nano /usr/share/code-oss/resources/app/product.json
and then, after
        "checksums": {
                "vs/workbench/workbench.main.js": "BompYN/DPDENjDaaz6Tl3w",
                "vs/workbench/workbench.main.css": "B0uvAV0QuNsAXdBJwcuhfA",
                "vs/code/electron-browser/workbench/workbench.html": "SJ2O65ioC$
                "vs/code/electron-browser/workbench/workbench.js": "+0ieKuns+AJ$
        }
add this:
,"extensionsGallery": {
    "serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery",
    "cacheUrl": "https://vscode.blob.core.windows.net/gallery/index",
    "itemUrl": "https://marketplace.visualstudio.com/items"
}
before the final bracket at the bottom.

Then reboot with:
sudo reboot

And after rebooting, run with:
code-oss

Hurray! 🎉🎊

Repairing Linux firewall

This is more a note to self, in case I mess up again.

I was playing around with the firewall on my Jetson Nano because I was testing out how to install NextCloud on it. However, I managed to thoroughly wreck my firewall settings, and in the end, I could not SSH in nor use VNC. So, I had to reset the firewall.

Here's how.

First, set all rules in iptables to ACCEPT.

sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

Then, flush the nat and mangle tables, and all chains.
sudo iptables -t nat -F
sudo iptables -t mangle -F
sudo iptables -F
sudo iptables -X

Then I did a reset of ufw with:
sudo ufw reset

I also had problems with the ufw rules, so I did something really stupid:
sudo rm -rf /etc/ufw

In the end, I had to reinstall ufw, and copy the default rules files by:
sudo apt remove ufw
sudo apt install ufw
sudo cp -p /usr/share/ufw/before.rules /etc/ufw/
sudo cp -p /usr/share/ufw/before6.rules /etc/ufw/
sudo cp -p /usr/share/ufw/after.rules /etc/ufw/
sudo cp -p /usr/share/ufw/after6.rules /etc/ufw/
sudo ufw enable

Then, add back the ports I need, like SSH, by:
sudo ufw allow ssh

And it seems I managed to get it working again. Phew!