Timed LED Lighting Control – Design

From Logical to Physical

Before I could start to translate the block diagram into KiCad, I needed to be sure about some of the parts I will be using. I want to reuse what I already have installed, so the motion detection module is already a given, along with the LED drivers. The micro controller needs three output pins, three input pins, I2C support as well as the pins for a program header. Since I have worked with Atmel in the clock project and therefore have the tool set I need, I decided for the ATTiny20. The only part I needed to look around for was the relays. As per the block diagram, I decided that the coil would be 12V and the switching contact should be for 240V AC RMS. For the moment I have settled on the JW1AFSN12F from Panasonic.

Translating the block diagrams to KiCad was fairly straight forward. The resulting KiCad diagram pretty much matches the block diagram in so much as the power system, relay driver and the PIR13 interface are modelled in their own sheet. In order to help to keep the 240VAC side separated from the Extra Low Voltage control section as much as possible, I opted to try for a stacked board layout. The two boards will be connected via a pin header and socket (P105 and P107). To simplify this layout I opted to utilise the different notations for the Ground plains. GND for the Extra Low Voltage board and GNDA for the Low Voltage Board.


tl2c-sheet2-powersystemThe Power System comprises of two LDO regulators. One for 12Volt and the other for the 3.3Volt supply. It is expected that the plug pack adapter will probably deliver about 14V – if not, I can always drop the 12V regulator out of the design. It is only provided for extra regulation. As already indicated in the previous post, the 12Volt supply is for the PIR13 modules and relays. The PIR13 modules can handle from 5 to 24Volts as a supply. Because of the distance of the cabling, any voltage drop should be within tolerance. The Micro Controller and therefore the signal lines such as for the I²C bus will be at 3V3 which is compatible with the Raspberry Pi removing the need for any level shifting. The ATTiny20 shares the pins for the I²C bus and SPI bus. At the moment, I have separated these with a couple of resistors as recommended in another article. I have my reservations about this and may yet change this over to a set of jumpers or even a double pole switch.


The signal from the PIR13 is open collector. To avoid having a direct connection between the ATTiny20 and the PIR13 modules, I will be installing some MOSFETs I already have from another project.


I am using the same MOSFETs to drive the relays. As a part of this initial design and a lesson learned in previous projects and Contextual Electronics, I will be including test points and indicator LEDs. An additional lesson learned is to not leave any spare GPIO pins unconnected. These can come in handy and for that reason I have even broken them out onto a pin header. I don’t have to populated the pull-down resistors nor the pin headers for these. But they are provided for if I need it.

Laying it out

I originally envisage the layout as a two piece board that will be separated after assembly. The first attempt was a two layer board and was not nice at all, so I shifted the design to a four layer board. This has pushed the price up enormously. The tip came from Chris Gammell to separate the two sections into their own layouts. One as a two layer board (the 240Volt AC section) and the other as four layer. This has reduced the overall cost significantly and now enables to be enlarge them enough for mounting holes and still be cheaper than the original full layout. The trick with this is how to model this in KiCad. I have tried out my own workflow for this:

  • Model the two boards as needed in the Master Layout PCB as 4-layer. This enables matching the mounting holes and pin-headers without having to swap between layouts
  • At the command prompt, copy the Master Layout PCB twice. Once for the 240V board and the other for the Extra Low Voltage (ELV) board.
  • In each new layout file, delete the section that is not needed and re-adjust, if needed the board layout graphics.
    • Adjust the layers for the 240V board from 4-layers to 2-layers.
“Master Layout” Both boards side by side

Design considerations and constraints

