Random Tech Makings

Mythtv and DVB entertainment.

2010-08-21T13:52:00.000+10:00

I just spent a number of hours on a pleasant saturday morning trying to work out exactly why MythTV doesn't get program info for Channel Nine (in Sydney, Australia). I already knew this was because Mythtv was failing to parse the EIT data, and in particular, the SDT wasn't being found.

After a fair bit of poking around, re-learning the fragments of DVB that I have long since forgotten, compiling various hacks into mythbackend, I eventually worked out that it was looking for the SDT in the wrong transport ID.

Because mythtv (being the bastion of stunning design that it is), stores a NIT/TID (network id, transport id) per channel, and _also_ stores a TID into the multiplex table. So the channel table has lots of very fine NIT/TIDs which I checked until the cows came home, before eventually discovering that the code was also reading from the dtv_multiplex table.

One "update dtv_multiplex set transportid = 1056 where mplexid=24;" and I now have program schedules for channel 9. w00t!

Ok, this is a pretty trivial thing, and I don't actually care about the data: It's just that this has been non-working for many months, and every time I noticed it it irritated me that I didn't know why it was broken.

Now I do. So now I'm happy :)

2010-01-11T17:51:00.000+11:00

Another thing to add to the list of "Life is too short".

Attempted to add an SVN project from http://code.google.com/p/project into Eclipse using the SVN plugin. Project is an android project.

Total failure. Eventually I got down to errors like:

java.lang.IllegalArgumentException: Path must include project and resource name: /android-l2tp-tether
        at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63)
        at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:1628)
        at org.eclipse.core.internal.resources.Container.getFolder(Container.java:137)
        at com.android.ide.eclipse.adt.internal.build.PreCompilerBuilder.buildAidlCompilationList(Unknown Source)
        at com.android.ide.eclipse.adt.internal.build.PreCompilerBuilder.build(Unknown Source)

Noting that there were a project called 'android-l2tp-tether'...
Eclipse is just too big, too clumsy, and too opaque to usefully debug. I wasted an hour wandering around with straces et al, but realized I was just wasting time. Copying the svn directory else, and then doing 'create new project from existing source' was instantly successful. ugh.

Unit tests

2010-01-09T21:45:00.000+11:00

Gradually coming up to speed on gtest (google c++ unit test framework). Yes, I'm know I'm painfully behind...

And retro-fitting unit tests to existing code isn't much fun. However, it is entertaining for the number of latent bugs it finds! There's always something special about output like:

[----------] 2 tests from Image
[ RUN      ] Image.Empty
Segmentation fault (core dumped)

Noting that the unit test in question creates an unparametrised object and inquires as to it's size. :)

Off to fire up a debugger and find out wtf is going on.

Bayes and models.

2009-11-15T21:30:00.000+11:00

This is me talking to the pumpkin (aka thinking aloud).

I have two models.
One is that everything is noise, and has a discrete distribution over a grid.
One is that there's a pattern and predicts the future location of an event.

Bayes says the posterior probability of the model is:
P(M|E) = P(E|M)P(M) / P(E)
where
P(E) = P(E)P(M) + P(E)P(!M)

Ahhh. I realise my mistake. P(E) is not the ideal probability of the event, but the much more restricted 'probably of event in the space the P(E|M) is measured '.

In my case, where the distance between the predicted location and a movement event is being considered, the underlying distribution is the expected distance to a movement events, independent of the model.

I.e. Have no model. Just measure the expected distance from random points to movement events to build the model. Then seperately build the same model specifically for known model conforming events. That generates P(E) and P(E|M).

Doh. For some reason that took a very long to sink in.

HAL sucks

2009-07-30T17:28:00.000+10:00

So you have a touchscreen, and a 'modern' X11 installation.

Your 'modern' X11 knows that actually configuring devices is something that people who live in caves do. 'Modern' X11s use HAL!

Unfortunately, the nice 'modern' X11 installation is borked. It's talking to HAL which is telling it to use inputs/event0. Which doesn't actually exist.

So the question is: How do you tell it to use /dev/inputs/event2 which is a working touchscreen?

Ahh, you might ask. What you really do is spend far too much time searching google and eventually arrive at:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="input.product" contains="Touchscreen">
    <merge key="input.x11_driver" type="string">evdev</merge>
    <merge key="input.x11_options.SwapAxes" type="string">true</merge>
    <merge key="input.x11_options.InvertX" type="string">true</merge>
</match>
</device>
</deviceinfo>

Which you install in /etc/hal/fdi/policy/touchscreen.fdi

Of course. it was obvious from the very start that this was the thing to do, no? And the documentation has zero mistakes or misspellings in it. A remarkable end it achieves by being non-existant.

Rust as far as the eye can see.

2009-07-12T15:01:00.000+10:00

Having many adventures trying to compile a new kernel for the DevKit8000

embest haven't submitted the board support to mainline and after reverse engineering their patches, it's easy to see why!

