I finally got my rube goldberg doorbell into an installable state. On the left is the door button detector. It is an ESP8266 ESP-07 making use of the U.FL connector to allow the WiFi signal to punch through from my basement to the 2nd floor where the router is located. On the right is another ESP8266 and a doorbell transformer. Just barely peaking out from under that module is an actual doorbell.

A key aspect of the system is that the door button module doesn’t communicate directly with the door bell module. Both modules log into a Mosquitto MQTT broker. The button module “publishes” events on the MQTT topic of “DoorBell” and the bell module subscribes to the MQTT topic of DoorBell. Later, I can split the topic names and have something like OpenHAB conditionally copy events from one topic to the other depending on the time of day. OpenHAB can also translate MQTT events to a service like Notify My Android so that my phone buzzes in response to a door button push.

I am excited to install this at home and see how it does!

Recently Arduino came out with the Arduino Zero. This is a neat 48MHz ARM Cortex M0 processor on a PCB with the same pin outs as an Arduino UNO. Existing 3rd party UNO libraries are a little hit and miss because some access the underlying hardware registers of the UNO. The Zero hardware registers are completely different from UNO. Still, the basic 1st party Arduino libraries work fine and I’m sure those 3rd party libraries that were twiddling the UNO hardware registers directly will start to support the Zero over time.

Anway, my curiosity was peaked by the ARM processor for the Zero the Atmel ATSAMD21G18. It turns out that the processor has alternative packages with higher pin counts. Same silicon, just more pins. So I gave the ATSAMD21J18 a try. In order to be able to use extra pins with digitalWrite, I had to add a small amount of code to a file called variant.cpp, but once done, I had a Zero with a nice chunk of extra I/O capability.

Here are my variant.cpp additions, tacked on to the definition of g_APinDescription:

 //Extra J pins
 { PORTB, 4, PIO_DIGITAL, PIN_ATTR_ANALOG, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 { PORTB, 5, PIO_DIGITAL, PIN_ATTR_ANALOG, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 { PORTB, 6, PIO_DIGITAL, PIN_ATTR_ANALOG, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 { PORTB, 7, PIO_DIGITAL, PIN_ATTR_ANALOG, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 
 { PORTB, 12, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 { PORTB, 13, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 { PORTB, 14, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 { PORTB, 15, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 
 { PORTB, 16, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 { PORTB, 17, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 
 { PORTB, 30, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 { PORTB, 31, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 { PORTB, 0, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 
 { PORTB, 1, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_NONE }, 

Right now this is digital only. Some addition modifications to other files would be needed to pick up analog or pwm.

It didn’t look pretty, but it did the job for years. However, the new fully integrated prototype controller looks a lot snazzier.

There are still more design changes to come for this board, but it was really nice to see it perform as intended in my full display.

The Singing Pumpkin controller continues along. This new spin of the board corrects the previous flub-up of the reversed amplifier pin-out as well as adds USB and RS-485 to the mix. There are some minor errors on the board, but nothing that has prevented 90% of the board function from being validated. I need to check the recv direction on the USB, the Arduino-style reset pulse, and the RS-485 transceiver. With that I’ll be able to work on generalized firmware and PC software.

This tester board seemed to work pretty well. It got plenty warm pushing around 2 amps, so it may need a heat sink. Still I’m pleased to have a solution that lets me get all the way up to the 3 amp limit of the converter.

This Saturday I continued with the commissioning of my unified singing pumpkin controller. I got all the sub-systems working except for the power amplifier. In the picture above, on the left is the pumpkin controller. On the right is a (normal) Arduino amplifier shield using the same amp chip.  That shield works. If you look carefully you can see that the chip pins are mirrored between the two boards.

Mirroring pins is an innocent enough mistake. It happens to everyone once in a while. The problem is that I made the EXACT same mistake on the first round of that amplifier shield. (Notice the R2 on the right hand silk?) Apparently I fixed that problem manually without correcting my library symbol. That was many months ago and I forgot about it, thus resulting in a repeat of the same error on the unified pumpkin controller. Dumb mistake! It would have taken 10 mins at most to fix the symbol.

Don’t be like me, fix your symbols the moment you notice the mistake! You may not get back to it for a while and may not remember there was a problem.

Anyway, I managed to forget to bring a microSD card, but the program loaded into the AVR OK and is running. All the various power supplies are outputting the correct voltage.  6 volts for the servos, 5 volts for the AVR, and 3.3V for the microSD card and buffer chip. The amplifer gets the raw 12 volts. So, I’m hopeful that over the next week I’ll be able to bring the board completely online.

In following the internet chatter about the FTDI bricked-chip dust up some months ago I came across mention of a Silicon Labs USB-Serial chip, the CP2110, that worked a bit different. The device enumerates as a regular HID device and uses a standard OS driver rather than a manufacturer specific one. Being a HID device, there is no COM port. Instead you link a library into your application that knows how to engage the standard HID driver to talk to the chip in a serial-like fashion. In effect, this moves the driver from the OS to your application.

So I grabbed some of the chips and made up an OSHPark board that implemented the minimum passives and broke out the pins. Tonight, during Builder’s Night Out, I finally got around to soldering it up. The worst part about the CP2110 is that it is a 4mm x 4mm QFN with a 0.5mm pin pitch. I used the space’s 50W laser to make a solder paste stencil out of some of the giant roll of 3 mil mylar we have. My first go at it with one pass of the solder paste squeegee didn’t put down enough paste on the QFN and my second go with 3 or 4 passes in orthogonal directions put down too much solder paste.  There is probably a middle ground there.

Anyway, I used the space’s Zallus reflow toaster oven to reflow that second paste attempt and wound up with a number of the QFN pins shorted together. (I should have wiped the paste off and looked for that middle ground.) To fix the shorts I used the space’s hot air rework gun to pull the QFN chip off. That allowed me to solder wick the pads to a point free of shorts and then use the hot air gun once again to put the chip back. I over heated and burnt the tantalum caps and the LEDs in that rework process. So I used the hot air gun to remove those components and then hand soldered replacements back on to the board.

The moment of truth came when I plugged the freshly soldered board into my laptop’s USB port. I fully expected it to say “over current limit”, but to my delight it happily installed the HID driver! I’m looking forward to trying out the link library.

So, a few of us got together and backed Nate’s Revision 2 controller kit. The kit came in last week, I picked up a cheap toaster on clearance, and this past weekend we installed the kit into the oven.

From the kit installer’s perspective Nate’s kit couldn’t be simpler. A supplied SSR is inserted in series with the main AC line, and a K-type thermocouple is fed into the oven cavity. Both items connect up to a pre-assembled circuit board and LCD touchscreen.

We fired up the oven and ran it through its paces right from the touch screen. It performed great right away. There were no real issues. I did manage to install the display upside down, but that will take 5 minutes to flip the next time I’m at the space. I just plain ran out of time. Next time I’ll also be able to play a bit with the PC software, but it was great that the controller fired up and ran right away without having to mess with the PC at all.

So now the space has a nice profiling reflow oven! I am looking forward to using it! I know one member already has a board lined up to go this Tuesday (Feb 3rd, 2015). So if you’d like to see it run in person stop on by the space on Tuesday at 7PM!

I have a space heater with a thermostat built in, but it is terrible.  It has a huge deadband and will click on and off enough to trip itself on occasion.  So I’m building my own. It will PWM with the SSR and will have and external temperature sensor. An Arduino will run the whole thing.