I am reasonable happy with this initial cut of the layout. However, I am not quite ready to send this off to OSH Park. This project and board contains an element I have not worked with before – Hazardous Voltage. This can not be under estimated. One aspect to this is to separate the Low Voltage (LV to ELV boards onto their own. There is still the question of Clearance and Creepage to consider on the LV board. There are a number of very good essays written some with calculators

Trace Width
PCB Trace Spacing
Creepage and Clearance
Clearance and Creepage Rules for PCB Assembly

So I have a bit of a quandary. I don’t want to send off the board for manufacturing before I have sorted out the safety aspects of the design first. I could send it off as-is but if there is a specific requirement I need to meet, I will have to request another. I can, however, make a compromise. With the tip for splitting out the boards as separate PCB files, I can send off the order for the four layer part and leave the two layer, LV board for further consideration. In the mean time, I can bring up and test the control board since the relays either are not needed for the proof of concept or can be simply wired in for basic testing.

At the moment, I have a small uncertainty about the housing and the terminal blocks. It is much easier for me to choose or to know what to look for when I have some actual samples in my hand. So I have ordered a couple of samples to get a better idea of these parts. It is tempting to consider to print the case. However, this would push out the project and shift the focus to a 3d Printing project. I would prefer to keep on track with the Timed LED Lighting Control hardware and firmware.

In the next post, I hope to have the casing and terminal blocks worked out which means that the board will be ready for fabrication. So hopefully then I will be able to talk about bringing the board up.


Stairwell Foot Lighting System

When getting back into electronics, one of the projects I had in mind was to revamp our stairwell lighting system. In 2010, we renovated our stairwell. I took the opportunity to design in a foot-lighting system that was motion controlled. It has worked faultlessly for the last six years. But who can stop at revision 1.0 when there is so much more can be done? This entry is about working out a new stair well foot lighting controller.

Fixing What is Not Broken

If it has worked faultlessly for six years, then what is there to fix? The basic driver was the size of the original solution. Like the doorbell project, the original was put together with what I could obtain with what I understood at the time. I have no regrets about that and would take that approach again since it solved the problem. However, since day-one, I had always had it in mind that I would like to rework this with my own Micro-Controller solution. Now with what I have learned in nearly two years, it’s time.


This initial solution comprised of an electro mechanical timer – that I have to manually set for Summer time and Winter time. It has three PIR13 modules from ELV as the motion detection sensors and three sets of PIR13 timers (also from ELV but now obsolete) connected to a LED driver from SLV that can drive up to eight high power LEDs each. In my system, I have only a maximum of four in each bank.

Initial Ideas – to the big picture

lcu1sI had envisaged using a small embedded device with an inbuilt touch display. This device the LCU1 was released by EQ3 through ELV. It has a tool set for UI development with direct interfacing to analogue inputs and four relays. I was attracted to this device because of the the embedded Linux and the size. I imagined having this positioned in place of the existing control system. Instead of the mechanical timer, the timing would be internal and possibly supported by “Astro” calculation. Any additional changes to the set up could be done by using the touch screen. I also have the thought that this could be eventually expanded as a burglar alarm. I had got as far as a rudimentary graphical user interface. There was still a lot to sort out with regard to interfacing with the motion sensors and eventually the connection to LED foot lighting. This is where I seemed to reach my limit and the project was put in a drawer. …In the mean time, the Raspberry Pi arrived!

The Raspberry Pi, with its huge support network, inspires and enables new ideas to be realised. After EQ3 brought out their Homematic transponder for Raspberry Pi, I was inspired to get this project back on the table.  In our house we have the Homematic system from EQ3. This is a Home Automation system that has a rich set of sensors and actuators using a bi-direction wireless protocol. It also has provision for a wired solution too, for larger, more complex installations. The beauty of this system is that it can be built upon. Starting only with, say, one heater regulator, then perhaps adding a wall thermostat and eventually adding in the Central Control Unit (CCU) to handle more complex relationships between the sensors and actuators. For a couple of years now EQ3 released their CCU2 firmware for Raspberry Pi. This now opens an exciting new world of possibilities that goes beyond a simple foot lighting controller

I realised that even though the touch display would be a cute feature, it was not actually essential to the solution. From a user point of view, any changes to the system would be better made by simply picking up a tablet and making the changes over a browser rather than having to go down into the basement each time – which is how changes are currently made.

So the plan is that the Raspberry Pi will be taking over the operation of the CCU2 with the lighting controller connected to the Raspberry Pi via the I²C bus and a Web User Interface enabling remote control of the lighting system and Homematic installation. I need to stress that I have no big interest in accessing this outside the home. The possibility is still there with the Raspberry Pi as the “back bone”.


I modelled the complete set of ideas as a SysML block “context” diagram. The idea here is that the new Lighting Controller is type of I²C device connected to a Home Server. The Home Server is an abstract description that is modelled as one or possibly more Raspberry Pis. The CCU2 and a web server is envisaged to run on the Pi.

The diagram below is similar to the context diagram but only contains the components relevant to the stairwell foot lighting. Taking this one level further I modelled the internal block diagram for Lighting Controller to start to explore the different power domains that the system will have to deal with. I have decided from the start that I will be trying to work solely with 3.3Volts and not the 5V/3V3 mix that I had with the Clock Project. However, I have found it prudent that 3V3 is suitable for micro controller but 12V is probably better for driving the relays and the motion detectors.



The Timed LED Lighting Controller (TL2C) has four basic parts. A Power System a Controller , three banks of LEDs including their drivers (I will be still using the drives from SLV) and three motion detectors (PIR13 modules).

The original intention for the Power System was to pass through 240V to the LED drivers and also provide the 3V3 for the controller and 12V for the relays.


A short discussion with my tutor, Chris Gammell of Contextual Electronics hinted that the design of an off-line power converter would probably shift the focus of this project to power supply design. This could certainly be tackled but maybe in parallel or at a later stage. It would be quicker to simply use a “Wall Wart” for the 240V to 12V conversion. A simple LDO  regulator can then be used for the 12V to 3V3 conversion.

As the larger context block diagram indicates, there will be more components to this final project than just a single micro controlled device. I will need to move the existing CCU2 set up I have to the Raspberry Pi, build some type of Web User Interface to be able to interface and configure the Stairwell Foot Lighting system and finally see if it is possible to integrate the astro timer of the CCU2 to the foot lighting system. My initial thought is through the XML-API offered by the CCU2. This will be confirmed in a future post.

To be honest, I am not sure how the web interface will work between the lighting controller and the Homematic CCU2. I figure I will let that piece evolve as I learn more about website deign, CGI and Python or what other scripting language I will choose to interface the I²C bus with Web front end.

In the next entry, I will be talking about the design I will come up with for the Timed LED Lighting Controller and the parts selected.


Wrapping up the Alarm Clock Project

It has been a long while since the last post. Amongst other things, the clock has been a work-in-progress. Each time I made some progress, I found some new reason to create a revision. The initial revisions where based on issues and oversights. I am finding that as the project matures, the nature of the revisions are changing. Earlier on I was focused on just seeing things working i.e. how to program the micro with the ISP, how to get the modules to communicate. The earlier boards were either bound to the original dev-board, bread board or both. Now, I have the display module and the main-board untethered from the bread board and they are happily working with each other. Each step of the way I learn something new and those earlier issues are no longer the obstacles that they were. So much so that the problems and challenges I face now are more functional and mechanical.

I now have a basic board layout for the controller and the display that I am happy to progress with. These are certainly not the cheapest options, but as I may have mentioned before, they offer a way for me to learn about and demonstrate inter processor communication as well as dealing with multiple voltages in the one application. My focus now was to get the job finished. I see two basic challenges. 1. Getting everything into the case and 2. Getting the alarm working!

Low Profile 7-Segment Display


The seven segment displays I had been using would not allow me to mount the display in the case. It was time to search for a better solution. I discovered some thin profile seven segment displays. They are perfect for the job, though they are a bit tricky to solder since they do not have any leads. I worked around that with a piece of lead wire inserted in two of the holes in my board. This enabled my to apply light pressure on the display in the direction of the leads to hold them firm in position for soldering. Then allowed all the displays to be identical.


The alarm buzzer then became my biggest challenge and something new to learn about.The clock originally had a Piezo buzzer. Since the goal is to restore the clock, I was hoping to use a Piezo again. However the results from testing were not what I had expected. It was really difficult to get any sort of appreciable sound. Admittedly, the simple Piezo need to be properly mounted in order to resonate correctly. This I could not really achieve with my test set-up.

Testing the Piezo and looking generally at buzzers was opening up a new avenue of concepts to learn. I found the theory simple enough and meant I still had some design decisions to make. The first thing was to understand what direction to take. Since this was new territory, I saw no other avenue but to order some different types and just try them out. The basic criteria I set was capable of handling at least 5V and in around the 90dB range. I have to admit, I had no idea what 90dB was going to give me.

Description Manufacturer Part Number Digi-Key part Number
Zero-Peak Signal Buzzer Single Tone 2.67kHz Magnetic 0~5V 88dB @ 3V, 10cm TDK Corporation CSQG703BP 445-4832-1-ND
Zero-Peak Signal Buzzer Single Tone 2kHz Magnetic 2~4V 85dB @ 3V, 5cm CUI Inc. SDR08540M3-01 102-1286-ND
Zero-Peak Signal Buzzer Single Tone 2.4kHz Magnetic 3~8V 87dB @ 5V, 10cm CUI Inc. CT-1205-SMT-TR 102-1199-1-ND

In choosing, I had the choice to use a device that need no external driver or to drive the buzzer myself. I opted for the second to also learn how to integrate the PWM feature of the micro into the solution. In testing the buzzers, I could mount the CSQG703BP directly on my bread board. For the other two I created a (rough) test harness and used a Gabotronics Xminilab as my signal source – I don’t possess a bench signal generator yet.


The CSQG703BP tested OK but the tone was quite weak. I could not get a tone out of the SDR08540M3-01 at all but that could be related to the set-up I had. Although the  CT-1205-SMT-TR was quite bulky in comparison to the others, it delivered the best results.

I made the final revision to the board to take the CT-1205-SMT-TR on the underside over the place where the Piezo was originally. The case had a moulding that gave more than enough space for this part, so I was lucky there.

In “bringing up” the buzzer, I had to learn about PWM control and what that meant. I created a test program to only operate the buzzer and not worry about the whole clock functionality yet. In the end I thought it would be cute if the alarm would not simply make the traditional chirps but send  the message “WAKE UP” in Morse code.wakeup

Buzzer Alias Portb.1
Config Buzzer = Output
' CTC-Mode for ~ 2.5kHz
Config Timer1 = Timer , Compare A = Toggle , Prescale = 1 , Clear Timer = 1

Const Timer0_startvalue = 100                               ' 0.001 seconds
Config Timer0 = Timer , Prescale = 64
Timer0 = Timer0_startvalue
On Timer0 Timer0_isr
Enable Timer0
Start Timer0
Enable Interrupts

Heartbeat Alias Portc.3 ' LED indicator
Config Heartbeat = Output : Heartbeat = 0
Const Tone_pitch = 200

Dim Tone As Byte
Dim Tone_length As Integer
Dim Tone_idx As Byte
Dim Song(40) As Byte
Dim Songlen As Byte
Dim Song_finished As Bit

Const Base_length = 7

' Load the song - Songlen should be used to know the length afterwards.
Wait 5
Songlen = 0
Restore Melody
   Read Tone
   If Tone <> &HFF Then
      Incr Songlen
      Song(songlen) = Tone
   End If
Loop Until Tone = &HFF
Tone_length = 1

' A wake up signal. Illuminate the LED for one second.
Set Heartbeat
Wait 1
Reset Heartbeat

' Play the "song" every 10 seconds
   If Song_finished = 1 Then
      Wait 10
      Tone_idx = 0
      Reset Song_finished
   End If

   Compare1a = Tone_pitch
   Tccr1a.6 = 1

   Tccr1a.6 = 0

' ISR for timer 0. This will traverse the "melody" playing each tone, and pause
' in turn until the end of the song.
' The Melody is a series of data values. Since there is only one tone from the 
' buzzer, only the length is given. There is a base length and the tone length is
' a multiple of that. Basically this comes from Morse code that the dots are three
' units long and the dashes are seven. Anything greater than &H80 is considered 
' a pause.
   Timer0 = Timer0_startvalue
   If Tone_length > 0 Then
      Decr Tone_length
      If Tone_length <= Base_length Then
         Gosub Buzzer_off
      End If
      Toggle Heartbeat
      If Tone_idx < Songlen Then          Incr Tone_idx                            ' Get the next tone          Tone = Song(tone_idx)          Tone_length = Tone And &H0F              ' Get the tone length          Tone_length = Base_length * Tone_length  ' Factor the tone buy the base length          Tone_length = Tone_length + Base_length  ' Build in a unit gap at the end          If Tone > &H80 Then
            Gosub Buzzer_off
            Gosub Buzzer_on
         End If
         Set Song_finished
      End If
   End If

Melody:                                             ' Wake up - Morse code
Data &H01 , &H03 , &H03 , &H83 , &H01 , &H03 , &H83 , &H03 , &H01 , 
     &H03 , &H83 , &H01 , &H87 , &H01 , &H01 , &H03 , &H83 , &H01 , 
     &H03 , &H03 , &H01 , &HFF

Alarm Integration

It was easy enough to integrate the alarm-tone code into the main-board code since since the 16-bit Timer0 was not in use. I could configure the Timer0 for CTC-Mode (Clear Timer on Compare) to deliver the 2.5kHz which produced the best results. I did attempt other PWM configurations but the results were not what I was expecting or wanted.

Config Timer1 = Timer , Compare A = Toggle , Prescale = 1 , Clear Timer = 1
Const Tone_pitch = 200

In my original design, I had anticipated to utilise the alarm interrupt (address $E) that the RTC-DFC supports – or is meant to support. I actually found that this does not work. When the alarm is programmed, it can be seen to be fired since the indicator LED on the module will illuminate. However, the Alarm Interrupt line is not brought low and therefore not detected in my code. I have two modules to try this out on and neither would pull the interrupt line low – even after upgrading to the latest firmware.

After chatting with my tutor, Chris Gammell from Contextual Electronics, I came to realise the workaround. In addition to the Interrupt line, it is possible to detect the alarm in the interrupt status register. This works. So I modified the code not to rely on the interrupt line but to, instead, query the Interrupt Status Register and invoke the alarm if the alarm bit is set.

   Reset Dfc_ss
   Mosi(1) = &HCE
   Spiout Mosi(1) , 1
   Spiin Mosi(1) , 1
   Set Dfc_ss
   Interrupt_register = Mosi(1)

   If Alarm_disabled = 0 Then
      Temp = Interrupt_register And &B00000100
      If Temp = &B00000100 Then
         Set Alarm_fired
      End If
   End If

Wrapping up

I was keen to get this project into a finished state. The enabling of the alarm was one of the last stages. All was needed then was to clean up the code a bit and implement an “alarm cancel”. There is a push-button on one of the front feet so that the alarm can be cancelled by tapping the top of the clock.

img_0274eSo here it is, the renovated clock. I utilised the BOM feature of KiCad to perform a cost analysis of the two modules. The Clock module comes to a BOM cost of 41.46€ (including the RTC-DFC from ELV) and the display module comes to a BOM cost of 35.14€. I have already mentioned that this implementation is a bit over the top in terms of components etc. but it is more about the learning exercise rather than making a cost effective clock and display module.

Just to recap on what I have learned in this exercise:

  • Circuit design
  • PCB layout
  • PCB Manufacturing
  • Assembly
    • Improved through-hole soldering
    • SMD
  • Programming through an ISP (to a development board and my own board)
  • Inter module programming using I²C and SPI
  • Trouble shooting using a logic analyser and oscilloscope


When I set out on this project, I anticipated to learn a bit about UML – SysML in particular. I did start out that way but with everything else I had to learn on the way, it sort of went by the way. However the block diagrams that I created ended up being an valuable reference of what I had intended the pin allocations to be. That is something will try to utilise more for the next project.


Now that the clock has been running a week or so, I was thinking about how it is able to pick up the time signal better in some places than others. I was made think about this further when the ELV Journal showcased an external antenna for the RTC-DCF. I realised that all this time, I have been treating the DFC-RTF as a black box an literally taking it for granted. That approach certainly helped to get the job done. It was time to take a closer look. The RTC-DFC is a module in two parts. A DCF77 receiver module and a micro based RTC. It turns out that I really had a bit of luck with the positioning of the antenna on the main board. In certain locations the clock can (eventually) receive a signal, in others not at all. Looking at the data signal from the DCF77, I could clearly see the one second pulses when the antenna was about 5cm from the board. Bring the antenna closer and the signal is disrupted as the images below show.

It was not a light decision to take to add the external antenna to the clock as I had to make a slight modification to the case for the antenna cable. The performance of the clock as improved immensely. It now sits, as a trophy, on my Lab windowsill.

Revisiting an old project

Some Background

TheOldDeviceI recently had the opportunity to revisit an old project of a doorbell extension that
used the ELV FS20-S4SUB to send a signal to the ELV FS20 SIG-2. At the time I did this with what I knew at the time to get the job done with the equipment I had. This meant nothing too sophisticated. Pretty much off the shelf modules for the “ELV Universal-Spannungsreglerplatine Komplettbausatz” as DC power supply, a 8 DIL 555 timer as a one-shot mounted on vero board. It certainly did not look nice and I knew there would be a better way, but it worked.

In this original implementation,  I had to go to these lengths of using the relay and oneshot as I found connecting a relay directly to the doorbell switch to drive the FS20-S4SUB was not reliable and needed a way to denounce the press button as well as being on long enough to trigger the FS20-S4SUB.




After four years of working without a hitch, this project was brought back to my attention, so I decided to redo this with what I know now. The major criteria is that I should not spend too much time on this. I had two choices 1) Go with with I have already done 2) move to an embedded solution. While 2) could be fun and would be more compact, I decided on option 1 since I could reuse the ELV FS20-S4SUB, which was still serviceable. All I needed to do was model the existing solution in KiCad as a single board.

