Now my car roars with 110db twintone horn

About 2 years ago, I had an auto accident (luckily no one was seriously injured) and damaged my front bumper and the horn was also replaced. But after I got my car back from the workshop, I realized that they gave me an cheap horn that is soft and squeak like a little kitten, far worse that the stock horn.

I have been wanting to change it for some time and recently, there was a few occasion when some reckless drivers dangerously cuts in front of me, forcing me to slam the brakes and also horn, but what came out was a mere little kitten squeak. So yesterday, I finally decided I had enough of the ineffective horn.

As I am sorta the DIY guy and also I been wanting to learn more about fixing my car,I decided to fix it myself. I could learn more about car wiring and save some money. First, I took a spanner to remove the horn, took it back into my room and experimented with it. I found that electric horn connection terminal are not polarized, so we can connect +12V and GND from my power supply to any of the two terminals. Using a multimeter to measure the current consumption, the horn drains about 4.2A or approximately 50W.

Old horn removed

Next, I went to an auto accessories and bought a Hella New Generation Twin Tone Horn for RM58.00. On the box, it states the sound pressure level is 110db and rate input power of 2 x 72W. I also bought a few connector for the wiring.

Later, I went home to install the horn. There are generally several types of horn connection for cars as shown in the installation instruction at the back of the box.

The existing horn has the 3rd configuration - one wire. After a few minutes of wiring and screwing the new pair of horn in place:

New Horns

Finally, a quick press on the horn button on the steering wheel... HORN!!!
Yeah, it is loud and the twintone sounds nice. I would like to try a few more times, but that will probably disturb the neighbours... hehehe..

Hosting WCF in WPF app

In an application that I am developing, I have encountered a problem when the WPF GUI freezes when a client access the services in the server. Both client and server are WPF applications and the service operations typically takes several seconds to complete. So, the server GUI became unresponsive when the client performs service operation calls to the server. After some investigation, I found that the default behavior for WCF is to use the default synchronization context for the current AppDomain for synchronizing client access. Thus, when it is hosted in a GUI application, it locks the UI thread too.

To disable this behavior, I have disable the UseSynchonizationContext switch in the ServiceBehavior attribute of the service implementation class.

[ServiceContract]
public interface IMyService
{
 [OperationContract]
 void DoSomething();
}

[ServiceBehavior(UseSynchonizationContext = false)]
public class MyServiceImpl : IMyService
{
 public void DoSomething()
 {
  ...
 }
}

Unfortunately, setting this flag to false also means I have to be extra careful with the golden rule of GUI and multithreading programming:

"Thou shalt only update UI using code that runs on the same thread as the UI."

Disabling UseSynchonizationContext causes WCF to process incoming client request using background thread. Thus, if we need to update the UI during the service operation execution, I'll need to use Dispatcher.BeginInvoke to marshal the call to the UI dispatcher thread to perform the UI update operations. For more information on multithreading and GUI, see this article from WPF SDK blog:
Thou Shalt Not Break the Golden Rule of Windows Multithreading. Or, Why the Dispatcher Rocks.