OK, Actually it will be Hybrid. We want to be inclusive to those who can’t make it out. We’ll be talking about badge planning, and I’ll give a demo of PCB design and how to build a badge in KiCad, from a blank slate to fabrication. You can put your filthy grubby hands on the early prototypes of the badge we hope to release at “summer camp” this year.
Weather looks good for a backyard meetup. I’ll see if I can bring a large-ish screen out to the table so everybody doesn’t have to crowd around my laptop. And I’ll stream the screen in the Discord so everyone can see it.
We’ve been playing with the Pico over here. Some of us have been going more in-depth than others. And since everyone starts with a different set of experiences, a historical perspective, you might say, we all sort of hit it from another angle.
A common angle to come at this unique and delicious combination is from a general familiarity with Python. That’s where I came from. I had written Python scripts to do various things. I had taken it to the next level and written tkinter visual apps for the Raspberry Pi 3 and for desktop OSes.
But I quickly got the understanding that MicroPython is not full Python. Is it safe to say it’s a highly-specific subset of Python?
So obviously my first question is, “what can I DO with it?”
So, you could go out and find things that have been done, and adapt them, and we’ve all done that.
Or…
You could ask your Pico directly.
Go install Thonny, if you haven’t already, and get it talking to your Pico. I’ll wait. And I won’t walk you through that. That’s beyond the scope of this little post.
[jeopardy theme song plays while I wait patiently…]
OK. You back? Let’s do this.
So hopefully you’ve connected up your Pico and been prompted to flash the MicroPython firmware to it. That’s all kind of automatic, right?
Now, create a new file in Thonny. Let’s call it fafo.py (fuck around, find out).
Put the following very simple script in it.
Save it (you should be prompted to choose whether you’re saving it to your PC or to your Pico — choose the Pico).
Now run it. You should have a shell in the bottom half of your Thonny window and should see the following output:
Congratulations. You’ve just asked your Pico politely for a list of modules, and it has responded with a list of all built-in modules (modules that are built in to the MicroPython firmware you flashed onto your Pico). Note the last line: “Plus any modules on the filesystem.” It’s not aware of any custom modules you may have written, borrowed, used within its governing license, or stolen, and dropped into the MicroPython filesystem.
Let’s take this a step further. What if you wanted to know what functions and classes are available within a module? Let’s try this:
Now you’ve asked your friendly little Pico to give you help on the module named “machine.” Note that you do not quote the module you are requesting help with. If you do, it thinks you’re asking help with strings, because “machine” is a string. Yeah, I don’t know why “modules” is quoted and machine is not. Let’s keep going anyway. Hit run. (In my setups on Mac and Win, you don’t need to save anymore once you’ve saved to Pico, it will automatically save before running, so unless you’re saving a new file, you can just hit run.
That’s pretty cool. And now you know you can ask it for help on any module. But what if you want to know more about a class within a module? Let’s take a look:
Hello, my little Pico friend, would you be kind enough to tell me more about the Pin class within the machine module?
Now you have a super helpful list of functions (methods) and constants associated with the Pin.class of the machine module. Now go forth and play with all the other modules. Find something that takes you to your happy place. I did:
This is actually what I came here looking for, a unique ID function.
So I plugged in another Pico, flashed the MP firmware on it, then hit run again. As predicted, it automatically saved it to the Pico, not even realizing I had swapped Picos, then ran it.
So here we are, it’s 2021, Def Con is hybrid this year, and we procrastinated long enough. We wanted to put together a badge for last year, but with the con being fully virtual, we lost motivation. There’s something about the idea of being in person for our first badge presentation that appeals to all of us.
Except Kevin, who hates crowds. And I get it.
So we were still on the fence until the org made the announcement and we decided to push forward. Then it became, “oh shit, do we have enough time to put a badge together?”
The answer became “fuck yeah.” Despite the fact that none of us has ever created a badge before. We’re just a bunch of nerds with a #badgelife fetish and some audacity.
The badge is based on the Raspberry Pi Pico. It will likely be released as a locked UF2 firmware compiled from MicroPython with some secrets and challenges in it. The artwork is shaping up to be sufficiently attractive to sit proudly in any #badgelife collection. And because the base is the Pico, it will be easy to update firmware, either with future releases from us or with your own cool ideas. I won’t spoil the artwork now, but certain subcultures might be very interested in the design functionality and I suspect some will find their own uses with their own code. I hope when this happens that they feed it back to us through our Github so that it can be shared with the community.
We currently have two needs for the badge:
(1) I would love for someone with #badgelife or other PCB design experience to help design a Lipo charging circuit for the badge. According to the datasheet, it should be able to charge through the existing USB port and power the badge accordingly. If we don’t get this reliably resolved, we’ll use battery holders and 2xAA batteries. Power usage is minimal on the Pico, even with neopixels and an SSD1306 OLED display. I just started testing powering the circuit by battery today, and at this moment I’m at nearly 7 hours of runtime, and that’s before we optimize power usage. For this test, the screen is always displaying or scrolling something, and 10 LEDs are cycling.
(2) Looking for someone with graphic design experience to come up with a lanyard design which fits the theme of the badge. Without spoiling the badge, there is a bit of an occult theme to the badge artwork, it would be great if that theme translates to the lanyard as well.
Sorry, no spoilers until the final boards arrive. First prototype should arrive this week.
Tonight I finally got around to firing up the ESP32-CAM I’ve had sitting in a drawer for long enough to forget exactly where it came from or what it came with.
It’s an annoying little buttmunch of an ESP32, because it didn’t come with a USB programming port. This means you have to wire up a USB-TTL FTDI programmer, ground IO0, and hit the reset button to program it.
I used the Arduino-provided example. Once you install the ESP32 boards via Boards Manager, it becomes available under ESP32->Camera->CameraServer.
All you really need to do is specify the board, fill in your SSID and Wifi password, and upload the sketch. It took a few tries, but it finally came up. Once it came up, I could see on the serial monitor that it had received an IP address. I browsed to it and was surprised to see the many options available in the example software. Face recognition is in there if you drop the resolution low enough.
In such a tiny, low-cost, low-power package, I could easily see building very cheap hidden cameras out of these and integrating them into your security/surveillance package. In fact, there are dozens of housings available on Thingiverse.
Here’s an example of someone who took the ESP32-CAM to the next level:
Ever since the first time I read about 3D printers, I knew I had to have one. Something about creating things out of filament, and imagining and designing those things, has always appealed to me.
If you’ve read anything here, you know that my first was the Anet A8. Someone (probably in an Anet forum) said “Don’t buy an Anet if you want a 3D printer. Buy an Anet if you want to learn how to build a 3D printer.” Boy was that true.
Now I have the Creality Ender 5. The price came within a comfortable reach, and the reviews have been stellar, both public and via word-of-mouth. It’s been rocking pretty steady since I got it, around the beginning of this year.
But the more you drill down into a 3D printer, the more you see how things can be improved. I soon realized that the questionable first-layer problems I have occasionally might not be a problem with my practices after all… It might just be about barely-perceptible warps in the bed, which are common. So I thought, what the hell, the BL-Touch bed leveling sensor is cheap, I’ll just get one, install it, and all my troubles will be gone.
Except that 3D printing, like most amazing things in technology, is based on rickety scaffolding and band-aids, and just about everything is more complicated than it looks. Here’s what I encountered, in semi-sensible order.
Adding BL-touch support requires making tweaks to the Marlin build.
Making tweaks to the Marlin build requires re-flashing the firmware.
Since the Ender 5 (Creality V1.1.4 motherboard) does not include a bootloader, I had to flash a bootloader prior to flashing firmware. The bootloader allows for flashing firmware via USB.
Flashing the bootloader requires using a USP-ISP or an Arduino Uno flashed with ArduinoISP to connect to the ISPC programing headers on the motherboard.
I used an Arduino Uno. I lost significant time to learning that a 10uF capacitor needs to be connected to the RESET and GND pins of the Arduino so that (as I understand it) the reset signal won’t be interpreted by the inline Arduino but passed forward to the target device. But yay, once that was done, I was able to reliably upload the bootloader. More importantly, I could take my laptop out of the equation and upload the firmware to Octoprint and use the firmware updater plugin to apply new firmware. This is much more streamlined because there’s no constant disconnect/reconnect of cables.
Meticulously following a guide for my specific printer, I was surprised when the orientation changed. Home/0,0 used to be in the back left on this printer with the stock Marlin 1.1.6 firmware on it. Imagine my surprise when my first test print started printing as if it was oriented in the diagonal opposite corner. This has cascading effects, from my calculation of nozzle to probe offset, to the move-out-of-the-way-to-pose-for-a-photo behavior for Octolapse, to the location of my Wyze Pan-Cam mount.
The whole concept of direction and home on a 3D printer, once it becomes disrupted, is extraordinarily confusing, and if you get it wrong, your shit will try to slide out of range and make a bunch of noise, and cause unnecessary wear on your parts.
The good news is, the probe “works” — as in it deploys and retracts, and senses surfaces. I still have more work to do with directions, inversions, and home locations before it correctly knows what’s going on, though.
Oh, and I also had to learn how to navigate VSCode/PlatformIO, because there are “issues” compiling this firmware via the Arduino IDE, which I had always used in the past.
I also had to disable certain less-than-necessary components of Marlin to build a firmware image that would fit in my ancient-ass 8-bit board. This probably means it’s time to replace the board with the fancy new 32-bit board, but as long as I can get this one to print, I think I can wait on that one.
All in all, I think I’ve dumped about six hours so far into this “improved experience” modification.
Improvements so far:
Incomplete BL-touch support
Disrupted orientation that still isn’t fixed
Marlin firmware went from 1.1.6 to 2.0.8.1. That’s got to be good, right?
When I finally got my hands on some Pico microcontrollers, I was excited to see what they could do. But I was used to the Arduino infrastructure and wanted to explore the Pico on its own terms.
Obviously MicroPython is the easy choice. Once the Pico is flashed with MicroPython firmware, you can write your code in Thonny and just save it straight to the Pico from within Thonny. Easy peazy.
Coding in C requires a bit more effort, especially at the start. You need to get the compiler installed, which varies by OS, and since I develop on a Mac with the M1 Silicon chip, it’s even more obscure for me. Fortunately, it’s all right there in the docs. Specifically, the “Getting Started” document, chapter 9, page 37. An architecture flag allowed the brew command to work, and I was off to the races.
Pin stuff is easy. I know I can do that. I wanted to skip to some wacky complicated stuff. So I started with the Waveshare demo for the Waveshare Pico-LCD-1.14 display hat with buttons. I decided i wanted to modify that demo to display my own image instead of the stock image. After some trial and error, I was sort of able to do so.
The image is stored as a c hex array. Getting that file exactly right was time-consuming. I didn’t see an image converter in their examples arsenal, so I found this one online. By tweaking the settings a bit I was able to get an image to display .. sort of. The color mappings are different somehow. Maybe 65K colors isn’t that many after all. I’ll have to mess with it with a more legible photo.
Original photo for reference:
The display is 240×135 and 65K colors. I’ll update this post when I figure out more. This is just to make it a little bit easier for those who want to get into C programming on the Pico but don’t know where to start.
Also, these kids will show you the general build environment / compile process completely if you live in Ubuntu-land. Amazing.
Next week’s meetup is slated to be DC540’s first in-person meetup this year. We decided to schedule the in-person meetup in the backyard. Since we made that decision, the CDC advised that vaccinated people should be able to gather indoors maskless. But we’re fine with outdoors. Especially since, when we scheduled it, it was looking like it might rain Monday evening, but since then the probability has decreased steadily. Looking very promising now.
We’ll have enough Raspberry Pi Pico microcontrollers to go around, I’m trying to pre-solder a bunch of headers so you don’t have to waste time soldering and you can get started right on deploying programs onto it. I’ll also have some breadboards and LEDs to play with if you’re so inclined. If you want to be prepared to play with that, install Thonny on your laptop and consider bringing a standard MicroUSB cable. MicroPython is WAY easier to get started with on the Pico than C. Plug it in with Thonny running, Thonny will prompt you to flash MicroPython firmware onto it, and then you can just save your python programs straight to the USB-connected Pico and run them. Easy as Pi.
Our next meeting will again focus on the Raspberry Pi Pico. We are looking at, weather permitting, an outdoor in-person meeting next Monday. Stay tuned in the Discord to see if it’s happening.
So, our regulars will know that one of our founding members, in a moment of extremely questionable judgment, purchased an entire REEL of Raspberry Pi Pico microcontrollers. If you’re out of the loop on this device, it’s closer to an Arduino than the previous iterations of the Raspberry Pi. While the Raspberry Pi 2, 3, 4 and Zero are all tiny computers onto which you install an operating system, the Raspberry Pi Pico is a microcontroller, onto which you flash firmware and code.
The Pico, as a microcontroller, has a lot of things going for it. It’s very small, it’s light weight, and the castellated edges provide a lot in terms of mounting flexibility. You can either mount it thru-hole or surface-mount it on pads!
The easiest way to use it is with MicroPython. By flashing the Pico with MicroPython firmware, it provides and environment that allows you to very easily drop new MicroPython programs onto the Pico just by pressing the boot button and having it mount to your computer as a storage device — programs that can easily interact with LEDs, sensors, servos, etc… basically anything that a microcontroller can do by sending and receiving data on its I/O pins, this little baby can do. See the recent post on the vintage powered breadboard for an example of the Pico in action.
This also includes using tiny OLED displays. For example, the Waveshare 1.14″ display for Pico — this is available in a “hat” format, meaning it sits right on top of the Pico once the headers are installed in the correct direction. At that point you can easily build a 3d-printed housing for it or include it in a larger project’s design. It conveniently includes four buttons to drive any menus you come up with or provide some other sort of input.
Then there’s the GPIO expander, also by Waveshare. It’s a single board, on which you mount the Pico, and it splits all of your GPIO pins into left and right versions. So if you have two different devices you want to connect (and there are no conflicting pins), it’s pretty easy to do that.
If you were around a few weeks ago, our man Kevin provided a really cool demo of reverse engineering using the Pico.
If the weather holds out, our next meeting maybe in person, outdoors, and we’ll have some cool Pico stuff to demo, build, and play with.
If you followed my previous post, you’ll know that I’ve been battling with one of those $20 LED 8x8x8 matrix kits recently. It was very frustrating, there’s little support out there and confusing information, and when you’re in that state you start to doubt yourself and assume you must have done something wrong. But I tested everything I could possibly test and I was convinced I did everything right.
At that point, all signs pointed to a chip that needed programming, and I tried with numerous sets of instructions and at least four separate programming adapters. Nothing was working, and the display stayed in its broken state.
I came up with two final plans. First, I would buy a new 12C5A60S2 IC, and see if that one would program correctly using the various adapters I have. Failing that, I would fork over the $20 for an entire new kit, build the base and test it extensively before attaching the LED faces to it.
The replacement chip was $5 shipped, so I pulled the trigger and waited. The chip arrived last night, but I wasn’t motivated last night, so I hit it first thing this morning.
Keep in mind, this is a “new” chip, allegedly.
I pried out the old chip, and carefully inserted the new one into the socket. I powered the unit up, thinking I’d spin around in my chair to access the programming interface (I’m using a Pi4 with the USB programming interface because linux supports the drivers natively). Imagine my surprise when the animations start scrolling on the LEDs.
What the everloving fuck? I bought what I thought was a brand new chip, assuming I would have to program it. Only to install it and discover it already has the animation firmware I need for my project?
Best as I can guess, this project is by far the most popular reason for people having these chips, and either it’s a return that someone programmed, or they preprogram all of them as a burn-in test. I might actually have to follow up with the ebay seller, because this has broken my brain.
A few weeks ago, I came across this vintage powered protoboard system on FB Marketplace. It seemed to be priced reasonably for its functionality, and the owner stated that it was working. So I snagged it. I admit I was tired of working with individual breadboard strips and cheap chinese power supplies, and wanted something larger and more stable. The fact that this provides 12V and 5V and a number of lamps, switches and buttons made it much more attractive.
I started looking online for a manual for it. It’s not a complicated unit, but I wanted to know what the manufacture intended for use case and workflow. So far I have been unable to find much on it other than a brochure on archive.org and a YouTube video from “IMSAI Guy” who picked one up for free at a junk drop-off location in Santa Clara. IMSAI Guy’s video was extremely helpful, as it gave me some clues about usage and expectations. Much of the board is unlabeled, but fairly intuitive. +12V and -12V terminals on the lower right, and two bare GND terminals near the bottom of the unit, are the only terminals that are labeled.
On the video, IMSAI guy shows two pairs of red terminals near the top, one on the left side and one on the right, and it sounded like he was saying that they are 5V terminals tied together. Here’s where mine starts to differ. Rather than two pairs of red, I have two red/black pairs. I powered it up and grabbed the multimeter. Measuring from red to ground gives the expected 5V. Black to ground gives zero. Is this another ground? Hmmm not quite. Red to black gives 4.7V. At this point I’m a bit confused. It’s definitely the same model as in the video, but it’s different.
So I went through and tested the other features. All twelve of the lamps are functional and pre-grounded with a 4.7K resistor inline, all you need to do is tie them to power >1.5V and they light up. The ten switches are nicely configured, they provide patch points for normal on and normal off. Same with the four momentary button switches.
There are edge PCB connectors on each side which I can’t imagine using at this point in time, and a pair of BNC jacks on the left side. Those could be interesting.
So I built a couple of Raspberry Pi Pico example circuits and powered them up, just for the photo op, and to put the thing through its paces.
But I was still perplexed about the black terminals. Why does mine have different terminals than IMSAI Guy’s? I made a mental note to open it up later and figure this out.
Then last night I looked at it from a different angle and noticed something I hadn’t seen before. There’s a DIN-5 connector on the left face of the unit that I hadn’t noticed before. What possible use for a DIN-5 connector would this thing have? I opened up IMSAI guy’s video again, and watched as he spun the unit. Nope, I don’t think his has this. Now I HAVE to open it up.
WOW. So mine is a modified unit. Getting the docs probably wouldn’t help at this point, unless this is a later model and how it was released by the manufacturer. (shrug).
I found another expired auction listing for one of these, and it did NOT have the DIN-5. So either it’s not stock or it’s a later model.
Opening up the unit, I find another board that’s not on the other two examples I’ve found. Over to the right is a more modern power supply than the brick transformer it came with. An E59712 board. And now the light bulb in my head goes on. Maybe, since this board seems to have adjustable voltage at R21, maybe it’s feeding the black terminals somehow, providing an alternative to just +/-12V or +5V. Further research required.
Add to that the fact that this subassembly is tied to the main power supply, the DIN-5 connector AND the surface board, and I’m starting to get a picture of things. I’m going to have to test more, but I feel like either this is a supplemental board designed to give more flexibility to the unit, or the main power supply died and this is a more modern replacement that was shoved in. I really am curious about the DIN-5 use case, though.
Mine had a SUNY asset tag on it, in case you’re curious. Anyhow, more digging later.
Update: Here’s a PDF of the original brochure. Not as good as a manual, but useful just the same.