The diff is littered with random patches to random files (that aren't used), #if 0'ed code, and cruft like:

 #ifdef CONFIG_OMAP_MUX_DEBUG
-       debug = cfg->debug;
+       //debug = cfg->debug;
+       debug = 1;
 #endif
        warn = (orig != reg);
-       if (debug || warn)
+       //if (debug || warn)
                printk(KERN_WARNING

It's been about two hours work to separate out the parts that actually do something, and port them forward to a 2.6.30 kernel.

Which brings me to a confession: I just realized it's been something like 3 years since I last ran 'make menuconfig' on a linux kernel. The rust! It burns!!

DevKit8000

2009-07-11T13:19:00.001+10:00

I recently ordered a DevKit8000 development board for use in an embedded image processing project I'm looking at.

My DevKit8000 arrived yesterday. I bought the "yes, I will have fries with that" version, so it has the 7" touchscreen, more cables than you can poke a stick at, 512MB sd card, a USB hub, and 2 power wall-wart power supplies.

Total cost was $AUD420 including DHL shipping of ~ $AUD80. The price for the board board is comparable with the BeagleBoard, but the shipping was cheaper and easier from China than it would have been from DigiKey! So I'm pretty happy with the price.

One of the power supplies has a USA plug, the other is something European.
The one with the USA plug is apparently the board power supply, the other is probably the USB hub power supply (at least, the plug doesn't fit the board).

The board itself had Windows CE loaded in NAND flash out of the box, which sent me on a 4 hour trail of destruction trying to replace it with linux. This was mostly due to me not realising that the sd-card that comes with the board is junk, and in addition to being unreliable, doesn't function at the 3.3V the OMAP processor requires for it to be booted from.

Not realising that, I thought that I must be doing something wrong (which given the .. umm.. erratic number of the board documentation wasn't unlikely) and so tried all sorts of things in an effort to re-flash the NAND X-loader, cumulating in formatting the NAND flash and rendering the board entirely unbootable. Waving aside the blue air, I finally did what I should have done to start with, and use a known-good SD card. Which instantly booted correctly, taking another 2 minutes for me to reflash the x-loader, u-boot, uImage and filesystem. *&^*&^*&^&*!!!!!!!

With the board actually booting and running linux, it was much more useful. It immediately come up on the ethernet with an ifconfig+route making it a lot faster to move images around than the sd-card sneakernet I had been using.

The CD that comes with it has a port of Android which functions rather well and was useful is checking that the touchscreen actually works.

The hardware appears to be fairly close to the beagleboard, except that it also includes an on-board ethernet, and a ZIF socket for a camera input.

There's a couple of odd things: The host USB port (as opposed to the OTG USB port) appears to be missing a chip. The pattern is there for it on the board, and all the pad have solder on them, just not chip. This is not entirely unexpected: The USB Host port isn't listed in the feature list, and the BeagleBoard people have had trouble getting it reliable.

The more concerning one is that one of the power regulators (TPS73701) has a terrible soldering job done on it. It looks like there may have been a solder mask problem and FAR too much solder paste was dumped on. The tab is swimming in solder, and leads look like they didn't quite reach temperature to fully melt the paste. This is one of a two parallel regulators, and the other one is spotless, so I'm a little puzzled as to what went wrong with this one. Both are running the same temperature so it appears they're both working, it just looks terrible.

Other than that, the rest of the board looks clean and well put together.

Now I'm off to setup a cross compiler environment!

Belated files

2009-07-11T12:27:00.002+10:00

Very belatedly getting around to posting these.

The Eagle CAD files for the relay driver board is now posted at https://sites.google.com/a/dgmo.org/home/Home/boards

Noise filter your signals!

2009-04-10T09:09:00.002+10:00

Free advice. When there's a 200m loop of wire carrying a low voltage signal, noise filtering is a _very_ good idea.

Otherwise the doorbell may ring at 3am in the morning from induced noise...

'Fixed' the doorbell today.

2009-04-05T19:16:00.002+10:00

The doorbell has been a source of trouble for a while. Mostly because D is in the habit of closing every between where she is and the front door, causing it to be inaudible.

So today, I wired the doorbell between the DCD and DTR lines on the main fileserver and wrote a little C program effectively gets an interrupt when DCD changes. When triggered, this program runs wget to hit a URL on another server, that runs a cgi-bin script, that plays a .wav file through the speaker.

For some reason the name 'Reuben Garret Lucius Goldberg ' kept running through my head...

But the end result is that one can push a door near the front door, and something near the center of the house chimes, so the end goal is fully achieved!

Clipsal C-Bus

2009-04-04T10:39:00.003+11:00

Clipsal have decided to open the C-Bus protocol.

http://www.cbusforums.com/forums/showthread.php?t=5022

Speaking as someone with a C-Bus wired house (for reasons that were never terribly good), this is a very, very good thing.

It's rather unexpected, and I suspect a little late (there's considerably more competition around now), but it's going to make it much easier to do semi-decent integration.

Yay Clipsal!

Adventures in Switzerland.

2009-03-16T05:39:00.005+11:00

Currently in Zurich.
R is here for first time, so wanted to do a little wandering around.

Had very vaguely hatched a plan to visit Pilatus, a mountain not too far from Zurich. The plan was to catch a train to Luzern, bus to the cable station, and then cable car up Pilastus.

The morning started off to plan: We managed to leave the hotel vaguely sort of on time, made our way to Zurich HB (Central train station), and found food at McDonalds. (hungry people do desperate things).

The first sign of trouble was attempting to buy a ticket to Luzern. This involved much fighting with the ticket machine. Firstly it didn't like anything. This was solved by actually pressing 'OK' on the screen before attempting to hand over money. Then it refused my visa card many times (in various orientations), then it wanted a pin (which I don't have), then rejected my EFTPOS card as unsupported (the pin for which I did know), R's visa card (it wanted a pin which he didn't know), and various other random pieces of plastic we attempted to feed it. Finally R found some cash and fed it that, which is liked, ate, and dispended tickets. Yay! For a train that was due to leave in 60 seconds. On a platform far, far away.

Sprinting for the platform had us there just in time to see it leaving in the distance. A 30 minute wait...

The trip to Luzern was very pleasant. The trains are very quiet and nice, and the scenery is picturesque. Did a few sudoku puzzles which R had infected me with, and we arrived in Luzern in short order.

Wandering around looking for things bearing the name 'Pilatus' had us finding the S31 bus which ran to Pilatusmarkt. Very promising. So we walked to the 6 blocks to Pilatusplatz, found a bus stop (yay), found the S31 stopped there (yay) and it was due to arrive in 6 mins (yay).

15 mins later, it was pretty clear that the S31 wasn't. The timetable insisted that all was well, but no bus. So we decide to take the S20, change to the S21 and we'd be fine. S20 was good. Actually did arrive, did travel in the right direction. Alas, we fell to talking and missed the stop. So getting off at the next stop decide to 'just walk back. Not far really'. About 15 mins of walking led us back to the stop for the S21. Which was due to arrive in a little over an hour. argh! Ok. Another change of plan. Now we'd take the S16 which looked like it also went to Pilatusmarkt and that one was only 6 mins away.

Bus arrive. We get on bus. Bus travels about 300meters to Pilatusmarkt. We get off. Find we are at deserted shopping center. Close for the sunday. Named 'Pilatus Market'. Doh! Turns that that many random things around Luzern are named after the mountain.

Now very lost, with the next bus not due to 60 mins, we decide to walk back to where we caught the S16. The horrendously unreliable map (scale optional) claimed a nearby train station.

20 mins of walking, we are at train station. We had originally intended to catch the train back toward Luzern, but there timetable had various stations marked with a cable car symbol. How exciting! Which led to R get excited about visiting Engelberg, and maybe wandering up Titlis, a 3000m high mountain.

More tickets, more fighting with ticket machine, eventually discovered that it enjoyed amex cards. Wait for train. Train takes us along a very pretty route. Alongside a lake, wending through valleys. And then turned into a cog-train for a while! Seriously steep assent led us into some stunning scenery (sorry, no photos yet) .

Engelberg was less interesting, but they really did have a cablecar up the mountain (actually, many many cable cars up many slopes). We caught one to Gerschnialp, about 1260m above sea level. Normal hairy cable car ride put us in some fairly serious snow. With us wearing jeans and tennis shoes...

We had a really good time. Walked along a snow trail for about 20 mins a small restaurant in the middle of no-where , had a fairly ordinary lunch (which cummulated with them refusing to accept anything except Amex, where the amex could only be used for bills over 50CHF [ours was 33CHF], and we had no cash left...) we then set off to walk down the mountain.

This was hugely enjoyable. A snow trail wandered down the mountain through forests et al. Most of it was fairly well packed snow so it wasn't that bad to walk on. Most of the other people we saw were wearing snowshoes, but they clearly envied our minimalist approach to snow hiking.

About 1/2 we down, we found a ski-jump! A truly terrifying affair. Seeing them on television can't convey just how insane they are. Standing at (well, near) the lip of the jump, you can't actually see any of the slope below, just the flat field far below. Actually: far, far, far below. I was having trouble with the heights just standing near the edge of the jump. I can't imagine just how certifiable you'd have to be to actually go down it on skis. Simply amazing.

It took a bit over an hour to walk down the mountain. Followed by a sprint to catch the train back to Luzern (more stunning scenery), and then the train back to Zurich, and then another train back to Stadelhofen.

Hugely enjoyable day; Now very, very tired. Goodnight.

PS: No, never did find out what happened to the S31 bus.

Puzzle Piece

2009-03-01T14:25:00.001+11:00

Just spent a few enjoyable hours making this exercise. "How DID the nut get on there?".

It's puzzle piece to which the photo doesn't do full justice. There's a no visible joins in the threaded piece: It looks seamless.

It's a nice exercise in lathe work with a number of tricky bits. The facing needs to be very good, threading interior sections is a generally a bitch to do, especially in stainless steel. And then finishing it all to the mirror polish (which you can somewhat see in the high fidelity reflection at the end).

I'm quite pleased with it because I pretty much got it right first time, it turned out well, and the polish came up far better than I was expecting. I keep underestimating how far the buffing wheel will cut.

Audio over HDMI

2009-02-13T20:48:00.002+11:00

Noted here mostly so I can find it later.

I have a Gigabyte motherboard, the GA-G33M-S2H, that I use for a HTPC (home theater pc). It lives under the couch, driving the LCD TV, diskless, quiet, and is generally pretty happy.

I bought it principally because it has on-board video that does HDMI with an intel chipset. The intel graphics chips are pretty well documented and Intel fund development of linux drivers so it was a fairly easy choice at the time.

When I first turned it on about a year ago, the video of HDMI turned up right away. Very easy. 1080P @ 50Hz is very nice.

Alas, the audio didn't work. At the time, there were bugs in the ALSA drivers that prevented the properly detecting the (seperate ATI) chip that handles audio encoding for the HDMI data stream. After mucking around with it for too long, I gave up and ran a DVI cable and an audio cable to the TV instead. Which had it's own mucking around to get 1080P working on a single DVI channel...

Coming back to the present, I had occasion to revisit my MythTV setup, due to the "urgent need" to repaint the wall. This mean the TV cable down briefly, and stirred me to investigate if the audio HDMI is fixed.

Yay! It is, as of ALSA 1.0.17. Which is in Fedora 9 which I upgraded to a while back, so the kernel already knew about the HDMI audio and was ready to use it. Sweeet.

But. There's always a but. Pulseaudio, the apparent audio hub of choice didn't know about it. After poking, peering and prying at the config, it was clear that HAL did know about it, but pulseaudio refused to use more than the first device on any given soundcard.

As the HDMI appears on this motherboard as hw:0,3 (3rd device on card 0), pulseaudio via HAL refused to have any truck with it. This turns out to be a known, very long standing bug in pulseaudio.

My hack solution: Boot the HAL module in pulseaudio out the door, and just hardcode the detection for the device. Which said that it worked, but didn't produce any sound. After even more trawling, it turns out that I needed to unmute the "IEC958" in the ALSA mixer.

And now it all works! HDMI, 1080P and audio over a single cable.

Tapping ACME nut.

2009-02-07T11:33:00.002+11:00

The short story is: I re-tapped the acetal nut for the X axis to an ACME thread.

The longer story involves much pain. :-)

To re-tap the nut to ACME thread involved making an ACME tap. (off-the-shelf ACME taps cost ~ $400 which is a bit much for a one-off). Making an ACME tap seemed very simple: Just cut a piece of thread rod, grind a taper onto it, and then grind an edge. No worries, right?

