En blogg om viktige ting

If you are familiar with Twitter and Gmail, there's no reason that you should not know about Linux. For long synonumous with geeky, ugly and difficult, it has over the past years evolved into something quite the opposite.

My reason for starting with Linux in the first place, was that I had harddrive problems - which in fact is quite common when you're using computers. However, the Windows (XP) tools available to do diagnostics and edit partitions, does not really exist. Say you want to shift some of the free space on the C: drive over to the D: drive, Windows cannot really help you out. Browsing the web for help, I found gparted - and even better - GParted Live CD. This Live option enables you to run programs and tools directly from a removable medium, without altering the system harddrive.

I then discovered that the GParted was actually launched from an operating system that was started from a CD. Linux. I was awed.

Ubuntu has been cheered the distro that took Linux to the masses. I started using this in 2008 before moving to Canada, so that I could access data back home. And since then I have truthfully upgraded home server and also desktop version of Ubuntu. Having a interest in web developing, I found the Linux desktop environment far more flexible in terms of connecting to ftp and ssh accounts, and seamlessly integrating this into a regular file browsing. There are of course downsides when it comes to available software, and trying to adapt your existing computer habits into a Linux experience. For years, Skype was terribly difficult to get to work with audio - and don't even mention video. Bluescreens doesn't exist in Ubuntu, but intense multimedia experiences - like Skype - may cause hang ups, then blackout, and eventually present the login screen over again.

Having used Ubuntu for years now, and even volunteered as a translator and in the end also as a translation administrator - the introduction of Ubuntu 11.10 forced me to make a change. And that for a number of reasons:

1. Unity - the new interface. For some reason, introducing something new seems to be the only way to display that something really works. Bottom line is, it doesn't. The pop-up "start menu bar" is far too slow, button effects tacky, and menus terribly unintuitive.
2. The new font. Ubuntu created their own font, which is used everywhere. And in the latest release, you don't even have the option to adjust its size. (This is not different from Fedora, though, but there the font is different and better suited)
3. One of the key applications for adding and removing software - Synaptics - had some serios troubles with translations in the previous release. I spent a few hours fixing this, as the application at this points was completely useless. It was fixed for a period of time, which was good. But amazingly, the problems reoccurred in the latest release.
4. Ubuntu One. This is a cloud sync software that can span across devices and OS'es. 2GB free, then you start to pay. The system itself is "ok", but is in my opinion too prominent throughout the system.
5. Software updates. Say there is a tiny change in a software, you would have to download the entire package again. With Fedora Linux, you download the changed code lines, and the software is "prepared" locally. Faster, more efficient, and way more elegant.
6. And for some reasons, things have started to run slow. Originally, Linux distros would "boost" your computer performance. I recently installed Fedora Linux on a removable drive, and this was actually running more smoothly than the Ubuntu running from inside the coputer. This was what finally convinced me to make the change.

And not to forget - Fedora desktop has a crisper interface and smoother animations. The whole experience is better, faster. Just the way Linux is supposed to be. Well, it does actually not support playing mp3's - but that's not a major problem, according to your favourite search engine.

Latest Fedora (16) was released just a few days ago. GNOME 3 is used also here, but in a far better way. Workspaces are not fixed, and applications are presented at a glance when clicking "super" button, or moving cursor to the upper left corner. Applications can then be moved from on screen or workspace to another, and applications are rearranged on the fly - smoothly.







Some recent experiences so far:

• When building software from sources, install "Developer tools" group first. But you may also have to remove old version of automake/autoconf, as they exist simultaneously.
• Install VLC from videolan.org. This will also provide repositories for playing mp3-files.

In the sequel "Get the most out of your Ubuntu home server" and "How to do cool tech stuff rather inexpensively", this topic is about using webcams, and starting and stopping them remotely.

You can get a webcam literally anywhere. It's fairly affordable, and they will most certainly connect through USB. And fortunately, that makes them compatible with any 10 year old hardware.

To use a webcam with, say, a Ubuntu computer, you would have to make sure that the webcam is UVC compliant (USB video device class). Quite often this feature isn't even marked as a feature on the packaging, so you need to actually plug it in to know that it works. Actually, most "cheap" webcams actually support UVC. There are lists online of webcams supporting UVC. Or you can just bring your handy laptop to the store, and try for yourself. Running this command while connecting should give you sufficient indications if the webcam is supported:

tail -f /var/log/syslog

The above command works in Ubuntu 11.04. Before this, "messages" was used, not "syslog". Anyways - what you're looking for is something like this:

kernel: [ 3102.392028] usb 1-1: new full speed USB device using uhci_hcd and address 18
kernel: [ 3102.677343] uvcvideo: Found UVC 1.00 device USB2.0_Camera (093a:2700)
kernel: [ 3102.686505] input: USB2.0_Camera as /devices/pci0000:00/0000:00:1f.2/usb1/1-1/1-1:1.0/input/input3

You can check that the cam actually works, by starting "cheese".

Next, we want to stream the video - that is, to be able to have a URL that we can connect and view the video. For that we need a broadcast server, and we also need to decide upon a video format. For the sake of cross platform compatibility, I would choose Theora as video format, and Icecast as stream server. These two components come from the same people - that is xiph.org, and therefore you can trust that these things work pretty well together. And best of all - Theora is supported natively on most browsers like Firefox, Opera and Google Chrome, meaning that you can playback the video literally anywhere, without extra plugins. Even on Android phones, which may use the Firefox Mobile application, which similar to its mother software also supports Theora.

Icecast is installed from Ubuntu repositories as usual. You will have to edit the config-file at /etc/icecast2/icecast.xml, to add passwords and your desired listening ports and so on.

To get the video from your webcam to Icecast, we need to do quite a trick. First we use ffmpeg2theora to encode the raw video from the webcam. Then we use oggfwd (ogg forward ) to push this to our Icecast server. A typical command line would look something like this:

ffmpeg2theora /dev/video0 -f video4linux2 --no-skeleton --inputfps 15 -v 5.5 -x 320 -y 240 --noaudio -o - | oggfwd -d "<your description>" -n "<stream_name>" localhost <icecast-port-number> <icecast-relay-password> <desired-url>

Remember that the video source (/dev/video0) must be readable (!), which it is not by default. Chmod usually takes care of this. You may tune ffmpeg2theora parameters, i.e the resolution and encoding quality. The above command currently works with a Clas Ohlson webcam.

You should make sure that you have some way to toggle the streaming video. This can easily be done with a php script, launching a shell script like this:

exec('nohup sh stream1.sh > /dev/null 2>&1 &');

You may also add a detector to see if the script is actually running, by this command:

$p = exec('ps -ef | grep oggfwd',$out);

$is_it_really_running = (strpos($out[0],'<part-of-stream-name>') > 0);

That's it! Universal video surveillance made affordable and robust.

(You may also look into udev scripts, to make sure that the video source /etc/video0 is readable at every reboot.)

I believe every engineer (legally entitled or not) should spend some time on research. When I first discovered the USB devices from Phidgets last fall, I realized that my very own research budget seemed destined to increase.

And having successfully built a remotely controlled LED-system using the Interface kit, I figured literally anything would be possible.

I recently acquired my first apartment. So, as I was told the entire apartment could be heated with a single fireplace and a small electric floor radiator, I quickly decided to look into temperature monitoring the rooms. This would be rewarding both in accomplishment, but it will probably also play a role in smarter heating (and hopefully heating cost savings). The core of the system will as always be the trusty Ubuntu server, and most likely the beforementioned Phidgets interface kit. But the most critical components, not to forget how to put it all together, were still unknown.

Browsing the catalogue, I quickly found that Phidgets has a 4-port temperature sensor. And having some knowledge in temperature instrumentation, I were able to find the right thermocouples and extension wire.

So - at this point, I knew I could get the necessary equipment to get it all up and running. Still, this wasn't all:

1. The system shall record temperatures in several places (rooms).
2. The instrumentation shall not be visible.
3. The data must be recorded.
4. The data must be recorded several times every hour, and must run from a cron script.
5. The recorded data has to be presented. If not, the effort will be all wasted.
6. The system must be as affordable as possible.

Point 1 is covered by just buying enough thermocouples, but is on the other hand limited by the latter point - the cost. Point 2 is a challenge, as wires has to be pulled to spots were it makes sense to measure the temperature - preferably shady areas with access to circulating air. Point 3 involves some kind of database, most likely mySQL. I were depending on finding bindings between Python and mySQL, as the temperature extraction script most likely would be written in Python. Fortunately, Ubuntu has this already in repositories. Point 4 involves a cron script. Cron is always messy, but the GNOME Schedule application makes it a little easier to set up. Point 5 is the final part, but makes it all worthwhile. Point 6 is a prerequisite, as this project doesn't make sense if it costs a huge amount of money.

