BMOW title
Floppy Emu banner

Archive for the 'Dev Tools' Category

Zeroplus LAP-C 322000 Logic Analyzer Review

Who needs a logic analyzer? You do! If you enjoy working with electronics, a good logic analyzer is an indispensable tool. It lets you examine exactly what’s happening with your data signals, so you can troubleshoot problems quickly or reverse-engineer unknown protocols. Developing digital electronics without a logic analyzer is like navigating without a map.

In decades past, logic analyzers were bulky and expensive purpose-built machines from companies like Hewlett Packard. There’s still a place for such high-end equipment, but today most engineers can get everything they need from a small USB device that costs just a few hundred dollars. Saleae is one of the better-known names here, but it’s a crowded market with many worthy competitors. Which one is right for you?

 
Hello Zeroplus

Today I’ll take a look at an example of the Zeroplus “Logic Cube” series. Zeroplus is based in Taiwan, and their logic analyzer products have a good reputation among Taiwanese IT companies, but are less well known in the West. Full disclosure: Zeroplus sent me a demo unit for the purpose of this review. What you’ll read below are my own unfiltered opinions of the hardware’s strengths and weaknesses.

The members of this product family are buffered logic analyzers, with a few megabits of high speed on-board memory for storing the captured sample data. This is the more traditional approach to designing a logic analyzer, and it provides some advantages versus the on-the-fly USB streaming approach used by Saleae and other similar low-cost logic analyzers. Buffered LAs aren’t reliant on the PC’s USB bandwidth, so they can capture many channels at high sample rates without fear of saturating the USB link and losing data. The tradeoff is that buffered LAs have finite storage space, so the maximum amount of data that can be captured is limited. Data compression helps, but once the on-board memory is full, signal acquisition stops. In contrast, streaming LAs support “infinite” capture sizes limited only by the PC’s available RAM and disk space, but have limited bandwidth.

The Zeroplus logic analyzers in this Logic Cube series are commonly called “LAP-C” for the common prefix in all of their model numbers, and you’ll find the most pertinent resources on the web by searching for this term. LAP-C models are sold in seven different versions, differing mainly in the number of channels and amount of on-board memory. For this review, I tested the top of the line LAP-C 322000, with a retail price of $1699 in the United States. Here are the specs:

Logic Analyzer: Zeroplus LAP-C 322000
Number of Channels: 32
Sample Memory: 64 Mbits (2 Mbits per channel)
Max Sample Rate: 200 MHz
Vinput of Testing Channels: -30V to +30V DC
Retail Price: USD $1699

In comparison, the mid-range members of the LAP-C family pare back the number of channels and memory size in exchange for lower prices. For example, LAP-C 16064 is 16 channels / 1 Mbit / 100 MHz for $249, and LAP-C 16128 is 16 channels / 4 Mbits / 200 MHz for $399.

 
Unboxing and Hardware

While the front of the box has English text, the technical bullet points on the back are primarily in Chinese. This probably doesn’t matter much, since very few people will ever be browsing store shelves when shopping for a logic analyzer, but it shows that Zeroplus’ marketing team has additional translation work to do if they hope to attract more Western customers.

The 34-page instruction manual inside the box is also Chinese, but a well-written English-language manual can be downloaded here.

The logic analyzer unit and its accessories all fit inside a hardshell zippered case that’s included. While it’s a small thing, this is a very nice touch, and it makes it easy to pack up your project when you’re finished debugging hardware. The pulse width trigger module included with the LAP-C 322000 model is the only accessory that doesn’t go in the hardshell case.

The LAP-C 322000 package includes:

  • logic analyzer main unit
  • USB cable
  • 32 flying lead wires
  • 36 IC test hooks
  • printed manual (Chinese)
  • installation software CD
  • hardshell case
  • pulse width trigger module
  • hookup wires for trigger module

The pulse width trigger module is made from brushed aluminum. When connected to the main unit, this module upgrades the logic analyzer with a new feature: the ability to trigger on a high or low pulse whose duration is outside a user-selected range. This may be useful when working on PWM applications like dimmable lighting.

