Damian Budd

B.Sc. Eng. (Hons) Electronic Engineer, Hobbyist and Private Pilot

Natcom Electronics

Duration: May 2002 – December 2003 (Part Time)

                January 2004 – September 2008 (Full Time)

Position: Senior Design Engineer

  • Short range Spread spectrum RF bidirectional communication devices in the 433MHz and 2GHz band.

  • Developed SLIC interface circuit for mobile Iridium phone application.

  • Developed DSP demodulator application for digital communications reception.

  • Developed Low frequency RFID wireless tag access system.

  • Vehicle Speed Measurement and digital camera systems. Developed complete fixed site and mobile radar speed camera systems using FireWire cameras and a PowerPC based processor with Yellowdog Linux operating system. Technical team leader of a team of 3 engineers on Project.

  • Developed hardware, software and antenna for 400-500MHz DSSS mobile crew radio.

  • Experience with Atmel AVR8, Motorola HC08 microprocessors, DSP56F800, Motorola PowerPC. FireWire bus, digital FireWire cameras (DCAM). GPRS connectivity.

  • Experienced Linux programmer for both desktop and embedded systems. Experience with device drivers for Linux Kernel. Experience with FreeRTOS real time embedded kernel.

  • Developed Bi-conical EMC test antenna


About a year after I left Grintek Comms, the directors at the company head office decided to shut down the regional office where I had worked and make all the staff redundant. Three of the engineering staff decided to form their own business in the wake of the closure and this business is called Natcom Electronics. They continued to use the same company premises and offered employment to some of the old Grintek Comms staff. Initially they hired engineers on contract basis so that if the work dried up they would not be faced with paying huge retrenchment packages.


When I left Prism Secure Solutions at the end of March 2002 I approached Natcom and offered my services and they were happy to employ me part time on a contract basis two days a week whilst I spent the rest of my week working for GGAcoustics.


The directors of Natcom wanted to pick up on the short range cordless communicator project that I had been involved in during my days with Grintek Comms. I therefore developed some new RF hardware using more up to date devices that had since come on the market as well as discrete digital hardware for working with the MLS codes used in spread spectrum. Eventually it became apparent however that this was a task for an FPGA. Unfortunately at the time no one in the company had adequate FPGA experience and so they decided to put the project on hold again.


Since Natcom was a start up company, at this time they did not have product lines of their own and relied upon obtaining contract work from other companies to keep the business moving. I was assigned to work on a number of these contract projects one of which was a subscriber line interface circuit (SLIC) for an Iridium mobile phone application. The company we were contracting to supplied us with an Iridium phone modem and we were required to interface it to a standard phone handset and supply a battery and recharge solution so that the whole kit could be packaged in a rucksack or backpack. The intention was to be able to provide pay phone access within Africa where land line installations were non existent. The kit had to be completely self contained and able to recharge itself from a small solar panel sewn into the backpack.


For this project we designed a custom PC Board to provide the interface between the Iridium phone, telephone handset and battery. We made use of a SLIC IC for the handset interface and a Freescale HC08 processor to control the SLIC, interface to the Iridium phone and perform other house keeping tasks. I wrote the majority of the software for this project. The SLIC generated the line voltages required for the handset and interpreted the DTMF tones generated by the phone as well as implementing a Codec. The processor ran a simple cooperative operating system that would service the SLIC and Iridium phone tasks and interrupts.


Another contract task I worked on was a DSP demodulator application for digital RF communications. The contracting company provided solutions for vehicle tracking and recovery. The client provided us with RF receiver hardware that would provide a base-band signal in the analog domain. The requirement was to decode the base-band signal and send the decoded messages to a processor. The client had an existing DSP solution for this, but they wanted to migrate to a newer processor (Freescale DSP56F800 series) and if possible get one processor to decode two signals at the same time. Unfortunately their algorithms were written in assembly language for the old platform so it was not just a simple case of porting code to a newer platform. The coding task had initially been given to another of the engineers who contracted to Natcom and he had coded up most of it, but then they handed the task on to me. When I took over the code it was functional, but did not meet the required timing performance. I had to optimize the code, first getting it sufficiently fast to decode one signal within the real-time capabilities of the processor and then attempted to get it to decode 2 signals asynchronously and in parallel within the same real-time budget of the processor. I achieved most of the optimization through de-referencing data structures and maintaining copies of local data and pointers within the functions.


