RaspberryPi Robot

It’s been almost two years since I did (or at least started) this project but I never sat down to document it. That’s what I want to do today. As the title says it’s about a little robot based on a RaspberryPi. Like many of its kind it is driven by a pair of stepper motors each driving a wheel directly attached to the respective motor axis. At the back there is another smaller, pivotable wheel to keep the robot in balance.

Here’s a video of the finished robot in action, running a simple demo program demonstrating the various functions.  By the way, I’ve started a youtube cannel to share these kind of videos. I’m not really a video guy so this text and photos blog will stay my main medium but some projects like this robot, videos are a welcome addition.

Yes, I’m well aware that many similar designs already exist out there I could just go out and buy a kit like this. But making my own sounded more interesting so when I was looking for a Christmas present for my godson of sorts I did just that.

Above is a close-up of the main PCB that I’ve designed and built for this project. The idea is simple: There is a PIC16F1936 microcontroller that communicates with a RaspberryPi over I2C. The PIC then handles all the low-level details of controlling a pair of Allegro A4982 stepper drivers. These work at up to 35 volts, handle up to 2 amps of current and can hence drive much more powerful motors than the relatively small NEMA 17 size motors I’ve used here. They are easy to use and feature microstepping up to 16th steps.

Besides the two stepper drivers there is a ULN2803 providing 4 power outputs capable of driving up to 1 amp each. The ULN2803 includes free-wheeling diodes so these outputs could be used to directly drive somethingn like a relay or a DC motor. But at least for now these outputs drive some RGB LEDs at the front as well as a buzzer.

The original idea was to power the RaspberryPi  from the 5V linear regulator on the board and then draw the power for the PIC from the RaspberryPi’s 3.3 volt rail. Since the PIC uses only a few milliamps that’s entirely possible.

Unfortunately I haven’t given that setup a lot of thought before building the board. Of course, when powered from something like 12V, the LM2931 regulator gets way too hot when powering a RaspberryPi that pulls a few hundred milliamps. So I’ve sacrificed one of my solar charger RevC boards that includes two very powerful USB charging outputs.

During testing and debuggin I’ve used a small 12V AC/DC converter screwed to the bottom side of the robot. Once more or less completed I’ve changed the power supply to an old 3-call (11.1V) LiPo battery from a RC helicopter. It’s no longer fit for flying but still adequate to power this thing for a few hours.

The entire structure is laser-cut from 5mm medium-density fiberboard and held together with M2.5 torx screws with square nuts. M2.5 square nuts measure precisely 5x5mm so that goes together rally nicely. I’ve added and changed a few things as I went along, drilling extra holes to mount the blue PCB for the power supply, the LEDs, to hold the battery in place and some other things. But the structure as such works very nicely. It’s relatively simple if you have some place to do laser cutting (try your local fab lab…) and is inexpensive and sturdy.

The weels are laser-cut from the same material and are sized to measure precisely 200mm in circumference. That’s handy since the steppers feature 200 steps per rotation. 


That’s about it, most of the relevant files are on github. The OpenSCAD files for the laser cutting are not so just let me know if you’re interested in them. I’m happy to share them, too. Here are the links for the software and hardware, respectively.

As always, I welcome any thoughts or comments.

MPPT Solar Charger – Update

It’s been a while since I posted anything related to my MPPT Solar Charger project. That doesn’t mean that no progress has been made…

I’ve performed many hours of testing, pushing the charger to and even beyond its 75 watts rating. I was able to confirm the very high efficiency n the range of 96 to 98% over a wide range of loads from 1 to 75 watts. And I’m happy to report that during all those tests I haven’t damaged anything. I’m more than pleased how this little charger is performing.

The most obvious progress that I’ve made is the mechanical design that you can see on the various photos here.  The case is a pretty standard 115x90x55mm cast aluminum box for which the boards were designed right from the start. So if you’ve ever wondered about the peculiar shape of the display unit’s PCB you now know why. If I had made it rectangular it won’t fit.

I’ve milled the various holes and slots out of that cast case on a manual mill which was somewhat time consuming but a lot of fun. The slots at the back for the in and outputs have turned out particularly well I find. Hence the close-up 😉

I’ve also given away some boards over the months. A few of them went to an open-source project named MeshPoint where they are integrated into a WiFi hotspot designed for outdoor use in disaster areas, refugee camps and the like. The project is also on hackaday .io where it runs for this year’s hackaday prize.

Together with the bords that I’ve used myself for testing I’m slowly but surely running out of the protopac that I’d ordered from dirtypcbs.com. So I decided to make a few minor changes to the board resulting in Revision D. The changes are really slight and require no or only slight changes in the firmware.

By far the biggest change concerns the flash chip. As I’ve mentioned before, the last one was simply a bad design choice because it can’t do sector ereases. The Atmel AT45DB161E can do that and provides 16Mbit (i.e. 2 MB) of storage which is plenty for our application. This change of course does require firmware changes but since hardly any code for the flash chip has been written so far that’s not really an issue.

I’ve also included the surge suppression diodes that I removed when going from Rev B to Rev C. They are not really required but make the charger far more rugged against any spikes in the (particularly input) voltage. That also makes testing quite a bit safer so  I thought at least having the option of including them is well worth while.