The main logic analyzer unit is made from an attractive gloss white plastic. The external interface is minimal: a button to start immediate captures, and status lights for Run, Read, and Trigger. The external connector is two rows of standard 0.1 inch male headers. In addition to the 32 data channel connections and ground pins, there’s also an external clock input, and a few special I/O pins for connecting the pulse width trigger module or a second LAP-C unit.

The LAP-C does not offer any analog measurement capability. While serious analog work demands an oscilloscope, some newer logic analyzers are starting to add low-bandwidth analog capability too. This can be useful for verifying that signal voltage levels are in a valid range, or that power supplies are behaving as expected. Analog measurement is a nice extra feature, but its absence here isn’t a deal-breaker.

 
Software

The LAP-C software is Windows-only. That’s not a big limitation, since any halfway-serious engineer will have access to a Windows machine even if it’s not their main system, but Macintosh and Linux software versions would have been nice. Windows 7, 8, and 10 compatibility is advertised. I used software V3.13.05 with Windows 7. You can download the software and try it out in demo mode, even if you don’t have the LAP-C hardware. The English-language software translations are generally well done and easy to understand.

The graphical interface appears geared towards advanced users, with a very large number of tools, measurements, and options visible directly on the main screen. This is great for power users, but may be overwhelming for newbies, or to anyone accustomed to the minimal interface of Saleae’s software. I found it a bit daunting at first, but after 30 minutes of experimenting and checking the manual, I had mastered the basics.

Some aspects of the UI would benefit from more polish. When viewing large data ranges, panning and zooming the waveform can be glitchy, with a laggy response to mouse input and different portions of the waveform scrolling a fraction of a second after others. Compared to the smooth pan and zoom of competing logic analyzer software, or to tools like Google Maps, that’s a little disappointing. Other minor graphical glitches and goofs sometimes appear, like waveforms that aren’t a uniform height or scale values that are the wrong units. The intervals of the ruler are also oddly chosen, with tickmarks at 0.409374912 seconds followed by 1.91042 seconds and then 3.411465 seconds, instead of divisions at even intervals using powers of 10. None of this prevents you from analyzing captured sample data, but it can be confusing and distracting.

A data capture can be started immediately by pressing a button in the software, or by pressing the physical button on the logic analyzer unit. Captures can also be triggered by a level or edge condition on a single channel, or by more complex functions like a specific value on a parallel bus, or a protocol-level event like an I2C NACK.

There are an impressive number of powerful features embedded in the LAP-C software. Repetitive run triggers the logic analyzer over and over, so you can look for one instance that’s different from the others. Noise filter ignores pulses with a duration below the threshold you specify. Data can be captured with an asynchronous internal clock, or synchronously using an external clock connection. Captured data can be searched in several different ways to find a region of interest. Waveforms and data can be imported and exported for additional examination with other tools. There are many more advanced analysis features that I didn’t have time to explore deeply. Some of these may only be valuable in specific circumstances, like the memory analyzer for examining address/data information, but they’re great when they provide the special capabilities you need.

One small but curious shortcoming: in the software’s list of choices for the sampling rate, it skips directly from 1 MHz to 10 MHz with no intermediate options. Most of my electronics projects operate a speeds faster than 1 MHz but slower than 10 MHz, so the missing sample rate options are a bigger issue for me than they might be for others.

Capturing and viewing sets of raw waveforms is great, and is the core of logic analyzer usage. But to really get the most out of the tool, you’ll want to use the software’s protocol analyzers to provide a high-level representation of the data. A protocol analyzer is a software module that converts raw waveforms into decoded data packets. For example, if the software offers an I2C protocol analyzer, then you can view the captured sample data as a series of device addresses, data bytes, and ACKs, instead of counting raw transitions of the SCK and SCL signals while you thumb through an I2C reference guide. The LAP-C software offers over 100 protocol analyzers, including I2C, SPI, serial (RS-232C/422/485), JTAG, PS/2, USB, 1-WIRE, CAN, IRDA, 3-WIRE, and many more. Some of these used to be extra cost options, but since 2016 all the protocol analyzers are available free. Here’s a typical protocol analyzer example from Zeroplus:

 
How Much Sample Memory Do You Need?

