Monthly Archives: July 2014

At the dirty board house in Shenzhen

Through the marvels of globalization and modern technology, my solar charger design, dubbed the Solar Stage, has been sent off to a board house in China for low cost production. Thanks to DirtyPCBs, and its sassy yet functional website, I placed my order for 9 to 12 boards of my 10 * 10 cm 2-layer design for only $25 (including Hong Kong Post — no tracking). Yes, that’s no typo. $25. Oh, and a pick from 6 colours (I chose red). 5 * 5 cm is a jaw-dropping $14.

Front of the image generated by the DirtyPCBs website. After countless revisions, the board is ready. A Dangerous Prototypes Bus Pirate and a self-designed SD/flash combo board occupy the space unused by the Solar Stage.

According to the DirtyPCBs website, my Gerber files are transmitted through their automated system to a board house in the high tech heart of China, where it’s batched up with other boards and given the full treatment. The boards are then forwarded on to the DirtyPCBs agent, to be sent on to me. The whole process takes 6 to 8 days, not including the postage time (1 to 8 weeks for Hong Kong Post, dependent on your country). Amazing!

Back of my board order.

One feature I really appreciated is DirtyPCBs unlimited file revisions. Up until the point the board design is sent to the board house, the site accepts a re-upload of your design files. In the 31 hours before it was batched, I submitted five (5) updates. In my post-submission high, I noticed little bits I could improve and went over everything with a fine-tooth comb. Nothing like the thrill of working against the clock! Granted, it might be a bust, but at least I have some useful boards out of the experience.

To be honest, I enjoyed the cheeky language that peppers the website. Apparently the website was originally made as a joke poking fun at people complaining about the quality of a new process. Or a very clever dirty marketing. Either way, the results are impressive for the cost, so I decided to give them a shot. Tonight I received a notification saying my board has been batched up. Stay tuned for an update when my dirty boards arrive.

Leave a comment

Filed under Battery power, DIY, fabrication, ICs, micro-controllers, PCB design, Solar Stage, Teensy

Progress on solar MPPT board

My first stab at PCB routing, using the design rules from

Perhaps overly complicated, but the challenge of routing a bunch of pins so close together was pretty fun. I will post a final schematic later, but here is what I have so far. Don’t mind the cramped nature of the drawing, for I am contending with EAGLE’s freeware limitations & paneling to cram other useful stuff onto the remaining 10*10cm allows.

Top layer

Bottom layer

Leave a comment

Filed under Battery power, DIY, fabrication, ICs, PCB design, regulators, Solar Stage, Soldering, Teensy

New software: Cadsoft EAGLE PCB

In order to bring my prototypes to the next stage, some professional software is needed. Enter Cadsoft’s EAGLE PCB. A fully-featured schematic and printed circuit board layout and design program, it comes bundled with an extensive library of devices and components from all the major manufacturers. Any parts that are not included are easily designed using a three stage process: schematic symbol, package layout, and device connections to tie the first two together. Although EAGLE has a bit of a learning curve, it’s quick and powerful once you develop an appreciation for the EAGLE way. Special thanks to Warren Young aka Tangent for his clear & succinct EAGLE tutorial videos.

Here is my first stab at a schematic diagram, including two of my own EAGLE components. A brilliant short-cut with EAGLE is the ability to borrow from existing symbols & packages, making for quick custom parts.

First EAGLE schematic using the SPV1040 & LTC4071 as the power portion of a solar harvesting wireless sensor platform.

While overall I have enjoyed my time with Cadsoft EAGLE PCB, it does leave a significant bit to be desired in the UI scaling department. Given my HiDPI display, EAGLE doesn’t support scaling of its icons and static help text, leaving me squinting whenever I consult the help function. Thankfully the text command shortcuts make fumbling for the tiny icons a rare ordeal.

Leave a comment

Filed under Battery power, ICs, PCB design

This looks challenging…


Leave a comment

2014-07-13 · 01:21

CaTrakr v0


openGLCD makes programming the display a joy.

Leave a comment

Filed under ICs, Lights, micro-controllers

Data over radio to remote display

