DIY musical doorbell

A doorbell is not the most important equipment of a home, however it is necessary and it still matters in a way. It is the thing that makes the first impression of your home to any visitor. The standard school-bell type doorbells hurts the ears and freaks out everyone who dares to touch the button and anyone who is unfortunate to be home at the time. A musical doorbell can be really expensive and the sound of the cheaper ones are simply annoying. Why not try to build one at home?

Hardware

It can be easier than it seems at first glance. Almost every part of it can be found in the drawer of an average hardware hacker:

Any speaker scooped from an old PC
A cheap MCU
An NPN transistor
An 1K resistor
Optionally a potmeter for volume control
4 diodes
2 capacitors
An 5V linear regulator (L7805)

The theory of operation is really simple: the MCU drives the speaker with a square wave on an arbitrary frequency to make a sound. Because the MCU usually cannot bear high current enough to make it loud, a transistor is used to drive the speaker.

The power source may be a standard bell transformer, which makes 12V AC from the 230V AC. In my case it was given as in our apartment building there is one generator for more apartments. To provide a stable 5V for the MCU, a simple Graetz-bridge can be used along with a linear regulator.

Doorbell schematic (https://www.circuitlab.com/circuit/3x9m3u/doorbell/)

Software

The software part is just as simple. The first problem is to make the proper frequency for the square wave output. The simplest approach for this is to use a timer integrated into the MCU, and toggle the output on the timer interrupt. Now the frequency can be set by the timer options.

The other task of the MCU to switch the settings of the mentioned timer after a time to make a series of sounds. I’ve used another timer to interrupt in every ~0.2sec, which decrements a counter to determine the delay for the sound. If the counter reaches zero, the new timer settings and delay counter are loaded from the program memory tables.

Calculation of timer settings

The music you want the bell to play, is a series of sounds with determined frequency. This must be converted to a series of timer settings. For the PIC16F1824 I’ve used, this settings includes the compare register value along with the pre- and postscaler settings. To determine the best settings for each sound frequency (best = real frequency closest to nominal within the available set of register values) is a straightforward task, but requires a lot of calculations. It is much easier to write a script that makes all the calculations and generates the proper code tables for the program. This way it is easy to change the music to whatever you want.

Finish the bell

All is left is a bit of soldering and putting it in a suitable box:

https://lh5.googleusercontent.com/-bCo7Z1mv3Jo/UBps6axVuLI/AAAAAAAAL00/Du4SNKyLdjg/s640/IMG_1373_cut.JPG — The finished doorbell

References

Code hosted on github: https://github.com/gbalage/hobbyelectronics/tree/master/pic.bell
MODembed: Model-based IDE for embedded development based on eclipse http://gbalage.github.com/modembed/

Java primitive type comparison – A wat look

Not long ago, we had a not too nice issue related to mismatch between int and long variables. As the concrete variables were coming from 1) a model created by others and 2) another model created by us, the solution did not appear to be simple.

We were thinking, if we could compare the variables by value consistently without the concrete type equality, we would not need to support both int and long numbers in our model, so we asked our collegue, Gábor Bergmann to experiment a bit with the comparison.