Once I had proved it was possible to decode two signals on one processor using a DSP56F800 evaluation board we were required to produce a prototype PC board for the client. They wanted to use this prototype board for testing and as a reference design from which they would develop their own circuit board. For this prototype board I supervised a colleague in drawing up the schematics and laying out the board, giving him strict instructions concerning the layout of the analog and digital sections and ground plane arrangements. When the board was complete and assembled it delivered 6dB improvement in sensitivity against both the DSP56F800 evaluation board and the clients existing older DSP board.


Another contract task that was handed onto me from a fellow employee was a Bovine (cow) RFID tag transceiver system. RFID tags are low frequency short range devices mainly used in access systems. The tag consists of a small loop antenna and a circuit which has no battery or power supply. The tag transceiver has a similar wire loop. The transceiver circuit energizes its loop antenna and when the tag is brought into close proximity with the transceiver antenna the tags antenna receives part of the energy from the transmission and is able to power itself for a brief period of time. This creates a sort of air-core RF transformer with low mutual inductance. During this brief period of time the tag transmits its code which is received by the transceiver circuit and decoded. There are two forms of RF ID tag, FM modulated where the tag transmits an FM signal and AM or amplitude shift keying (ASK) where the tag modulates the amplitude of the transceiver field. The difference between these two methods is that for the AM type tag the tag transmits its reply during excitation from the transceiver and for the FM tag it transmits its code after excitation by the transceiver.


For this project the client expected the tag to be sensed from up to 1 metre away from the transceiver loop antenna, which is unlike most RFID solutions where the tag is held in contact with the transceiver. The reason for this was that the tags would be attached to cows for the purpose of cattle counting where the cows would pass through a cattle run past the transceiver circuit. Thus the tags could be up to 1 metre away from the loop antenna. The client also required the circuit to handle both the FM and AM type tags. This project had been started by a colleague and he had developed some circuitry but it was not performing at the required 1 metre distance and he was unable to continue working on it so I was given the task of getting it to work. The transceiver loop was generating a sufficiently strong field to energize the tags at 1 metre from the antenna, but the receiver circuitry wasn't sensitive enough to detect the tag transmissions from that distance. This required a change to some of the circuitry and a new board layout to improve the sensitivity. I laid out the new board using Pads PCB.


At the beginning of 2003 I started working full time for Natcom Electronics. In March of that year they placed a blank Freescale Lite5200 evaluation board containing a MPC5200 PowerPC processor on my desk and said “Make it happen!” Natcom had teamed up with another company who were in the traffic camera sales and management business and they wanted to develop their own brand of traffic camera equipment. I was put in charge of the development work for this project. The first step was to install Debian Linux on my desktop PC and then get embedded Linux running on the Lite5200 board. I made use of the Embedded Linux Development Kit (ELDK) that was maintained by a company called Denx (www.denx.de). Denx had made a port of a non-commercial version of Yellowdog Linux for the Lite5200 board. Yellowdog Linux is essentially the Red Hat distribution but built specifically for the PowerPC architecture. Denx also had their own open-source boot-loader namely U-boot which they recommended using instead of the built in Freescale boot-loader of the Lite5200. U-boot is a much more powerful boot-loader that supports booting from multiple devices as well as providing file-system access from an IDE device. After getting U-boot loaded onto the Lite5200 I was able to load the Linux Kernel into the Lite5200 flash memory and then either mount the file-system from an IDE hard drive or using NFS and mount it directly from a folder on my desktop PC which was more useful for development work.


The next stage in development process was to start writing an application that could read incoming data from a serial port, manage and trigger cameras and then package image and measurement data into a format to be stored on disk. Natcom had previously developed a stand alone speed measurement device product that could interface to piezo strips installed in a road surface, perform measurements on signals sensed from the piezo strips and then transmit measurement data through a standard serial port. The transmitted data contained information about which piezo had been activated, speed information and vehicle classification information. The response time of the speed measurement device was very fast and could transmit speed measurement information in less than 1ms after sensing signals from the piezo strips. In a traffic camera application is it extremely important that the timing delay between measuring a vehicle and triggering a camera is known, guaranteed and kept to a minimum. I had to write a serial port interface to receive data from the speed measurement device, parse this data and determine whether to trigger a camera. It was essential that this part of the software executed in a reliable known period of time to guarantee that the image capture took place within a known window of time after the measurement was taken. As it is Linux is not considered a real time operation system, however there are mechanisms in the kernel that one can make use of that deliver good real time performance, one of which is signals. I made use of a serial port driver application that used a callback routine initiated by a signal and built my serial data parser in this callback routine. Thus the callback function would execute within a separate thread from the main application. The requirements for the parser routine were complex and it took a number of reworks to get it really robust. I also had to write a special module to control the cameras. This module not only handled camera initialization and image capture, but also had to handle and control shutter times and exposure settings. I wrote my own kernel driver to control a custom piggy back interface board we created for the Lite5200.