After fussing with two SPI devices that were not playing nice (namely, the TFT’s ST7735 and the NRF24L01+ radio), I turned my attention again to a graphic LCD module (MTB-368 from ETT Co. in Thailand) found on eBay back in January. Its M68-type parallel interface made it a bit trickier to get going. On top of this, it uses 5V logic, and my Teensy 3.0‘s Kenetis is 3V3. Google’s only hit for a datasheet was mostly in Thai. Thankfully, a quick email to the manufacturer yielded an English manual.

First shot at a 5V GLCD to a 3V3 micro.

Next, finding a library that would allow me to talk to the GLCD with my MCU in at a high level. Thankfully, there were two candidates: openGLCD and u8glib. To correct for the logic voltage level mismatch, I used 10K Ohm resistors in series on the bidirectional data lines. After many hours of fiddling with code and configuration with both candidates, I was no farther along than illuminating the backlight and a few erratic lines through the display.

After posting to the Teensy forum at PJRC, I had contact with the developer behind openGLCD, Bill Perry, and with his help we were able to get the MTB-368 running. One point that was unclear from the GLCD module’s datasheet was whether the CLK pin (not common on SED1520-based controllers) was an input or output. After Bill correcting some timing and initialization sequences, the MTB-368 still wasn’t working, though it was behaving differently.

After looking for more MTB-368 modules online, I noticed the SBN1661 (a cousin to the SED1520) had a similar configuration with its backlight circuitry, and also required a clock. Based on a hunch, and after confirming there was no readable voltage on the pin, I configured my Teensy board to provide a 2kHz square wave (50% duty cycle) by adjusting Timer 1 (pins 3 and 4). With the LCD running on my new bi-voltage UNO, the Teensy was free to experiment with PWM timing. After a rough shot at the right frequency (I do not have a scope — yet), the MTB-368 leapt to life.

Having already done a experiment with a set of nRF240l+ PA/LNA v5.1 radios (recommended: conforms to layout spec), I hooked up the GPS on the client side (UNO) and the display on the server side. Both the Teensy and the UNO communicate with the NRF radio using the RH_NRF24 library and its ReliableDatagram manager. All my experiments to-date have used the library’s default rate of 2.402 GHz (channel 2), 2Mbps, and 0dBm. PA and LNA have not been used.

UNO clone handles the reading & transmitting.

The biggest challenge in sending GPS data over the radio was getting the two fields, latitude and longitude, mashed together with the appropriate separator and passed in the correct format to the radio manager. According to RH_NRF24’s documentation, the data packet buffer requires an unsigned 8-bit pointer (uint8_t*). TinyGPS++ provides an object for every data field in a floating format. Thus my challenge was two-fold: mashing the two together and converting to a binary format needed for the radio manager.


This project quickly became a study in the differences of micro-controller C versus its big brother running on full computers. The usual suspects for type conversion, including stringstream and lexical_cast, are not included in the anemic version of C++ running under the hood of Arduino. Even heap functions, such as those used by printf in its floating number handling, is unavailable. After getting a grasp on data types, casting, and forming data to satisfy different applications (and compiling without error!), I discovered the hobbled printf wasn’t going to cut it. Fortunately, a quick Google search provided an alternative: dtostrf().

Almost every pin in use on the Teensy 3.0 — 20 in all.

Some more fiddling with proper casting yielded a functional result. Data was received from the other side of the house with virtually no missed packets. Further work includes additional GPS fields, logging on the server, and display layout to maximize data on the screen and minimize refreshes. Experimenting with different channels, signal strength, and data rates. Additional sensors may also be included in the wireless mix.

Data from the remote GPS received over radio and displayed by the server.

Data from the remote GPS received over radio and displayed by the server.

Arduino sketch for the client:


Leave a comment

Filed under C++, code, DIY, ICs, micro-controllers, radio, Teensy

Location rx’d!


Progress on a location/radio project.

Combining 3 devices on one MCU.

Project involves two MCUs, two radios (not pictured), and a GPS receiver.

Leave a comment

Filed under DIY, ICs, Lights, micro-controllers, radio, regulators, Teensy