New Design

As shown above, the existing solution was based on relays. I didn’t  want to bring these forward into the new design. There is an interesting solution put forward in ELV 06/2014 whereby they implement a door bell sensor by feeding the rectified signal into the base of a transistor (pins 1 and 3 of P2). Their solution also provided an addition possibility by sourcing the voltage as well so that a stand-along press button could be used (pins 1 and 2 of P2).


Here most doorbells are powered by a transformer delivering between 8 to 12V. So this system was designed sense the voltage from the doorbell button whereby the device itself is battery powered and the doorbell system is sourced by a 12V transformer. In my case I would be powering the device from the same transformer as I have done in the original solution, thereby saving the need to change batteries.

The part that was bugging me was the interface to the FS20-S4SUB. My first approach to this problem was to simply use the same reed relay. But in examining this set up, I started to have doubts about what I was actually doing in the original design.

My first problem was the power. The transformer is delivering about 15 Volts without load. I originally had set up the DC power supply with a LM7812. Everything worked fine, but in this design, there is no room for any error or movement. Something I had not considered before. After speaking with my tutor, Chris Gammell of Contextual Electronics, he confirmed the doubt. Under load, if the transformer voltage would go below 12V, there could be a chance of a “drop-out”. He suggested bringing the supply voltage down to 9V, which would be more reliable. The main reason for sticking with 12Volts was the availability of cheap reed relays. I had trouble finding anything for 6V. Chris suggested the use of an Opto-Coupler in place of the reed relay.

