• Testing software RAID performance on Raspberry Pi B+

    I was doing some tests today with the Linux kernel’s software RAID support to find out if the Raspberry Pi would be powerful enough for it. I plugged in four identical USB pendrive of 4 GB each, and installed mdadm to setup the RAID volume.
    Read the rest of this entry »

  • C# socket broadcasts sent out on a random interface

    Today I was working on a service discovery algoritm using C# sockets sending and receiving broadcast packets. It worked fine when the computer in use is having just one network interface, but testing on a different machine, I found out that even while binding the socket to IPAddress.Any, it still picks just one of the interfaces to send out the packet.

    The solution is to use the ‘do not route’ option on the socket. The code becomes:

    sock = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
    iep1 = new IPEndPoint(IPAddress.Broadcast, 9050);
    string hostname = Dns.GetHostName();
    data = Encoding.ASCII.GetBytes(hostname);
    sock.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.Broadcast, 1);
    sock.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
    sock.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.DontRoute, true);
    sock.Bind(new IPEndPoint(IPAddress.Any, 9051));
    sock.SendTo(data, iep1);

  • How to make a redundant switching power supply

    Today I came across a nice article on the website of Power Electronics about current sharing in redundant power systems. If you’re looking for information about how to parralel SMPS’, here’s a good place to start.

  • Atmel AVR Studio 5 and the big blue JtagICE mkII

    I was so thrilled when I saw the first beta of AVR studio 5. Finally the missing IDE features were added that most programmers really can’t live without. Well all the more disappointed I was, when I tried to fire up the JtagICE. It keeps failing to initalise with a “Message from peer:USB driver attach timed out”. I must have reinstalled the driver a dozen times, but no matter what I can’t get it to work. Must be a problem with the driver running on x64 systems. I run Windows 7 x64, but I must be the only one using it in combination with AVR studio 5?
    Anyway, there seems to be a workaround to get it going. I haven’t done much testing on this though.

    Go to: Tools -> Options. Under ‘Debugger’ tick the box ‘use tool polling’.
    Now I’m not sure why this makes a difference, but at least it got me around the above error message. Programming seems to work now, next I’ll try debugging in this mode.

  • No network icon in Windows 7!

    For those of you who have tried out Windows 7 latetely and to their astonishment have come to realise the network indicator is completely gone, you might want to read this. As much as I have come to rely on this nifty little system tray icon, I just couldn’t believe it wasn’t there in some lost corner of the control panel waiting to be activated. Luckily I wasn’t the only one :)

  • .NET serial port datareceived fires slow?

    Today I discovered something that had been a pain in my .NET project for weeks. If you work with the SerialPort component in .NET 4 you might notice that in some cases it takes several hundreds of milliseconds between data arriving in your serial port buffer, and your datareceived handler being called. I couldn’t trace this until I started doing some debugging with a port monitor like HDD free serial port monitor, and reading through this threadat MSDN forums. I figured that the delay occurred when the handler was queued for execution through the threadpool. Under certain circumstances the threadpool creates a new thread in order to handle your routine, and apparently this may take up to 500 milliseconds.

    So what you should do is use Threadpool.SetMinThreads() at program startup to increase the minimum number of threads to a suitable value, and there you are! No more delay!

    Thanks to Alex Pinsker and ‘nobugz’.

  • Synchronisation and Communication using chaotic signals

    Back in 2005 I was working in Terrassa, Spain, at the Universitat Politècnica de Catalunya. I had a wonderfull time there working on my graduation project for electrotechnical engineering. Together with Fons Pijpers we were doing research on the use of chaotic electric signals for encrypting telecommunication signals. Chaotic you say? Isn’t chaos something you definitely do not want in your circuits? Well Leon O. Chua designed something that is still known under his name, the Chua circuit. A Chua circuit is a circuit which exhibits a chaotic electrical signal. Those who know more about the chaos theory or have seen movies like ‘the butterfly effect’ understand that chaos is very different from random garbage. Whithout going into too much detail on the chaos, what me and Fons did there was to try and synchronise two of these chaotic signals by means of electrical coupling. We then tried to use this signal a carrier and modulate it with a digital signal. The point is that if you don’t understand the carrier (it appears random, like garbage), you can’t lock on to it and thus cannot demodulate the data. Hence it is encrypted.

    I’d like to make our work available here, to a broader public than just the UPC students. If you find it usefull in any way please be so kind to drop me a line.