When purchasing a buffered logic analyzer, you need to predict in advance how much sample memory you’re likely to need. Underestimating is bad: if there’s not enough sample memory, you won’t be able to capture as many channels for as long a duration as needed for your debugging work. But overestimating is bad too: it means you’ll pay hundreds of dollars extra for additional sample memory you don’t need. So how can you decide how much memory is enough?

This is a difficult question to answer, because it depends heavily on the type of electronics work that you do. You might work primarily with low speed serial signals, or you might need to analyze a wide parallel bus running at high speeds. Your data might be highly compressible with the LAP-C’s compression algorithm, or it might not. This leads to a frustrating “it depends” answer that satisfies no one.

For my own hobby electronics work over the past few years, I typically need to analyze systems with 5 to 10 signals running at speeds between 1 MHz and 10 MHz. My normal work pattern with a streaming logic analyzer is to manually start the capture, and record a few seconds of data, then examine it afterwards to zoom in on the interesting parts. Using a buffered logic analyzer, without the benefit of compression, this would require a worst case of 10 signals times 10 MHz times 10 seconds, or 1000 Mbits total. My simple experiments with LAP-C compression found that it provided about a 10x improvement for my data, so that reduces the memory requirement to 100 Mbits – close enough to the LAP-C 322000’s 64 Mbits. So with the top of the line LAP-C model, I could probably support my existing work pattern, but anything with less memory would be insufficient.

To really get the benefit of the LAP-C hardware, I would need to stop using 10 second long captures, and instead set up triggers to capture only the few hundred milliseconds or microseconds I’m really interested in. That would require some extra time for setup, but would greatly reduce the amount of memory needed.

 
Other Thoughts

Zeroplus’ web site lists two official US distributors, and one appears to only stock the entry level LAP-C 16032, leaving a single source for most LAP-C models in the US. With a bit of Google searching, you can also find third-party LAP-C sellers from Asia who will ship directly to the US. Direct sales from the Zeroplus web site would be a welcome addition, but are not currently an option.

Is the Zeroplus LAP-C series right for you? It depends on what you plan to do with it. For the casual electronics hobbyists who are typical readers of this blog, the $1699 price tag of the LAP-C 322000 may be more than they’re willing to spend, but they probably don’t need all the features of the LAP-C 322000 either. Zeroplus offers three LAP-C models with slightly lower specs all priced below $400, which are probably a better fit for part-time garage hackers. I expect that most hobbyists will be fine stepping down from 32 to 16 channels, although stepping down from 64 Mbits of memory to 4 Mbits or 1 Mbit may be a concern.

With 4 Mbits and 16 channels, at a 10 MHz sample rate and using compression, you’ll get a capture window of a couple hundred milliseconds. That’s small enough so that manual triggering is unrealistic. Instead, you’ll need to plan ahead of time to decide what your goal is with this capture, and how you can construct a trigger to capture exactly the region you need to examine. For power users working with high speed systems and large numbers of channels, this will already be familiar. They’re more likely to know specifically what they’re looking for, and to see complex trigger setup as a normal and expected part of debugging. They’re also more likely to benefit from some of the LAP-C’s advanced features and hardware options like external clock input, pulse width triggering, and detailed software analysis. The breadth and depth of the LAP-C software’s various tools and analyzers is impressive, and will surely be a boon for hardcore electronics engineers. Beginners and others with more basic needs may be better off with an 8-channel streaming logic analyzer with a simple and friendly software interface.