So being a doofus, I actually did grind the taper, but in a way that involves destroying my finger tips along the way. I made a simple jig with bearings that allow me to rotate the rod against the grinder. The idea was to let the rod spin against the grinder, ensuring that it would be ground evenly and giving an accurate taper.

In practise, the rod spun much too fast, and in reaching out to slow the spinning rod, I found out that rolled ACME thread has fine burs along the thread edges. Some of them relatively large. As I can measure by the many fine cuts in my finger tips....

I started grinding an edge on the rod as well, but I really need a diamond cup grinder to do the postive rake. After mulling it over, I slapped myself upside the head, and just milled the edge onto it. The ACME rod I have isn't ground, nor hardened, so milling it is fine. I just used a carbide boring tool to cut the postive rake.

Once I'd actually managed to wake to using the mill, it all went fairly fast; Just cut the edge, polish it up a bit with the diamond lap, then bung it on the lathe and it's done.

Well, almost. The amount of plastic being removed is fairly large and the taper on the acme isn't as shallow as it should be, so machine tapping it mostly out. I used lathe power to get the tap started, but then using a spanner to turn the nut by hand to cut the thread.

The end result is fairly good. It's a relatively loose fit, so I'll need to add an anti-backlash nut at some point, but the tap itself worked well.

Bearing mounts

2009-02-05T20:41:00.004+11:00

Last night I made the two new bearing mounts. These are brackets that hold the angular contact bearings for the ACME rod. The task was to bore a 16mm hole for the rod, and then a blind 30mm hole for the bearing. The 16mm through hole had no real accuracy considerations, but the 30mm needed to be 29.99mm so as to ensure that the 30.00mm bearing were a press fit.

I had originally planned to do this using the boring bar, but on reflection realized that that would make it difficult to do the accurate flat base required to support the bearing.

So I got out the rotary table. Now normally the rotary table is a pain in the butt to use. Partly because it's difficult to clamp things on my relatively small table, but mostly because I'm terribly slow at indicating the part to be aligned with the table center. I'm just awful; it normally takes me more than an hour to get terrible accuracy. And thus I avoid it like the plague.

My brain wave was to use the lathe to made a trivial jig; The table has a 17.50mm hole in the center, and my part already had a milled 16mm hole in the center. So I made a piece of delrin (plastic) that was just a short section of 17.5mm dia, stepping down to 16mm dia.

A few taps with the mallet inserted it into the table, and then the blanks were a press fit onto the 16mm section. Instant alignment. Yay!

Even better, this made clamping much easier as I just needed to clamp at one point. Much win all around.

Actually milling the blind 30mm hole was then pretty simple. Just offset a 12mm end mill 8.950mm from the center, mill 5mm into the blank, and run the table around a full 360 degrees. Easy.

The slow bit was getting the hole to be a solid press fit for the bearings, and 29.950mm is much too small. So I increased the hole size in 10 micron increment thru to 29.990. At which point the bearings went in with about 200 newtons of force. Perfect!

I think this is some of the more accurate milling I've done. I'm pretty happy with how it turned out.

Bearing jig

2009-02-01T12:47:00.003+11:00

Dichro milled this up from a scrap piece of aluminium bar. 10x50mm flat bar, drilled with 16mm hole, then added 4 x 7mm holes on a 25x25mm square. M6 bolts, some washers, some skate bearing.

Ta-dah!

Worked extremely well. Should have done it sooner :)

Maching ACME threaded rod

2009-02-01T07:51:00.003+11:00

ACME threaded rod, cut to 1150mm long, first end machined.

The 0.5 inch ACME was turned down to 10mm to match the inner diameter of the bearing. It was then threaded to M10 for ~ 30mm to allow for the lock nuts to go on, and then turned down to 4.75mm for the last 10mm to match the coupling for the motor shaft.

The metal was a serious pain to machine. Owing to the length (> 1 meter) I was running the lathe at fairly low speed. The steel work hardened VERY easily, and it's very flexible steel. This meant that it was just as easily bent away from the lathe cutting tool as cut. And it was threaded to boot, which mean highly variable loads on the initial cuts...

I ended up using the live center to attempt to hold it in place which improved matters a little, but not much.

Eventually, I used a handful of skate bearing to make up a jig to support the other end, which let me run the lathe much faster, which made the whole thing easier to do. I was initially turning it at 220 rpm with HSS cutting tool. Running it at ~ 480 rpm was dramatically easier.

The threading was done with a 60degree lathe tool, mounted upside down, with the lathe running backwards. I threaded it in until it "looked done", and then cleaned up by running an M10 x 1.5 die over it. Worked very nicely as I didn't need to try to fight workhardening steel with the die getting an initial thread.

Now to make the bearing brackets...

ACME threaded rod.

2009-01-31T15:14:00.002+11:00

I bought it from


  Bomond Trading Co Pty Ltd
  49 Orchard Rd, Brookvale, NSW 2100
  p: (02) 99391344

1/2 inch (12.7mm) ACME threaded rod (aka leadscrew), 10 tpi (10 turns per inch). This is rolled rather than ground so it's less accurate.

The chap at Bomond was very helpful; I phone up on thursday, he said it was a speciality item, but he could get next day. I went this on saturday (this morning), and picked it up. The length of leadscrew and a handful of M10 nuts was under $AUD100 so I was pretty happy. It was the closet place in Sydney I could find to supply it. There's a number of other places I'd found, but they were a long drive away.

The only fly in the ointment was that I was expecting it to be a 3 meter length, but it was actually 12 foot. For some mad reason I'd heard "12 foot" and mentally translated that to "about 3 meters". Of course, it's actually about 3.7 meters, which is longer than will fit in the car.

Bomond didn't have cutting facilities, but I was on my way to Edcon Steel to pick up some aluminium flat bar, so I just left it poking out of the boot of the car a bit while I drove around the corner and asked the chap at Edcon to snip 1150mm off one end for me. Nice and easy.

Stepper motors

2009-01-28T23:24:00.002+11:00

The stepper motors I have are Linengineering 4118S-62-07 motors. They were a surplus item, so unfortunately the datasheet doesn't seem to be a very common.

My motors are rated for 2.5A per phase, and a resistance of ~1 ohm is cited in a catalogue with a ~3.6Kg-cm torque.

Looking at http://www.linengineering.com/site/products/4118.html and extrapolating a bit, my motor would be something like the 4118S-04V, or having approx the same torque the 4118S-04P does, just at twice the rpm.

So when I'm running my mill at 2000mm/sec on a 1.25mm pitch, that's about 26 revs/sec. Which would be something like 1600g-cm of torque from my wild guessing and eyeballing the graph. Which, frankly, isn't too bad at all at all!

If I get this ACME at 10tpi (or 2.54mm pitch), I should be able to run a similar speed, but at 13 revs/sec and ~ 2200g-cm of torque. When is very reasonable indeed. Ok, I'm sold.

Now I'm off to buy some 3 meters of ACME threaded rod.

Simple image to g-code converter

2009-01-27T20:33:00.002+11:00

I did a tiny little bit of tidy up and uploaded my trivial C program to http://code.google.com/p/imagecarve/

The program simply translates images to G-code. It does nothing else. It assumes that you're capable of editing the resulting G-code to make it usable on your machine, and that you can add minor things to the g-code like feed rates et al.

It's pretty raw. It assumes many things, including that you have a ballnose cutter and that the input is always correctly formatted PGM.

The line I used to generate the (upside down) image from the pic above is:


cat ../IMG_545.JPG | jpegtopnm | ppmtopgm | 
    ./imagecarve --scale=0.25 --toolsize=3.2 --stepover=1.5 > out.g

followed by hand editing of the resulting 'out.g' file to set a feed rate.

Yay! First cut!

2009-01-26T13:22:00.002+11:00

After a lot of preperation the mini-mill is cutting foam again! Pic shows a little test cut from semi hand-rolled G-code. It was done with a 3.2mm ball-nose endmill, using a 2mm stepover and running at ~ 400mm/minute feed rate.

Frankly, the biggest thing it showed was that I feel the need for speed! It could easily have cut at > 1000mm/minute given the fairly shallow cuts being taken. My steppers are pretty tiny, and the threaded rod I'm using is only a 1.25mm pitch so it's spinning pretty fast to reach the 600mm/min rapids it's currently doing. I think I see a purchase of some ACME threaded rod in my future... Which will mean re-doing all the delrin nuts again, dammit.

Currently debating if I should buy 1/2inch or 5/8th inch rod (~12mm and ~16mm respectively). The 12mm is 2.54mm pitch, and the 16mm is 4.3mm pitch, so the 5/8th is capable of much higher speeds, at the cost of some accuracy and backlash. Still very undecided on this.

