Paul René Jørgensen

I’ll post this piece of code since it could come in handy for more developers than me.

	private static HashMap decode(int[] data) {
		HashMap m = new HashMap();

		// Extract date information
		int date = data[0] << 8 | data[1];
		int year = 2000 + (date & 0x7f); // 7 bits
		int month = (date >>> 7) & 0xf; // 4 bits
		int day = (date >>> 11) & 0×1f; // 5 bits

		// Extract time information
		int millis = data[4] << 8 | data[5]; // 16 bits
		int time = data[2] << 8 | data[3];
		int minute = time & 0x3f; // 6 bits
		int hour = (time >>> 6) & 0×1f; // 5 bits
		int second = millis / 1000;
		millis = millis % 1000;

		// Construct Date object
		Calendar c = Calendar.getInstance(TimeZone.getTimeZone(”GMT+00″));
		c.set(year, month-1, day, hour, minute, second);
		c.set(Calendar.MILLISECOND, millis);
		m.put(”gpsTime”, c.getTime());

		// Extract validity
		m.put(”valid”, (time >> 31) == 1);

		// Extract latitude
		int latValue = data[6] << 24 | data [7] << 16 | data [8] << 8 | data[9];
		if((latValue>>>31) == 1) latValue = - ((~latValue) + 1);
		m.put(”latitude”, latValue * 0.0000001);

		// Extract longitude
		int lngValue = data[10] << 24 | data [11] << 16 | data [12] << 8 | data[13];
		if((lngValue>>>31) == 1) lngValue = - ((~lngValue) + 1);
		m.put(”longitude”, lngValue * 0.0000001);

		// Extract speed
		int speedValue = data[14] << 8 | data[15];
		m.put("speed", speedValue * 0.01);

		// Extract course
		int courseValue = data[16] << 8 | data[17];
		m.put("course", courseValue * 0.01);

		// Extract altitude
		int altValue = data[18] << 8 | data[19];
		m.put("altitude", altValue);

		return m;
	}

I hereby put this code into the public domain.

Presentation I held last year for my colleagues at Adresseavisen.

I just stumbled upon an article by Werner Vogels about consistency in distributed systems. It was an eye opener and I recommend everyone interested to read it.

Eventually Consistent: “This is a specific form of weak consistency; the storage system guarantees that if no new updates are made to the object, eventually all accesses will return the last updated value. If no failures occur, the maximum size of the inconsistency window can be determined based on factors such as communication delays, the load on the system, and the number of replicas involved in the replication scheme. The most popular system that implements eventual consistency is DNS (Domain Name System). Updates to a name are distributed according to a configured pattern and in combination with time-controlled caches; eventually, all clients will see the update.”

In the same reading frenzy I also read these related pages:

• http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php
• http://belaban.blogspot.com/2009/01/replcache-storing-your-data-in-cloud.html
• http://commons.apache.org/sandbox/pipeline/
• http://www.jgroups.org/demos.html
• http://www.helidb.org/

My employer Adresseavisen (local newspaper in Norway) released a Google Maps based property transfer database I’ve written for them today.

You can visit the application here: Eiendomsdatabasen

• Usemon presentation is available from Slideshare
• Usemon Live demo video is available here

Tonight I upgraded one of my Sun Spots to the new beta release of the blue firmware. One of the changes were an important bugfix in the UART code of the daughter board handling the UART buffers.

Anyway, after upgrading I wrote some test code to display the NMEA data from the GPS and guess what.. It worked!

        EDemoBoard edb = EDemoBoard.getInstance();
        edb.initUART(edb.SERIAL_SPEED_4800, edb.SERIAL_DATABITS_8, edb.SERIAL_PARITY_NONE, edb.SERIAL_STOPBITS_1);
        while(true) {
            try {
                System.out.print((char) edb.readUART(1000));
            } catch (IOException e) {
                e.printStackTrace();
            }
        }

And the output (No fix. I was in my livingroom)..

Squawk VM Starting (blue-080718)...
$GPGGA,220058.000,,,,,0,00,50.0,,M,0.0,M,,0000*40
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.0*05
$GPRMC,220058.000,V,,,,,,,080808,,*2A
$GPGGA,220059.000,,,,,0,00,50.0,,M,0.0,M,,0000*41
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.0*05
$GPRMC,220059.000,V,,,,,,,080808,,*2B
$GPGGA,220100.000,,,,,0,00,50.0,,M,0.0,M,,0000*4C
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.0*05
$GPGSV,3,1,12,03,67,195,,06,61,164,21,19,57,270,,18,48,083,17*71
$GPGSV,3,2,12,22,46,145,17,21,26,080,,08,20,318,32,15,20,030,*74
$GPGSV,3,3,12,26,17,013,,27,12,293,,07,11,282,,16,10,185,*71
$GPRMC,220100.000,V,,,,,,,080808,,*26

Sorry for not posting any progress on this for some days, but I’ve started in my new day job and have been pretty tired in the evenings. Hopefully this will change soon, but during some spare time tonight I was able to create the proper cable to be able to interface the GPS with the Sun Spot.