What about the general merits of buffered vs streaming logic analyzer designs? For situations where there’s enough USB bandwidth to stream the sample data on the fly, I believe that approach provides a better user experience. There’s no need to worry about trading off sample rate for sample depth, or worrying whether the capture window will be large enough to contain all the events of interest. But for more demanding situations with large numbers of channels and high sample rates, streaming just doesn’t work. 32 channels at 200 Mhz sampling rate is 6.4 Gbits/sec, which is more than USB 3.0’s total maximum theoretical bandwidth and far more than its real-world bandwidth. So depending on the application, both streaming and buffered designs have their place.

My ideal logic analyzer would be one that operates in streaming mode where sufficient USB bandwidth is available, and falls back to buffered operation when streaming won’t work. That would probably be needlessly complex and expensive, but I can dream!

Read 4 comments and join the conversation 

PIC32MX Mini-Review

Now that I’ve been using a PIC32MX microcontroller for a while, and its associated software tools from Microchip, it’s time for a mini-review. My previous microcontroller experience was primarily with 8-bit Atmel AVRs, so my comments will reflect that. Many of the differences between a PIC32MX and AVR will also apply to any other modern 32-bit microcontroller, like the many ARM variants.

On the whole, I’ve been fairly pleased with the PIC32MX. Below you’ll see that I’ve written much more about dislikes than likes, but that’s because the likes are largely self-explanatory, while the dislikes deserve a more detailed explanation.

Note: Last year Microchip purchased Atmel, the makers of the AVR. So now both of the microcontrollers in my comparison are provided by the same company.

 

HARDWARE LIKES

Faster core speeds – Up to 50 MHz on my PIC32MX230F256, 80 MHz on other devices in this family.

Clock PLL – Synthesize core speeds anywhere from 1 MHz to 50 MHz from a fixed-speed external crystal or internal RC oscillator.

More flash memory – 256KB seems like a lot.

Configurable pin remapping – Relocate functions like the UART’s TXD and RXD to one of several different possible physical pin locations. Makes PCB routing much easier.

Set / clear / invert registers – Modify a single GPIO pin with a single instruction, without needing to do a read-modify-write of an entire port.

DMA – I haven’t used it yet, but this will enable possibilities like writing a long piece of text to the serial port while the program continues on to do other things.

 

SOFTWARE LIKES

IDE – The Microchip MPLAB X IDE seems pretty good, after you install the separate PLIB libraries that are required for compiling all the example code.

Debugger – With the el-cheapo PICKit 3 programming tool, you get a halfway decent debugger in MPLAB X. I can’t believe I survived for years on the AVR with no debugger at all.

 

HARDWARE DISLIKES

Bloaty code – A similar amount of code seems to consume substantially more program flash memory on the PIC32MX than the AVR, so the larger amount of flash on the device isn’t as much of an advantage as it first seems. Part of this is due to the hardware difference between 8-bit and 32-bit instructions, and part due to compiler optimizations to software (see below).

Awkward bootloader setup – The PIC32MX230F256 has 3KB of protected boot flash, which isn’t enough to do anything useful, considering how bloaty the code is, and that more than 1KB will be consumed by interrupt vector tables and the C startup code. My USB mass storage device bootloader is 39KB of code! This forces the bootloader to be located in main program flash, which requires using a customized linker script for the main program to map everything to new memory locations, which requires that the bootloaded and non-bootloaded versions of the main program are subtly different.

No EEPROM – AVR has separate non-volatile EEPROM memory for storing user preference data, that can be updated one byte at a time, and is rated for 100K erase cycles. PIC32MX has no equivalent. You can reuse some of the program flash memory for the same purpose, but it can only be updated one page at a time (1K or 4K depending on the device) and is rated for 10K erase cycles.

Fewer instructions per clock cycle – AVR executes one instruction per clock cycle, so 16 MHz means 16 MIPS. The number of instructions per clock cycle for PIC32MX varies, but will on average be less than one, due to flash memory wait states, addressing modes, pipeline stalls, and other factors. So while the core speed of PIC32MX might be 3x faster than AVR, it won’t necessarily run code 3x faster.

 