I say 'semi hand-rolled' G-code as it involved initially a significant chunk of perl, and eventually a chunk of C code that properly compensated for the cutter size. At the moment, it will take a PGM image and convert it into G-code, treating the grey levels as a high map. It's did a semi-reasonable job of carving a picture of K into foam; albeit with some oddities given the simple lightlevel->height conversion. Took nearly an hour to carve a 120mm x 80mm image tho. I am seriously feeling the need for speed!

Getting slower better at milling.

2009-01-25T08:07:00.002+11:00

I'm slowly getting better at maching parts. The photo is a trival couple of spacers; Just some aluminium box, cut and faced to the same length.

I cut them on the bandsaw, squared one end of each on the mill, turned them over, stood them on equal bars and then run a face cutter over the pair.

Pretty trivial machining, but it still involved 3 tools. The nice bit that I'm happy about is that it only took me about 5 to 10 minutes. I'm very slowly getting more experienced and quicker.

This morning I was making more delrin nuts (for the mini-mill) and had both the lathe and knee-mill running at the same time. The lathe was on auto-feed facing and then parting delrin, while the mill was on power-feed facing the aluminium bracket. Less standing around waiting while the machines take fine cuts. Not entirely sure it was a good idea, but it did make things go faster.

2009-01-25T07:50:00.003+11:00

The PCBs for the relay board finally arrived from BatchPCB. (Well, I should say I finally got them; Turns out they were sitting the mailroom at work waiting for me to pick them up for about 2 weeks. Oops)

Pic is a raw board on the right, and a fully assembled board on the left. The board went together fairly easily.

I tried to use the SMD oven for the first time in anger, and was mildly annoyed to find that it doesn't quite reach the melting point of the lead-free solder I'm now using. Dammit. I need to get a toaster oven or similar.

So I just hot-air soldered all the SMD components, and then hand-soldered all the through hole components. A lot of soldering! Took most of an hour to solder it. ( Some 123 thru-hole solder points).

Interestingly, I managed to get a dry-solder on one of the SMD components. I suspect I managed to just not put enough solder paste on it, but it's a first for me. I fixed it by hand-soldering; Good thing it was an enormous 0.8mm pitch component.

Board is now plugged into an ATNGW100 and it looks like it's working well. I can read temperature from a DS18B20+ that's attached to one of the 1-wire interfaces, and the board hasn't caught fire. Yay!!

When I get time later today I'll do the spot of programming to talk to the GPIO pins and start testing the relay drivers, RS422, and SPI interfaces.

Eye-Fi, grumble, grumble.

2009-01-25T07:36:00.002+11:00

The Eye-Fi card simply stopped working a few days ago.

After trying the usual sorts of things (power cycle, power cycle again in a fit of sheer optimism, opwer cycle with it next to the access point, tcpdump on the network looking for it's MAC address) it was clear that things had gone badly wrong.


10:38:04.919893 00:18:56:10:1d:b6 > Broadcast, 802.3, length 60: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Response, ctrl 0xaf: Unnumbered, xid, Flags [Response], length 46: 01 00
10:38:09.174952 00:18:56:10:1d:b6 > Broadcast, 802.3, length 60: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Response, ctrl 0xaf: Unnumbered, xid, Flags [Response], length 46: 01 00
10:38:13.444594 00:18:56:10:1d:b6 > Broadcast, 802.3, length 60: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Response, ctrl 0xaf: Unnumbered, xid, Flags [Response], length 46: 01 00
10:38:17.707051 00:18:56:10:1d:b6 > Broadcast, 802.3, length 60: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Response, ctrl 0xaf: Unnumbered, xid, Flags [Response], length 46: 01 00

It was basically just broadcasting an invalid ethernet frame over and over again. Curses. Looks like it had corrupted its configuration.

After laboriously re-installing the windows software, it wanted a firmware update (2.0396 -> 2.0400 ) which I did. Pulling the log from the card showed things like..


[111:32] Disconnected from WLAN (reason = 4).
[111:32] Connection dropped (previous state is 2)

looping. Yuck. No idea what causes it to corrupt it's settings. It's "fixed" now in the sense that it's uploading images again, but I'm a little perturbed. (Luckily the firmware update didn't break the perl server).

I need to find out why Dave Hansens linux utility doesn't work and fix it. It's very annoying having to fire up a windows instance all the time.

Bracket to suit.

2009-01-24T07:34:00.003+11:00

This is the bracket that goes with the acetal nut. It's just a piece of 50mm x 50mm x 10mm aluminum, squared up on the mill, slotted with a 6mm end-mill, drilled in the center with same, increased out to 16mm with a 16mm roughing endmill, and then bored out to ~21mm with the boring tool.

The finished piece. I just love the finish the boring tool puts on holes. The final pass was cutting ~0.1mm deep, feeding at about 0.03mm per turn, so it was taking a pretty fine cut indeed. The result is this mirror smooth finish. Total overkill for this piece, but I take any opportunity to practise. The results I'm getting these days are far improved over the mess I made with it when I first got it.

Acetal nut fitted to bracket. The bolts are just my usual M6 stainless steel. There's about 5mm of adjustment available in both the X and Y directions.

The driving side. The nut isn't actually totally flat on this side. It turns out the parting tool I used to cut it off the bar isn't totally straight, so there's ~0.07mm of curvature across the nut. Which turned out to be fine as it's the otherside that fits to the bracket, but it's still annoying. Will have to get out the dial indicator and straighten the parting tool at some point; Come to think of it, I'd better do it soon before I forget and attempt to use a bent parting tool to part steel....

This bracket is fitted to the table mill and working very well. Much better than the old nut. Unsuprisingly, having the threaded hole accurate makes a big difference to the effort required to drive it. The tiny steppers I have easily drive it at better than 1200 rpm now.

My blogging process.

2009-01-20T07:20:00.002+11:00

I'm not 100% happy with this, but it's still the least effort I know of.

I take photos with the Canon 20D, which then uses an eye-fi to upload to the server. The script on the server auto-sorts into directories by month.

I then use picassa on the linux desktop to pick out suitable photos, occasionally cropping particularly dud ones that I still want. After getting a few useful pics, I click on 'Blog this', and then 'Save as draft'. (As the picassa blog editor is awful).

Then I got to blogger.com, click on 'Edit posts', select the draft and add text. Then publish if all goes well.

Things that suck:

1. Picassa on linux frequently forgets to scan the directories regularly. I need to go to the Folder manager, change nothing, click OK, and then it finally scans the directory and picks up the new images.

2. Picassa won't 'Blog this' with more than 4 pics. Sometimes this is a pain.

3. There's no easy way to add captions to pictures that show up in the blog post. Picassa lets you set captions on pictures, but promptly discards them when you ask it to generate HTML. I kinda get the impression that 'Blog this' was a kinda half-arsed feature.

4. The Blogger editor is pretty flakey. Then editing posts that have images floated right, it's easy to get into a state when it simply won't add text at the top of the post. Increasingly, I just edit the HTML as it's easier than fighting the editor.

5. The whole process is still a large work burden than I'd like. My mental barriers to regularly updating the blog are high enough without fighting tools as well.

What do other people use?

TechCrunch tablet lappad

2009-01-20T06:31:00.002+11:00

Looks like someone is finally building my ideal tablet.

http://www.techcrunch.com/2009/01/19/techcrunch-tablet-update-prototype-b

Reasonable price point, nice and simple, good sized screen, runs linux: What's not to like?

I'm still hunting something like this as a better interface for the home automation system.

Finishing flanged nut

2009-01-18T22:48:00.001+11:00

This is just finishing off the delrin nut for the table mill. After turning the blank on the lathe, I finished it off on the mill. This was basically just cut the top and bottom off to reduce the height to 30mm, then mill the slots either side (which will be used for position adjustment).

Acetal is seriously nice to work with. It cuts very cool (no lubricant or cooling required!), and the surface finish is just fantastic.

The only (very minor) downside is that it compresses slightly under load, so I needed to do a few passes on the slots to get them the right side.

Easy machine, relatively cheap (cost me ~$50AUD for a 1000m x 50mm rod), nice finish, tough. What's not to like!? :)

Acetal on the lathe

2009-01-18T22:45:00.001+11:00

I started turning up the flanged nut for the X axis on the table mill. The current nut is made of UHMWPE (aka a piece of plastic cutting board), but it was made on a drill press, and it's accuracy is low enough that it binds fairly easily.

The new nut is made of Delrin (aka Acetal). This is my first time maching acetal and overall it was very pleasant. The only negative is that is grabs very easily. I got a little carried away and the autofeed was a little fast, and thus the piece of 50mm rod made contact with the ceiling. Oops.

Taking slightly lighter cut made everything good. The plastic machines to a very nice finish, and appears to hold it's shape very well. I just faced the rod, did a skim cut to true it, narrowed one section and then cut it off with a parting tool. Very easy!

I'll definitely be using this more.

The other thing I did was something I've been been meaning to do for a while. After tapping a thread into a hole, there's frequently small shards of metal et al which are difficult to remove. Just running a bolt into the hole tends to mash the splinters into the thread making a bit of a mess.

So took a normal M6 bolt, and used the ginder to put a groove up the side of it (cutting across the threads). Screwing this into the hole nicely removes the splinters of metal (they collect in the groove). This is akin to just running the tap in, but the bolt is a looser fit, and doesn't risk further cutting of the thread. Worked better than I expected.

Home Switches

2009-01-17T21:36:00.001+11:00

Today I added home switches to the table mill.

The microswitches were just ones I had lying around that were a suitable size. It didn't take long to discover that they mounted via a pair of 2mm holes. Unfortunately, I didn't have any M2 bolts around.

So with desperation driving necessity, I found a length of thick wire (actually ~ 1.9mm music wire) and used the drill to run it through an M2 die. This nicely gave me a length of M2 threaded rod.

In the spirit of hackery, I then drilled a pair of 1.5mm holes into the aluminium bracket, and use the drill to drive the threaded rod into the holes. The music wire being much harder than the aluminium, it just tapped a thread into the al bracket. Ta-dah! Easy mounting for the micro-switches. A very small bad of CA glue to stop things vibrating free and it's all done.

I'm still using MACH3 to drive the mill at the moment (haven't yet installed EMC2) but it's still neat to click on 'Ref All Home', and watch the mill drive the Z, Y and X axis to the home switches, stop, and reverse slowly until it comes off the switch.

I think tomorrow I'll be in shape to do the initial cuts on the upgraded mill.

Eye

2009-01-15T20:49:00.002+11:00

The range of the Eye-fi card is pretty ordinary indeed.

It can do 2 meters of air.
It can do 5 meters of air.
It can't do 10 meters of air + 2 glass windows.
It can't do 5 meters and a brick wall.

Am mildly disappointed. The last thing left to try is bump up the access-point power from 40mW to 250mW. This doesn't help if it's a transmit problem on the eye-fi card, but hey! it's about 50/50 right? right? :)

Actual progress

2009-01-14T21:18:00.002+11:00

I basically finished re-assembling the table mill. Starting to look like it can actually cut something!

The table went on very easily. There's a lot of socket screws involved, so I took an old allen key and cut the tail off with the grinder. (With a stupid moment along the way; I had assumed the key would be case hardened as it's a cheap key, so I ground off the surface and then put it against the metal bandsaw. Mistake. Now I think I need to fit a new blade to the bandsaw. Doh! Not a total disaster as the blade was pretty close to the end anyway but still annoying)

