Hey folks! Some time has passed since my last activity in this blog…I was pretty busy with studies/working, but now I’m nearly finished with my Master studies. New hobbies and fields of interest appeared in the meantime – and therefore I want to share some of my experiences with you again, the cats and tubes! Hopefully, a pretty bunch of posts related to electronics, HAM (amateur radio), news of teh interwebs, tinkering for my T4 bus, linnex stuff, etc. will appear here!
I have been using X-Chat2 for quite a while now, and since my ISP cuts my line every 24h, i rejoin all IRC networks once my client detects the disconnect. This happens before the server realises, that the old connection is invalid, so my nickname is occupied by a ghost (zombie connection). There is a command to tell the server, that this situation has happened (ghosting), but not all servers support it.
Thats why i wrote this script, which listens for some events (e.g. the QUIT command, which is sent when the server realises, the other connection is dead) and then tries to change the nick back to the primary nick. It also listens to some more events and has a nickchange delay (so you dont spam the server with nickchanges in case of a problem). One could probably reduce the eventlisteners to the QUIT one.
I wrote this in perl, because i was looking at other plugins how the xchat API works, but it should be fairly easy to port it to python or c++, or whatever you want. No special license.
Install by simply renaming it to nickChanger.pl and putting it into your
~/.xchat2/
folder and ensuring that perl is installed. X-Chat will try to load it on start.
the first person to get the ISP working, will get an MCA-25 camera for free. Shipping not included.
The CCC r0ket, handed out at the Chaos Communication Camp 2011, is a slick ARM based developing board, featuring a battery, a display, 5-way jog dial button, RF and an USB mountable dataflash.
The most intresting feature though is the m0dbus, which enables the eager tinkerer to build his own m0duls (addons), to bring new features to the r0ket. The wiki shows some m0duls like “the flame”, which is an LED with acrylic art.
My idea now was to build a m0dul that features a low-power AVR, which is connected to the r0ket over SPI (available through the m0dbus connectors) and offers even more possibilities for m0duls because of the possible UART interface, the more pins, one can delegate tasks to the AVR and so on. Virtually, i’d be a m0dul-m0dul or simply: m0dul². Can you go deeper?
Since ripping the AVR out of the circuit to update its firmware is not an option, as a first step i looked into programming the AVR serially via SPI by the ARM. That is possible with most AVR MCU’s featurung “ISP Programming”. This leads to the first feature of the m0dul², beeing an in-system programmer for AVR chips. How cool is that?
ISP Programming is described in the full Datasheet of each AVR and the AVR910 note. Also, there are two implementations mentioned in this thread:
My prototype features an ATTiny2313 (because it was the first i found) so i tried flashing some IntelHex file via SPI, but so far didnt manage to get beyond the flash erase cycle (which works great). The hexfile is read completely into RAM (because the dataflash also uses SPI, just like the display) and then the ISP magic should happen.
If you think you could help the project, please checkout my fork at
I am working with an application (because space is sparse, so the official firmware will be too big) called “avrisp”. To build the firmware, simply change to the firmware/ directory and call the makefile with
make APP=avrisp
The avrisp lib is located under firmware/avr and should be built automatically. The firmware then has to be flashed to the r0ket in ISP mode (hold left and power up). Im doing this via dd and a little helperscript “ravr.sh“.
Since the display cant be used while flashing via SPI (shared bus), the ISP routines feature no debug output. I created *_dry functions, which print to the display instead of talking to the SPI bus, in order to locate the problem.
Hooking up the AVR is straightforward. The repo contains hardware schematics, which show the needed pins on the m0dbus connector. Looking from on top, the right (m0dul A) connector has the following pinout:
VCC- -BUSINT
SS2- -SCL
SS1- -SDA
SS0- -GND
SCK- -MOSI
MISO- -3.3V
I connected SS0 with RESET on the AVR and used the 3.3V for the AVR’s VCC. MOSI, MISO and SCK get directly connected. One could put resistors in between, i didnt. I connected a LED between GND and a pin, so i could the the AVR’s firmware.
Since the ARM runs at 72Mhz, but the AVR is at 8Mhz tops, one needs to divide the SPI frequency before trying to talk to the AVR. This is done in the avrspi_select() routine. Constants for the project are located in the avr.h
TODO:
decide which AVR to use, it should have low power consumption but many features (adc, uart, timer, ram/flash) and run at 3.3V
fix code to be able to program AVR through SPI
integrate avrisp lib into r0ket repo
draft schematics, route layout, print pcbs, make kits
write SPI communication code, which can be used in the AVR firmware to talk to the ARM
build a m0dul² that uses the newly gained features (one i have in mind is to interface the MCA-25 cam)
I unfortunately dont have the time, to continue this right now, so if you have some tips, patches, ideas, feel free to comment, contact me (im also in #r0ket on IRC) or directly send some github pull requests. I’d love to see this w0rking.
This was my situation: Ubuntu 10.04 i686 Host, Ubuntu 10.04 i686 Guest, VirtualBox 4.0.12, dynamic virtual guest hard drive with 8GB, which were simply too few.
Searching the VBox-Forums, it seems there are a couple of ways to increase the disc space of your dynamic virtual harddrive, the way also depends on your host/guest combination.
You might want to look into CloneVDI, a tool that lets you do many things with your VDI. The Post on the VBox-Forums can be found here: CloneVDI Discussion and Support.
I followed the instructions from this post, which seemed to fit my combination just fine. All you need is another guest linux, which happened to be another Ubuntu 10.04 for me. I will call this guest tmp-guest.
First, shut down the guest with the too-small harddrive, which i will call original.vdi. Then goto the vbox settings of your tmp-guest and select the storage tab. There you can add another harddrive to the controller, which will be a new harddrive. Follow the guide to create a harddrive with the desired size (e.g. 15GB for me). I will call this the new.vdi.
After that, stay in this section and also add the original.vdi harddrive (by choosing “select existing harddisk” in the guide). You should now have the harddisk of the tmp-guest, the newly created big new.vdi and the original.vdi attached to your tmp-guest.
Now boot up your tmp-guest and install e.g. “gparted” by doing:
sudo apt-get install gparted
The operations done by gparted could also be done via the LiveCD, where the .iso can be mounted by virtualbox, if you dont want to install gparted to your tmp-guest.
Before we can resize the virtual harddrives, we need to clone the original.vdi to the new.vdi. This can be achieved with the following command:
dd if=/dev/[device of original.vdi] of=/dev/[device of new.vdi] bs=1M conf=noerror
The device will probably be /dev/sdb for the original.vdi and /dev/sdc for the new.vdi, /dev/sda is the harddrive of your tmp-guest. Depending on your configuration this could be totally different though, so its better to verify that you copy the right devices.
ALL YOUR DATA COULD BE LOST.
If you know the harddrives UUID’s, you could use the command
blkid
to identify the devices. Another option is to use
fdisk /dev/sdb
and hit the “p” option to show the details of this device. Pay attention to quit fdisk with “q” so that no changes are written. The new.vdi will not display proper information, since now partitions were created in it.
One could also install “smartmontools” (sudo apt-get install smartmontools) and use the command:
sudo smartctl –all /dev/sdc
to get information on that device.
Assuming the dd command was successfull, you will see the transfer stats like
Now new.vdi contains an exact mirror of original.vdi, but the extra space is not yet available. This will be fixed by gparted.
Start gparted and select the new.vdi device from the top right (should be 15GB or whatever your new size is). Right click on the 8.6GB of partition (left) and select resize. Draw the border all the way to the right (this uses all the available space) and click OK. These changes have to be applied (green arrow on middle).
Now your new.vdi contains the data of your original.vdi but has some extra space.
Shut down your tmp-guest, go back to the settings, detach the new.vdi and original.vdi from your tmp-guest, remove the original.vdi from your original guest and add the new.vdi instead. You should be able to boot the new.vdi without problems and TADA, more space!
One note, if you have different snapshots and want to merge them into a .vdi, you have to delete the previous stages from the snapshowview. Otherwise, snapshots are stored as a difference to the vdi and you will have an old snapshot in your new.vdi.
See this post on how to merge a vdi with a snapshot.
If you have trouble, removing your original.vdi, e.g. because of the error
“… has more than one child hard disk”
it might still be attached somewhere. This can be resolved in the Virtual Media Manager, which shows the machines, an image is attached to. For further guidance, please see this post or this blog entry.
So you own one of those nifty little cubes? And want to solve it?
Let me tell you, if you follow some simple instructions, you will be able to solve the cube, no matter what the initial setting is. But if your not familiar with the terminus or just started to play with the cube, i highly recommend Dan Browns instruction on youtube. The entrypoint can be found here:
If you are familiar with the terms and the algorithms and just need the instructions again, read on. The instructions assume a standard color cube and the following notation:
notation for the cheatsheet
1. Green cross (green color on top)
- bring green each piece to bottom side
- turn bottom until the other color of the edge piece is underneath the right side color
- turn side twice
2. Green corners (green color on top)
- bring a green cornerpiece underneath the right corner or at the right position (wrong direction)
- R’, D’, R, D until corner fits
- repeat with all green corners. The sides should form little T’s
3. Second layer (green color on bottom, blue on top)
- if edge pieces in top layer only contain blue:
– turn cube until edge piece in question is on front middle right
– U, R, U’, R’, U’, F’, U, F
- if edge piece in top layer does not contain blue:
– turn top layer so the edge piece color fits the side color
— top color belongs to left side:
— U’, L’, U, L, U, F, U’, F’
— top color belongs to right side:
— U, R, U’, R’, U’, F’, U, F
4. Blue cross (blue on top)
- top shows a little L form (middle, and two edges are blue): put L in back-left of top
- top shows an I form (blue line): put I horizontal
- top shows no shape at all: do nothing
- then perform: F, R, U, R’, U’, F’ until blue cross on top
5. Arrange blue cross (blue on top)
- if two edges of top layer correspond and are:
– beside each other: put one in back and one right
– opposite sides: put one in front and one in back
- perform R, U, R’, U, R, 2U, R’ (+U)
6. Prepare finish (corner place, blue top)
- if one corner is in the correct place (dont mind the orientation, just the colors): put it in top right front
- perform: U, R, U’, L’, U, R’, U’, L
- repeat with correct corners on top right front until all corners are in place
7. Finish the cube (corner orientation, blue top)
- REMEMBER THE FRONT COLOR THAT YOU START THIS STEP WITH
- with the unfinished corner in the top right front: R’, D’, R, D until corner is on correct orientation
- ONLY TURN TOP, to bring next corner to top right front, keep your front color the same. Repeat above algorithm until all corners are oriented correctly.
- turn top und bottom layer to fit the middle layer and you are DONE.
