Updates to the DEMAND project

Yes, I haven't updated for a considerable while.  As usual, I am incredibly busy both at work and at home... yay academia! But those issues are for a different post.

What this post is about is that there are a couple of things happening regarding the DEMAND noise database:

• First off, DEMAND will be officially presented (by me) at the International Conference on Acoustics (ICA) 2013 in Montreal, Quebec!  Yay, I get to go back to what is effectively my home town and favourite city, paid for by Research money!
• More recordings have been made and will be added to the database - still some finalisation to be done, but then DEMAND v1.1 will be ready to go out into the wild!
• I'm in the process of building a second array since the original went with Emmanuel to Nancy.  While the basic layout will be the same, I will try to construct it with higher precision, given the knowledge acquired from the first round.

Blog updates (why it hasn't and why it will)

Ok, I admit this post has been spurred on since there is actually a comment asking "why hasn't this updated?", and how I decide to post an update anyways.  (I've tried twice to reply directly to the comment in the comments section, but blogger ate my reply... no clue why!).

Hmmmm, Arduino or Raspberry Pi?
Which one shall I play with?

The simple answer is that I put up a post a) when I feel I have something significant to post and b) I have time to post.  And lately I have been very busy, both with my work and in my personal life. In a very good way.

Yes, my last post was in October.  Since then there was an ICASSP deadline (result will be known end of February), an ICA deadline, and early March is the deadline for EUSIPCO. Last Monday we had a deadline for some internal documentation.  Oh, and since my Postdoc contract ends in July I'm hunting for a new job, which means I'm also spending time on applying places (and being interviewed already!)

In December we visited family in Maastricht (in the Netherlands) and Kitchener, ON, and experienced the joys of transatlantic air travel with an infant.  We even managed to visit Montreal for a few days around new years day.

But eventually I should get to play with my toys again.  Maybe even with some help :-)  In the meantime, I will post some stuff on my work results (esp. the DEMAND array and the ICA paper - which is on the DEMAND database).  Real soon now.

DEMAND: Diverse Environments Multichannel Acoustic Noise Database

It's official: our database of recordings with the microphone array described in a previous post is now active and can be found at http://www.irisa.fr/metiss/DEMAND/. Licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License, this is a large chunk of data - so much, we are only putting it on the website in one format, a zip file of 16 mono wav files for each environment.  My preferred format would have been to post it as 16-channel wav files (easier to work with in MATLAB, provided you have loads and loads of RAM) but that decision had to be made.

The original design called for 18 recordings, but one of those was too challenging to do proper around Rennes, and two were unsatisfactory after recording.  So, those will be left for v2.0.  Still, this is a far more diverse set that most other databases I know of - and with more channels.

So if you're into multichannel signal processing... have at it!

Wireless Serial on a Raspberry Pi

I don't have my Raspberry Pi yet.  RS has informed me of a delay - I guess the good news is I should be getting a Rev. 2 board.  In the mean time, a colleague of mine got his a while ago, but due to lack of time is letting me play with it.  I don't have time either, but I'm not letting me stop that!

So the first thing I did, not wanting to mess around with swapping monitors and keyboards etc..., was to hook up the Rπ to a bluetooth serial adapter I got off DX. ($8.60!, see also here)  It was trivial to hook up to the Rπ, but make sure to hook Vcc up to 3.3V! Otherwise, the TX line will probably output 5V TTL levels that could damage the Rπ input pin.  So, the hookup is, (adapter pin:Rπ pin) VCC: P1-01, GND: P1-06, TXD: P1-10, RXD: P1-08.