The resulting hardened hex bar fits into the cordless drill and making doing and undoing socket screws very fast and easy.

I still need to finish aligning the table (need to get the electronics back together for that). I also finished all the plywood sections for the dust box.

Next step is to cut to the perspex lid and side for it, and hinge them on. Cutting the perspex will be .. interesting. It's only 3mm thick, but I need to make a greater than 1.5 meter long cut.

I'm planning on using the circular saw for it. I'll need to ensure that the perspex is clamped well on both side of the cut. Not going to be easy as I'm running a cut up the middle of a 2.4 meter long sheet. I suspect it will be a matter of reducing the depth on the circular saw to a minimum, using backing plywood, and lots and lots of weight. Not sure how else I can usefully clamp it.

Plastic fantastic

2009-01-13T20:53:00.002+11:00

More toys arrived yesterday. This is 2 x 1000mm x 50mm Delrin rod. A fairly tough plastic, dimensionally pretty stable, and very, very easy to machine.

I bought it originally to make anti-backlash nuts, but I suspect it'll find up getting used for a fair few more things than that..

I'm planning to fire up the lathe this evening and turn a couple of nuts for the mini table mill, just to get some experience with the material.

Small progress

2009-01-13T20:52:00.003+11:00

The original task to 'just remove a bit of lash' from the table mill has grown. A little. Just slightly.

So after adding the extra linear bearing, and noticing that the table structs needed fixing, which resulted in noticing that the drill holes in the original brackets weren't accurately aligned and basically tearing down the full X axis to do these things, I was on track to re-assemble.

Except that the side project of enclosing the mill (to contain dust and reduce noise) reared it's head and pointed out that it's much easier to add that while the mill is mostly disassembled.

Which led to noticing that the enclosure would shade the ethernet and power points on that side of the bench. So off to add extension leads to all power points and longer ethernet cables to ensure I wouldn't need to regularly get to them. Which led to relocating the PC to free up the desk space. And moving the monitor/keyboard. Which led to re-doing the power cabling to tidy it up a bit.

And so this evening I finally put two sides of the enclosure is on. I just used some angle aluminium to make brackets, and screwed the plywood on. Yay! Progress!

Except that in doing that and moving the X carriage around, I noticed that the nut wasn't quite aligned with the threaded rod...

On the bright side, it was an opportunity to use one of the most brutal tools I own: A 26mm , high helix milling bit. When you want to make a big hole in a hurry, and you're not too fussed about the accuracy, that's the way to do it!

A 26mm hole in 12mm aluminium, 8 seconds. Done! Sometimes, using a bigger hammer is just plain fun.

Timing belts

2009-01-12T19:14:00.002+11:00

Another step toward finishing the CNC of the big mill arrived today. These are timing belts and pulleys. The largest one is ~300mm in diameter. I'll use this to run the Z-axis (aka the knee) on the mill, and the smaller ones to run a 2:1 reduction for the X and Y axis.

Like most solutions, they come with a problem. The holes are just guide holes, I'll need to bore them out to size. That's easy. The hard bit is cutting a keyway in each one. I don't have a keyway broach, and don't feel like spending ~ $200 just for this. I'll probably try and grind out out of a bit of high speed steel. We'll see how well that works....

I'm making slow progress on putting the table for the table router back together, but I've gotten mildly distracted by cleaning up the workshop.

The need to put a dust case around the table router has stirred up areas of the workbench that haven't been touched in months. So now I'm moving the PC under the bench, re-running the ethernet and power cables, tidying up and putting away, and generally making ~ 2 meters of bench space useable again. The long slow cycle continues!

Tedious machining

2009-01-11T19:02:00.005+11:00

Sorry, more machining. I'm still on my quest to rebuild/improve the mini table router.

The previous table supports were hacked together from a bunch of aluminium box, drilled and bolted at one end. It wasn't fastened at the other end, and the structs were overlength (I had never cut them to the right size). The ho

Today I drilled and tapped holes into both end brackets for the table support structs to bolt onto. This was drilling 14 holes, each 5 mm diameter, 35 mm deep, and then tapping said holes. Suprisingly, the bulk of the time went into drilling the holes. I suspect all my 5mm drill bits are getting blunt (I use 6mm bolts almost everywhere) so it may be time to invest in a drill sharpening tool. It took almost half an hour to drill the 14 holes. Part of the time was fiddly adjustment (release table clamps, wind table to x+70mm, fiddle back and forth until it was exact on the DRO, clamp table) but it just wasn't cutting very fast either. I get bored and wound up using the quill auto-feed and auto-stop to do the bulk of them.

The tapping by comparison went very fast. I love the VFD I fitted to the mill. It's just so nice to dial up 40 rpm, and let the tap just thread straight in. I press reverse when it's in far enough, and the VFS nicely slows the mill to a stop, and then winds it up into reverse. Makes tapping (at least in Al) very quick.

I followed this lot of tediousness by milling slots into the ends of all the table structs too. 28 slots (12mm slots on top, 6mm slots on bottom). Man, I'm glad I don't do this for a living.

Boring

2009-01-10T22:06:00.006+11:00

I had noticed earlier that there was a little too much slop in the mini table router. The Y-axis was rotating, being insufficiently restrained by the Z-axis carriage.

So this afternoon I got around to doing something about it (or maybe it was just an excuse for some boring action.. :)

I decided to add another pair of linear bearings to the top of the Z carriage so that a moment about the Y-axis would be carried by the bearings on the same rail instead of working to seperate the rails. This should (with a little pre-load) be much stiffer.

And while I had the boring set out, I enlarged the motor mount opening. The top photo is the boring bar in action, on autofeed. I love the finish it leaves! This is using a carbine tipped bar in aluminium which isn't ideal, but it was the bar I had to hand.

Nest was making a bracket for the linear bearings. This is a simple piece with 2 x 22mm holes for the linear bearings, and 2 x 7mm holes for attaching it (and 1 x 6mm holes in the center for the threaded rod to pass through). The digital readout on the mill makes this a piece of cake: Just touch off the piece to find the corner, set it to (0,0) on the DRO, then just drill 6mm pilot holes for the 2 x 22mm, enlarge to 16mm using a roughing mill bit, then use the boring bar to enlarge 1mm at a time to 21.8mm, then enlarge 0.0.05mm at a time to get to 21.99 which leaves the linear bearings a press fit.

