I needed a nice way to debug all the radio stuff I was doing in the spring of 2011, and the whole thought of hassling with serial ports gave me a headache. I had known for quite a while of a bit-banging USB solution on low-end 8bit Atmel microcontrollers, called the V-USB. I had been eager to try it, but I never really had a need for it, until now.
So, the vision was a USB dongle which could be used to receive and transmit packets easily through the radio module. In addition to help with debugging, I needed it to act as a PC interface to my other projects, such as home automation. Using it as a telemetry receiver, however, didn't come up until quite some time later, but as things turned out that's what I use it for mostly these days.
Bottom side view |
Top side with a rubber ducky antenna in the SMA connector |
- ICSP and radio share SPI
- Missing bypass capacitors
- Flux residues
The radio module was attached to the microcontroller through SPI and will act as a slave device, which means it will listen on MOSI and talk on MISO. The microcontroller of course acts as a master device when talking to the radio. However, the microcontroller is programmed through the SPI port and will act as an SPI slave device during this time. Meaning it will too listen on MOSI and talk on MISO. Since both devices are talking on the same line at the same time, we have a conflict and the programming fails.
Okay. It's not like I didn't think of that when I was designing the board. The thing is: the radio will only talk on the MISO line if its slave select line is pulled low. As the microcontroller is being programmed, it should release the slave select line and a pull-up resistor should deselect the radio. For some reason this does not always happen, of which I'm still unclear why. Anyway, in all of my later designs I added a jumper, or some other method, which can be used to disconnect the radio from the SPI bus. This problem didn't very much affect the usability of the dongle, because it can be programmed through USB anyway. The SPI programming was only used a couple of times at first, just to get the USB boot loader programmed.
I'm not sure if it ever caused any issues, but inspecting the board later on I noticed, that I had completely forgotten about the chip level bypass capacitors. There is only one capacitor on the output side of the 3.3V regulator. I bodged a couple of small ceramics between tracks, to make sure that insufficient bypass was not an issue.
What turned out to be a real problem was flux residue. You would assume flux used in electronics solder is non-conductive, right? Wrong! I'm pretty sure it depends on the type of flux, but whatever is in my soldering paste (I think it's just kolophonium) is a bastard. The problem is that the flux flows between the radio module PCB and the main PCB as well as between the microcontroller package and the main PCB, and causes "shorts". Of course they are not zero resistance shorts or anything, but they present a significant finite resistance, which changes rise times of especially the very weak drivers of the radio module (I think they are in the order of 1mA max.). Now, getting rid of the flux residues is a real pain in the ass. Kolophonium is not really soluble in water. It is supposed to be soluble in isopropanol, but even after keeping the boards submerged in isopropanol for a full day, the residues are still there. I tried:
- water & soap
- isopropanol
- commercial flux cleaning agent (smells and looks a lot like soapy water)
- ethanol
- acetone
- turpentine
- paint remover
And I'm happy to report that paint remover works amazingly well! Anything else on that list is not really worth the effort. The stuff I was using is something called Nitromors, but I've heard that many other paint removers work well too. This one has dichloromethane listed as the active ingredient and is a gooey consistency. Next bottle I buy, I'll probably go for something that's a bit easier to wash off.
No comments:
Post a Comment