I might add, the temperature monitoring is interesting for several matters. In Norway, as with other Nordic countries, there is a serious concern that piping and plumbing may freeze over and create massive leaks. By always being able to check the indoor temperature, it may be possible to allow colder temperatures indoor if one should be away for longer periods of time - and still be able to react if temperatures should drop. Secondly, monitoring temperatures may reveal areas/rooms with high heat leakage.


Having spent quite a few hours wiring up the server and the thermocouples, the measurements started pouring into the database. I confronted the Phidget staff on connecting to the Temperature reading device as frequent as every 10 minutes, but they didn't have any major concerns with this:

I don't see there being a downside to this. If you were looking to
get the temperature data in 10 minute intervals that would certainly
be one way to do it. A cron job that launches a simple application
that will poll the data and store it somewhere.

You could also just have an active running service that simply polls
the value and stores it based on a timer as well, but I haven't done
services using Python so not sure how that works exactly.

-Adam

I specified 4 ciphers and 2 decimal digits for the temp readings, and currently have about 4,400 X 4 readings taking up 126KB space.


The final part was to create some kind of service for mobile devices. This sure might get improved on a later time, but currently holds 3 diagrams:

1. A 3D model of the apartment, with current temperatures plotted.
2. 24 hours plot
3. Week plot

The first diagram is solved using the internal capabilities of GD. The two latter ones are created using latest version of jpgraph, which actually where a whole lot more complicated than first expected. Thanks to Maxiwebs for providing a php5-gd compiled with imageantialias() support.




Most of the thermocouples are mounted quite close to the ceiling, which introduces readings that are quite off the actual temperature mid-room. I tried to come up with a clever correction to this, but I'm at the moment using only a linear correction based on a separate temperature reading. I have however attempted to find correlations, logging temperatures mid-room with a separate thermocouple (extension wire standing at the floor):


Several ways to correlate the data were attempted. None were working as well as I had hoped for:



Using the plots, it is possible to identify at least one room which has issues regarding severe heat leakage - the bedroom. Here the temperature shows to drop by 2 degrees in a mere hour - far worse than any of the other rooms:

This tool is now available online: www.versati.no/mesher/

OpenFOAM is an excellent tool to perform accurate CFD studies. The software also has its own mesh language – making it possible to create simple geometries, fast, without an extra meshing application.

For larger meshes, this format becomes difficult and almost impossible to use efficiently. Still, this blockMesh format is a sought after alternative, as it produces only hex cells, and block volumes can be specified for every edge, in terms of expansion and number of cells. It can also create perfect transitions between (curved) edges.

To investigate flow in bends and diffusers, I have created automated routines to create this kind of meshes – also incorporating O-grid to avoid singularities in pipe centre. The mesh routines are completely parameterized, producing meshes in mere milliseconds – with full control of all mesh parameters.

These routines are completely module based, making it possible to add straight sections as well as bends, and diffusers.

One set-up could be like this:

$block[] = array(0,1,45,3);
$block[] = array(4,0,0,0);
$block[] = array(0,-1,30,0.4);

The three "blocks" produce first one 45 degree bend to the right with radius 3m, then a straight 4m long pipe section, and finally a bend turning "left", 30 degrees with radius 0.4m.

And this is how it all started:

I disse miljøtider er det poppis å vise til små tiltak som begrenser utslipp, reduserer footprint og generelt viser at vi har et uavbrutt fokus på å bedre det rundt oss. Vel, hva er vel da mer riktig enn tiltak for å unngå å kaste selv det mest slitte møblement?

Men det holder ikke liksom å bare male over råtnet treverk i det uendelige. Dårlig vedlikehold, eller kanskje bare slitasje, medfører at man til slutt må gjøre vesentlig mer drastiske tiltak, som å bytte deler. Dette er jo ikke ulikt det man gjør med en sykkel, bil eller annet mekanisk utstyr. Mindre vanlig er det kanskje med møbler.

Men dette er heller ikke et hvilket som helst møbel. "Balans" som stolen heter, fra 1979, fikk riktig nok merket for god design allerede i 1986 - men var i første omgang en hyllest til korrekt sittestilling. Først i senere tid har det blitt mer et designmøbel enn funksjonsmøbel.



Denne stolen, som jeg har kjent i hele mitt liv, bærer nå preg av tidens tann. Den ser ikke spesielt stilig ut, og frister egentlig ikke å brukes i det hele tatt.



Etter noen runder med e-postkorrespondanse med Inside Design, ble flett nye seter bestilt, i et ganske så slitesterkt materiale. Og best av alt - den ble levert under to uker senere.