Choosing the Opto-Coupler

I decided to embrace the Opto-Coupler suggestion since it would solve the power supply issue. But I had to familiarise myself with Opto-Couplers where I have never had reason to implement one before. The FS20-S4SUB has five wires. One Ground and four inputs, presumably open-collector with internal pull-ups. The problem now was finding a suitable Opto-Coupler. The resources I was finding on the web all seemed to be from the perspective of driving some load through the collector-emitter side and would then base their calculations on that current flow.

Placing a DMM across the contacts, I see 2.9Volts @ 0.03mA. It seemed to me that I could place almost any Opto-Coupler there. I decided to take the selection the other way. I intend to drive the LED at 10mA (though the rated maximum will probably be 40mA). From that, I need to only ensure 0.03mA can be seen at Ic, I figured a current transfer rate of 50%@5mA will be more than enough.

Interestingly enough, this criteria ushered me to the LTV-817S, which I had been seeing in lots of places as a standard, easily available part. So I presumed this to be a good place to start.


The circuit above shows the implementation I will be using. The 1KΩ R11 is used to limit the current to the LED. The 10kΩ R12 is used to pull the value on the LED down to ground when not active. R13, which is marked as “NO-POPulate” is there was a “Just-in-case” 0Ω or Jumper in case I may need to tie the FS20-S4SUB ground to the system ground.

