Thursday, 12 March 2015


In between calculations and doing development work on the engine itself, I have been looking at what will be required for the power and telemetry set up on the test bed.

I've built a few data acquisition and control systems, mostly centred on either the Basic Stamp or PIC type microcontrollers. Over the years I have formulated a set of guidelines to assist rapid system prototyping. These are as follows:-


Each part of the design problem is broken down into manageable portions. The sub-assemblies produced are then combined to form a coherent whole.


In 2002 the DEER report stated that due to rapid advances in component design, leading to rapid obsolescence, component recycling will be necessary in the future for repair of in service equipment.

Indeed, nowadays most electronic equipment is simply thrown away when it reaches the end of its useful life, containing hundreds of perfectly serviceable, usable components. These components can and should be re-used when possible.

Heterogeneous Architecture

This approach to control system design was first enunciated by Whitcomb and Yoerger, of Woods Hole Oceanographic Institute, in their 1993 paper on the Jason MK2 ROV. They argue that most control systems can be split into at least two computational subsystems, namely user interface and control.

The heterogeneous approach attempts to speed up system development by using standard, off the shelf hardware and software for generic system functions: -

“A better alternative for medium and large-scale fast-track development is to embrace heterogeneous architecture at the outset. Use general purpose machines for commonplace tasks such as user-interface and logging, use dedicated real-time machines for control.”

The case is made for the use of commercially available machines and software wherever possible. Whitcomb and Yoerger conclude that: -

“The metric of success in fast-track development is not the uniformity of design, but its rapid and successful implementation.”

Dr. AM Turing

Dr. Turing’s paper "Intelligent Machines" (King's College, Cambridge, 1947) is now widely regarded to have been the first introduction of the software control concept. Turing argued that software based control could produce an extremely flexible system in which very few hardware alterations would be required. Rewriting software would accommodate any problem that arose, or changes in operating parameters.

The basic design of the test bed control and data acquisition system will be guided by these principles. Use will be made of as many standard, readily available components, communication protocols and sub-systems as possible.

With the above in mind I decided to go with a laptop running a GUI that would then interface with a microcontroller based I/O card at the test bed end. Rather than build my own microcontroller board, I went for a kit solution in the form of the Velleman K8061 USB I/O card. The specification of this card is as follows:-

8 analogue 10 bit resolution inputs: 0…5 or 10VDC / 20kohm
8 analogue 8 bit resolution outputs: 0…5V or 10VDC / 47ohm
8 digital inputs: open collector compatible (connection to GND=0) with on board LED indication
8 digital open collector outputs (max. 50V/100mA) with on board LED indication
One 10 bit PWM output: 0 to 100% open collector output (max 100mA / 40V) with on board LED indication.
General response time: 4ms per command
USB Port: 2.0 and 1.1 compatible (USB cable included)

Further details may be found at

As can be seen the K8061 card has a fairly impressive analogue and digital I/O capacity. It took me an afternoon to build and test, using Velleman's own free diagnostic software. This was significantly quicker than had I programmed and debugged my own PIC based board. Here is a photograph of the completed board:-

The long narrow IC to the left of centre at the top of the board is the pre-programmed PIC that handles the USB communication to the laptop. The long wide IC below this is the second pre-programmed PIC that deals with all of the analogue and digital I/O.

The communication routines for the K8061 are contained in a DLL which the user is given access to. This enables custom control applications to be written in a variety of languages. That said, one of my chief reasons for wanting to use the K8061 was my choice of Profilab to develop the GUI on the laptop.

Profilab is a graphical programming language for the development of control systems. It is somewhat similar to NI LabVIEW. In the Profilab hardware library there is a module for communicating with and controlling the K8061. You can read more about this software at

My first step was to attempt to interface one of my K type thermocouples to the K8061 and obtain a temperature readout in Profilab. Initially I was going to design and build my own thermocouple pre-amplifier, based on the AD8495 IC. Whilst researching this I found another excellent kit designed and produced by Dr. Matthew Little of re-innovation, here in the United Kingdom. More can be found at The construction was straightforward, although I had to solder the tiny SMD AD8495's to the PCB by hand, something I'd never attempted before. Fortunately I quickly got the hang of "drag soldering".

I got four of these boards, here is a photograph of a completed one:-

You can see where this is going; any electronics design and construction I would do myself would be restricted to signal conditioning and driver circuitry. This is where the recycling aspect would come in as I have literally thousands of components in my workshop to use up!

I had to connect the thermocouple and AD8495 board to the K8061 via an op-amp buffer due to the relatively low input impedance of the K8061. I used an LM324. It has the great advantage of not requiring a split supply.

Here is a photograph of the test set up. The K type thermocouple is connected to the AD8495 board and thence through the LM324 buffer on the breadboard to the K8061:-

And here is a screenshot of Profilab displaying the temperature in my electronics lab (which my wife continues to refer to as the dining room):-

Now, you are all probably thinking, quite rightly, that a safe distance ought to be maintained between an untested homebuilt rocket motor and it's tester. And you'd be right. Of course, USB only has a range of 3-5 metres....but as Baldrick used to say "I have a cunning plan...." All will be revealed. That is, if I can do it...

No comments:

Post a Comment