Last photo in the new bracket installed. It's the top bracket on the Z carriage (the carriage on the vertical rails). There's a little preload from the Y rails, so it's now nice and stiff. Well, not up to cutting metal stiff, but it should now be adequate for wood and plexiglass. (I'd previously just used it for XPP foam and wax).

Modifying ACME nut on mill.

2009-01-09T18:01:00.009+11:00

Taking another step toward converting my mill to CNC control, I decided this to take a closer look at the nut on the X axis with a view to seeing how easy it would be to replace/augment. (The idea being to remove backlash out of the system).

This is a little trickier than it would normally be because my mill has an X-Y digital readout, with the optical encoders bolted to the mill. These needed to be removed as the table was being moved beyond the normal limits to expose the nut.

Being an idiot, I look at the end with the power feed and said "Hmm. Looks complicated, let's leave that alone".

So I started with this end. After about 30 minutes of mucking around, it become abundantly clear that this was the end with the thrust bearings; I.e. the complex end. The end that's relatively high precision. And with the benefit of hindsight, it was obvious that the power feed would be fitted to the end that's easiest to fit to. Doh.

So back to the powerfeed end, it disassembled much more easily. This is after removing the retaining nut, handle, and feed cog. Nice simple mechanism.

The power feed just sits on roller bearing (no thrust bearing required) and so is very easy to remove after clearing the keyway.

And there's the acme nut. Piece of cake. Interestingly, it turns out there's two of them (another on the other side), so removing the backlash looks very easy. Just mill some slots in the nut, and turn it to adjust the degree of slop.

Nut removed.

Preparing to mill the nut. It's just centered and clamped onto a small rotary table. I'm using a 4 flute 6mm bit. The slots will be 7mm wide, but I didn't have a 7mm to hand, and I can just cut one side of the slot at a time.

All done. The slots I left slightly under size to improve the centering. It was the work of moments to reassembled everything and measure the nut backlash. (Well, many, many moments. About an hour actually).

Poor control

2009-01-09T08:30:00.002+11:00

So I've been collecting data from the temperature monitors for a while now and one thing is abundantly clear.

The air-conditioning controller sucks.