putting it all together

I took the liberty of compiling what were separate modules onto one board to create a self-contained solution and minimise its overall size. The layout below shows the remodelled DC Power supply, using a bridge rectifier and a LM7809 based on the ELV DC power supply, the One-shot trigger, using a SMD 555 timer and instead of the reed relay,  the LVT-817S is used. Instead of the bulky relay as seen in the photo above, will be the door bell sensor as showcased in the ELV HomeMatic®-Funk Klingelsignalsensor. Some additional enhancements that were not included on the original design are some test points for verifying the behaviour and an indicator LEDs to indicate power-on and to show when the FS20-S4SUB should be sending its signal.

Revision 2

The Gerbers for the board was sent off to OSH Park and a couple of weeks later, The first set of prototype boards arrived. I ran into a small issue with my footprints. This has happened before where a I model the footprint as per the data sheet. However, there is a margin of error in the holes required for the leads and a margin of error for the holes drilled by OSH Park. Neither are wrong. It is just that one should take that into account and model the holes on the larger side. As it was, it was not too bad since I could solder some leads in the holes for the rectifier bridge and solder the rectifier bridge to the leads. The result looked quite neat.

Bringing the board up went smoothly and all aspects of the device tested out fine including driving the FS20-S4SUB through the Opto-Coupler.I was confident with the board that I proceeded with the second and final revision – the layout is shown above.

The connection of the device can be configured in a couple of ways which was a offshoot of using mechanism provided in the door bell sensor. However, I was only intending to use the configuration where by I power the system from the existing doorbell transformer and only need then the return wire from the actual doorbell switch.



I found an appropriate case which happened to fit the board just nicely. Since I was using SMD LEDs for the indicators, I had the challenge of trying to work out where I should drill the holes for the Light-Pipes. I then decided to sacrifice a couple of the light pipes. Since Osh Park send three boards, I took one of the spare boards and hot glued the light pipes to the footprint location for the LEDs. I then coloured the tops with some ink and placed the cover in place. This provided some marks on the inner side of the casing and a closer than rough indicator as to where to drill.