I just wanted you to see that tiny red light on the GPS indicating that it’s properly powered and connected to the Sun Spot. Now that I’ve prototyped all the hardware I’m ready to tackle the the real challenge, to code this bugger! That will be a lot of fun!

Just a reminder at the end. I hope to meet a lot of you guys at JavaZone, 17.-18. September in Oslo. I’ll be at the speakers dinner on the evening the 16, but hopefully we’ll get some time to grab a few beers and talk about old times during the conference..

I just wanted to let you know about todays progress. The GPS module landed in the mailbox this morning, but I forced myself not to rush and wire it up to the Spot right away. I know that this GPS module is compatible with the Spot so there was no reason to rush it.

What I was more concerned with was the enable/disable switch and the rudder pass through signal. I started out wiring up the RC receiver to the spot and wrote some lines of code to get the pulse length of a signal connected to one of the Dx pins of the Spot.

    private int getRCPulse() {
        EDemoBoard edb = EDemoBoard.getInstance();
        IInputPin pin = edb.getIOPins()[EDemoBoard.D3];
        return edb.getPulse(pin, true, 30);
    }

These few lines of code should give me the length of the pulse coming in on the D3 pin every 30 ms measured in microseconds. And guess what happened when I connected the battery? It worked!!

Next up was to prototype the rudder servo pass through. I added some more wires to the Spot connecting the servo signal cable to one of the Hx pins and made sure the servo was powered by the RC receiver.

        Servo s = new Servo(EDemoBoard.getInstance().getOutputPins()[EDemoBoard.H1]);
        while(true) {
            int l = getRCPulse();
            s.setValue(l);
            System.out.println(l);
            Utils.sleep(1);
        }

This code reads the rudder RC channel and passes the value on to the connected servo. Amazing as it sounds, but it actually works!

I now have a spot decoding the RC receiver signal and later outputting it to a connected servo, passing it through the spot as if it was not there! This is what is supposed to happen when the autopilot is disabled. When I hit the gear switch on my transmitter the autopilot logics should kick in. But that is another story..

Crazy me have been thinking about this for some time now. Those who know me know that I’m trying to make a part time business taking photographs from the air using RC model aircrafts. I have a dedicated page for some of the videos I’ve been making at http://paulrene.no/index.php/aerial-photography/. I even set up a page for my business at http://settfraluften.no (Norwegian only).

Anyway; During spring this year I got hold of a Sun Spot development kit and I’ve been playing around with it for a while. When writing a program to control servos using the built in accelerometer the idea struck me that this would be a nice platform for an autopilot. I’ve never worked in this field before so this is all new to me and a bit of a challenge. But if I can pull this of it would be a nice project and maybe something that would inspire others to do the same and improve it.

One of the first things I did was to assemble a list of parts:

• Sun Spot - http://www.sunspotworld.com
• Pressure sensor - MPX5100AP pressure sensor 15-115kPa
• GPS module - GPS-module EM-406a
• Headers - Stiftlist 2×10poler rak Au
• Gyro - MKS 380 Aeroplane Gyro

Along with this I need servos, RC receiver, wires and connectors.

The feature list as I see it just now will include:

• Way point navigation using rudder control
• Altitude hold
• Autopilot enable/disable using separate RC channel (landing gear channel)

I’ll continue to write about this as the project evolves. Stay tuned, this will be fun!

This is a small tutorial describing how to use a RC gear to trigger a Canon Camera loaded with the CHDK add on firmware. Using CHDK enables you to write scripts that can run triggered by a 4 volt current on the USB port of the camera.

List of parts:

• 1x old servo
• USB mini-B cable
• RC-transmitter
• RC-receiver

To make an remote controlled trigger I started by disassembling an old HXT 9g servo.

Be very careful not to destroy any of the wires. I removed all the gears, but kept the pot wires attached so I could adjust the center point.

I then removed the two green wires and used a multimeter to determine the polarity. Then I connected the wires to a spare USB mini-b connector.

There are 4 types of USB connectors. The Canon cameras using the Mini-B type. The pin descriptions according to Wikipedia are described in this table.

Connect the positive servo motor cable to pin 1 (red wire) and the negative motor cable to pin 4 (ground). You should check and double check your wiring using a multimeter. Attach a receiver and battery to your servo and test that giving you’ll get about 4.2 volts on one side of the stick and -4.2 volts on the other. Remember the correct stick movement to generate the positive voltage. If your transmitter is programmable, remove the stick movement that gives your the negative voltage or be very careful when using remote trigger.

Now it’s time to upload a script to your camera and check if it all work.

@title Remote button
:loop
wait_click 1
is_key k "remote"
if k=1 then shoot
goto "loop"
end

Create a file in /chdk/scripts/ folder of your SD card called remotetest.bas and enabled it in the scripting menu of the camera (after enabling the ALT-menu).

Attach the cables and power up the transmitter, receiver and servo. Hit the shutter button on the camera to start the script and then use the stick on the transmitter to trigger the running of the script.

Congratulations! You now have a non-mechanical way to trigger your CHDK enabled Canon camera.