I’ve ran into this technology a couple of years ago when I coded a desktop application to communicate with such a device. So I wasn’t really involved in designing the parts external to that.
A couple of weeks ago I decided to try the real deal and implement something inside the AVR controller. Since I wanted to do something that is actually useful, I decided to make a digital thermometer.

At first I searched for some temperature sensors and it seems that there are many options in that area. So I had to do lots of digging to find out what would best fit for such solutions. In the end, I found out that there are both sensors and AVR controllers supporting the I²C two wire interface. No, I didn’t have a clue about what that was before starting this. In fact I admit learning lots of the electronics basics with this project.
Based on I²C is how I got to my winning candidates: ATmega168 and the DS1621 sensor.

Obviously, the other part of the problem was getting the information displayed. I was aware of the (most obvious) options in that area from the beginning: LED display or LCD display. I knew that using an LED display will either use up my controller pins or force me to use some shift register to expand the number of outputs. Since I wanted to keep it simple I opted for an LCD device. I bought one that is a lot larger than necessary, but only because I also plan to use it for some other purposes.

This is how the whole thing looked like in it’s final phase.

No, of course the board is not something I built. It’s the STK200 AVR starter kit from Kanda which is also an AVR programmer.
I know how the whole thing looks messy, but I didn’t spent time in making it compact since that was not the actual purpose.

The TWI and the LCD interfaces didn’t seem impossible to code since it’s pretty standard and well documented stuff. But since I am a complete rookie on this, I didn’t want to spend too many nights re-inventing the wheel when there are lots of libraries taking care of the low-level communication. So I used Peter Fleury’s LCD and I²C master libraries to handle the low-level protocols.

What I did have to clarify in detail though (even if it was fairly light) was the DS1621 specs where each of the commands and expected results are described. This however was the part that I found the most attractive and I believe that in general these are the parts that are worth the trouble: at a certain level of specs, you get the detailed description of what bits you have to wire and what you get back. No questions asked – (almost) always works as specified.

Once I’ve put all the pieces together and managed to display the actual temperature value, I had to somehow validate the output. Not that there is much to do about it. The thing is that if you managed to read some value from the sensor it usually means that you did your part of the deal and an error in the actual numerical value is (probably) not something you caused. This was however not the case since I have a multimeter that also does temperature measuring among other things.

Yeah, I know, my place is pretty warm. In the winter I sometimes overreact with the heating. Anyways, the DS1621 also has an 0.5 degree error (at least that’s the spec value), as for the multimeter’s sensor I have no idea. Bottom line is that is good enough so I’m a happy panda.

I didn’t spend the time to draw the schematics of this, but if you are really interested drop me a note and I can send you some summary of what exactly is to be done.

It took me a while to learn everything since this doesn’t quite work like “learning a new framework for the platform you know for years”. But it’s definitely interesting and it’s definitely a new level of geekness for me. Fuck yeah.

Usage

1. Running the script with no arguments – will result in scanning the current directory recursively for .class files. The results are grouped by directory and a total number of files is also displayed. Directories that do not contain any .class files will be ignored, in order to keep a clean output. Below is a short sample.

cosmin@cosminaru:~/work/quizine$ bcversion.pl

* /home/cosmin/work/quizine/src/main/webroot/WEB-INF/classes/org/quizine (2 files)
	QuizineException.class -> 1.6
	ApplicationContext.class -> 1.6

* /home/cosmin/work/quizine/src/main/webroot/WEB-INF/classes/org/quizine/web (2 files)
	ErrorHandlerFilter.class -> 1.6
	SessionContext.class -> 1.6

* /home/cosmin/work/quizine/src/main/webroot/WEB-INF/classes/org/quizine/web/actions (1 files)
	ActionBase.class -> 1.6

2. If you provide one or more arguments, the script will only scan the content of these arguments. If the argument is a file then the byte code version is displayed for that file. If it is a directory then it will be scanned recursively, just like above.
Note: The paths from the argument list should all be relative to the current directory in order for the script to work correctly.

cosmin@cosminaru:~.../model/quiz$ bcversion.pl AbstractQuestion.class result
* AbstractQuestion.class -> 1.6

* /home/cosmin/work/quizine/src/main/webroot/WEB-INF/classes/org/quizine/model/quiz/result (5 files)
	QuestionnaireResult.class -> 1.6
	BooleanAnswer.class -> 1.6
	AbstractAnswer.class -> 1.6
	SingleChoiceAnswer.class -> 1.6
	MultipleChoiceAnswer.class -> 1.6

I’ll probably want to scan JAR files and directories containing JAR files. But the really poor Perl docs for reading ZIP buffers didn’t quite help me. If you think think you can give a hand with that, drop a note .

Download:

You can get the script from here.

Fortunately, BNR also provides an XML with the exchange rates for the most important currencies in a manner that is very easy to understand:

...
<Rate currency="DKK">0.4926</Rate>
<Rate currency="EGP">0.4291</Rate>
<Rate currency="EUR">3.6747</Rate>
<Rate currency="GBP">4.6020</Rate>
...

Luckily, Perl knows how to parse XMLs so we’re almost good to go. Now I am not Perl expert, nor want to become one very soon, but this sounded like something doable with a minimum amount effort.

What we need is to get the XML with an HTTP request, parse it and convert the given amount of money using the desired currency. So I created a tiny script convert2ron.pl that accepts two parameters: the currency identifier (EUR, USD, etc.) and the amount to be converted. I will not go into the details of how this script works as it’s pretty straight-forward (even for someone with a minimal understanding of Perl). So now I can convert all sorts of currencies to RON using calls like this:

$ ./convert2ron.pl EUR 245


and get results like these:

245 EUR = 900.30 RON

(rate is 3.6747)


Is this the geekiest way to do this, or what? And the geekness doesn’t stop here. Now I also have some scripts like eur2ron.sh and usd2ron.sh so I can do stuff like this all day:

$ eur2ron 456

So, if you want to convert international currencies to RON the geek way, here’s the download: http://cosminaru.ro/downloads/ron-convert.zip.