The end result I considered was very good. The light pipes pick up the individual LEDs very well. I have put aside the light-pipes that I used to locate the holes in case I need them again one day.


I have now the completed board and the FS20-4SUB neatly in the casing. I shortened the leads for the GND and TA1 on the FS20-4SUB but I still don’t have the heart to cut back the leads for the unused channels.


It was a lot of fun and very rewarding to revisit this old project. It is especially rewarding to compare what I knew then to what I have learned since then.

One of the goals was to see how quickly this could be completed. The first commit on Git-Hub was June 5, 2016 and I am writing this 49 days later (1 month, 2 weeks and 5 days), I did not record actual time spent on the project. I will leave that discipline for another project. This time includes the turnaround for two revisions of the board. Going through the BOM and adding up the parts used in the final device, the cost comes to 19,09€.

One Year of Contextual Electronics

Before Contextual Electronics, I knew I wanted to get back into practical electronics, after a very long break. But I still had a lot to learn or re-learn. My study days left my head spinning trying to grasp operational amplifiers with two or three pages of algebra and still did not know exactly how they are applied. So the whole thing was a little daunting. I found gEDA and tried using it. It was not very stable, even on Ubuntu and then It was in December of 2014 that I came across KiCad. This is also when I discovered Chris’s tutorial, “Getting into Blinky”, the AmpHour and of course Contextual Electronics. So I signed up January 2015, not knowing where it would take me or if I could even keep up. Reflecting back, my goals were to understand better how to implement components like transistors and op-amps etc. Particularly to take a design from schematic to PCB. Local Fabs (Germany) are prohibitively expensive, so I was after any tips I could get along the way.
When Chris announced the Roll-With-It project, I had a small panic attack. I wanted just to learn how to implement a transistor correctly and now I am supposed to build a tele-presense robot? So that is where my journey began. Since January 2015, I have been part of the subscription based Contextual-Electronics and have seen it change its appearance and evolve to the current site. I don’t know if it has always been subscription based but this works well for me. I am liking the “workshop” approach to the projects as opposed to a fixed time period school-term like approach.

In terms of ticking off goals achieved, that list is much larger than when I started. Over the last twelve months, I have learned about applying an op-amp (yay!) and even a comparator. I have learned about PCB layout and where I can get them created for a reasonable price. I have also learned about SMD and how to solder them by hand and now using reflow. I think one of the biggest lessons is prototyping though board design and not necessarily with bread or vero board. Other things added to the list are In System Programming of micro controllers i.e. outside the safe-haven of a dev-board such as Arduino. These things I would not have dreamed of twelve months ago.

Now we are starting a new year and can think about “what would I like out of Contextual Electronics?”: The direction of the course seems to be heading towards a more micro/digital based. I was probably expecting more of an analog component. However, when everything that is published is interesting, relevant and seems to just flow with the ultimate goal in mind (Roll-With-It), the question of what do I want from the course become a difficult question to give a direct answer to. The work by Ron and Eric providing professional instruction in Embedded system design and coding has given the course a whole new dimension. I have not taken the opportunity to work through the material properly but that is a goal for 2016!

The journey with Contextual Electronics has been a very inspirational one and the support from Chris has been motivating. I probably would not have gotten so far with my own project without his encouragement – I certainly would not have started a blog on it! So it has been an a amazing journey, though I now have to say, I don’t remember what I did in my spare time before Contextual Electronics, as there seems to have been little time for anything else 🙂

I look forward to 2016 and our first CE all-in, live, tele-seminar with our RWIs.

The Main Board

I created the main board in the same pattern as the original. That made for quite an expensive prototype as there is a lot of empty space. This size is needed to fit the tactile switches in their proper places. Now that I have Revision 2 up and running, a write up of what I have learned along the way is over due.

The assembly was not without issues. There were some lessons to learn with KiCad and circuit design and layout as I did make some mistakes but I was able to identify the issue and make some corrections. Here are some of the things I picked up along the way

Check the pin outs

This might sound like an obvious thing and it hind-sight, it was. Complacency crept in on more than one occasion and I did not verify the pin allocations between the datasheet, symbol and footprint for the linear regulator. As it was a three pinned device, I only needed to reset it and run a bridge to ground.


I did not factor any indicator LEDs on the main board. While this is not a mistake, the addition of an LED to blink to show that something is happening is well worth the few seconds it takes to model it in the schematic and layout.

Don’t leave GPIO pins unconnected

This is just to say for any prototyping board, it would be worthwhile to expose any spare pins to headers, and or coupled with 0Ω resistors. When troubleshooting, you never know when you might need something. Of course in the production board, these would not be populated.

Getting Things up and Running

Heartbeat-Bodge-bOnce the power rails were reading the correct voltage, I connected in the RTC module. This fired up OK. I.e. Its LED lit up for a second. This is when I realised I was missing a heartbeat LED. I simply connected a piece of through hole lead to Port B0. This was the output that was configured as the heartbeat on the myAVR development board.


Using the procedure I used for the previous boards, I tested the connection between the PC and the AVRISP mkII using the Atmel Studio. If I could read the serial number of the micro, then I knew I was in good form.

Main Board and Rev1 of the Display Module