SOFTWARE DISLIKES

Debugger limitations – When using the PICKit 3, the debugger can’t view arbitrary memory or array elements, can’t set new breakpoints while the program is already running, can’t step through a disassembled view of arbitrary code (without a map file), and is incredibly slow for single-stepping through code. I’m not sure if these are software issues, or limitations of the PICKit 3. Microchip offers other more expensive debugging tools that may address these issues.

Limited compiler optimizations – The XC32 compiler that’s included with MPLAB X will compile your code with -O0 (no optimization) or -O1 (some optimization for speed and size). But it won’t do -O2 (more optimization for speed) or -Os (optimize for size). It also won’t do a bunch of related linker optimizations to help reduce code size. Those require the pro version of the compiler, which is a $30/month subscription.

Mixed quality libraries and code examples – Almost all the PIC example code you’ll find on the web, from Microchip or 3rd parties, uses the PLIB peripheral library along with MLA (Microchip libraries for applications). A few years ago these were officially discontinued in favor of a newer solution called Harmony, but the developer community has largely ignored Harmony and continued using PLIB and MLA. The strong impression I had was that attempting to use Harmony would make life unnecessarily difficult. Yet some of Microchip’s newer code examples are only available in Harmony versions, while older examples are only PLIB/MLA versions, resulting in a confusing mess.

Many of the PIC32MX code examples I found were designed for the top of the line, the PIC32MX795. These examples are mostly applicable to the PIC32MX2xx family too, but sometimes there are subtle differences that are difficult to catch. For example, Microchip’s PIC32 USB mass storage bootloader example assumed the device had a flash erase page size of 4K, with a comment in the code that said “do not change this value”. Only after much frustration did I discover why it wasn’t working reliably – the PIC32MX2xx has a 1K flash erase page, so the Microchip code was only erasing 1/4 of the the flash memory during bootloading.

Read 2 comments and join the conversation 

Reflow Soldering Re-re-re-revisited

This was my 6th *@#&% attempt to assemble some ROM-inator II PCBs using reflow soldering, instead of my normal drag-soldering with an iron. I may not be too bright, but at least I’m persistent. All of the previous attempts failed in slightly different ways, resulting in boards with multiple solder bridges that needed to be cleaned up manually with an iron. This time I altered the way I created a frame for the board being reflowed, and it almost worked. It was certainly the best result so far, but still not good enough.

You can read about the previous reflow attempts here:

1. Reflow with hot air
2. Switched to a hot plate
3. With an aluminum pie pan
4. New solder paste and aluminum sheet
5. Using a stainless steel stencil

My reflow soldering adventures have been a challenge for two reasons:

1. The ROM-inator II PCB has two chips with 0.5mm pin spacing, which is very small. If my boards had larger components with more forgiving pin spacing, my earlier attempts would probably have gone much better. 0.5mm might be approaching the limit of what can be done at home without special equipment.

2. I need the PCB to be 100% perfect after reflow, with no manual touch-ups required to fix solder bridges. If this were a one-off prototype, a few solder bridges would be no big deal. But since my goal is to develop a new process that’s faster than hand-soldering, I can’t afford the time needed to do manual touch-ups after reflow.

 
Floating Stencils

In my previous attempt, I used purpose-made plastic framing pieces to hold the PCB while I applied solder paste with the stencil. These plastic pieces were a tiny bit thicker than the PCB, resulting in the stencil floating above the surface of the PCB instead of resting on it. The amount of float was less than 0.3 mm, but it was still enough to cause problems. This time I used extra PCBs to create a frame, so the thickness was an exact match with no float. The solder paste application looked pretty much spot-on, as you can see here:

Placement of the chips is still difficult. I’m doing it by hand with a pair of tweezers, and the best I can do is to drop the chip within a couple of millimeters of the correct position. Then I slide it around until it’s in the right spot, smearing a bit of the solder paste in the process. Here’s how things looked after chip placement:

After reflow on my hot plate, the results were pretty good, but unfortunately there were still several solder bridges. Here’s a typical example. It all looks decent, except for those two pins at the far left. The chip also didn’t snap to the correct alignment, as I’d been led to believe would happen thanks to the surface tension of liquid solder. The alignment is pretty good, but not quite centered, and there’s a bridge at pin 1:

I assembled ten boards this way, with two chips per board, and two sides to be soldered per chip, making a total of 40 sides. The good news was that 14 of the 40 sides had zero solder bridges. The bad news was that about half the sides had 2+ solder bridges, and I never assembled a PCB that didn’t have at least one solder bridge on it somewhere. This was the final score:

0 solder bridges: 14 sides
1 solder bridge: 7 sides
2 solder bridges: 7 sides
3 solder bridges: 3 sides
4+ solder bridges: 9 sides

I discovered that I needed to wipe both sides of the stencil clean after each use, otherwise the solder paste application grew progressively messier with each new PCB. I also found that I wasted a lot of solder paste. Dispensing the minimum possible amount from my syringe was still too much, and resulted in a lot of leftover paste on my plastic scraping tool. It was hard to reuse the paste stuck to the scraper. When I tried it a couple of times, using another scraper to clean off the first scraper, the results weren’t good.

 
End?

Is this the end of my reflow soldering saga? I think so, at least for this particular PCB. I don’t think I can improve further on these results without more effort than can be justified, yet the speed and quality of the process isn’t good enough to replace my current method of drag-soldering with an iron. I’ll revisit this again the next time I have a new PCB to assemble, and I’ll try to stay away from 0.5 mm pitch parts in my designs.

Read 7 comments and join the conversation 

Reflow Soldering with Hot Plate and Stencil

This was my 5th attempt to assemble some ROM-inator II boards using reflow soldering, instead of my normal drag-soldering with an iron. After various failures in the previous attempts, this time I used a stainless steel stencil to apply solder paste to the pads, hoping the stencil was the missing ingredient needed for success. I’ll save you the suspense: it didn’t work any better than my earlier efforts. I think I’m cursed.

You can read about the previous reflow attempts here:

1. Reflow with hot air
2. Switched to a hot plate
3. With an aluminum pie pan
4. New solder paste and aluminum sheet

The ROM-inator II PCB has two chips with 0.5mm pin spacing, which makes home reflow particularly challenging. If my boards only had larger components, SOICs, and the like, my attempts would probably have gone much better. With the 0.5mm chips, no matter what method I tried, I ended up with numerous solder bridges between adjacent pins. I was able to fix up the solder bridges manually with an iron, so all the boards worked in the end, but reflow totally failed as a faster and easier replacement for drag-soldering. For that, I’d need boards to come out of reflow with zero solder bridges at least 80-90% of the time, and I was never anywhere close to that level of success.

 
Stencil Process

I ordered a 4 mil stainless steel stencil from OSH Stencils, and paid a little over $20 for the stencil and a couple of acrylic framing pieces. Ordering was easy, but I did run into a a few problems with my paste layer generated by EAGLE. The paste layer also contained my board outline, which I clearly didn’t want cut into the stencil. It also contained openings for all the edge contact pads on the PCB, which are not meant to be soldered. It required some extended futzing around in EAGLE in order to suppress the unwanted outline and pads, and generate a new paste file.

I taped the acrylic framing pieces to my desk, along with an extra blank PCB, to create a secure frame. Next, I placed a ROM-inator II PCB in the frame, and taped the stencil over it. Aligning the stencil correctly with the pads underneath was easier than I expected, even for the sub-millimeter sized pads. I then squirted some solder paste from a syringe onto the stencil, and used a plastic card to scrape the paste across the stencil, filling the holes.

Framed area for PCB:

Blank PCB in frame:

Stencil positioned on top of PCB:

Solder paste applied to the stencil:

After scraping paste across the stencil:

The PCB after removing the stencil:

Scraping the paste into the stencil openings was more difficult than I’d expected. I’d thought I would be able to make a single pass and fill all the holes, but some holes only partially filled with paste, even when there was plenty of paste scraped over them. Something to do with the thickness of the stencil, the size of the openings, or the viscosity of paste maybe? I had to make repeated passes from different directions with the plastic scraper before all the stencil openings were filled evenly.

One problem I hadn’t anticipated was the thickness of the acrylic framing pieces. They’re about 1.5mm thick, but the ROM-inator II PCB is only 1.2mm thick, resulting in the stencil floating 0.3mm above the PCB. 0.3mm may not sound like a lot, but it’s about 3x the thickness of stencil. In practice, the stencil flexed enough that it mostly sat flush on top of the PCB, but it clearly wasn’t ideal.

The final photo above shows the mixed results of solder paste application. For larger things like the C1 capacitor, it was great. And for many of the individual pads on chip IC1, there was a nice clear line of paste right on the pad. But for many other pads, the solder paste was smeared between several adjacent pads. Not good.

The final difficulty was placing the chip on the pads. Even where I had clean lines of paste, it was difficult to position the chip accurately without smearing the paste around in the process. I would drop the chip down with tweezers, close to where it needed to go, but “close” wasn’t close enough. Even a tiny sub-millimeter nudge to line up the chip properly was enough to smear paste from one pad to the next, possibly negating the whole benefit of using a stencil in the first place. Here’s what things looked like after placing the chip, but before reflow:

 
Results

The result was similar to all my previous attempts: lots of solder bridges. Not surprisingly, most of the bridges showed up in those areas where the solder paste was smeared before reflow, but some bridges appeared even in areas where the paste had looked OK. Here’s how the same chip looked, after reflow with the hot plate:

I tried a second PCB, this time attempting to use less solder paste overall, but the results were the same. Then I tried a third PCB, and scraped the solder paste across the stencil left-to-right, parallel to the orientation of the pads, instead of perpendicular. That resulted in some weirdly uneven application, and more of the same solder bridges after reflow.

I could never get the solder paste application to come out cleanly, and it always seemed like too much.

 
Conclusions

At this point I’ve run out of blank ROM-inator II PCBs, so my experiments will have to stop for a while. I hate to end a series on a down note, but I’m a little frustrated and disappointed with this whole effort. Maybe I would get better results with thinner frame pieces, or a toaster oven instead of a hot plate, or yet another brand of solder paste, or a different paste applicator, or more flux, or a pick-and-place, or… but at some point I have to admit this just isn’t working. Once I get more blank PCBs to play with, I’ll consider whether to try further experiments.

Read 8 comments and join the conversation 

Reflow Soldering Still Doesn’t #*&@ Work

After four semi-failed attempts, I am not destined for success with reflow soldering using an electric hotplate. At least not with chips having a 0.5 mm pin spacing. At this point I’m only motivated to continue on by pure stubbornness, as any hope that this would “save me time” is long gone.

Building on the results of my most recent previous attempt, I tried again with a new aluminum plate and new solder paste. I was pinning my hopes on the new solder paste, after having discovered that my original solder paste syringe had already expired by the time I bought it. I suspected that the poor wetting behavior and large number of solder bridges were due to spoiled paste. Judging by its date code, the new solder paste was only five months old, and before purchase it was stored refrigerated by DigiKey to prevent spoilage. They shipped it in a cold pack, at least, so I assume it was refrigerated before that.

The results were sadly the same as my prior attempts: poor wetting and tons of solder bridges. Apparently it wasn’t my solder paste’s fault, but my technique. The video shows the story in all its gory detail.

After having more-or-less exhausted the other possibilities, I’ve come to the conclusion that using a stencil must be essential for success. Maybe no-stencil application of solder paste direct from the syringe can work for components with nice big pads, but not for chips with 0.5 mm pin spacing, unless you want to spend time afterwards manually fixing solder bridges with an iron. Lacking a stencil, I prepared a second PCB by carefully smoothing out the solder paste with a cotton swab, trying to approximate the result of a stencil. I couldn’t avoid getting solder paste between the pads, of course, but I tried to get a thin and even coating over the entire pad area. Here’s what this second attempt looked like, prior to placing the components:

Looking at this photo now, the solder paste coating is kind of terrible, but at the time it seemed good. It’s hard to appreciate just how small those pads are, and it’s very difficult to spread the solder paste around evenly with a cotton swab.

After reflow, this second board turned out better than the first. There were fewer solder bridges, and the overall distribution of solder was more uniform. It was still far from acceptable, though.

Now it’s time for a decision. Do I order a stencil, and try again? Out of pure stubbornness and a desire to see this finally work, I want to say yes. But the practical part of my brain says no, I’ve already proven that it’s faster to assemble these boards with my current technique of drag-soldering. That makes success or failure with reflow and a stencil irrelevant. Maybe I’ll try it anyway for “educational purposes” – a sure way to justify any questionable idea.

Read 16 comments and join the conversation 

Hot Plate + Aluminum Pie Pan = No Joy

I’m back with another episode of my DIY reflow soldering adventures! The first attempt using hot air didn’t go well, and the second attempt with a hot plate and half-inch thick aluminum block wasn’t great either. This time I used a lightweight disposable aluminum pie plate instead of the half-inch aluminum block. The idea was to reduce the thermal lag observed with the thicker block, and make it easier to remove the PCB from the hot plate after reflow was complete.

The lightweight pie plate proved to be a bad idea. Its bottom was embossed with small ridges, and was slightly warped and dented. The pie plate wouldn’t sit flat on the burner, and the PCB wouldn’t sit flat on the pie plate. To make matters worse, the pie plate also deformed as it heated. With such poor thermal contact between the burner, pie plate, and PCB, the PCB heated very slowly and unevenly. It did eventually reflow successfully after 10 minutes of heating, but I had to push down one side of the PCB with tweezers to improve the thermal contact.

The results of reflowing looked similar to my first reflow attempt using hot air: not good. There were solder bridges everywhere, but also clear evidence that many pads were dry, with only a portion of the pad area covered in solder. The photo above shows an example. The bare pads are ENIG plated and have a gold color. After reflow is finished it’s easy to see the areas that are still gold-colored, where solder never flowed. Ideally there should be no such areas.

Such poor flowing of solder makes me think the flux in my solder paste has gone bad. A few days ago I discovered that my newly-purchased paste was already beyond its shelf life, so I’ve got more solder paste on order. Hopefully that will result in better solder flow, with pads that are completely covered in solder, and few or no solder bridges.

 
It’s All About Time

My main goal with this whole reflow adventure is speed. I hope to assemble batches of a few dozen ROM-inator II PCBs faster than I can by drag-soldering with a standard iron. I can finish one PCB every 10 minutes with drag-soldering, and at least half of that time is consumed by fixing solder bridges. If I have to spend a similar amount of time fixing solder bridges on the reflowed PCBs as on the drag-soldered ones, then it’s unlikely reflow will provide the speed-up I’m looking for.

Even if new solder paste resolves my solder bridge problems, I’m also concerned by the setup time required to dispense the solder paste and position the chips. I timed these steps, and they took 6 minutes, all before the reflow process even started. With practice I could probably speed that up by a minute or two, but that still puts the total time including reflow close to 10 minutes, even assuming everything goes perfectly with no solder bridges. Only by reflowing multiple PCBs at once could I hope to save any appreciable time vs drag-soldering.

The video shows the entire process end to end, including dispensing the solder paste, placing the chips, reflow heating, and saying “woah” and “oh my gosh” about 20 times. I apologize for the poor quality of the video. My hand often blocks the view, and the camera isn’t positioned well to show the solder reflow in detail. Maybe you’ll find the “authentic amateur” style amusing!

Read 8 comments and join the conversation 

Older Posts »