Author: Baab

Posted on

KiCad: Cannot Determine Board Outline

I gave a silly little “Intro to KiCad” presentation at our meetup last night, before the weather came and insisted we not congregate outdoors.

I shit you not, it happened almost too fast to document. “Oh look, the sky is threatening. Oh wow, the wind is picking up. Better get the electronics inside. Oh, there go the beer cans and a dessert plate. Holy shit.

Then everyone scattered home, and it really came down. We actually had hail. It was the first time hearing hail in our house. People were concerned. The cat was concerned.

Anyhow, I wanted to relay a problem/solution I ran across yesterday, because I hadn’t come across this particular solution to the problem in my Googling, and maybe this will help someone.

PROBLEM: When trying to do a 3D view, you get the dreaded “Cannot determine board outline” message and it will not properly render your board shape.

VARIANT 1: KiCad provides coordinates to look at. In most cases, this is because your board edges aren’t properly connected and locked together. Go around the perimeter, zoom in very close, and click both lines, observing where the square marking the end of the segment appears. If they are in the exact same point, they are locked together, move on to the next one. If you need to move one, move it until a circle with a square inside appears, that’s the locked/connected indicator while moving the line.

VARIANT 2: KiCad provides no further information, just the subject error message. This one took me a few minutes. I walked the perimeter and everything was fine/locked. I turned off all other layers’ visibility except for Edge Cuts and could see no stray segments. I was confused. So I went old school. Knowing that all of these files are just text files with information, I grepped the .kicad_pcb file for “Edge” and was treated with the following:

  (gr_line (start -189 84) (end -189 -90) (layer Edge.Cuts) (width 0.05))
  (gr_line (start -114 84) (end -189 84) (layer Edge.Cuts) (width 0.05))
  (gr_line (start -114 -90) (end -114 84) (layer Edge.Cuts) (width 0.05))
  (gr_line (start -189 -90) (end -114 -90) (layer Edge.Cuts) (width 0.05))
  (gr_line (start -151.86914 77.27188) (end -151.87168 77.27188) (layer Edge.Cuts) (width 0.05))

My first clue was that my board shape was a rectangle and there were five segments described. The second clue is that fifth segment was too short. Ridiculously short. Invisibly short. So I zoomed in at those coordinates, and sure enough, there was a stray dot of edge cut sitting there that couldn’t be seen without the zoom. I removed it, then everything was fine.

Documenting here in case it helps others. But if you don’t move your board outlines much, and don’t accidentally draw on the edge cut layer and forget it, this probably won’t happen to you.

It occurs to me that this happens frequently with other layers, I often end up with an extra dot of something that I discover later when zoomed in. It might be useful to have a routine or view that just highlights every sub-millimeter unnecessary portion of wire, mask, edge or silkscreen that was probably left there by accident. 🙂

Posted on

Raspberry Pi Pico wireless communication

So this thing we’re working on, you know. This is the second or third iteration of an idea, and it finally got enough momentum to, you know, be something. Or become something.

Originally, we were going to do it on maybe an ESP8266. Then maybe an ESP32. Then the Pico came out, and we’re like, fuck it, let’s ride the wave of momentum of this new awesome microcontroller and see what we can do with it.

Well, it’s amazing, and awesome, and wonderful, BUT it lacks wireless communication.

And we started looking into what it would take.

And found a couple of articles that piggyback an ESP32 to handle the comms.

Meh. Nah. Number 1, if we wanted an ESP32, we’d just use an ESP32. Number 2, we don’t need, or even want, full wifi. We just want communication between units. For this thing of ours.

Then I saw that I can get this model of the NRF24L01+ for just a buck a piece.

Like the Pico, it has those glorious edges that can either be thru-hole (albeit half pitch) or surface-mount. I love that, you all know I love that. I love that you can mount it on a board and the other side of the board can be virtually unmolested.

So I picked up a few for testing.

And dang, they’re small.

And this half-pitch bullshit presents a problem for traditional breadboarding.

Fortunately, I have some SMD breakout boards that fit this perfectly. Let’s put a couple together for testing.

OK, now that I can breadboard this, let’s find some software for it.

NRF24L01 drivers for Micropython

These drivers won’t recognize the Raspberry Pi Pico without modification. You need to add a configuration line in nrf24l01test.py:

if usys.platform == "pyboard":
    cfg = {"spi": 2, "miso": "Y7", "mosi": "Y8", "sck": "Y6", "csn": "Y5", "ce": "Y4"}
elif usys.platform == "esp8266":  # Hardware SPI
    cfg = {"spi": 1, "miso": 12, "mosi": 13, "sck": 14, "csn": 4, "ce": 5}
elif usys.platform == "esp32":  # Software SPI
    cfg = {"spi": -1, "miso": 32, "mosi": 33, "sck": 25, "csn": 26, "ce": 27} 
else:
    raise ValueError("Unsupported platform {}".format(usys.platform))

Just add another elif stanza: 

elif usys.platform == "rp2": #Pico
    cfg = {"spi": 0, "miso": 4, "mosi": 7, "sck": 6, "csn": 14, "ce": 17}

and connect the appropriate pins on your Pico to the correct pins on the NRF24L01+:

So I did all this, and fixed the connections so that I wasn’t getting hardware failures. I did it twice, because the example code has a master function and a slave function. Yes, I know, these are now outdated terms. Maybe someone should tell them to update it.

Anyhow, nrf24l01test.master() broadcasts a packet with the milliseconds, and wait 250ms for a response. nrf24l01test.slave() will listen for those packets, and if one is received, send a response. I ran it, excitedly — one pico/nrf24l01 assembly running nrf24l01test.slave() and another running nrf24l01test.master()… and…

Nothing. Response timeout. Consistently. So I googled a bit, and found that with some devices, a capacitor is needed “to smooth the current.” Some docs say 10uf, others say 100uf. I found that 10uf cut the failures to about half, and 100uf eliminated the failures. With a 100uf capacitor between VDD and GND on the transceiver, responses come back steadily, even if I take the sender into another room, 30 feet away, even to a different floor of the house, with walls in between. I’m impressed.

sending: 2802292 2
got response: 2802292 (delay 40 ms)
sending: 2802591 4
got response: 2802591 (delay 34 ms)
sending: 2802886 8
got response: 2802886 (delay 35 ms)
sending: 2803177 1
got response: 2803177 (delay 39 ms)
sending: 2803475 2
got response: 2803475 (delay 35 ms)
sending: 2803770 4
got response: 2803770 (delay 35 ms)
sending: 2804065 8
got response: 2804065 (delay 35 ms)
sending: 2804360 1
got response: 2804360 (delay 35 ms)
sending: 2804656 2
got response: 2804656 (delay 40 ms)
sending: 2804957 4
got response: 2804957 (delay 45 ms)
sending: 2805260 8
got response: 2805260 (delay 37 ms)
sending: 2805558 1
got response: 2805558 (delay 38 ms)
sending: 2805853 2
got response: 2805853 (delay 42 ms)
sending: 2806153 4
got response: 2806153 (delay 35 ms)
sending: 2806449 8
got response: 2806449 (delay 37 ms)
master finished sending; successes=16, failures=0

Interesting info: I had so much trouble finding a KiCad symbol and footprint for this device that I started to build my own. But then I found one by accident in the mysensors repo. Important note: Pay attention to the symbol on this one. The symbol as provided in mysensors has VCC on pin 2 and GND on pin 1, but the units I received have VCC on pin 1 and GND on pin 2. I suspect that’s the reason for one review of the unit I ordered stating that the pinout was nonstandard. I don’t know what’s official and standard, but the pinout on the units I received match the photo above, so maybe mysensors is wrong, or maybe there is no standard. Just be aware so that you don’t smoke your transceivers.

Update: LOL. I take it back about the pin 1 vs 2 confusion. Look what they did in the footprint!

Posted on

Monday 6/14 Meeting is In-Person

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.

Posted on

Thonny, MicroPython and Pico Inside Out

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.

Mission accomplished!

Posted on

#badgelife development from a band of misfits

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 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 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 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.

Posted on

Fun with the ESP32-Cam

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:

https://www.thingiverse.com/thing:4315841

Posted on

My love-hate relationship with 3D printers

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?
Posted on

Fun with the Pico and C

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.

Posted on

Prepping for 2021’s first in-person meetup

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.

Posted on

More fun with Raspberry Pi Pico

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.