I flashed the program I was using on the myAVR Dev board. Straight away the heartbeat started pulsing. Another good sign. The display did not react, or when it did, it was with garbage.

The issue with the display module as due to a mismatch between the main board and the display module. Since communication was OK to the RTC, I could assume that the SPI was largely OK. The obvious place the issue would be was with the actual signalling and or timing.

This issue has kept me occupied for some time. The biggest help was the Salea Logic Analyzer. To be able to capture the signals and have the digital values interpreted is a huge advantage. I could read the values being sent to the clock and display to ensure they were correct. I was able to tweak the code so that I could match the SPI specifications described on the RTC datasheet. I used this as a base to then configure the display module. Everything started to fall into place then and the display was more stable.

I found that to get the flexibility out of BASCOM, I needed to set up the Master i.e. the main board using software controlled SPI. Whereas, I could simply rely on the hardware SPI for the slave (display board).

Main Board SPI Setup

Fir the main board, the software controlled SPI was preferred since I could then use the SS = None property on the configuration. I then had to allocate my own chip-select lines for each of the RTC and the display module.

Config Spi = Soft , Din = Pinb.4 , Dout = Portb.3 , Ss = None , Clock = Portb.5 , Setup = 40 , Mode = 1

Display_ss Alias Portb.2
Config Display_ss = Output : Display_ss = 1

Dcf_ss Alias Portb.1
Config Dcf_ss = Output : Dcf_ss = 1


Display Board SPI setup

The key to the display board setup was to use the Master = no to ensure that this would be configured as a slave. All pin allocations were as per the datasheet for the micro controller.

Config Pinb.4 = Output
Config Pinb.3 = Input                                       ' MISO
Config Spi = Hard , Interrupt = On , Data Order = Msb , Master = No , Polarity = Low , Phase = 0       ' , Clockrate = 128


On Spi Spi_isr                                              'Nosave

In principle, things were good. I know I can flash the display module and I know I can flash the main board. I also know that communication is happening between the main board and the RTC.However there is still a niggling problem between the controller board and the display unit. After a while, the data seems to get out of sync and the display starts to display wrong values. SignalToDisplay Examining the SPI signals, I could be satisfied that the data presented and received by the display module is correct. There is something else happening inside the display module that is causing the information to be gabled. This is where I am reaching another boundary on my tool-set. The myAVR and the AVRISP MkII do not support any debugger. This is a set of tools I have yet to expose myself to and learn. Thinking around the problem, I am sure that this is some type of synchronisation issue. The actual cause, I can’t be sure. One thought would be some interference with the interrupt service routines. Since the data presented to and received by the display module is correct, I am willing to exclude the actual controller from the equation, for the moment. The problem has lead to some optimisations on the display module. One of the first improvements was seen when removing the NOSAVE from the On spi Spi_isr statement. This reduced the Spi_isr down to the following

   Set Rbit
   Mosi = SPDR

The same routine as described in a previous blog entry also contained logic to arbitrate whether the incoming data was a register address or a value for the register. in fact, this was always a concern. How to reliably determine the name from the value. The very first entry after start-up is going to be an address. After that, if something happens to the timing, it is not so clear cut.

After trying several ways to analyse the problem and make changes that were not always successful, I have determined the most effective way would be to flag the address. This means the API to the display module has now changed such that the first byte send to it, as address, must have the most significant bit set. This is a major improvement on reliability, but still no solution!

   If Rbit = 1 Then
      Reset Rbit
      Spdr = Mosi

      If Mosi.7 = 1 Then
         Idx = Mosi And &B00001111
         Register(idx) = Mosi ' Assign the data to the register
         Select Case Idx      ' Based on the register/value, set the affected variables
            Case Hours_10:
               Digits(1) = Register(idx)

There are still some issues to solve with this. For the above change, the controller board was not considered. However, the problem now comes back to the controller board to understand what the interaction is between the RTC, the controller board and the display board really is. Only once in a while at the transition of a minute, the display will be corrupted for a second or two. This does not happen often. Perhaps three to four times in an hour. But it shows there is still some form of timing race condition happening.

Where to from here?

I am happy that the communication is happening but I can’t call the job complete as there are some odd issues still persisting. I could work around them by sending only one byte rather than two so that the high end nibble is the address and the low end nibble is the value to be set. This would work for most of my values, but no all. Besides – that would be a work around and not a solution. I need to find a way to better understand what is happening with the data between the RTC, main board and display module such that the display modules register address and values are being skewed. At least that is my current understanding of the issue.



Further testing the μController Display Module

In the last post, I was able to get the μController version of the display module working with a basic test routine that proved that 1. the controller could be programmed and 2. the display was being driven correctly. The next stage is to flesh this out to replicate the MAX2771 API. The purpose here is not to simply create a duplicate of the MAX2771 which does a great job on its own. This approach means that I can re-use the code I created for the MAX2771 display module project. The additional goal of this small project was to gain experience in creating a SPI slave! Interfacing with the MAX2771 was simple since that is already a SPI slave unit. All I needed was to just create the master.

Connecting things together