Software wise, there is not much to do either.  I left the adapter at 9600 baud; at some point I will send it the magic AT incantation to change that, but at the moment it was simple to just change numbers on the Rπ, all of which can be done on the SD card using another computer running Linux (in other words, the Rπ never needs to be hooked up to a monitor/keyboard).  In the boot partition, change the baudrates for ttyAMA0 to 9600, and in the actual real linux root partition, change the appropriate inittab line.  (details will follow - I don't have the board in front of me)

The biggest problem is the power.  As the Rπ (rev 1) does not have a halt or reset line, the bluetooth adapter will get power at the same time as the Rπ, so you cannot connect to it before the Rπ boots - on the Rev 2 board I think I could hold it in reset state until I've connected the bluetooth so I can monitor all bootup messages.  The other solution would be to give BT adapter its own 3.3V supply but that could also be dangerous for the serial input line of the Rπ.

LASERS! on (virtual) paper

Yay, another journal article! Ok, ok, I'm 8th author (out of 13 - quite the horde) but it's still good (besides, I wasn't able to contribute much after leaving Montreal). Kudos to Philip and his gang.  The paper was published in Analyst, a journal of the Royal Society of Chemistry; the article itself ("Demonstration of a plasmonic thermocycler for the amplification of human androgen receptor DNA") can be found here.  For reference this was the project I was playing with when I wrote this post.

In related news, the ICASSP 2012 paper (mentioned in this post) is finally in IEEE Xplore.  That took a while.  Now back to research to write a paper on my current research!

Panasonic HHC Schematics by Tony Duell

(TL;DR version: the scans are here)

Some years ago, I picked up a Panasonic HHC, having had an interest in the small hand-held BASIC computers for a while.  As it turns out, the HHC does not use basic at all, and is by default not really "open" in any way - there was a BASIC ROM available, but generally the thing was used as a specialized calculator with custom ROMs.  Still, It's a cute little machine with the interesting feature of using a 6502 inside, and it came with a printer that uses regular paper, and even the internal batteries still work.

Recently, there was a discussion about it on the Classiccmp mailing list, and Tony Duell - known for his classic computer electronics acumen if not his take-no-prisoners approach to typing emails - mentioned that he had traced out the circuits of this little machine.  This got me (and several others) interested, and he offered to make these available to the general public if someone would scan them and place them somewhere on the web.  The physical pieces of paper from Tony were scanned by Dave Colver, who in turn sent me the images.  I did a bit of cleaning up (nothing more than adjusting levels to remove some JPG compression artifacts) and collated them into a PDF document and you can download them from here: Panasonic HHC RL-H1400 Schematics.

Unfortunately, my HHC is at this moment a couple of thousand kilometers away, in a box at a friend's house in Pointe-Claire, Canada.  However, once I live in a place where I have a workshop again, I will mess around with it, for sure.  Dumping the ROMs would be a good start!

Real life interference again, of the best kind

A short time ago, life has become quite overwhelming, but in a good way.   To announce the reason, I sent a little bit of creative writing to my friends; I'll post it here with the personally identifying information masked out.

CHILD PROCESS (1)        THIEMANN FAMILY INFORMATION        CHILD PROCESS (1)

SUMMARY
     A child process with PID "------ ------ Thiemann" has been successfully
     spawned.  While the process is not yet ready for completely standalone 
     deployment, it operates within all expected parameters.
     
DESCRIPTION
     On --- -- Aug 2012 --:-- CEST, a child process was successfully spawned
     from two parent processes.  The new process was given a PID of "------
     ------ Thiemann".  All parameters are within design specifications, as
     are the parameters of the parent processes.  Note that the new process
     is not functioning as a completely independent unit yet, but relies on
     I/O processing by the parent processes; in particular, the flushed 
     output functionality is not yet present, and instead uses buffered
     output where the buffers are emptied by the parent processes.  Input
     is taken exclusively from one of the parent processes.  Furthermore,
     the self-diagnosis functionality is currently limited to a one-bit sonic
     indicator; if this indicator is activated, it is left to the parent 
     processes to determine if I/O needs to be serviced or if the current
     operating environment is incompatible.
     
     When not performing I/O, the new process spends a considerable amount 
     of time in the sleep state.  A visualization of the process is appended
     to the report, showing the interaction of the new process with its
     parent processes.
     
BUGS
     As of yet, no bugs have been found in the system that merit intervention
     by either the parent processes or the operating system.  However, it is
     expected as the process interacts with the greater system environment,
     some abnormal processing states may occur, but it is expected that the
     self-repair functions will be fully functional by that time.
     

I know the "thing to do" these days is to have a facebook page, twitter account, email address, etc. for a new kid set up.  Well, this kid's information will be off the net for as long as possible, until he is capable of understanding and deciding for himself.  But watch out world once he gets his hands on a soldering iron and/or a compiler!