(That would be HVAC for the crazy people that still haven't gone metric yet)

Graph is of room temperature for 4 rooms over the last 24 hours, with the air-conditioner turned on at ~ 1930. Note that it starts cycling almost immediately.

To put it in context, this is an AC that has a variable-speed-drive on the compressor, so there's no reason whatsoever that it should be oscillating. The PID loop driving it (and I do hope there is a PID loop...) should hold it all at a steady state.

(Note that the green line aka Living Room zone was turned off until ~ 2330 which is why it didn't start cycling until then. And the reason that the study isn't cycling more is that the balancing is awful and there's not enough air going to the study. Something I need to climb into the roof space to adjust the dampers for I think.

The AC is a Daikin FDYQ200MR. Which is a 22.2KW system I think. (Note that that's not the power draw: That's the peak heat-pumping capability).

Added to the to-do list: See if I can find datasheets for the AC VFD + compressor + evaporator, and scrap the existing controller in favour of talking to the VFD directly. Task #5412345 I think that is...

Echo

2009-01-08T22:13:00.002+11:00

The main living room in our house has always been a little harsh to my ear; I've been complaining to the wife that there's just too many hard surfaces in the room (lots of windows) which make it very 'bright' acoustically. This has the big down sides of making it difficult to understand what people are saying on the other side of the room, and annoying the hell out of me which the kids start making a racket.

So when D poked me on the subject this evening, it motivated me to go measure the problem. Mostly in a half-arsed sort of way to start with.

I used a crappy USB webcam which happened to have an in-built microphone to record audio, and then a tiny bit of perl to play a 1 KHz pulse out of the TV speakers at reasonably high volume. (Just a single cycle of a 1 Khz sine wave).

There are so many things wrong with this as a measurement setup it's difficult to count them all (not a pure tone, speaker distortion, awful directional microphone, no calibration to speak of, etc, etc, etc) but it was to at least give me an indication that it was worth putting more effort into it.

The graph above is the result. X axis is in seconds. It's rather entertaining that there's still significant energy in echos at 250 ms past the impulse. So it's not just all in my head: The room really is very echoy. Which I already knew, but now I has some numbers! Which is surely most of the way to fixing the problem, right?

Unfortunately, reducing echo is probably going to be non-trivial. At least, it will be given that D's hard requirement is that I don't cover the windows in felt...

We'll start with simple things like throw rugs over the couches, a tablecloth over the dining table, felting the undersize of the table and the bench. And if all else fails, the dreaded curtains discussion will probably enter the stage.

But first I need to get a better microphone. And some sort of software that's able to effectively measure and display how much the echo has changed. And maybe a good psychoaccoustic model. And a pony!

It's nice to be home...

2009-01-07T20:34:00.002+11:00

Being away with family in entertaining, but there's something very nice about being home.

Today I have:

Kicked off PicardTagger to fix up all the tags on my various MP3 files. Free hint: If you have 26,000 mp3 files, don't try and feed them all at once into Picard. Looks like there's at least some O(n log n) algorithms in there, if not O(n^2).
Much hacking with Eye-Fi. It nows properly with the main linux server.
Rebuild an N800 device as a video-player for Katie. This is notable hindsight: It would have been better to do this before the 4 hour plane flight... Firmware is upgraded, video transcoder tools are installed and running. I ordered a new 8G flash micro sd-card to hold the videos.
Start more actively hunting down a dehumidifier for the garage. I'm tired of fighting the rust battle on the milling machine and lathe; I'll cheat by just dropping the humidity. Right now, it's often in the 80% range which is deadly to precision iron. EBay sniper is fired up and ready!
Fixed the bluetooth download for D's phone. The script that auto-detected D's phone as being in range and then grabbing all the pictures on it via bluetooth was broken by the semi-recent OS upgrade (forgot to cover up a config file). Each fix, but I still need to add some monitoring for it.
Had a long chat with Andrew B about planes,rockets and software. He kindly brought over the paint needed for my glider, so that's a repair I'll kick off on friday.
Polished off PID software for SMD oven. I left the hill-climbing running while we were away, so now I have the PID constants tuned to better than 6 significant figures. (NOTE: This is a total waste of time! This was running against the simulator, not the real hardware. But it's still entertaining). I had intended to use it in anger today, but ran out of time. The boards for the 200W audio amplifier are on the bench, I just need to heat them.
Gone for a swim with the kids. The long days make it very pleasant to go swimming at circa 7pm at night. I'm still waiting for the relay PCB boards to arrive from batchpcb.com but I have patience. Maybe. I hear Olimex calling my name.
Ordered the timing belts and pulleys for the mill CNC conversion. I'd decided that I'm just going to do it and the cost isn't that outragous. At least, not in comparison to some of the other things I've wasted money on over the years.

It's nice to be home. :)

Eye-Fi

2009-01-07T18:45:00.004+11:00

Update: Perl standalone server that runs under linux for Eye-Fi card is linked here.

I bought an Eye-Fi sd-card a few weeks ago in a fit of laziness. The idea being I could put it in the SLR camera, and it would auto-upload images to the fileserver instead of me having to do the (very onerous..) walk to the server and plug it in.

I bought it in ignorance of the hugely proprietary nature of the card; Not sure I would have bought it knowing what I know now.

Part of the problem is that Eye-Fi's business model apparently includes charging large sums of money for trivial features. Thus, they go through all sorts of contortions to avoid you implementing said trivial features yourself rather than paying them.

Luckily, the protocol that the card uses on the WiFi side has been reverse engineered by others that have gone before me.

Chris helpfully wrote a little perl server that looked like it worked once apon a time. It appears that Eye-Fi have changed a few things since then so it took a little bashing to get it to work seamlessly with my card.

The two major changes are the certification calculation and the transfer mode.

It turns out that a different forumula is used to authenticate the client to the server. It's md5(mac addr, upload key, snonce) rather than the md5(mac address, cnonce, upload key) used in the other direction. Seems strange to me; Not sure this isn't a bug in the Eye-Fi code.

The other one is reflecting back the transfermode and transfermodetimestamp used in the session setup. Without this, the Eye-Fi refused to transfer more than one picture in a session.

Some minor changes include the server doing a fork for each client connect, and an unsuccessful attempt to verify that file checksum. The eye-fi card passes an MD5 sum along with the file on each upload, but it isn't a straight md5 of the tar file, nor of the embedded JPG file. I had a very quick poke, but the calculation wasn't immediately obvious to me so I wrote it off as a 'nice to have'.

Changed file can be found here. The upload key that's required in the file is stored in Settings.xml if you've used the windows app manager to configure the card. (Which I did: I failed to get it to do anything useful when run under wine).

So now I have it all working on my linux fileserver; When the camera comes into range and it's turned on, photos are automagically dropped into a spool directory, and a little daemon renames them into timestamped directories. So now I'm happy. Yay. :)

Ps: I would really have liked to get working the eyefi-config tools that Dave Hansen wrote but I simply couldn't get them to do anything beyond detect that there was a card in the USB adaptor. It appears that the protocol between the manager and the card has changed enough that the tools no longer work.

I had a quick bash trying to get the manager to run under wine so I could spy on the protocol, but after more than an hour of fighting wine the end wasn't in sight, so I moved onto other things.

IP Camera.

2009-01-07T09:03:00.003+11:00

In my ongoing frustration to find a relatively cheap, IP based camera, I started looking at the Sparkfun 1300x1040 CMOS Camera. This is a $USD10 device, that connects via an 8-bit bus to ... something. In my case, that would be an ATNGW100.

I'll probably have to make up a board for it, to be able to handle the full bit rate, but the end result would be an IP camera for about $AUD160 - $AUD200 that handles a full mega-pixel, and does on-board motion detection. Assuming that I can get it efficient enough on the CPU. :)

It pretty much requires DMA to get the data into memory, but the camera does on-board JPEG compression so it should be too bad to ship the resulting data out over the network. And trivial jpeg decode just enough to do motion detect will hopefully be light enough on the CPU..

Anyway, something to play with. I ordered a couple so first step will be to see if I can actually get a picture off them.

CNC for Milling machine.

2009-01-04T12:15:00.005+11:00

Making intermittent progress on converting my knee milling machine to CNC. This is random notes on my researches to date

Those that have gone before: Hafco HM-52 CNC Conversion

Torque goals:

Maximum handle pressure in normal operation is probably under 5 kilograms.
Handle radius is ~ 3 inches.
This is ~ 3.3 newton-meters of torque.

Speed goals:

Table is ~ 1200mm
Would like to be able to go one of the table to the other in substantially less than a minute.
Say 12 seconds?
Speed circa 6000mm/minute.
Leadscrew is ~ 3mm/turn from memory (8 tpi)
So need around 2000 rpm at the leadscrew for this speed.

Which gives around 600 rpm/Nm required from motor. So something around 5000 rpm @ 1.5 Nm peak torque would be ideal. (Using timing belt to gear it down to 2k rpm @ 3.3Nm).

Would like to use brushless DC motors for efficiency, heat, ease of sealing et al.

Can use of-the-shelf brushless controllers but they're expensive, and require hall-effect sensors on motors.

Can use Takao Shimizu effort, and modify slightly for sensor'ed operation. This would require doing boards, a fair bit of testing and mucking around, but probably substantially cheaper, particularly if I do a bunch of such boards.

Looking to use EMC2 for motion control, so the Mesa boards seem popular and vestitile. Particularly the 7I43-U which is USB or parallel port @ $USD90. Mesa also sell the 7I39-LV which will drive 2 BLDC motors at up to 250 Watts. ( ~ $USD300 for 4 axis). This is currently ~$AUD600 plus shipping. Hmmm.

On the other hand, running brushed motors enabled using the 7I30 which does 100W/channel over 4 channels for ~$USD90. This would effectively drop the top speed to ~2500mm/minute for the X and Y axis, and something much less for the Z-axis (which will need to be geared way down anyway).

Still need to find a suitable source for servo motors (i.e. cheap!).

GCAM is looking for more useful for simple CAM tasks.

Need to change over to anti-backlash nuts for X and Y axis (can probably rely on weight to handle Z-axis). Simplest thing is probably to use delrin split nut? May need to make/buy an suitable ACME tap for nuts (or find an already made one on ebay?)

APT looks like an interesting thing to play with for CAD/CAM.

Cheap rotary encoders are available for $USD25 ea. Example of one being fitted is here.

I like the tools...

2008-12-25T10:51:00.002+11:00

Tiny garden project for D involved running some 13mm pipe for irrigation from the right side to the left side.

Keeping it vaguely neat meant running it under the seat thingo. Small problem: Seat thingo has no place to bring pipe out.

Solution: Using 16mm 3-way wod drill bit I just happened to have lying around.. Oh, and the new cordless drill.

Drill bit is very neat: The pitch means that it seriously bites into wood: No pressure at all involved, it pulls itself forward. And the 3-way thing means that it doesn't get clogged doing it. (Just as well, it's pretty much impossible to reduce the rate at which it drills using a hand drill!)

End result is a nice neat hole through a 60mm chunk of pine, with pipe run and water flowing into pots on demand.

Yay tools!

Math fail

2008-12-25T10:08:00.003+11:00

After posting the previous, I was going over the Kalman filter again, and realized that I had completely borked the math.

I had laboriously moved all the temperature calculation into log space because I couldn't see a way to write the matrix for the temperature decay as a function of temperature.

Silly me. I didn't need to write it as a function of time, but as a function of dt (the time interval). Which makes exponential decay all nice and linear. Doh!

So stripping all the log conversion out make it much simpler to understand and debug.

And then because I was getting bored tweaking PID constants, I wrote a trivial hill-climber in perl to search for good values. After running a few minutes that had reached the solution above.

Looks pretty to good to me! I still think I can get tighter fit to the measured temp (Red line) if I wrote a LQR but I currently fail as finding a good resource that explains how it works. ('explains' means "without going into Laplace transforms which are totally gone from my brain").

(Hmm. How can I attach text files et al to blogger posts?)

PID , Kalman filters, fun!

2008-12-24T08:54:00.003+11:00

I started writing the software to the drive my temperature controlled oven thinking it was going to be a fairly easy process: Just whack in a PID controller, tune the constants a little, Voila!

Not so much.

Some of this is undoubtedly my inexperience, some of it is the extreme time lag between action and result, and some of it is the fairly exacting requirements I placed.

The model is something like: The heating element heats up ~ 0.6 Celsius per second that the power is applied. It cools at around r= ~0.007 (ie. It cools at roughly 0.7% of the difference between it's temperature and ambient temperature per second)

The heat transfer rate between the element and the board has r = ~0.085

This means the temperature as measured at the thermocouple is heavily lagged behind the applied power. Something like 12 - 15 seconds lagged.

This means that it's very difficult to get good performance out of the PID controller. The huge lag means that overshoot is difficult to control without high Kd constants. This would be ok, but for the relatively large noise in the temperature measurement. Quantization noise alone is ~ 1% and there's another 2% in measurement noise.

This could be reduced by low-pass filtering the thermocouple measurements but the sample rate is only about 5Hz. This means that to get the noise down to ~0.5% by straight averaging would need to average over ~ 15 data points which means 1.5 seconds of measurement lag into a system that already has extreme lag. :(

The first graph above shows my attempts at straight PID control. Keeping Kd low enough to avoid crazy noise in the PWM output means pushing Kp fairly low as low. The result is nice and stable about 50 degrees, and horribly over-damped at 120 degress.

I spent far too long fighting this, tweaking constants back and forth, generally wasting time.

Eventually, I gave up on the straight PID approach, took a deep breath and implemented a Kalman filter to be able to accurately estimate the current element temperature from the lagged thermocouple measurements and the known inputs.

This proved to be more than a little hairy: My maths is extremely rusty, the kalman filter has lots of matrix math, and I'm writing it all in C (it's running on an embedded board). It took me a couple of hours just to understand what was going on with the state update equations! (I may do a later post with some more detail on the maths).

Oh, and the modelled process is non-linear so I had to move it all to log space to linearize it so the kalman filter can operate.

The result is the second graph. The red line is what I care about, and you can see it's doing much better. It quickly gets to the setpoint (orange line), and then follows it fairly accurately (albeit lagged). The green line is the heating element. It deliberately overshoots the setpoint to improve the speed at which the measured temperature gets to the setpoint.

I'm pretty happy with this; I could just leave it like this.

But I probably won't. :) In the spirit that nothing suceeds quite like overkill, I'll probably attempt to write a LQR (essentially, it inverts the kalman filter to be able to predict which needs to be done). This would remove most of the lag between the measured temperature and the setpoint.

SMD Oven

2008-12-24T08:53:00.003+11:00

I started looking some time ago at a temperature controlled oven to do surface-mount device soldering.

An oven has a couple of advantages: It's much easier to get even temperature distribution, and it's easier to follow the temperature soak profile listed in the datasheet (Important for some of the more complex sensor devices).

The first point has been a serious pain to me: Devices with sharp edges are likely to see those edges heat up very quickly so when using a hot-air gun it's easy to burn the edge of the part before the solder is close to melting. (Very easy. Really, really easy. Especially with expensive sensors that have wierd things poking out. Or expensive ZIF ribbon connects. For example. I'm just saying).

So I put together a simple board to interface to a K-type thermocouple. It's just a MAX6675 which does a K-type thermocouple on one side and an SPI interface on the other. This connects to an NGW100 board, and the SPI drivers in the linux kernel take care of all the hardware interfacing.

A tiny userspace program handles reading temperature. The end result is ~ 0 - 1000 celsius with 0.25 degree precision and ~ 2 degree accuracy.

This is coupled with a computer-driven relay switching 240VAC that drives an SMD reflow oven (aka, an electric frypan I picked up at K-mart). I just drilled a hole in the side of the lid to insert the thermocouple into.

The frypan is turned up to maximum, and the element is pulse-width modulated. (Actually, it's sigma-delta modulated with minimum on and off times, but let's not split hairs).

From here, it's a trivial matter of writing some software to run closed-loop control of the heating element to walk the temperature through a profile.

Plans...

2008-12-20T22:20:00.002+11:00

While I was at Bunnings today, I had a thought about paints. My 3.7 meter wingspan glider is looking a little the worse for wear from a hasty and poorly executed repair, so I'd like to sand it back, re-glass the damaged sections, and paint it.

Sand and re-glass is easy, but the paint isn't something I've done before.

Thus, when I noticed 'epoxy gloss enamel' at Bunnings, it seems like something I should definitely try! The plane has an epoxy gel-coat, so "Epoxy Gloss" seems like it would be very compatible, right?

This afternoon I took 5 mins to sand a previously damaged nose cone and sprayed it up. It's still not quite dry yet, and it's only the first coat, but it's looking very decent indeed. When it full dry I'll cut it back to see how well the new paint is adhering.

The only issue is that my mind immediately wanders to grander plans. To wit: Rather than just re-glass, if I'm going to sand it back anyway, why not run some carbon tow under kevlar (aka aramid) sock and give it some decent strength in that area.

This is an attractive idea, but there's some practical difficulties: The fuselage is about 1200mm long, so putting it in a vacuum bag is going to be very non-trivial. And protecting the wing bolt nuts from epoxy is going to be similarly interesting. Lets not forget the tow hook underneath which is not built for large compression (750 newtons of tension yes, compression no).

So I'm still pondering what to do here. The repair certainly is ugly, and I'm concerned about the strength given the cruftiness. But the sanded back fuselage is probably not going to be up to carrying a full atmosphere of pressure in a vac bag.

Which means I need to finish off the pressure-to-I2C board I have lying around, so I can have one of the NGW100s run closed loop pressure control of the vacuum pump. But the MPX5010 pressure sensors I have only run 0 - 10 kpa, so they're only good for 1/10th of an atmosphere. So I need to get some larger range sensors. Or make a microswitch based one....

Yak Shaving again! I just start looking at repainting a plane, and now I'm off buying new solid state pressure sensors!

It's a terrible life :)

A Cautionary tale.

2008-12-20T21:31:00.003+11:00

Some time ago I built a trivial irrigation controller. Based on a Atmel NGW100 (AVR32 CPU) it just controlled 2 x AC solenoids. Taking the easy way out, I used a couple of solid state relays to do the buffering between the CPU and the solenoids.

In keeping with keeping things mildly simple, I also derived the board power supply from the 28VAC that drove the solenoids. 28VAC, into a bridge rectifier, across a capacitor, and into an LM7815 supply a nice 15VDC that the NGW100 was very happy with.

The thing that wasn't happy was the LM7815. It was sinking the best part of 150ma across a ~15 volt drop. AKA a 2 watt dissipation. The LM7815 is something like 65 Celsius per watt to air, so that wasn't going to fly. I add a tiny heat sink I had lying around, but it got a bit hotter than I'd estimated (and than I was really happy with), so I just bolted it to a whacking big hunk of aluminium and called it a day. That's been working nicely for a couple of months now.

In the interim, I'd ordered some DC/DC converters. Little drop-in replacements for LM78xx devices, they promised to make all the heat issues go away.

So today I pulled the box out, and happily removed the LM7815 and added in a dimension engineering device. Adjusted it for 15 volt output and all looked good.

In an abundance of caution, I checked the voltages across everything between taking it all live.

This was fateful. Much to my surprise, the DC voltage from the bridge rectifier was over 40 volts! No wonder the poor little LM7815 was unhappy. I guess nameplate rating don't mean much on AC devices. It's putting out considerably more AC than it's rating. (Too light a load probably?)

A thought tickling the back of my mind had me looking up the datasheet: The absolute maximum rating for the DC/DC converter was 35 volts.

Yuck.

At this point, I should have put anything back and called it a day. But no, I was much to pig headed for that.

The next thought that occurred was "Well, 40V is too much for the DC/DC and too much for the LM7815, so why don't I just run the DC/DC with a floating ground to make it happy?". I.e. connect the ground for the DC/DC convertor to the output of the LM7815, so it only sees a ~25 volt differential. The connect the input of the LM7815 to the output of the DC/DC so it only sees a ~2 volt drop it has to manage, and every one's happy.

Oh, sorry day.

So I stupidly wired this all up, blightly ignored concerns about "what does this look like when it's powering up?" and "Is it stable!?" and promptly managed to stuff a 40volt power-on spike into the NGW100. Which has it's own DC/DC convertor with a 22V absolute max rating. Which blew up. :(

In hindsight, this was bleeding obvious. The DC/DC is going to look like a short circuit to ground on power-up (charging caps), so it's going to drop the full 40V to the line after the LM7815 == Boom! No shortage of haste and stupidly around here! No siree!

Very unhappy. To make it better, on my TODO list for later in the day was to write the software to backup all these boards I have running around the place. :( And all the mucking around, testing and poking, and then trying to coax the NGW100 back into life had chewed up most of a day. Very, very unhappy.

But the time I'd put a new board in, put the old power supply back in, and re-writing the software it was a 14 hours exercise in utter pointlessness. Not that I'm bitter or anything!

The only bright spot was: I got a new toy. I've been meaning to get a Li-ion cordless drill for some time, but last I looked (umm, about 2 years ago) they were pretty expensive.

Today I picked one up at bunnings for ~$AUD200 including spare battery. Wow. Prices really had dropped! It seems to work well: I was putting 7mm holes into timber this afternoon and it was doing just as well as the corded beast.

(The corded beast really is a beast: I bought it when I was driving 150mm bugle screws after the 600W drill I was using leaked all it's magic smoke. The beast has enough torque that I'm in fear of my wrist bones on occasion).

Oops!

2008-12-11T17:50:00.003+11:00

Ooops! Stuffed it up. Shortly after I send the board off, I realized that I had the 12V and GND the wrong way around on the jumper!!

This is just my sillyness in not checking it: I normally put power pins above ground pins, but the NGW100 doesn't follow my standard.

Being extra careful before sending it off again, I noticed that I had also managed to get the distance between the two 36-pin header wrong. Argh! Really not my day. And they were 34 pin headers instead of the correct 36 pin.

Ahh well. Board is now very carefully checked, send it off to batchpcb.com

Relay board (plus a bit)

2008-12-10T18:31:00.002+11:00

Following on from my successful 240V project, I designed a board to attach to the NGW100 and drive up to 8 relays.

The form factor for the board was dictated by the placement of the J5 and J6 jumpers on the NGW100, so there was a lot of spare board area.

So the logical thing to do was stuff in just about everything thing else I could think of that I ever interfaced to the NGW100. Which is why there's also 8-channel 1-wire interfaces, an SPI interface, and an RS-485 half-duplex driver.

The silk screen lists the RS-485 driver as the MAX-487, but it's really the equivilant 3.3V part. (I got lazy and skipped making a custom part in the library for it).

This board will plug straight into the NGW100, picking up all the signals from J5 and J6, and picking up supply power for the relays from J15, being the pre-DC/DC voltage.

This means that I can supply the NGW100 with 12VDC, which the onboard dc-dc convertor will drop down to 3.3V for the ARM32, and the daughterboard will take directly as 12VDC for the relay driving, but 3.3V for the SPI, 1-wire, and RS485.

First 240V project!

2008-12-08T10:12:00.002+11:00

Created my first 240V project over the weekend.

I now have a NGW100 emebedded ARM board driving a relay that switches 240V on or off.

This is wired to a K-type thermocouple that measures temperature up to around 1000 degrees celcius.

The final result is that I can now do controlled temperature profile for SMD soldering. The board monitoring temperature in an electric fry pan, and turns it on or off according to time and temperature to do a nicely controlled profile per the component datasheets!