The camera devices we used were FireWire cameras. There is a standard specification for FireWire cameras known as the DCAM spec. There are also Linux drivers and libraries available which support FireWire and DCAM cameras (libraw1394 and libdc1394). However these libraries did not provide the exact features I need for the cameras, such as one-shot triggering or control of multiple camera devices at the same time. Through the course of the development work I had to make numerous modifications to the libdc1394 library and some of the kernel drivers to achieve the correct functionality from the system. I also encountered a bug in the serial port driver that came with the ELDK. The problem occurred when one had opened a serial port and then closed it. When one tried to re-open the serial port the kernel hung. I tracked this down to a pointer being set up to point to the wrong hardware FIFO. When the serial port was closed the lower level serial line discipline driver attempted to flush both the TX and RX FIFOs, however with the pointer pointing to the wrong FIFO, this never occurred. When the user-space application tried to re-open the serial port the kernel became locked in the kernel driver and never returned control to user-space.


Once images and data had been captured by the camera and serial port routines, the data had to be packaged in an encrypted format and stored on non-volatile disk. I wrote an image processing routine that printed a text header onto the image showing such information as was legally required for traffic camera images, converted the images to JPG format and then packaged the images and binary data into a single signed and encrypted file that was written to disk. Instead of trying to write my own functions to write data to DVD I made use of the POSIX fork and spawn functions to create a new child process that spawned the DVD+RW-tools binaries which took care of the writing to disk.


The Lite5200 platform I was working on had fairly limited computing power, it was a single core 400MHz processor with 64MB RAM, half of which was consumed by the operating system. I had to create an optimized custom build of the Linux kernel, using only those modules which were required for the operation of the system. I also had to structure the software for optimum performance and avoid bottle necks. The camera system was required to be able to capture up to 10 infringements per second. But the platform itself was not capable of processing all 10 image and data packages in one second as well as writing them to disk. So I made use of queues and linked lists to queue the data coming from the real time serial callback routine, thus allowing the image and data processing to take place in non real time. I also created very comprehensive data logging and statistical reporting functions, logging all system data to file for health monitoring and debugging purposes.


The first camera system that we developed was for a fixed site application where the system would be expected to operate unattended for months with little operator intervention aside from retrieving the written DVDs at regular intervals. The hardware had to operate in a tough environment in a kiosk by the roadside and endure high temperatures from a baking sun during the day and freezing temperatures at night. The cameras themselves had to operate in similar conditions mounted inside a camera head on top of a pole. The application software, kernel and operating system also had to reliable and bug free and was expected to be capable of recovering on its own accord from any conceivable glitch. Thus the hardware and software went through some very rigorous testing before the first system was installed for active use. We built a test generator circuit that would synthesize piezo signals of all types of vehicles traveling at all sorts of speeds. This was connected up to the camera system and left to bombarded the system with generated signals over long periods of time exercising all elements of the software. When I encountered program or operating system crashes as a result of these tests I was able to iron out the issues and bugs making use of the collected log and statistics data. As a final belts and braces approach I implemented a parent “monitor” application that started up and monitored the main camera application keeping it alive. I also made use of the hardware watchdog timer function on the Lite5200. Thus in all eventualities the system was able to restart and recover itself no matter what glitch may have occurred. I was responsible for getting the system through EMC testing, type approval and certification.


Although I was the main engineer in charge of the project, other company staff were involved from time to time in developing various aspects of the system such as some custom PC boards and the mechanics of the systems. Once the first fixed sites were operational, the partner company requested the development of a variant of the camera product for use as a mobile laser camera. At this stage another engineer had joined in working on the project full time and he took ownership of the mobile laser variant, building onto the existing software application the functions required for that system. All the software was under source control and we used CVS. My colleague also added a GPRS modem to the system and arranged a virtual private network that all camera systems would connect to automatically. This network enabled us to log into the camera sites using a secure shell and download log data using secure FTP. This gave us remote maintenance and monitoring capability on all installed systems. Using these capabilities I was able to diagnose camera faults at sites anywhere in the country and give maintenance staff at the sites instructions on how to rectify the faults. I was also able to analyze performance data such as system operating temperatures gathered over periods of months without interfering with the camera operation or having to make costly trips to all the sites.


