DC540

So I dropped my TS-80 portable soldering iron on the tile kitchen floor last week, and broke the glass covering the OLED. It still works, but it spooked me, because of #badgelife and the upcoming Defcon trip. Very bad timing. I wanted to make sure I had a backup in case we need to fix anything on the fly, or solder new stuff, etc.

I looked into getting another one, because I’ve been pretty happy with it, but then I found some posts touting the PINECIL. At about 1/3 the price of the TS-80, supports open firmware and custom logos just like the TS-80 and TS-100, and pretty well-reviewed.

So I got a PINECIL. It showed up last week. I plugged it into the same battery pack I’ve always used for my TS-80 (since fall 2018!), and it reported low voltage. Looked into it, and it turns out the PINECIL needs more juice than something made in 2018 can push. From multiple sources, the PINECIL really works its magic when it’s getting 60W at 20V. So now I need a new battery to power my new iron.

You should totally buy one. It’s just $35. https://amzn.to/3lqKDlp

I spent a couple hours looking at battery packs, specs, reviews, the whole bit. I finally settled on the EasyLonger model. 65W USB-C PD, 10000mAh. It’s important to stay below around 30000mah if you want to take it on a flight with you.

First test, fires right up, pumps the iron right up to the optimal temperature.

You should totally buy one, it’s about $55. https://amzn.to/2VhXpIj

Also get a high-capacity USB-C cable. The one I got is rated for 5A.

You should totally buy one. https://amzn.to/3xp9CrM

When we chose our badge design, we were cocky and full of ourselves, and went with surface-mount pads on our prototypes. Because our badge is based on the RPi Pico microcontroller, and had castellated edges, we figured we would minimize soldering, maximize space for silkscreen artwork, and up the cool factor by mounting on the pads using solder paste with the castellated edges.

Well, that turned out to be too hard. We don’t know what we’re doing, and didn’t have time for a learning curve, and kept running into bridging below the surface, which is hard to correct after it’s soldered down.

So we decided to go back to thru-hole with the finals. We soldered about half of them with thru-hole headers, which, let me tell you, is a pain. 40 header pins soldered to the board, and 40 soldered to the Pico. It’s tried and true, and any screw-ups are obvious and visible, but we were disappointed.

I was assembling the last of batch 1 earlier today, and decided on a whim to try headerless soldering directly to the pads with regular solder instead of paste. I used a 20-pin header temporarily on the left side to hold the pico in place on the board, soldered down the right side, then removed the header and soldered down the left. It worked great. It’s the best of both worlds. It saves wasted time with headers, cuts soldering in half, and keeps unsightly pins from poking out the bottom of the board. Just like regular thru-hole soldering, problems are visible. Bridging is not usually a problem, the solder tends to stick to the pads on the board as well as the generous copper pads on the Pico. All I need to do is make sure there’s a nice ramp from the upper pad, waterfalling over the castellated edges and onto the board pad.

If you ever have the urge to base a PCB around the Pico, consider this option.

Yes, we’re aware you can get the RP2040 chip on its own without the Pico, but one of our members bought a whole REEL of Picos, so it made sense for us to do this.

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

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!