Sadly, the result is that there is no reasonable way to compare longs and integers by value. However, we found a truly nice wat moment, almost fitting to the issues presented by Gary Bernhardt in a talk called WAT at CodeMash 2012 (or instead of the video, you could have a look at http://www.shopify.com/technology/5370262-wat-a-funny-look-at-ruby-and-javascript-oddities).

Because of Java is statically typed, most inconsistencies of Javascript do not apply here. However, the implicit contracts of Java are sometimes broken, just as the following code snippet shows (it is Gábor’s work entirely, I only changed only the white spaces):

public class IntLongWat { public static void main(String[] args) { System.out.println(new Integer(1).equals(1)); // true System.out.println(new Long(1).equals(1)); // false, it only equals 1L - so much for semantic equivalence System.out.println(new Integer(1).equals(new Long(1))); // false... Y U NO EQUAL? // although System.out.println(new Integer(1) == 1); // true System.out.println(new Long(1) == 1); // true... WAT? they are == but not equals() ? // so then, transitively... // System.out.println(new Integer(1) == new Long(1)); // COMPILE ERROR... CLEVER BASTARD Object oInt = new Integer(1); Object oLong = new Long(1); System.out.println(oInt == oLong); // false, of course - so much for transitivity } }

Basically, when comparing primitive types and their boxed values, if you have two different types, all hell’s might break loose. Sometimes two values are considered equal when using ‘==’ but not when using Object.equals. Even worse, transitivity can also be broken.

I cannot think about any possible reason for this behavior, but we could reproduce it issue consistently across different computers using Java 1.6, so this appears to be according to be designed that way.

If someone could provide some reasonable explanation, I would be glad for it. Then we could learn something nice instead of just laughing a bit. Otherwise, be careful with primitive comparison…

Multitouch gesture support for Zest graphs

When I read Jan Köhnlein’s post about multitouch gestures support in their graph viewer, I was thinking, these gestures would be a nice addition to the Zest visualization library. In addition to that, it could be my first new feature as a Zest committer, so I opened bug 371152.

So I looked into the multitouch API in SWT (btw. it is really to use, check snippet 353). Luckily, only a gesture listener had to be added, that is already supported by the Zest graph widget.

I thought about what gestures could be universally supported in the Zest graph, and found that scrolling is already supported, magnification is easy to implement, and for rotation I found a possible use.

Today, I finished the implementation, and created a short video presentation that shows the features in action. See the Youtube video: http://youtu.be/cVVxOIwHN7s

Additionally, it is possible to replace the built-in gestures by creating the graph with a specific style bit, and adding other gesture listeners manually as below:

//Disabling default gestures
Graph graph = new Graph(parent, ZestStyles.GESTURES_DISABLED);
//Adding own gesture listener
graph.addGestureListener(new GestureListener() {

  public void gesture(GestureEvent e) {
    switch (e.detail) {
      // Do nothing
    }
  }
});

I believe the base implementation of the gesture support is useful, but I am open to change it if someone has a better idea.

Reflective tree editor for Xtext-based languages

Xtext is a great technology. I really mean it. After 15-30 minutes (depending on your previous domain knowledge) you can get a really fancy textual editor, that parses your text into an EMF model. Xbase is even better: you can simply include Java-like expressions into your language, that can be easily translated into pure Java code.

However, while using Xtext I found some minor “paper-cuts”. One of the most problematic of them was the fact that I cannot open my textual models using the Sample Reflective Ecore Model editor, as I get an exception: java.net.MalformedURLException: unknown protocol: java.

A similar exception occurred if I tried to open the files programatically (but without the help of the generated Xtext editor). When I asked in the Eclipse forums how to open Xtext model files programatically, I was answered (btw. very quickly – kudos for that 🙂 ) that a specific ResourceSet implementation is needed that refers to model files and classes available in a Java project.

This gave me the idea to create an Xtext extension that allows opening an EMF tree editor, the Xtext Reflective Tree Editor. The plug-in consists of two parts:

An extended version of the org.eclipse.emf.ecore.presentation.EcoreEditor class, that opens its ResourceSet using the Xtext API (more specifically, uses an injected ResourceSet);
And an Xtext generator fragment, that can be used to generate a new editor extension to the ui project (with the corresponding dependency added to the reflective editor plug-in).

Usage

To use the plug-in, just follow the following simple steps:

Add hu.cubussapiens.xtext.reflectiveeditor as a dependency to your language project.
Extend your editor generation workflow:

Import the generator package: import hu.cubussapiens.xtext.reflectiveeditor.generator.*
Add the new generator fragment at the end of the generator (file.extensions is the list of file extensions defined in the default workflow):
fragment = ReflectiveXtextEditorFragment { fileExtensions = file.extensions }
Regenerate your language.

Unless the plugin.xml files are updated automatically, you have to copy the newly generated editor extension from the end of the plugin.xml_gen file of the ui plug-in to the plugin.xml file. The simplest way to do this is to select both files, and open the compare editor from the popup menu (Compare with/Each other…), the copy the changes manually.
Finally, open the runtime workbench, and open your textual model files from the popup menu using Open with/«LanguageName» Reflective Editor. The result should be similar to the screenshot below.

xtext-reflective — The Xtext Reflective Editor

In my case, the editor shows both the domain model generated from the file directly (the Pattern Model element), the inferred JVM model classes (the various JVM Generic Type instances), and also the referred Java classes as external resources (the resources beginning with the java:/ URIs).

Download

If you are interested in the plug-in in action, download it from our update site: http://eclipse.cubussapiens.hu, or take a look at the repository on Github: https://github.com/ujhelyiz/xtext-reflective

Version 0.5.3 is already available, and hopefully works well for all languages.

Applications of high-performance model queries @ OMG/Eclipse workshop

At the last EclipseCon Europe, my collegue, István Ráth presented our incremental model query approach in the Modeling Symposium. Since then, we are working hard to evaluate further uses of the technology while creating a better tooling support for the specification of those queries.

This year, during the OMG/Eclipse workshop a day before EclipseCon 2012 István will present our approach together with our new results:

14:35 – 15:00

High performance queries and their novel applications

István Ráth- Research Associate, BME

High-performance model queries are still a major challenge for the industry standard Eclipse Modeling Framework (EMF), they are intensively used in various model validation, model transformation or code generation scenarios. Existing EMF-based query technologies (like Eclipse OCL, EMF Model Query 1-2, or native Java programs) can have significant scalability issues for complex queries of models over 50-100000 model elements. Moreover, it is often tedious and time consuming to efficiently implement EMF-based queries manually on a case-by-case basis.

Recent initiatives, such as the EMF-IncQuery framework (http://viatra.inf.mit.bme.hu/incquery) have proposed innovative algorithms to mitigate this issue. EMF-IncQuery uses a graph query language, and provides incremental query evaluation by caching the results of the model queries and incrementally maintaining the cache when the underlying EMF model changes. Furthermore, the EMF-IncQuery framework can be easily integrated into existing EMF-based applications in a non-intrusive way.

In the first part of the talk, we overview the results of a thorough benchmark comparison
intended to aid software engineers in picking the best tool for a given purpose. The measurements involve several versions of Eclipse OCL, manually optimized Java code, dedicated academic query and well-formedness checking tools and EMF-IncQuery and highlight the most important practical considerations of queries in model-driven tool design.

In the second part of the talk, we briefly overview novel and innovative uses of high performance queries such design-space exploration, whereby traditional modeling is augmented with AI techniques to aid the (semi-automatic) optimization of model-based software designs.

If you are interested in modeling techniques, I recommend attending to the talk. As a teaser, I show now an existing application of such AI-based techniques: an automated quick fix generation for domain-specific modeling languages. We already presented this technique, albeit based on the VIATRA2 transformation framework in VL/HCC 2011. The article, together with a video demonstration is available from http://dx.doi.org/10.1109/VLHCC.2011.6070373

For interest, the video demonstration is also uploaded to Youtube for easier watching. (UPDATE: For feed readers the video url is the following: http://youtu.be/kPc4x01K7-s).