Need a new set of wheels?

I have just uploaded my second eBay auction.
Take a look at the auction here - these would be great for a range of mechanical and robotics projects - projects that I just don't have time to go into now.

Clock me up!

Just yesterday Wade and I were fiddling around with the clock settings for the control board for our project. By default an internal clock is used (generated within the AVR). This internal clock is slower than the external clock that we are using (16MHz) and so had to be changed. Unfortunately changing the clock can be a slightly confusing process - since there are about 15 settings for different external oscillators. Wade picked out one and tried it (with my approval). Note we didn't properly read the data sheet - and so after we made this change everything went dead.
The programmer (ISP) that is used doesn't generate its own clock signal - and since we were using a clock that didn't actually exist we couldn't reprogram to fix the problem. My solution was a fallback one as I didn't have any crystals about. Program a PIC microcontroller to toggle an output to emulate the clock. To do this we had to remove the old oscillator from the AVR board, connect the PIC and then reprogram the fuse bits. This worked a treat - we replaced the oscillator back in and we are in business at 16MHz.
The code for the PIC couldn’t' have been much simpler - and using the internal oscillator on the PIC16F88, I basically had to connect power to the pic with some decoupling caps and that was it. Simple!

#include
#define clockFreq 0x70 //8MHz

#ifdef _PIC16
#pragma DATA _CONFIG1, _CP_OFF & _CCP1_RB0 & _DEBUG_OFF & _WRT_PROTECT_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _MCLR_OFF & _PWRTE_OFF & _WDT_OFF & _INTRC_IO
#endif //_PIC16

void main()
{
osccon = clockFreq; //Choose internal clock rate
ansel = 00000000b; //all A/D off
cmcon = 00000111b; //comparators off

trisa = 00000000b;//All outputs
trisb = 00000000b;//All outputs
porta = 00000000b;
portb = 00000000b;

while (1){
porta ^= 0x01; //Invert bottom bit
}
}

GPS antenna - unhacked

Ok, at midnight last night I was working away, testing the UART's on the final board. The strangely the GPS reciever could not pick up a signal at all - it was just refusing to track satellites. The antenna I was using was the hacked down version, where I had removed the case, 90% of the wiring and the base. It seems the base is needed to complete the ground plane - so when this was added back in the GPS picked up the satellites virually straight away and locked on. This brings the weight back up a bit - the moral of the story is keep the ground plane!

OK - no it is Excellent!!!

After just plugging in the AVR to the computer and clicking program the results are in:

Reading FLASH input file.. OK
Setting mode and device parameters.. OK!
Entering programming mode.. OK!
Erasing device.. OK!
Programming FLASH .. OK!
Reading FLASH .. OK!
FLASH contents is equal to file.. OK
Leaving programming mode.. OK!


