Sunday, January 22, 2012

Apple netboot

I tried updating an old Apple macbook (this one) to Mac OS Snow Leopard. I lost my install DVD a long time ago, but I did have an image of it.
First, I tried fitting the DVD image to a single layer DVD-r. I managed to do so, but it wouldn't boot. Next I tried booting from an IDE disk with the contents of the image via USB, it booted but hanged while starting the OS.
So there was one thing left to try: netbooting!
I once noticed this 'Remote Install Mac OS' in Applications/Utilities. So I started it, clicked through the menu and fired up the macbook in netstart mode. I don't know what this application does, but it doesn't even respond to DHCP / BOOTP. Maybe this does work for newer macbooks, but it doesn't work for this one. Googling away, I found some guides on how to use a Mac OS server as bootserver, but I don't own one. You can, however download the server package which contains the 'System Image Utility' (go to support.apple.com and look for 'Server Admin Tools'. This, together with a linux box, finally allowed me install the macbook.
On the linux box, you will need apache, tftp and dhcp.
To setup the image, mount the disk image and start the System Image Utility. Select netinstall, next, create. When done, copy the files in '/Library/NetBoot/NetBootSP0/xxxx.nbi/i386/' (xxxx being the name of the created image) to /srv/tftp/macnbi-i386/ on the linux box. Copy the dmg file to your webroot.
Now, setup DHCP with this config:


class "AppleNBI-i386" {
match if substring (option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386";
option dhcp-parameter-request-list 1,3,17,43,60;
if (option dhcp-message-type = 1) { option vendor-class-identifier "AAPLBSDPC/i386"; }
if (option dhcp-message-type = 1) { option vendor-encapsulated-options 08:04:81:00:00:67; }
filename "macnbi-i386/booter"; # the kernel to boot from
option root-path "http://xx.xx.xx.xx/yyy.dmg"; #xx.xx.xx.xx being the IP of the web server and yyy.dmg the name of the dmg file
}
allow booting;
allow bootp;

 

Friday, December 02, 2011

Setting up a driver as dkms in Debian 6

So I have this weird intel 4-port network card. It uses the igb driver. Now after switching from Ubuntu to Debian 6, I could not get any traffic over the ports. It seems the version delivered with Debian is too old to correctly support my card. So I decided to add the current driver, which can be downloaded here, as a dkms package. This means that the driver is automatically recompiled every time the kernel is updated. Here's how I did this:

  • first prepare the driver source. In this case, the tar.gz contains a src directory, so I moved everything from the src directory to the main directory: cd igb-3.2.10; mv src/* .
  • next, we need a dkms.conf file (place this inside the source code's tree), here's mine:
    PACKAGE_NAME="igb"
    PACKAGE_VERSION="3.2.10"
    CLEAN="make clean"
    BUILT_MODULE_NAME[0]="igb"
    DEST_MODULE_NAME[0]="igb"
    DEST_MODULE_LOCATION="/updates"
    AUTOINSTALL="yes"
  • from the directory where you extracted the source (and added the dkms.conf file), execute the command to 'add' this source as a dkms:dkms add -m igb -v 3.2.10
  • now build and install the source: dkms build -m igb -v 3.2.10; dkms install -m igb -v 3.2.10
  • finally, create the dsc and the .deb file: dkms mkdsc -m igb -v 3.2.10 --source-only; dkms mkdeb -m igb -v 3.2.10 --source-only
  • now we need to install the dkms on the local machine. But before we do that, we need to remove the created dkms from the system as it conflicts with the created package. mv the .deb file and install it: cp /var/lib/dkms/igb/3.2.10/deb/igb-dkms_3.2.10_all.deb ~; rm -r /var/lib/dkms/igb; dpkg -i ~/igb-dkms_3.2.10_all.deb

 

msp430-rf2500 & linux

I bought the msp430-rf2500. A development kit for the msp430 with a wireless 2.4 GHz transceiver. This is an USB programmer with 2 development boards containing an msp430F2274 microcontroller and a CC2500 transceiver. The USB programmer allows to communicate with the UART in the msp430. Under Windows this works fine. Under Linux however, it does not.
After searching high and low, I found a way to successfully connect to the UART without issues. I did this using Debian 6.0.3, kernel version 2.6.32-5-686.
Here's how:

  • disconnect the development board from the USB programmer
  • put the USB programmer (only the programmer!) in the USB port
  • use dmesg to find the device that it registered (/dev/ttyACM0 in my case).
  • now type (replacing ttyACM0 with the device name you found earlier): stty 9600 -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke -F /dev/ttyACM0
  • next open the port and start reading from it (for example using minicom, or cat /dev/ttyACM0)
  • and NOW you can put the development board in.

The issue seems to be that the UART is flooding the ACM device, which then decides to disconnect.
Happy hacking!


 

Wednesday, February 02, 2011

*NEW* Now with less functionality!

I use a single linux box as a router, HTPC and storage server. I use XBMC for my HTPC needs which I control with an ancient MCE remote (1039). I don't use this remote much, as I mostly use the web GUI. I noticed some days ago that the remote didn't function anymore, or actually only the arrow buttons worked. After much swearing and looking for reasons I found that:

  • This was since the first reboot since I upgraded to Ubuntu 10.10
  • I could stop lirc and still have the working arrow buttons
  • irw did not echo anything on button presses

It seems this is all caused by a new driver that's included with 10.10. The mceusb kernel driver. Lirc used to make use of lirc_mceusb. I found this forum thread stating this. I also found some complaining about the state of the kernel driver in ubuntu on the lirc mailinglist.
So I figured it would be best for now to fall back to the old driver which did work correctly. Doing this is quite easy, as explained in the forum thread:

  • add 'blocklist mceusb' to /etc/modprobe/blacklist.conf
  • install lirc-modules-source which contains the old drivers
  • change /etc/lirc/hardware.conf to load lirc_mceusb instead of mceusb
  • stop lirc and unload all related modules (lsmod|grep -e lirc -e ir)
  • start lirc and test functionality with irw

 

Sunday, October 03, 2010

Color management

This article is a work in progress, I'll add stuff as I learn

I'm trying to get my head around color management. I own a Nikon D90 and I publish my pictures on Flickr.com. In between, there's a macbook pro with led screen that I use to edit my pictures with. So there's 3 devices (camera, laptop and the screen of the visitor to flickr) with all their variables to manage. I want to be able to take a picture, edit it and make it look natural and correct on most screens.

Between each 2 devices, there is a resulting picture. I think that it's important to make sure that the resulting picture is as 'perfect' as can be in regards to the color and light distribution.

Let's first look at the variables.

White balance
This is the color temperature, or the color that is used to display 'white'. It's expressed in Kelvin (K) or by standard (D50, D65). Some well known values are:
  • 1850K
  • Candle flame
  • +/- 2700K
  • Light bulb
  • 5000K / D50
  • Horizon daylight
  • 6500K / D65
  • Daylight

Now for the devices.

The camera
A camera doesn't see colors, it has to guess them. If the cameras white balance is set to auto, it does this by looking at the average color and defining that as 18% gray. If you use a preset, you are telling the camera what temperature 18% gray has. A third, and most exact, option is to photograph an 18% gray card and telling the camera to store that as a preset (custom white balance). Note that the 18% might be 12% or 13% with some cameras as read here.
So what happens if you make a picture where the average isn't 18% gray? The white balance will be off and the colors wrong. Think about orange street lights for example, or snow. These things change the average a lot and cause wrong colors.

So what to do? Best is to take a gray card with you and make pictures of it before every change of scene or light, but which amateur does that? Hence the need to post-process images...
This isn't a very difficult thing to handle though.. as it's one single white point you have to change, the rest of the colors slide with it. Many software programs can help you here, for example by letting you set a specific part of the image (like a gray wall) as average gray.

Another issue with a graphics device is the sensitivity for each color. This is never 'straight'. A camera might, for example, be more sensitive to red and thus assigning higher values to this channel.
To solve this, or better: adjust to this, color profiles exist. Each camera/lens combination has it's own little abnormalities which can be described in a color profile. This profile is then used by the post-processing or conversion (in case of RAW) software to adjust them. You can easily make such a profile yourself by photographing a standardized color chart and using software like argyllCMS to build a profile from it.

Last part is the color space used. This defines what the values that are recorded actually mean. In other words, how red is 50% red? The most popular color space is sRGB, this is what all browsers use as well. Some browsers are capable of reading a color space definition that is packed with an image (some firefox versions, chrome, Safari). But best is to not trust that and go for the standard sRGB. Adobe has a derived definition, AdobeRGB which allows for brighter colors. When a picture using this definition is viewed on, for example, Internet Explorer, it looks flat due to the mismatch with the assumed (by IE) sRGB.

So now we have a picture that has correct white balance set (or a least a way to fix it) and with the color values calibrated and defined. On to the next stage...

Post-processing
Most important to start with is to make sure we don't change the color space or white balance (color temperature) due to wrong settings. It's ok if you want to change either of them, as long as you do it on purpose. If you edit in a different color space for example, you will be bound to work in the space that's available in both. So if you photograph in a space with bright colors but edit in one with less bright colors, you loose the bright colors but ALSO the dark ones as they were not defined in both.

Then, if you want to change the colors or light levels, you need to make sure that what you see on the screen is correct.
First of all the color temperature. A computer with a screen is somewhat the reverse of a camera. The computer doesn't know by default what white balance the screen has. CRTs for example have a color temperature of around 9300K, while most laptop screens have below 5000K. A 5000K screen viewed with 6500K set looks reddish for example.
Second, there are sensitivity issues as well, a screen never displays the same brightness for each color at the same value, just like a camera is capable of capturing each color with the same brightness into the same values.
In order to adjust for these issues, we need to profile and calibrate. The profiling will tell you what color temperature your screen has, so that you can choose one that's close and use that in your software and calibrate for it as well. The calibration will display patches of colors on the screen to be measured in order to see the differences in color level. All this is then stored into a color profile (.cal) file.
When loaded into the operating system, and with the color temperature set in the editing software if applicable, you can be sure that what you see is what you get.

Of course on this level we have color definitions as well, so be sure to use the same one you chose before, in your camera.

A computer screen also needs a gamma setting. This is the graph that defines how a screen goes from dark to bright (which is never just linear). I find it best to get the value from my profiling software and feed it to the calibration software. That way I'm sure I see the correct distribution of light within a specific contrast.

 

Sunday, July 04, 2010

Tube preamplifier with RIAA network

I'm building a preamp kit with JAN6418 tubes (order here).

Day 1 20100702

I received the package from Oatley. After verifying the contents I found that I received 2 resistors of 170KΩ instead of 180Ω, and 4 capacitors with a max voltage of 25V instead of 35V (in a circuit of 30V). The diode delivered was the wrong type and size as well, as were some C's.

Day 2 20100704

I've soldered most of the components on the board. I need to buy some components that were wrong or missing and I need to measure the gain of the tubes to decide where to place which.


Labels:

 

Friday, September 18, 2009

Linux analog surround on a GA-E7AUM-DS2H

This took me quite some effort while it's actually very simple. So let's share this, shall we? :D

  1. Install the latest and greatest ALSA stuff (script)
  2. Make sure you don't have any /etc/asound.conf or ~/.asoundrc laying around
  3. Use alsamixer to do the following settings:
  • Unmute everything! (using m)
  • Mute all S/PDIF (not really necessary, but won't hurt)
  • Set channel to 6 or 8
If you don't use your TV as center (why not?), you're done. If you do, and have it connected using HDMI, you need to alter the EDID it gives to X. This is because your Nvidia driver will give it an empty pcm stream causing your TV to not accept analogue audio any more. You can read about this flaw here.

Now test your setup:

speaker-test -Dsurround51 -c 6 -twav

If you are using Xbmc, you might want to change the 'default' audio device to 'surround51' or 'surround71'.

Labels:

 

Tuesday, June 19, 2007

The road to espresso perfection

After having used my Silvia for some weeks, I knew it was time for the next step... A grinder. After all i want my espresso to be perfect, which actually starts with the beans, but roasting is still a step too far for me.
I went back to the koffie cultuur centrum in Amsterdam for some advice, and a
grinder of course. This time I was helped by the even older man (sorry, you asked for it). After a quick chat I decided to by a Rocky, how surprising ;o)
I got the machine together with a big bag of beans to begin with and left after a nice chat and persuading another customer into the Silvia ;)
After having set up the machine at home and finding the right grind setting, I can honestly say it is worth it! My espresso is even better than before, which
was already amazing!
I can advise anyone who takes espresso seriously to get this beautiful couple, it's really worth the money.

On to the next level...;o)