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.

DoorBellSchematic

 

VeroLayoutc

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).

DoorbellSensor

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.

FS20Driver

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.

EBSDoorbellRev2Layout
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.

ConnectionE

Assembly

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.

IMG_0860E

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.

Conclusion

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€.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s