Just as I had hoped (at least the good OK's had an '!' following them).
I should note that this was the second shot- the first time one of the ISP-Prog pins was incorrectly connected - a couple of solder joints later and success!

Power - Check, Override - Check

The last few days I have spent doing one of my favourite parts of the engineering process - hardware design, implementation and testing. You will see the PCB is starting to become populated with various components. The first part to build was the power supply circuitry - as this was fairly robust and nothing else could really be tested without it. Having installed the regulation circuitry for 5V and 3V - these were tested and found to be working well.
Next was the manual override circuitry - After installing all the relevant components I plugged my receiver in and checked what sort of result I was getting. Firstly I tuned the potentiometer to a nice position where moving my control stick in one direction switched to auto and centred or in the other direction switched to manual. So far - so good. Then the big test for this stage was to look at the behaviour when I switched off the controller (simulating a loss of signal) - the circuit started oscillating between auto and manual control every second or so - not a desired outcome. Looking back through my log book (yes these are really handy now - this saved me lots of debugging time) I found I had mistakenly put the wrong capacitor value on the schematic (for the 555 timer). When I changed the value (from 22nF to 10nF) the whole system worked perfectly - that log book has probably already paid for itself in saved time! Soon I'm planning on putting together a tutorial on double sided soldering of DIP terminal connectors.

PCB - Finally

Today I picked up two very nicely fabricated PCB's (exactly 1 month and 2 days after I submitted them). The finish on the PCB's is extremely professional. Unfortunately my setup at home only allows me to do single sided photo etching - if I can find a supplier for double sided pre-sensitised boards, I might step up to the next level.

Please wake me up

Over recent days I have been toying with the idea of creating a hardware based WOL (Wake On LAN). The application is an interesting one. I'm setting up a computer in a remote location which is connected to LAN via WIFI. This computer will be used for a estimated maximum of 5 hours a week (mostly on weekends). The computer is about 2km from my house (and on a different network), so it would be nice to turn it on remotely so that I can connect to it from home via remote desktop (or something of the like - after configuring this in the local router). Unfortunately the WIFI standards up to 802.11g don't support WOL (although 802.11n is rumoured to) - unlike most standard 10/100 NIC's these days.
With this in mind I have thought about setting up a small microprocessor connected to the Ethernet port of the computer. This micro could have a real time clock and could trigger the WOL functionality of the computer at predefined times that I have programmed in. How does this work then? Basically a special UDP packet containing a 'magic string' is used to trigger the computer into waking up. Using Ethereal (a great packet analysing program Wade put me onto a while back), I was able to take a look at what these 'magic packets' look like.
Basically it is like:
0000 ff ff ff ff ff ff 00 10 a4 84 5a d2 08 00 45 00 ........ ..Z...E.
0010 00 82 63 f9 00 00 80 11 14 c7 c0 a8 01 03 ff ff ..c..... ........
0020 ff ff 05 eb 2f ff 00 6e 05 b2 ff ff ff ff ff ff ..../..n ........
0030 00 14 85 ea 2a 1e 00 14 85 ea 2a 1e 00 14 85 ea ....*... ..*.....
0040 2a 1e 00 14 85 ea 2a 1e 00 14 85 ea 2a 1e 00 14 *.....*. ....*...
0050 85 ea 2a 1e 00 14 85 ea 2a 1e 00 14 85 ea 2a 1e ..*..... *.....*.
0060 00 14 85 ea 2a 1e 00 14 85 ea 2a 1e 00 14 85 ea ....*... ..*.....
0070 2a 1e 00 14 85 ea 2a 1e 00 14 85 ea 2a 1e 00 14 *.....*. ....*...
0080 85 ea 2a 1e 00 14 85 ea 2a 1e 00 14 85 ea 2a 1e ..*..... *.....*.

Note the sequence 00:14:84:ea:2a:1e which is repeated about 15 times - this is the MAC address of the host computer. Besides this the packet is made up of source and dest (FF FF FF FF in this case) IP addresses, checksums, a source MAC address, a dest MAC (FF FF FF FF FF FF) and various port and mode settings.
At some point I hope to get around to building this and testing it out - but for now, uni is pretty busy - I should also probably build the computer this will interface with first as well.

Problems (a)float

My recent glossy posts have really gotten off topic - the topic of engineering project work. I will take off my marketing hat for a moment and put the engineering one (in this case software) back on.
An interesting recent problem I have been encountering is in the calculation of bearings. Well, not really the calculation of bearings - that part was rather trivial. It is a rather quirky compiler or emulator bug in how floating point numbers are used. Basically I can make assignments to these numbers without a worry (i.e. ratio = opposite/(float) adjacent). (You may recognise that I'm calculating bearings based on tangents - so next time a high school maths teacher gets asked why are studying trigonometry? they can answer - well when you are developing vectoring algorithms for autonomous craft it will really come in handy - NOTE: I wasn't the one to ask such questions - I'd just hear them again and again from the same people).
Back to the problem - when I try any compare these floating point numbers I come into grief.
Simple statements like:
if (ratio > 0)
or even:
if (ratio > 0.0)
would corrupt other data variables not even passed to the specific function.
To cut a long story short - I switched over to integers (which don't have any decimal places) which allows me to do the calculations in half the space and with much greater speed (I'm not sure why I didn't do this to begin with).

Souvenirs and sustainance

Wades recent post on the open day and some questions from readers jogged my memory on a few open day points.
- The food was great - officially catered lunch and then some really well catered afternoon tea.
- A neat La Trobe hat - which made me less conspicuous when getting the afternoon tea.
- A handful of La Trobe sweets (which we managed to get from the CS department). Unfortunately I couldn't find where to get a CS hat (same as the engineering one but red), but the lollies made up for it

(The hat reads - "Engineer your future at LA TROBE UNIVERSITY")