Anybody remember these? Anyone else use wire as bookmarks? Back in the day (when low-power Schottky was actually low power) one of these were worth their weight in gold. For the longest time I was stuck sharing a very worn one (no cover, lots of missing pages, etc) with a group of other people until I saved up enough to get my own.
With the internet, looking up a datasheet is easier and faster than with this old book, and I’ve been tempted to throw it out a couple of times… but last night I was stuck on a problem and found myself leafing through it for ideas. I’m glad I kept it!
Here’s another video through the microscope… a protist going about its day as a couple others do the same thing in the background. You can’t see the cilia waving around but if you watch the debris in the water around the protist, you can see the disturbance they make.
Taken with an OMAX A3550S camera through an OMAX M82ES microscope.
After all the Arduino and 3D printing and Raspberry Pi posts, it might be a bit of a surprise that microbiology is another one of my hobbies. I find it amazing how little tiny blobs of life still go about their days, eating, reproducing, and eventually getting eaten. Life is fascinating and pretty disgusting! It can be a pain to prepare samples, but when things work out it’s really worth it.
I took this particular video through my microscope a little while ago. I dug some goop out of the fish tank, put it in some water, and let it settle and spread out for a day before putting it under the microscope. There was quite the assortment of life to be seen, but the star of the show was this flatworm. It sniffed around for a while and did what could be best described as “squooshing” before making a break for it.
Ever since Ms Geek introduced me to the Arduino last April, I’ve been having a blast tinkering with them and building things. I’ve bought quite a few Arduino boards now, most of which are clones or third-party boards. A couple of them have been duds out of the package, but when I can buy four cheap boards for the cost of one “real” board, it’s tough to rationalize paying the extra money. Plus, a bit of time with a magnifier and a soldering iron fixed all but one of the boards that were DOA.
Up until two days ago, I’ve used the Arduino IDE exclusively under Windows and things have been working well. Two days ago, I installed the IDE (1.18.10) on a Raspberry Pi 4 running Raspbian Linux (Buster), and had no problems connecting to and uploading programs to MEGA328p boards like the Nano and Pro Mini.
A nice thing about Arduinos is that from a programming perspective, they’re pretty tough to permanently kill. As always, though, I make no guarantees that any of the following (or anything on this site, for that matter) will work for you. It’s worked for me so far, but it may not work for you. Who knows – it may not even work for me tomorrow. Anyway…
When I tried to do anything with a board that had the MEGA32U4 chip, though, the IDE couldn’t find it. There were no serial ports listed that pointed to the board:
The same thing happened with every single Pro Micro clone I tested (four of them from two different orders months apart) and a Keyestudio Leonardo clone. After hours of research and tinkering, I wasn’t any closer to fixing the problem, although I did disable modemmanager, which is something I discovered you should do if you want to do Arduino stuff under Linux anyway.
Just before I gave up, I extricated an authentic Leonardo from the project it was wired to and plugged it in. Immediately, a new serial port (ttyACM0) appeared in the IDE and showed a device connected to it:
Finally, I had a starting point. Here’s an assortment of my 32U4-based Arduino boards (the Pro Micro is basically a little Leonardo):
An easy thing to check was the 32U4 chip. They all looked pretty much the same, other than the authentic Leonardo being quite a bit older than the other boards:
Since the boards all worked under Windows, I was pretty sure that despite some different components (regulators, crystals, etc) on the clone boards, all were electrically sound. So, I took a look at what the Pi said when I plugged the boards in. It turned out that Linux was seeing the clones when I plugged them in but they disconnected almost immediately:
Then I plugged the genuine Leonardo in. It showed up in dmesg and stayed connected:
Aside from not disconnecting, the genuine Leonardo showed up a little different in dmesg. Take a look at the “New USB device found” and “New USB device strings” lines.
On the genuine Arduino: idVendor=2341, idProduct=8036, bcdDevice=1.00, Mfr=1, Product=2, SerialNumber=3
On the clones: idVendor=2341, idProduct=0036, bcdDevice=0.01, Mfr=2, Product=1, SerialNumber=0
Everything except the idVendor is different. According to the USB ID Repository, the vendor ID of 2341 belongs to Arduino. The Product ID of 8036 is associated with the Leonardo, while the Product ID of 0036 is associated with… a blank spot:
I still remember going through USB hell when the original Raspberry Pi came out, so to make sure the Pi or Raspbian weren’t causing the problem, I connected the boards to an Ubuntu VM. I got the exact same results, which took the Pi off the list of suspects. I did some more research and discovered that the vendor, product, and other information presented by the MEGA32U4 isn’t hard-coded in the chip or selected by OTP fuses – it’s firmware. As in, the bootloader. Which can be replaced.
I found some instructions for replacing the bootloader on an Arduino here and used a Nano (which works fine in Linux) as the programmer. I hooked one of the 32U4-based clones to the Nano, set the IDE to use the Nano as a programmer (Tools -> Programmer -> ArduinoISP), then burned the new bootloader (Tools -> Board -> Arduino Leonardo, then Tools -> Burn Bootloader).
I hooked the clone Leonardo up to the Raspberry Pi and took a look at the output of dmesg:
After burning the new bootloader, all of the clones showed the same values as the genuine Leonardo for idVendor, idProduct, bcdDevice, Mfr, Product, and SerialNumber… and all of the clones now show up as /dev/ttyACM0 or /dev/ttyACM1, and they are all visible and programmable in the Arduino IDE on a Pi 4 running Raspbian.
So, to sum up… if you can’t program a 32U4-based board with the Arduino IDE in Linux but it works fine in Windows, you can try the following:
Check dmesg and confirm that the board is connecting and disconnecting. If so, then…
Disable modemmanager (good idea to do this anyway), then…
Check dmesg and see if the board has idVendor=2341 and idProduct=0036. If so, then…
Buy or build an Arduino ISP. Once you’ve got it, then…
Hook up the board in question to the ISP and burn the correct bootloader to the board. Once that’s done, you can…
Check dmesg again and see if the board now has idProduct=8036. If it does, then…
Give it a try (don’t forget to change the IDE settings (i.e. Tools -> Programmer -> AVRISP mkII) back to program your board directly instead of using the IDE!)
I’ve been playing around with the ESP32-CAM modules a lot lately, and after spending some time searching through pages of code, I think I’ve finally got a handle on configuring the camera and getting it to start up cleanly.
With its boot time being about a second and the price being as low as it is, I think there are tons of applications for it. Everything from an always-on security camera to an occasionally used trail/wildlife camera, eye/brain/wifi for a remote-controlled car or robot… all kinds of things.
I want to put some cameras outside to catch the various animals that are leaving tracks in the snow, and these things are so inexpensive that they’re aalllllmost disposable. That’s not to say that I plan on putting them in situations where they’ll be ruined, but if one gets gnawed on or water gets to it, it won’t be the end of the world.
One thing that the stock camera can’t do, though, is see well in the dark. Even with bright IR illumination, the IR filter in the camera does a good job of keeping the picture stubbornly dark. Back when the Raspberry Pi camera module first came out, I fought with the IR filters in a couple of them, so I figured I’d take a shot at removing the filter from one of the OV2640s that came with the ESP32-CAM. Turns out it wasn’t too tough, although it took some patience.
PLEASE NOTE THAT THIS IS ONLY FOR THE CAMERA SHOWN IN THE PICTURES BELOW. I DON’T KNOW IF THIS PROCEDURE WORKS FOR OTHER CAMERAS.
OH, AND ALSO PLEASE NOTE THAT I’M NOT RESPONSIBLE FOR ANYTHING YOU DO, SO IF YOU WRECK YOUR CAMERA OR CUT YOURSELF OR BURN YOUR HOUSE DOWN OR WHATEVER, THAT’S ON YOU. BE CAREFUL!
First, remove the camera from the ESP32-CAM module by lifting the latch that’s holding the connector in place. Take note of where the glue is on the lens – it shines a little more under a light than the plastic does:
After the camera is loose from the module and you’ve located the glue, very carefully and gently run a sharp knife in the seam between the lens barrel and the camera casing:
Once you’ve cut the glue, grab the lens barrel with one finger and thumb and the casing with the other and gently turn the barrel counterclockwise. If it doesn’t turn, go back and run the knife through the glue again. If it does turn, you’ll be rewarded with a view of the camera sensor…
… and you’ll be able to see the IR cut filter too:
The filter in this particular camera is held on by a very thin ring of plastic and possibly some glue. I slowly shaved the plastic away until I got right down to the filter, then very carefully pried the filter off with the knife:
After that, it’s just a matter of making sure there’s no dust on the inside of the lens or on the camera sensor, then very carefully threading the barrel back into the casing. It is really easy to cross-thread it, so take it slow and be careful. If all goes well, you should end up with a put-back-together camera:
One of the other advantages of cutting the glue and being able to thread the barren in and out is that you can adjust the focus on the camera now. Want to look at something nearby? Back the barrel out a bit. Something far away you want to see? Spin it in a bit.
Anyway, put the camera back in the ESP32-CAM and flip the lever down on the connector to secure it all. Voila, you now have an IR-sensitive camera!
Oh, one of the things that sometimes goes unmentioned when talking about making your camera “see in the dark” is that after you remove the IR-cut filter, your camera will no longer work very well in colour, particularly where there is a lot of extra IR light bouncing around (i.e. daytime). The colours will not look normal and it will seem like the picture is out of focus. You can fix that by putting an IR-cut filter back into or in front of the camera, but I just want to watch animals wander around in the dark so B&W is just fine for me.
Here’s the difference removing the filter makes. Same remote, same button (3), and same camera settings. Here’s before I removed the filter:
And here’s after:
A bit of a difference! I’m looking forward to trying this out and seeing which wavelength of IR LEDs it will be the most sensitive to.
In my previous post, I showed that it was indeed possible to print TPU on a plain old CR-10s. That was with a couple of sample packs that had no name on them but had the following recommendations:
With that sample TPU, I had success printing at around 20mm/s with a nozzle temperature of 240C and a bed temperature of 75C.
I ordered the a spool of the cheapest black TPU I could find on Amazon, sold by a company named Priline. The recommendations for this TPU were different than the other stuff I’d used:
I thought I’d print the same nut and bolt models that I’d done before to compare. I made the temperature changes in Cura, then sent it off to print, first with a nozzle temperature of 220C and a bed temperature of 75C.
Right off the bat I could see there was a problem. The lines weren’t adhering to each other as they were being printed. I tried bumping up the flow rate, which only made things lumpier. Then I turned up the temperature a few degrees at a time until it looked like things were working better. Unfortunately, the print failed on the second layer when it didn’t stick to the first layer and became a blob on the nozzle.
I ran another print with the temperature set to 230C and with the flow rate still higher. The first layer went down a lot better and I thought things were going to work but the fourth layer didn’t stick to the third and it ended up all over the nozzle again. I thought that might’ve been a fluke, so I leveled the bed again and tried again but had the same results on the sixth layer.
Another print started at 235C and was working pretty well but once there were about a dozen layers put down, it didn’t look right. I cancelled the print, let everything cool down, and then took a look at the parts. With a bit of pulling, I was able to separate some of the layers. Still no good.
Despite the recommendations being only up to 230C, I tried bumping it up one more time to 240C, just like the TPU from the sample packs. That extra five degrees made a world of difference. There was some over-extrusion so I turned the flow rate back down a bit.
Here’s what I ended up with. You can see there’s a bit of stringing between the models just like last time:
Here are two comparison pictures of the nut and bolt printed with the sample TPU on the left, and the Priline TPU on the right:
Both had some stringing, but it’s pretty obvious that the Priline printed cleaner than the sample packs did. From the look of it, I probably should’ve dried the sample TPU before I used it.
After the print, I compared my notes and found that the settings that had finally worked for the Priline were exactly the same as I’d used when printing with the sample filament:
Nozzle temperature: 240C
Bed temperature: 75C
Flow rate: 105%
These results make me even more confident in saying that yes, a stock CR-10s can print TPU and do a decent job at it.
A good friend of mine has a dad who’s suffering from dementia. He’s a farmer and spent decades building and fixing things, and he still likes tools and things he can manipulate with his hands. Unfortunately, there are times when he throws things.
I printed him up some big nuts and bolts in PLA but realized that if they were all screwed together they’d make a pretty hefty projectile. So I wasn’t entirely sure what to do. Then, I remembered there were some 30g sample packs of TPU sitting around and collecting dust, so I figured I’d see if I could do something with them.
Having never printed TPU before, it was a few hours worth of DuckDuckGoing (I know it doesn’t roll off the tongue as well) before I’d learned that yes, it was possible to print TPU on a CR-10. I’d also learned that no, it wasn’t possible to print TPU on a CR-10. Interestingly, it was also possible to print TPU on a CR-1o, but only if you installed anywhere from $0.50 to $250 worth of modifications.
I opened one of the packages and played with the filament. Rubbery, stretchy, a little squishy… definitely different from the PLA and PETG I’m used to. So, I loaded it into the printer, started a print, and sat there for the entire thing so I could dial the settings in while it printed (thank you Octoprint!!!).
Here’s a bendy wrench:
I then fused what was left of one pack with the other pack I had (and set off the smoke alarm, whoops). After things calmed down, I drew up and printed a nut and bolt, which came out really well:
I did this on my CR-10s with a 0.4mm nozzle and no modifications, and the TPU I used had the following recommendations listed on the pack:
After a bit of experimentation, here’s what I found worked for me. Again, this is on a stock CR-10s with a 0.4mm nozzle:
Level your print bed. Actually, go level it now even if you’re not going to print TPU. It fixes sooo many problems.
Clean the outside of the nozzle before you print.
Purge whatever was in there before. Do not mix TPU with another material, even if it’s “just a bit”. Trust me.
Bed surface: Glass with two layers of Elmer’s all-purpose glue stick, applied after the bed is at temperature.
Bed temperature: 75C (all layers).
Nozzle temperature: 240C (all layers).
Fan: 0% for first layer, 100% for rest of print.
Flow rate: 105% (all layers).
Print speed: 18-21mm/s.
Layer height: 0.2mm for first layer, 0.25mm for rest of print.
Print with a skirt, at least 7-10 lines wide.
After the hotend and bed are heated up and just before you’re ready to print, raise the hotend 100-150mm and wait until the nozzle stops drooling TPU. Clean up the debris, carefully wipe the excess TPU from the nozzle, then start the print. It will take a while for the hotend to fill up again – print with a skirt to give it time to fill back up (see above point).
With these settings on this printer and with that particular flavour of TPU, I was able to get good strong prints that looked pretty good. There is some stringing between parts, but it cuts away easily with a small pair of scissors or snips.
I lobbed the wrench at my wife, who reported that it didn’t hurt. I screwed the nut onto the bolt and threw it at the front door and it bounced nicely without leaving a dent. I think these might work for my friend’s dad.
I’ve ordered some more TPU, and of course I couldn’t find stuff with the same temperature recommendations as the sample packs. I will give it a shot and do up another post with what I find out. At this point, though, I’m pretty comfortable with saying that yes, you can print TPU on an unmodified CR-10s and it can turn out well. Just go slow. And level the print bed!
A while ago I got my hands on a pair of ESP32-Cam modules. They were crazy cheap and it looked like I had a great little device that would work well as a security or wildlife cam:
It was easy to program using the Arduino IDE and the example program, but no matter what I tried changing in the program it wouldn’t connect to my home wireless network.
There’s a lot of documentation out there on the ESP32 devices, but there are parts that seem to be missing. I wish I’d bookmarked the link, but I came across the comment section of one article that mentioned a 0R surface-mount resistor that selected the external antenna jack or the on-board PCB antenna. It didn’t take too long to find, and it was set to use the external antenna jack:
That explained why it wasn’t talking to the wireless – no signal. I could fix the problem in two ways: plug in an external antenna, or move the tiny little resistor so that it connected the ESP32 to the PCB antenna. I don’t have any connector that will fit that jack, so I decided to move the resistor.
**NOTE** Doing any combination or number of the following steps will definitely, POSITIVELY void the warranty of the device. It may also increase the electrical noise produced by the unit and/or its susceptibility to other sources of electrical noise. It may also cause operational or stability problems. It may also cause the device to produce wifi signals that are more powerful than allowed by law. Proceed at your own risk.
Unfortunately, between not being able to see it very well (even with a magnifier lamp), having a soldering iron with too large a tip, and having tingly fingers and shaking hands, I ended up with this:
Not only did I not manage to solder the resistor in place, I also ruined the PCB pad that connected back to the ESP32.
By this point I was getting pretty frustrated. Actually, I don’t think I’ve been that frustrated in quite a while. Fortunately, I had another ESP32-Cam that I could apply the knowledge that I gained on this one and not make the same mistake twi-bahahahaha… yeah, I ruined that one, too.
The two of them together cost me less than $15, but I hate throwing something out when it’s still “alive” (they both still booted and tried to connect to the wifi), and I was looking forward to playing around with them. Seeing as how they were pretty much garbage at this point anyway, I figured I’d see if there was anything I could do to get them working.
**NOTE** See previous note. Seriously.
I could see the PCB trace leading under the metal can, so I figured that if I was careful, I might be able to remove the can and find another soldering point to attach an antenna.
To remove the can, you don’t need a hacksaw or a Dremel… just a pair of very fine-tipped pliers or snippers. there is a small hole in the can in the inside corner right by where the antenna selection resistor pads are. Carefully grab it with the pliers/snips and pull straight upwards to make some room:
Slide the pliers in a bit more and lift up and away from the PCB antenna (towards the top of this picture). It may take a bit but the can end by the PCB antenna should break away:
Reposition and pull the can up and to the left – the right side and top should come free easily as well:
Reposition again and the last bit should break away with very little force:
The antenna connection point is – very nicely – right by where the antenna selection pads are, right between two surface-mount components with big pads and lots of solder:
So now to make the antenna. I used a piece of 26ga solid wire-wrap wire, but anything nice and thin will do 22ga is too big.
Cut a piece about 6.5cm long, then strip about 1-1.5mm and bend the stripped part at a right angle. Tin the wire, make sure it’s got a good coat of solder on it:
Bend the insulated part of the wire to whatever shape and angle helps you hold the stripped part in place at the new attachment point. Use the iron sparingly – if you’re heating and heating and it doesn’t seem to be melting, back off, give it a minute, and change your angle before trying again.
If you’re careful and lucky, you’ll end up with something like (or much better than) this:
Gently bend the antenna into the orientation you prefer, and you’re done!
The next thing to try is powering it up (unless you haven’t programmed it, in which case you should probably do that now). With no can and a crappy detuned wire antenna, the ESP32-Cam was able to finally connect to my home wireless network:
And the camera’s video streaming works like a charm:
I suppose that instead of hanging a wire antenna off that point, I could’ve run a jumper from the new attachment point to the pad that connected to the PCB antenna (or the antenna jack, for that matter), but a) I just thought of it, and b) I don’t mind the crappy antenna look.
I’ve been enjoying finding and listening to all kinds of stuff with the SDR, and since I got it working with the Pi 4 I’ve wanted to use it without needing an extension cord.
I had a lot of trouble finding a battery supply that would do the trick. I have a few of those USB power packs at home and tried them but the Pi kept reporting low voltage.
I then turned to putting a regulator on a 12V SLA battery. Unfortunately, even with capacitors and shielding, the switching regulator I tried put out a lot of noise that the SDR picked up. I knew a linear regulator would be quieter but as I suspected, it only took about a minute before the biggest heatsink I had was too hot to touch.
So… I went back to the USB battery packs.
There are a few problems with those packs. They can also be noisy (there’s switching circuitry in them too), they can sag under load, and most of the USB cables out there are cheap crap that use very thin wire.
I put a load (actually, a Pi 2) on each pack and watched what happened to the noise and voltage on the oscilloscope. The best of the lot turned out to be an older Anker Astro E4 13000mAh unit that held a pretty constant 4.92V and wasn’t too noisy. So I started there.
I don’t know how many USB cables (or pieces of USB cables) I have sitting around. Some came with phones, tablets, or other devices… some were bought separately… some looked good… some looked cheap. I started going through the cables to see what kind of voltage drop there was when there was a Pi 4 on the end (with a micro-USB to USB-C adapter).
None of them ran the Pi without triggering the low voltage warning, and some of them couldn’t run the Pi without triggering the voltage warning even when idle. Two of them were so bad that the Pi couldn’t finish booting. The voltage drop across the cables was as much as 0.62V!
With those results, I decided to make my own cable. Unfortunately, when I looked in my USB parts drawer, I only had micro-USB plugs and USB type A jacks.
Out came the snips and I started chopping up the cables, starting with the ones that looked the best. Turns out that how a cable looks doesn’t mean much when it comes to how heavy the wire inside it is.
Eventually I found one that had considerably heavier wire than what I’d seen up to that point, so I decided to use it instead of chopping up the rest of the cables. I cut it to 60cm, soldered on the plug end, and gave it a try.
It was a lot better, but the Pi was still reporting that there’d been a low voltage condition at some point. I cut the cable to 50cm.
20cm did the trick, and I couldn’t trigger the low voltage warning anymore, even with the SDR plugged in and running and the CPU pinned to 100% (I usually use cat /dev/urandom > gzip > /dev/null for that).
Here it is, the beautiful and reliable USB cable of portable GQRXing:
Since I only had the micro-USB plugs on hand, I still have to use the adapter, which could also be wasting a bit of power. I need to order some other stuff sometime soon so I may grab a couple of parts to make another good cable or two.
To test the cable and battery pack, I hooked it up to my SDR Pi, fired up GQRX, told it to record the audio, and checked in on it every half hour. It ran for six hours before the battery LEDs showed it was at less than 25% capacity. I don’t like running those packs flat so I stopped the test there.
Before I shut down the Pi, I hopped onto it (using VNC on my phone, heh) and checked whether any of the warning conditions had been triggered (voltage, temperature, etc). Here’s what I saw:
0x0, or no problems at all… after running for six hours straight. Not too shabby!