It has always been on my list to try a project with some wireless communication. I now have a project in mind but there are a few things to sort out first. I have not worked with any wireless at the embedded hardware level. This is not inteded to be any instructional post but my usual style of describing how I have approached this topic, what I encountered and how I worked around any issues I discovered. Maybe this might be of some help to others like me, starting at zero. Continue reading An Encounter with XBee
In the last entry for the Timed LED Lighting Controller, I realised that there are no working examples of an I²C driver for the ATtiny20. I then had to work through the data sheet to implement my own. With that done, I could then start on the application firmware and get the board really working. So this is where my proof of concept becomes the prototype.
In this post I describe the trials an tribulations of bringing up my Timed LED Lighting Controller and how I went about implementing my first I²C Slave Driver for the ATTiny20.
In the last post for the Timed LED Lighting Controller, I had figured out the circuit and a basic layout and approach that I was happy with. That is to separate the hazardous voltage from the control circuitry by putting it on a separate board. But still, this was not enough. I need to assemble this in a case. No hazardous voltage is allowed to be exposed. The idea of printing a case is attractive but I don’t really want to loose focus of this project. I can always reserve the printed case for revision 2.
I found myself feeling like I as facing a bit of a chicken and egg. Needing a housing to fit the board and having to make the board fit the housing. I also needed sort out a set of terminal blocks and ensure that they are in specification. The only way forward was simply have a look around and order some terminal blocks and cases and just to see what is out there. Photos and technical diagrams are great but to have the actual items in hand is much better. I decided to use Reichelt this time. I had not used them before but they had a good range of terminal blocks of various dimensions and configurations and I could purchase single units which was important for a look-and-see. I settled to take a look at a small selection
|Manufacturer||Pole||Spacing||Voltage / Current|
|Springcon||6||2.5mm||150V / 8A|
|Springcon||2||2.5mm||150V / 8A|
|Metz Connect vertical||2||5mm||300V/ 10A|
|Metz Connect angled||2||5mm||300V/ 10A|
The smaller units are not suitable for the hazardous voltages but I will still use them for the connections to the motion detectors (PIR13).
Without wasting too much time, I ordered two housings manufactured by Bopla. When they arrived, it was clear that I could use the smaller of the two (BOPLA KS 430) that I had ordered. There are undoubtedly other housing that would suite but this will do for the moment. I will, of course, have to modify the casing to expose the terminal blocks.
Now that the decision was made for the terminals and housing, I could look back at the layout with more confidence. This also meant a bit of a rehash. I had to add the footprints for the terminal blocks and their outlines to make sure they will fit on the board.
Revisiting the Layout
The next was the housing. This was a little more involved since I am going to stack the boards. I ended up making use of the dimensioning tool in KiCad so I could correctly line up the joining pin-header and the mounting holes.The outcome of this was that I needed to extend the respective boards so that they could get past the “assembly posts” for the housing and also that the terminal blocks will reach the ends of the housing.
The larger board has given me space to reorganise a few things. I have now collected all indicator LEDs into a single bank of LEDs. This will look a lot neater when they are exposed to the housing surface compared to LEDs that are placed simply where it is convenient on the PCB. The LEDs are to help with bringing the board up and there is nothing to say they need to be populated for the final version.
Going back on the question of Clearance and Creepage, the dimensioning tool as was also useful to verify the distance between the traces where they look a bit close. At the moment, according the the on-line calculators (Creepage.com and ANSI PCB Trace Width Calculator) I have checked, seems to be in specification – further verification is required.
Mocking the Board
On the screen, it was all looking good, but I was still not confident I had covered all the possible issues. It was then I decided to “mock” the board. Simply print it out and paste the images to some card board and cut them out. I could then use a real pin-header to assemble the two parts to see how they would fit.
Of course, I could not stop there. I had to then also punch through the other through-holes and set the terminal blocks that I now had in my possession. At first this was just for a bit of fun, but as it turns out, I discovered some issues with the layout that would have normally gone unnoticed.
The first issue was that I did not realise the mounting holes for the board at each end are spaced differently. From the perspective of the photo above, the mounting holes on the left are set narrower than the mounting holes on the right.
The second issue was that I had not calculated the “Y” location of the mounting holes correctly and they were 1.7mm out.That was easily sorted out since it did not affect any other parts on the board.
The third issue was with the terminal blocks for the motion detectors.I was trying to get away with the terminal blocks I had received. I need provision for 12 wires. Three for the I²C Bus and nine for the connections to the motion detectors.I was thinking I could butt two six-pole terminal blocks together. However with the way they are modelled in KiCad and the respective footprints, this was not possible as these terminal blocks have a nominal 2.5mm spacing and a 3mm spacing when butted together. So solve the issue, I went back to KiCad and remodelled the connections to the motion controllers as three sets of three. In the layout I only needed ensure that there is a minimum 3mm spacing between the three-pole terminal blocks.
The Timed LED Lighting Controller is another step forward. This will be one of the more expensive boards I will send off for fabrication so I am very pleased to have spotted those issues with the layout. The goal is to have as few “spins” of the board as possible and the process of mocking the board was a huge help. Just a few more checks and I can send this off to OSH Park!
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.
The 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.
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
|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.
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
I 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.
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.
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 Do 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 Do If Song_finished = 1 Then Wait 10 Tone_idx = 0 Reset Song_finished End If Loop End Buzzer_on: Compare1a = Tone_pitch Tccr1a.6 = 1 Return Buzzer_off: Tccr1a.6 = 0 Return ' 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_isr: Timer0 = Timer0_startvalue If Tone_length > 0 Then Decr Tone_length If Tone_length <= Base_length Then Gosub Buzzer_off End If Else 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 Else Gosub Buzzer_on End If Else Set Song_finished End If End If Return 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
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.
Read_dfc_interrupt_flag: 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 Return
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.
So 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
- Improved through-hole soldering
- 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.