I still have things set up from the previous tests so it was just a matter of connecting things back up again. Though this time I had two units to program instead of just one. I still have the main controller board for the clock to complete so I used the myAVR Dev board as a provisional main controller. Luckly, the myAVR dev board comes with its own programmer. I had to program this via the myAVR ProgTool since the BASCOM-AVR IDE was in use with programming the display module via the AVRISP mkII. It sounds more awkward than what it turned out to be. The part that was awkward was that the AVRISP mkII had trouble programming the display module while the SPI connection was still made to the myAVR dev board (my provisional mainboard). I had to disconnect the /SS, MOSI and CLK from the display module before being able to program. This would be a point of research to work out what is involved to be able to program the display module while still connected!

μControlled Display Driver Integration Test
μControlled Display Driver Integration Test

Once the infrastructure of programmers and connections was sorted, it was just then a matter of piecing together the code to enable the slave unit to start servicing the requests of the master i.e to start displaying the time. With the Real Time Clock still connected (via an I2C bus) I had a neat source of test data.

Getting thing up and running was rewarded with a red blinking LED on the dev board. This was my signal that the communication with the Real Time Clock was functioning. The next was the display module itself.To keep things simple,  I am opting to use the basic BASCOM constructs for SPI. The logic analyzer was useful for seeing that the SPI messages were being sent. Though my particular logic analyzer only shows that there was activity. It lacks the sophistication of being able to see exactly what was being sent. Thankfully, I have been able to get things working without that level of sophistication.


Creating the Slave

Dim Rbit As Bit
Config Pinb.4 = Output                    ' MISO
Config Spi = Hard , Interrupt = On , Data Order = Msb , 
       Master = No , Polarity = Low , Phase = 0 , Clockrate = 128

On Spi Spi_isr Nosave

Enable Timer0
Enable Timer1
Enable Interrupts

The snippet above shows how the slave was defined. Basically I used the same construct in the master. The “Master = yes” property is the only difference. Once data is available for the slave to read, the spi_isr interrupt routine is executed. Here I just grab the data into a Regisiter array. The API I was wanting to implement was to read a two byte command i.e. a register address and then a value. I was not sure on how this is to be done since BASCOM-AVR documentation only really talks about receiving one byte at a time for slave. In comparison, sending multiple bytes from the master is not difficult at all.

   PUSH r24    ; save used register
   IN r24, SREG; save SREG
   PUSH r24
   Set Rbit                         ' we received something
      If Spi_idx = 0 Then
         Idx = SPDR
         Set Spi_idx
         Register(idx) = SPDR
         Reset Spi_idx
      End If
   POP r24
   !OUT SREG, r24 ; restore sreg
   POP r24       ; and the used register

Here I had a variable to track which element of the command was being received spi_idx. When reset, then the first value from the master is expected and therefore that value is recorded as an index value i.e the register address. When spi_idx is set, then it is expected that the value from the master is the register value and that is then directly recorded in the Register array.

With the register address and value for the register obtained from the master, then it was a matter of interpreting the newly arrived information. I implemented this using a case construct.

   If Spi_idx = 0 Then
      Select Case Idx
         Case Hours_10:
            Digits(1) = Register(idx)
         Case Hours_unit:
             Digits(2) = Register(idx)
         Case Minutes_10:
            Digits(3) = Register(idx)
         Case Minutes_unit:
            Digits(4) = Register(idx)
         Case Colon:
            Digits(5) = Register(idx)
         Case Indicators:
            Digits(6) = Register(idx)
         ' Case Intensity:
         ' Case Power_mode:
         Case Digit_blink:
             Blink_mask = Register(idx)
         ' Case Blink_rate:
         Case Test_mode:
            If Register(idx) = Enabled Then
               Digits(1) = 8
               Digits(2) = 8
               Digits(3) = 8
               Digits(4) = 8
               Digits(5) = 8
               Digits(6) = 8
               Digits(1) = 0
               Digits(2) = 0
               Digits(3) = 0
               Digits(4) = 0
               Digits(5) = 0
               Digits(6) = 0
            End If
         Case Else
      End Select
      End If
   End If

The idea here is to simply  react if there is a new value arrived. Based on the value of idx (the register address) to then assign the value from the register to a variable that will result in the desired behaviour. i.e. setting a digit value etc.

One feature I have implemented that is not part of the MAX2771 API is a Blink feature. i.e. to enable a digit or colon to blink. I managed this with a mask with one bit for each element of the display. This seems to work quite well.

   Timer0 = Timer0_count
   Incr Position
   If Position > 5 Then
      Position = 0
   End If

   Digit = Position + 1
   PORTD = &H0A          ' Set all segments off
   PORTC = Makebcd(position)

   Blink_test = &B00000001
   Shift Blink_test , Left , Position
   Blink_test = Blink_test And Blink_mask
   If blink_flag = 1 and blink_test > 0 Then
      Value = Digit_off
      Value = Digits(digit)
   End If
   PORTD = Value

Next Steps

The μController version of the display module is working, I have to admit, in principle. There is still a bit more work to do to clean up its behaviour and possibly implement more tests and features i.e. the indicators on the top and bottom left of the display.

The actual main board still needs to be done. This will be presented in future posts. There are some considerations to be done with that in terms of its physical size for the existing casing. Another task that is outstanding is the interfacing of the Real Time Clock with SPI rather than I2C. I have been using I2C since that is what I used on the very first trial. My goal is to have a multiple slave SPI implementation. This too can be prototyped with my current set up before finalising on the actual main controller board.

The advantage I have with the current approach is that the firmware for the main board is progressively being done with the testing of the modules. It is just missing the implementation of the various push buttons. Even this can be implemented in the myAVR Development board.