A third engineer joined the team specifically to add Red light infringement capabilities to the existing fixed site code base. As the product developed I was became heavily involved assisting production with manufacture of the camera systems as well as visiting customer sites and dealing with issues.


My employers and their partner company entered into negotiations with a company in Australia with a view to developing a mobile radar camera variant for their requirements. I made some modifications to the existing software to support a radar speed measurement device and was sent to visit the client in Australia to demonstrate our capabilities with the modified equipment and discuss their requirements. Following this visit the Australian customer contracted us to develop a custom mobile radar camera solution for their requirements.


At the outset of the development of the mobile radar camera project I was technical team leader on the project working with the two other engineers and another more senior engineer acting as project manager and liaising with the customer. Since the customer had some unique requirements that would have been hard to meet with the existing camera software code base, I decided we should begin this project with a clean slate, but making use of all the knowledge we had gained from the existing systems. As we were very familiar with the limitations of the Lite5200 board in such systems we knew the new camera system called for a higher performance platform so we opted to use an embedded EBX i386 motherboard solution from Ampro (www.adlinktech.com). My main task in this development effort was to design a software architecture and system that would meet all the requirements of the customer (of which there were many). The most demanding requirement was that the customer wanted to be able to view a live video feed from the camera on a touch screen, but at the same time be able to take a photo of an infringement taking place within a specified time window. This required careful design of the data paths through the system. My two colleagues took on the main coding tasks whilst I handled various side tasks such as the hardware kernel drivers and low level hardware API functions. I was also in charge of the hardware development and supervised other colleagues in laying out PC boards for the system. At this time the company was using Mentor Graphics Pads for laying out PC Boards.


When the system was partially complete and functional I took it to Australia for the customer to view and performs some initial tests on. From these tests the customer gave their feedback about performance and some requests for alterations to the functionality. The mobile radar project lasted from February to October of 2007. In about August 2007 the Australian customer's existing contract to supply traffic camera and management systems in their state was coming to an end and they had to submit a tender for the new contract. Unfortunately the customer lost their contract so although they purchased 5 prototype camera systems from my employer, the project did not go into formal production. As a result of this lost opportunity and for various other reasons my employer decided to pull out of the partnership with the other South African company and terminate all further camera development work. They also negotiated to sell off the camera IP to the other partner. They also ceased production of camera systems. By this time there were over 100 each of the fixed site and mobile laser cameras systems operational in South Africa.


During the camera development period other Natcom engineers had been involved in other projects including the secure cordless communicator. They had developed an FPGA and microprocessor solution along with some RF hardware. Initially after working on the camera project I was tasked with developing a portable antenna solution for the cordless communicator but then took over the software for the project after one of the engineers left. The software was a bit of a shambles, having been passed between a number of engineers. It had been hacked together to operate the hardware and demonstrate its capabilities, but was in no shape to be worked into a proper application. The software was built on FreeRTOS, the open-source real time operating system and the processor was an Atmel ATMega2561. The development environment was Atmel's AVRStudio and the compiler was GCC for the AVRs. I had to start by restructuring the software into distinct driver modules and individual tasks and then build it into a structured application on top of the operating system. I encountered a number of problems with the FreeRTOS port for the AtMega2561 and had to do some debugging and fixing of the operating system code itself. I also built in some mechanisms to help profile the performance of the software and OS. This included toggling port pins when the kernel changed context and switched tasks.


Whilst working on the cordless communicator project I developed a bi-conical antenna for in-house EMC pretesting of new products before they were shipped off to a certified EMC test laboratory. The intention being to identify and fix EMI problems before incurring the costs of having the equipment formally tested.


The final task I performed for Natcom was the rework of a vehicle radio intercom system. This was an existing product but it had a history of problems and the design responsibility had passed through a number of hands without anyone actually solving the problems. I was called in to fix the problems. I identified a number of fundamental flaws in the design and recommended a rework of the circuit. Around this time I had indicated to the company that I intended leaving and moving overseas to the UK. I therefore undertook to rework the design and leave the company with a good working article that they could put into production. In just over 2 ½ months I completed the rework having resolved the issues. The rework entailed supervising the layout of 2 major and 5 minor PC boards, manufacture, assembly and then testing the boards myself. I finished up working for Natcom at the end of September 2008.