The signals from the three temperature sensors now get RC filtered to hopefully solve some issues I’ve experienced with overly noisy measurements. Placing the capacitors close to the microcontroller was a major challenge but I think I did the best I could.

The other changes are really tiny. I’ve fixed a mistake on the silk screen, changed a number of footprints to make the parts easier to solder and added a diode from the USB bus to the output. That allows to power the charger via USB. That’s obviously only useful for testing and debugging but there it’s a nice feature.

If you want to check out the details, they are on github: https://github.com/soldernerd/SolarChargerHardware

RX/TX Sequencer

Much like the beacon keyer presented here earlier, this RX/TX sequencer is a simple but useful little device. Its typical use is in ham radio applications when a separate power amplifier (PA) and/or a sensitive low-noise pre-amplifier (LNA) is used. Care has then to be take to safely transition between RX and TX states – and that’s where this sequencer comes in.

Why a sequencer?

There are many sequencer designs on the web, both analog (http://www.ifwtech.co.uk/g3sek/dx-book/sequencer/) and digital (http://www.mancuso.net.au/sequencer.html) There’s also a beautifully made but somewhat more involved design here: http://www.w6pql.com/relay_sequencer.htm. The links above (and many more) explain the purpose of (and need for) such a sequencer in quite some detail so I won’t repeat it all here.

soldernerd.com on YouTube

Maybe the best way to understand what this sequencer does is to see it in action. I’ve just yesterday started a YouTube channel to share that kind of videos. Here’s the link: https://www.youtube.com/watch?v=Ctxm0VxeM4g.

This is already Rev D

I have designed and built a number of sequencers over the years so this is already revision D. Unfortunately, I don’t seem to have photos of the first two versions.

Above is a photo of the previous (Rev C) version. Its design was very similar but quite a bit larger as the side-by-side comparison shows.

Input and Output

The sequencer presented here is of the digital variety, uses a 12V power supply and is fully reverse-polarity protected. It is controlled via a PPT input which is pulled high (to +5V) with a 10k resistor and active when pulled to ground.

That PPT input is both debounced as well as reasonably well protected. You can short it to the 12V supply without any adverse effects. Actually, anything in the plus/minus 50 volts range is fine.

Its outputs consist of 3  relay outputs. I’ve used DR-12V types. Those are single-pole, double throw (SPDT) reed relays. They are not inexpensive but both reliable and fast as well as nearly bounce-free.  Each relay has an LED next to it indicating its state and all three relevant relay contacts are accessible via the orange 200mil header.

PIC Microcontroller

The actual behaviour of the relays is controlled by a PIC16F18325 whose programming pins are accessible via the 5-pin, 100mil ICSP header.  Its pinout matches that of the popular PICKit3 programmer distributed by Microchip.

Speed control

How much delay should there be between switching the individual relays? The answer obviously depends on your lineup and that’s why you can control the speed via the on-board pot. The way I have it programmed the delay can be varied from 70 to 325 milliseconds.

Undervoltage lockout

 There were still some pins left on the microcontroller and the PIC comes with a 10bit ADC and voltage reference module. So I decided enable the PIC to measure the input voltage of nominally 12 volts. As it is now programmed, the sequencer will only start operation after the input voltage has consistently been above 11.1 volts for 1.6 seconds.


As usual, all the files are on github:

Programmable LED Dimmer

Around one and a half years ago I’ve designed and built various LED dimmers for both white and RGB LEDs.  Then late last year someone approached me asking if I could make an RGB dimmer for him, too. But my designs were really tailored to their specific applications and built with home-made, i.e. milled PCBs which are time-consuming to make. So I decided to make a more universal version based on a proper, etched board which could be built in a small series and used for all kind of applications, both white and RGB. The result is this versatile, programmable 4-channel dimmer.

The design is based on my previous RGB dimmer but with a number of improvements.

soldernerd.com is now on YouTube

I’ve just uploaded a short video showing this device in action. Here’s the link: https://www.youtube.com/watch?v=ehZybd3Y2kc. This is only my second video so don’t expect miracles but I’d be interested to hear if you would like to see more videos in the future or if you prefer the traditional text and photos format.

Wide voltage range

It now operates from any voltage in the range of 6 to 26 volts as opposed to 12V only. In order to accomodate such a wide range of inupt voltages the regulated logic level voltage of 5V rather than the inupt voltage is now used to drive the mosfets.

Extremely low standby current

This 5V rail is generated by an LM2936 linear regulator with a very low quiscent current and shutdown input. That allows for a nice power saving feature for when all the outputs are off. After a few seconds of sitting idle the entire device powers itself off, i.e. it turns off the LM2936 thus only consuming 30 microamps (typ.) plus some leakage in the capacitors. So the device can stay connected to a battery for months without draining it. To wake it up one has to press any of the two push buttons.

Rotary encoder design options

Talking of push buttons. Like my previous RGB dimmer it features two rotary encoders with push buttons.

But now there are two different types of encoders that can be used.
The ones previously used with their axis perpendicular to the board and a different type where the rotary axis is parallel to the board.
And either type can be mounted on either side which gives you even more freedom for your physical design.

Perfectly debounced switch signals

As always with my designs, the signals from the encoders (six in total) are nicely debounced in hardware by running the RC-filtered signal through a 74HC14 schmitt-triggered hex inverter. So the singals are perfectly clean when they reach the microcontroller.

Noise immunity

With my last design I had experienced some difficulties with ground bounce or insufficient ground connections in general leading to less-than-reliable encoder readings. It’s always more difficult go ensure good, low impedance ground connections on those prototype boards since there are no plated-through holes and vias. On that prototype board the issue was solved by soldering in a few short pieces of wire where the ground connection needed improvement.

So with this new design I paid very close attention to ground. I spent a lot of time working on the board layout to ensure that everything is as noise immune as possible. I always use ground vias generously but here I really tried everything to get the best, shortest and lowest impedence ground connections could get. I’ve also used decoupling capacitors even more lavishly than I usually do.

New microcontroller

I’ve changed the microcontroller to a PIC16F18325 which is smaller and cheaper than the previously used PIC16F1936.
The 18325 has become my standard choicer whenever I need a low pin-count microcontroller. I particularly like its remappable pins which give a lot of freedom to simplify your signal routing on the PCB.

Smaller size and more outputs

The mosfet drivers are basically the same as before but now with non-inverting outputs: LM5111-1M. There are two of them for a total of 4 outputs compared to only 3 with the previous version.
They now drive much (physically) smaller but no less capable mosfets which allowed me to significantly downsize the whole board to 75x65mm.  The NXP BUK9Y12-40E are rated at 40 volts and offer an on-resistance of 12 milliohms (max @ 25 degrees ) with a 5V drive as we have here. Their large thermal pads a the bottom (NXP calls that package LFPAK) pass heat efficiently to the PCB which then serves as a heat sink. There is also a 30V version that offers even better performance but with a maximum input voltage of 26 volts I thought the 40V version is the safer choice.

As you can see, there’s plenty of capacity on the board. A total of 5 330uF 35V low ESR capacitors are placed in parallel in order to smooth out the PWMs inherent current ripple.


So now we have a device with 2 rotary encoders and 4 outputs but it won’t do anything without software. There’s absolutely nothing hard-wired between the encoders and the outputs so we can program this device to behave in any way we like. That’s what makes it so flexible.

I have so far implemented two functions. The first is aimed at RGB LEDs and behaves exactly like my RGB dimmer. One encoder controls the brightness, pressing its button turns the outputs on and off. The other encoder controls the color, pressing its button toggles between white and color. The three outputs are 120 degrees out-of-phase which presents a more steady load to the power supply.

The second function is aimed at plain white LEDs. There are two pairs of outputs with output 1 & 2 forming a group and 3 & 4 the other. Each pair is controlled by one encoder. Turn it to control the brightness and press its button to turn the respective output pair on and off. The two outputs of any group are 180 degrees out-of-phase to smoothen the load. And since there is a 4th output it is easy to implement a case where there is an independent white channel.

With both functions, the entire device turns off after a pre-defined period of time (currently set at 3000ms) with all outputs off in order to save power. Before turning its own power supply off and hence losing all its data in RAM, the necessary parameters are saved to EEPROM. So the device remembers its last state and will power up the with the same (brightness, color and so on) settings it powered off with.

The switching frequency is 31.25kHz which is high enough to be entirely inaudible and the 10bit resolution gives you 1023 levels to finely control the brightness down to very low levels.

All the settings reside in a file named config.h. That is where you define the function you want the device to perform. The number of brightness levels and their respective values can simply be parameterized there. The same is true for the colors. You can also set the RGB values for neutral white. The seemingly obvious choice of 1023/1023/1023 often does not result in a pleasent white. For my LEDs I had to substantially reduce the green content but this, of course, depends on your particular choice of LEDs.

I currently have 3 devices productively deployed and they perform very nicely. Also, adding new functions is easy since all the heavy lifting like has already been done. It takes somethign like 100 lines of relatively simple code to implement a new function. No need to get involved with any registers and the like. So if you have any experience in C you should be totally fine programming this thing.

Visit github for code and Eagle files

Both the eagle files (including Gerbers) and code are on github:

Also want one?

I have some boards left and can make one for you, too. Fully built, tested and programmed to your needs. Cost is USD 65 payable via PayPal, including worldwide shipping. Simply contact me using this form.

Beacon Keyer

This is likely the first ham radio related project that I document here on this blog. But my very first PIC project was a beacon keyer that I made for my father, HB9BBD. That was was in 2013. A beacon keyer is a great project to get started with microcontrollers since it’s not much more than a fancy way of blinking an LED.

At that time I didn’t even use Eagle yet and so the layouts were based on a software called Sprint Layout. These were all very simple circuits, all based on a PIC16F688, and therefore perfectly suited for making some of my first homemade PCBs as well. The very early versions like the one in the picture above even used the DIP version of the PIC in a socket. All the resistors and capacitors are 1206 size not 0805 like of my later designs.

In fall last year, HB9MPU asked me if I could make some keyers for his new 10GHz beacon. That was a great oportunity to design a new one from scratch and this is what this post is about.


These were the requirements:
– 12V operation
– Open drain outputs, i.e. a transistor to ground
– 2 outputs, one of them inverted


I decided to use a PIC16F18325 this time. Like the 688 it is a 14-pin PIC but a much more recent addition to the PIC16 family. It’s fully featured with I2C, remappable pins, an onboard voltage reference, plenty of timers and a whole bunch of other features. And it’s widely available a very low price. So I tend to use this PIC whenever I need a low pin count micro somewhere. Like for my fan controller.


Instead of using discrete transistors and protection diodes I’ve used a Texas TPL7407. That’s a 7-channel low-side driver, basically 7 mosfets to ground together with an on-board voltage regulator for the gate voltage and protection diodes all in a SOIC16 package. It sinks up to 600mA (with a maximum of 2A total) per channel and operates from 8.5 to 40 volts. Perfect to drive relays, small motors, powerful diodes or just about anything else that doesn’t require that much current. Some of you may be familiar with the ULN2003 which does the same thing but using bipolar transistors (as darlington pairs) instead of mosfets.

Power supply

The power supply is based on a Texas LM2931, basically a rugged LM7805 that operates all the way up to 26 volts and survives up to plus/minus 50V. While the LM2931 is reverse polarity protected, the diodes in the TPL7407 will short any negative input voltage to ground which is obviously a bad idea. I’ve added a 60V, 2A schottky diode at the input so the device is truely reverse protected. Minimum operating voltage of the TPL7407 (after a diode drop)  and maximum operating voltage of the LM2931 result in an input voltage range of the final device of 9 to 26 volts.

Speed control

There’s a small pot on the board that lets you control the speed of the keyer. The PIC measures the wiper voltage with its built-in 10-bit ADC and sets its speed accordingly.

Fan output

As mentioned, the TPL7407 has 7 channels but I only really needed two for the beacon keyer outputs, one normal and the other one inverted. The PIC also has an on-board voltage reference module and a temperature sensor so I decided to use all that functionality to add a fan controller. Beacons often have fans that run constantly even when there’s absolutely no need for cooling such as in winter which only wears out the fan’s bearings.

So the pic also measures the temperature and turns the fan output on and off according to software-defined threshold temperatures. Since the PIC’s temperature module is rather inacurate I’ve added an inexpensive but much more accurate LMT86 analog temperature sensor.

I’ve used 4 TPL7407 channels for the fan output so the current is limited by the total allowable current of 2 amps. Of course, you can also use this output to control a relay and use, for example, a 230V fan.

There are also 3 LEDs on the board so you can immediately see what’s going on.  And just in case you care, the board measures 45x45mm.

As always, programming is done with a PicKit3 or similar via a 100mil in-circuit programming header.

That’s pretty much all that is to say about this little device. As always, I appreciate any feedback and let me know if you need one of these.

And as always, everything from Eagle files to firmware is on Github:

MPPT Solar Charger Rev C – First Test Results

Over the last few weeks I have been quite busy with my MPPT Solar Charger project. I’ve built up a first board and started writing firmware for it. Since the last version was not too different in terms of hardware I was able to re-use most of that code. But I hadn’t even touched on the whole USB stuff back then so there was still a lot of work to do. While the project is still far from being complete I am happy to say that I’ve made quite some progress. Most importantly, the new design seems to work well and so far I haven’t found any mistakes in the board layout. But let’s go through this step by step.


I regularly find USB communication to be the most complex and obscure part of the firmware. That’s why I like to get that working first and then add all the other functionality later. I’ve started with some sample code that Microchip provides for their PIC1846J50 family of chips. That way I was able to get the my board act as a composite HID (Human Interface Device) / MSD (Mass Storage Device) quite quickly. Of course, that demo application doesn’t do anything particularly useful but it provides a solid basis for adding the functionality you need.

At least for the HID I’ve implemented most of that functionality. I can read all the relevant data such as settings, currents, temperatures, voltages and so on over USB. I can also control all the outputs as well as the actual solar charger remotely. More on that later.

On the MSD side there is still lots to be done. The solar charger successfully enumerates as a USB flash drive and you can read and write data from and to it. But that’s really it. The charger doesn’t care about the files you save there and also doesn’t put any data there.

Flash and EEPROM

This brings us to the next topic: Non-volatile memory. There is both a I2C EEPROM as well as a SPI flash on the board. Communication with the EEPROM is fully implemented but currently its only used to save the time and date. The idea is to save all the settings and calibrations on the EEPROM. That shouldn’t be difficult but I haven’t had time for that yet.

The flash also works just as it is supposed to but the chip I chose turned out to be a bad design choice. It can’t do page erase, only entire 16k sectors can be ereased. That makes it difficult to use since you have to temporarily save the sector’s data somewhere when you want to change only part of a sector. We don’t have that much RAM so we have to save that data to flash itself. That can all be done but it’s just a hassle. Apart from that a sector erease takes time. A loooot of time. So I’ll just juse a different chip when I do the next iteration of the board. For now I’ll just use the first 512bytes of each sector. That’s extremely wasteful but will do for now I guess.

Solar Charger

The actual charger circuit hasn’t changed much since the last version so I expected little trouble in getting it to work. However, I managed to confuse the low and high gate pins in firmware and only found that bug days later when I had already done plenty of damage to the board. By the time I found and fixed the problem I had already killed the input current sensor, the ADC, as well as some of the PIC’s output drivers.

So I built up a second board but only with the components required to test the buck. And much to my relief it works. And it works well. I haven’t done any precise measurements yet but it seems at least as efficient as the last version. I had it running at its rated power of 75 without it getting overly hot. As expected, most power dissipation takes place in the coil so the coil did get quite warm but not hot. The FETs heat up a bit due to their proximity to the coil but otherwise don’t care much. My main problem with these tests was to somehow sink the power at the output without overcharging the battery. My home-made dummy load can sink up to 4.5 amps but not for very long before it regulates down to avoid overheating. I had the charger running at around 40 watts for several hours and it only got modestly warm.

Also, the wave forms on the scope look nice and clean. There’s considerably less ringing and overshoot than with the last version. So the improved layout seems to work well. During the tests so far I have turned the charger on and off at least a hundred times, switched from asynchronous to synchronous mode and vice versa and had it running for about 10 hours. I also pushed it all the way up to about 85 watts where the coil starts saturating and the caps have to handle more ripple than they are rated for. I’m happy to report that during all these tests I haven’t killed a single fet nor any other component (once the firmware was ok). I am confident that it will stay this way.

Synchronous bucks are somewhat dangerous in the sense that it is easy to short the input or output to ground when you’re not careful. My solution to this is having rigorously tested functions for turn-on, turn-off, switching mode and changing duty cycle and then rely only on these functions when implementing different MPPT strategies. If these few functions do what they should you can get away with quite a bit of abuse without damaging anything.

What I also noticed during my tests is that the break-even between synchronous and asynchronous mode is somewhere in the region of 1 amp. That’s about twice what it was with the last version and is thanks to the extremely efficient diode that makes asynchronous mode much more efficient.

USB Charger and power outputs

This is something that has changed quite a bit since so I was eager to see how it performs. I haven’t done any detailed tests but I’m very pleased with it so far. It definitely performs better than the last version. In theory, you should be able to simultaneously pull 2 amps from each of the two USB charging ports. I haven’t done that yet but when fast-charging two cell phones (approximately 2 amps judging from the power it pulls from the battery) it stayed surprisingly cool – unlike the last version.

Also no surprise with the 4 power outputs. I had changed the mosfet drivers and mosfets in order to save board area. Apart from that everything works like before. I can still turn off the drivers when none of the outputs is in use in order to preserve power. All works as it should.

Solar Charger App

Of course, all the USB HID functionality is of little use without some software on the other side, i.e. running on a PC. I’ve spent a lot of  time writing my Solar Charger App over the past few weeks and I can say it’s getting pretty good. I has already proved very useful in testing the buck. Since I can monitor and control everything via USB there is no need to have a user interface sitting on top of the board during testing. That means unrestricted access for scope and multimeter probes. And since there’s so much more space on a PC screen than on the little LCD I can display all parameters simultaneously.

The program is written in C#, using my recently published HID utility and WPF .  I’ve tested it on Win7 and Win10 and runs absolutely stable. It also copes well with ultra high resolution displays where everything gets scaled-up in order to still be visible/readable. The screen shot above gives you some idea of its current functionality. Take the efficiency measurement with a grain of salt, though. The measurements are yet to be calibrated.

The code is available on github: github.com/soldernerd/SolarchargerApp. To compile it you need VisualStudio 2015 Community which is available free of charge.


Measurements is another important topic. The newly chosen 16-bit ADC works well. Actually, I don’t feel much of a difference to the 18-bit version used previously. Anyway, the measurements are done with 14-bit precision only in order to speed them up.


The readings I get from the two current sensors are surprisingly accurate even without having done any calibration so far. So for now, all measurements have been done with their theoretical (i.e. calculated) multipliers and offsets.

The temperature measurements are done by the PIC directly, using a 2.5V external voltage reference. Both the temperature sensors (one on-board, up to two externally) as well as the voltage reference perform just like they should but I get a lot of noise in my otherwise reasonable measurements. This is quite certainly a software issue. I might not give the PIC’s internal ADC enough time to settle after switching channels or something like that. I’m sure it can and will be solved but I haven’t given this very high priority so far.

Next steps

A lot of work remains to be done. One of the next things I will do is to implement proper calibration for the voltage and current measurements. At the moment, all the relevant constants are hard-coded so I first need to change them being variables, store them in EEPROM and retrieve them from there at startup. In a second step I need to make them accessible over USB. Once that’s done it should be possible to calibrate them in a fully automated fashion. I’ve never done that so far but my multimeter as well as my power supplies can be controlled via USB (or GPIB, respectively).  So I want to write a calibration routine that sweeps the device under test, calculates the proper calibration values and sends them to the solar charger.

Getting the Mass Storage Device working from FLASH is another big thing to do. As reported, the currently 7kb of memory on the flash drive are mapped into the PIC’s internal flash memory. I’ll have to dive quite deep into the Microchip USB code in order to figure out how to change that. I expect to spend a significant amount of time until that works but there’s no way around it in the long run.

Once mass storage works properly I can also start implementing settings as a configuration file on the flash drive. So as an alternative to doing things via HID which requires dedicated software to run on the PC you can also check and change settings by editing a text file residing on the flash drive. The next step will then be to also write measured data to that storage.

Then most of the low-power features are still to be implemented. The most basic stuff is there: The 5V buck for USB charging is turned off when not in use and so are the mosfet drivers for the power outputs and the solar charger. The user interface is also turned off after a certain time of inactivity. But the PIC constantly runs at 48MHz, the USB module is never turned off even when not in use, it never goes into any of the several low-power modes and so on. So at the moment it consumes around 10mA with the display off and 16mA with the display on.

And yes, there’s also more testing to be done on a lot of aspects. The code could definitely use a clean-up once I’m done with it, I also have plans of adding a boot-loader so users can update the firmware via USB… I won’t run out of work any time soon.

The firmware is on github, too: github.com/soldernerd/SolarChargerRevC_Software. It is updated much more frequently than I do posts here so if you’re interested I suggest you track the most recent development there.

The next post on this topic is here.

MPPT Solar Charger Rev C Design

Over the last year or so I’ve designed, built and tested a standalone solar charger. It performed quite well but as with any complex design there were a number of things that needed to be improved.  So I eventually reached the point where I decided to design a revised version. And this is what this post is all about.

Things to improve

Here’s a list of things that I wanted to improve besides fixing the design errors of the old design:

  • Downsize the board and give some thought to how to put the whole thing into a case. Consider carefully where to put screw holes, connectors and the like.
  • Reduce complexity wherever possible. Reduce the number of distinct components.
  • Reduce total component cost without sacrificing performance.
  • Reduce height of the assembled board so that it can ship in a padded envelope.
  • Turn user interface on by means of a logic signal as opposed to turning its power supply on and off. Ability to control the display entirely via I2C, including backlight brightness and reset.

Let’s look at these points one by one.

Downsize the board

I looked around for a suitable case for my solar charger and finally decided on a 90x115mm cast aluminium case. The specific model chosen is available from Farnell at around 10 bucks which I found very reasonable. With the case chosen the size of the board was pretty much given. The inside shape of the case is rather special since there are also mounting holes for the case itself that take away space for the board. However, I decided to keep the board rectangular so it stays universal and is not just made to fit that particular case. That left me with a board of 85x78mm as opposed to 90x140mm of the last version. That’s about half the size in terms of board area so fitting everything on the new board was really a challenge.

The main space saving came from using much smaller mosfets. The model previously used was rather huge in physical size. I’m now using NXP PSMN6R0-30YL in a LFPAK package that is much smaller while delivering similar if not better performance.

The main inductor is also somewhat smaller. I found that the Coilcraft MSS1210 series delivers pretty much the same performance as the MSS1583 while saving some space.

Apart from that I didn’t downsize any of the components in order to keep everything hand-solderable  and hobbyist-friendly. Particularly, all the resistors and ceramic capacitors are at least 0805 in size.

Getting the board made from dirtypcbs.com also allowed me to do a denser layout, mainly by using smaller vias. But I didn’t push it to the limit, all traces are still at least 12 mils (0.3mm) wide with 0.4mm vias and 6 mils clearance.

Now all the power connectors are located at the top of the board with a single 12-pin 200-mil connector. USB is still located at the front and the programming header is at the right edge of the board. External temperature sensors and fan output are now on the left side. The header for the user interface is now located so that the user interface can just be stacked on top of the charger and sits precisely in the middle. There are also mounting holes for the user interface on the charger board.

Reduce complexity

The obvious place to start was the combination of PIC18F26J50 microcontroller with a I2C multiplexer and a port extender. The same PIC family also includes a 44-pin version that allows replacing all 3 chips with a single chip.  I’m now using the top-of-the-line PIC18F46J50. That not only simplifies the board but also the software since we no longer need to care about the mux and which pins are on the PIC and which are on the port extender.

The 4 mosfet drivers for the power outputs have been replaced by 2 MCP14A0153 dual mosfet drivers that also don’t require a reference voltage signal which further reduces complexity somewhat.

The 5V switching converter for USB charging on the last version needed quite a few external components to function. Besides that it got rather hot at 2 amps. I’ve replaced it with a Texas TPS54428 synchronous switcher that is more efficient, uses less external components, delivers up to 4 amps and has a thermal pad at the bottom which helps keeping it cool. The new Coilcraft MSS1048 coil is slightly higher but otherwise the same size and helps keeping power dissipation low.

I’ve tried quite hard to keep the number of distinct capacitor and resistor values to a minimum. You can easily see that the same values such as 10k, 300k and 680k appear over and over again. The only point where there are still a lot of distinct resistor values are the USB charging ports where I’ve tried to emulate an Apple and Samsung charger, respectively. I’m not sure to what extent one can cut corners here without risking that certain devices don’t charge properly.

Overall, the number of distinct components has been reduced from 60 to 47 despite some added features.

Reduce cost

Getting rid of the I2C mux and the port extender already saves some cost. The same goes for the dual mosfet drivers and the downsized inductor. There were some unnecessarily expensive components on the last version. There was an 18-bit ADC that we didn’t really need. The Microchip MCP3428 is a very similar model that only has a maximum resolution of 16 bits and is quite a bit cheaper without making any difference to our application. Another component that was somewhat of an overkill was the voltage reference. Note that the voltage reference is only needed for the temperature measurements. The voltage and current measurements are done by the external ADC that comes with a precise on-board voltage reference. I found the Silicon Labs TS6001 which provides a sufficiently precise 2.5V reference.
I’ve also replaced the large and relatively expensive EEPROM with a much smaller 16kbit Microchip 24AA16 EEPROM in combination with a cost-effective serial Flash (Spansion S25FL208K) with 8Mbit of capacity. This way we get much more storage at a similar total cost while still keeping some easy-to-use EEPROM for configurations and the like.

Reducing height

Since the only overly high components on the last version were the input and output capacitors this was an easy task. I decided that I want to use the same model for both input and output which meant that I needed a 25 volt rating. Maintaining the 10mm diameter and limiting the height to 12.5mm left me with a maximum available capacity of 470uF. The ripple current rating of the new caps is also lower so I now have to use 2 caps in parallel at the input to not exceed this rating at 75 watts.
The caps are still the highest components on the board but only slightly higher than the USB connector, the main inductor and the 200-mil connector. The resulting total height of about 15mm is low enough to comfortably ship the assembled board in a padded envelope which is much cheaper than a small parcel.

User interface

I’ve already presented a user interface that fulfills most requirements listed. However, I still needed to again revise the user interface for two reasons. First, the previous version would not physically fit inside the cast aluminium case. So I had to somewhat taper off the board towards the side so it would fit. I also had to re-locate the mounting holes inward so that they lay on the charger board. Secondly, I need to be able to shut down the user interface without blocking the I2C interface. This was not an issue with the last version where I had a I2C mux in between. So the new  interface now includes a 2-channel bi-directional switch that is controlled via the same signal that turns the interface on and off.

Next steps

I’m looking forward to my ReflowR hopefullly arriving soon so I can build up the board in an efficient way.  As you can see below I have already prepared a setup to apply the solder paste to the board. I have glued three faulty user interface boards to a piece of coated plywood to repeatedly align the board. I have limited experience with reflow soldering but I will hopefully learn quickly and report my progress and lessons learned here.

As you can see from all the photos here the boards have already arrived and I’m excited to try them out. All the eagle files as well as the Gerbers and everything are on github: github.com/soldernerd/SolarChargerHardware.

C# USB HID Utility

Have you ever tried to write a program that connects to some device via USB? I have done so a few years ago and was shocked how much of a pain that is (at least on a Windows plattform). I always thought there should be a nice little library that wraps all those uggly DLL imports, marshalling and COM API calls and offers a nice and clean C# interface to the outside world.

Much to my surprise I found nothing that really did what I was looking for. Now I finally sat down and wrote my own. It’s on github.com under GNU GPLv3 license for anyone to modify and use.

My starting point was the Microchip PIC18F46J50 FS USB Demo Board. This nice little board comes pre-programmed as a HID (Human Interface Device) / MSD (Mass Storage Device) USB composite device and is a great starting point for anyone interested in building a USB device based on a PIC.

Once uppon a time, Microchip also wrote a WindowsForms application to showcase the USB functionality of their microcontrollers and that application (in various versions) can still be found here. It lets you read an analog voltage from the board, tells you if a pushbutton is pressed or not and lets you toggle an LED. Very simple but all you need to get started with your own device and application.

Unfortunately, that code no longer gets maintained and is quite outdated by now. It was created with VisualStudio2010 and .NET 2.0.  And all USB and WindowsForms code is mixed up in a single file which makes it difficult to re-use. It also lacks some functionality such as the ability to list available devices. Apart from that it works very well and stable so I used it as a starting point.

My solution is now based on VisualStudio Community 2015 (which is available for free) and .NET framework 4.6. So you can just download VisualStudio and open the HidUtilityDemo.sln file.

There are 3 projects inside the solution:

  • A WindowsForms application named HidDemoWindowsForms
  • A WPF application named HidDemoWpf
  • A console application named HidDemoConsole

All projects use a common file named hid.cs. This file is what this is all about. The applications mainly just show how to use it and give you a starting point for your own application.

hid.cs is not pretty. 900 something lines of DLL imports, COM object calls and marshalling. It’s C# but it doesn’t look and feel like C#. But it does all the heavy lifting for you and offers a nice, clean, truely C# interface for you to work with HID devices.

You add it to your namespace, create an instance of HidUtility, tell it what device to connect to  and subscribe to the events you are interested in:

// Get an instance of HidUtility
HidUtility HidUtil = new HidUtility();
// Connect to device with Vid=0x1234 and Pid=0x5678
HidUtil.SelectDevice(new hid.Device(0x1234, 0x5678));
// Subscribe to the events you care about
HidUtil.RaiseDeviceRemovedEvent += DeviceRemovedHandler;
HidUtil.RaiseDeviceAddedEvent += DeviceAddedHandler;
HidUtil.RaiseConnectionStatusChangedEvent += ConnectionStatusChangedHandler;
HidUtil.RaiseSendPacketEvent += SendPacketHandler;
HidUtil.RaisePacketSentEvent += PacketSentHandler;
HidUtil.RaiseReceivePacketEvent += ReceivePacketHandler;
HidUtil.RaisePacketReceivedEvent += PacketReceivedHandler;

You can also obtain a list of all available HID devices at any time:

foreach (Device dev in HidUtil.DeviceList)

As the three projects demonstrate, the very same hid.cs file can be included in just about any C# project. There is not a single API call or anything in the remaining files.

Just register some event handlers and your application will be informed whenever a device has been added or removed, when a package of data has been received from the device, when the connection status has changed or whatever else.

So you don’t have to re-invent the wheel every time and can fully concentrate on the application you have in mind, not the details of USB communication.

A word of caution: I am by no means an expert C# programmer. I have tried the applications on 3 different PCs running Win7 and Win10, respectively. They seem to work reliably on any of these. Apart from that the code has not yet been productively deployed and there may well be some bugs and issues. If you find anything that doesn’t work, please let me know and I will do my best to get things fixed and updated on github. Also, please comment on this post if anything needs clarification.

So once again, the code is available for download from github.com/soldernerd/HID_Utility.

Ultrasonic Anemometer Part 30: Downsized Hardware

In my last post of this series I’ve looked at different transducers and finally decided on a entirely waterproof 14mm model. The much lower signal level from those kind of transducers makes it  necessary to reduce the distance between the transducers in order to still receive a reasonable signal amplitude.
So I took my previous lasercut design and reduced it in size so that the distance between the transducers is only 120mm. I went to the local FabLab and and lasered two copies of the downsized design.

Since the new transducers are only 14mm in diameter but those plastic pipes are only available in 16mm I had to pad the transducers with short sections of aluminium tube with an outer and inner diameter of 16 and 14mm, respectively.
I previsously connected the wind meter to an Arduino with a LCD display to test the I2C functionality as well as to read the wind speed and direction without having to connect the anemometer to a PC. Now I have used my I2C user interface for that purpose. It is powered from the wind meter’s 3.3 volt rail and is controlled via I2C including the backlight brightness and display reset. The user interface usually also includes a rotary encoder with push-button not present in this application.

In an attempt to boost signal amplitude I’ve also changed the first stage op amp’s gain from 11 to 31 by replacing the 10k resistor with a 30k one. I’ve argued in my last post that this is probably about as far as you can safely push it.
Even with the lowered transducer distance and increased gain the signal amplitude after the first stage is less than impressive. But we knew that already. And we have a second variable-gain stage at our disposal. Setting the second stage’s gain sufficiently high we hopefully get the 3 volts peak-to-peak amplitude we are aiming for.

By the way, I’ll started from scratch with the firmware. The reason for that is mainly USB. Currently, the anemometer acts as a HID device. While working on my solar charger I started to play around with HID / MSD (human interface device / mass storage device) composite devices. They still act as HIDs with all the functionality just like before. But when you plug it into a PC it also enumerates as a mass storage device, i.e. it behaves just like a memory stick. You can read and write the files on it from any computer, irrespective of the operating system and without needing any particular softwar or driver installed. So you can put all the configuration parameters in a text file that resides on what looks like a memory stick. I guess that’s the most user friendly way of dealing with those user-specific configuration parameters. Just plug it in, open a text file, change what you need, save the file and you’re done. This is how the solar charger will operate and  I’ve decided to implement the same here.
Microchip’s Harmony library includes all that functionality so I have no doubt it’s doable. But I’ve figured that it’s likely easier to do this as a new project and then add the previously implemented functionality step-by-step.

And then there’s another USB-related feature that I had in mind right from the start but which I haven’t event started to implement so far: A USB boot loader. That would enable people to do a firmware update without needing a in-circuit programmer such as the PICKit 3. Users could just download a new HEX file and upgrade the firmware without needing any special hardware or even skills.
USB boot loaders come in various flavours. The Harmony library includes support for an HID boot loader. But that’s not really ideal if you ask me. It means that you need to run some software on your PC that communicates with the anemometer and sends the new firmware via USB. The need for software means that it matters what kind of operating system you run. And needing additional software is undesirable in the first place.

There are also MSD bootloaders which do not have all those downsides. The device acts as a memory stick to the PC. The user then just copies the HEX file to that memory stick and that’s it. Just drag-and-drop, no extra software, no matter what OS.

The problem is that the Harmony library does not support that out of the box. Indeed, Microchip doesn’t seem to have implemented that for any of their chips. That’s kind of strange because other chip manufacturers have done so long time since. There is at least one implementation for PICs out there in the web but I haven’t looked at it yet because the website it was hosted on no longer exists it seems. Probably I’ll have to implement this myself but the Harmony support for MSD will hopefully do much of the heavy lifting.

So that’s the plan. Implement a bootloader, preferably of the MSD variety. And then run the anemometer appliction as a HID/MSD composite device. You may say that I set the wrong priorities given the fact that the actual measuring is not yet as good as it needs to be. But this kind of fundamental architecture is easier to get right from the very beginning. So that’s why.
If you’re interested in this lasercut design you can find iton github.com or more precisely on https://github.com/soldernerd/AnemometerLasercut. This version is called Anemometer_03.scad and the PDF that was used for the actual laser cutting is Anemometer_03.pdf.

Standalone Inductance Meter on a Etched Board

In late 2014 and early 2015 I had posted a short series on an inductance meter project. The first post in that series described an Arduino shield that allowed an Arduino UNO to do inductance measurements and got this blog mentioned on dangerousprototypes.com for the very first time.

I got a lot of encouraging feedback and some time last year Andy Beasley asked me if I could help him extracting Gerber files from Eagle so that he could get some boards made and build his own. I was happy to do so and was rewarded with half a dozen boards. Thank you very much, Andy.

At the time I was busy working on other projects so the boards collected some dust until Sean Connolly sent me a message asking if I could make an inductance meter for him. That was a great opportunity to finally build up one of these boards.

The result was the most  beautiful of my inductance meters so far. There’s nothing new technically – It’s still the circuit described in this post.

By the way, I’ve started to share more and more of the projects on github. All the photos, descriptions and so on will continue to be published here on soldernerd.com but I will put the download material such as source code, eagle files and the like on github.com/soldernerd where it is easier to keep files in sync and to potentially collaborate with other developers.

So here’s a list of the relevant repositories on github:

DIY Electronics