Sound and Vision

More on telemetry...

It seems fairly obvious that a device as potentially fractious as a home built liquid fuelled rocket engine would be best viewed from a safe distance. Indeed, Krzycki suggests viewing the rocket exhaust plume by means of a conveniently positioned mirror.

Fortunately things have moved on since 1967. From the outset, a video system was always going to be a part of the telemetry set up I had in mind. Nowadays, small, reliable CCD cameras and USB digital video recording systems (DVR's) can be had for a modest outlay.

I purchased a four channel USB DVR and four miniature CCD cameras from Lightinthebox.com. The cameras are also equipped with a small microphone. Each camera has a flying lead terminated in three RCA type connectors. The colour coding used is as follows:-

Red = 9VDC power

Yellow = Video signal

White = Audio

The DVR features four video inputs through male BNC connectors, hence a BNC to RCA adaptor was required for each one. There is also one audio input. This is not a great worry as I do not anticipate hearing the engine being a problem.

Each camera measures ~ 20mm (0.75") square. They are thus small enough to fit into a tight space. 

Here is a photograph of the DVR unit with all four cameras connected:-

In and amongst this snake's wedding it is possible to see the four cameras, DVR and the RCA to BNC adaptors.

The DVR comes packaged with software to view and record the camera images. The images can be viewed in quad format, or each channel can be viewed separately. Motion detect record is also possible. Here is a screenshot of the software running, with some frankly resistable images of my kitchen:-

And here is a close up of one of the cameras, the lens through the lens, so to speak:-

When these cameras are spread around the test stand, they will greatly improve the safety of operation, as well as acting as a back up and cross reference to any data acquisition set up. Transducers may well tell the story, but a recording of a camera pointing at a bank of gauges is still hard to beat.

And finally...on the subject of telemetry, National Instruments have just released a home version of their industry leading LabVIEW software, aimed at the Maker Movement. It boasts elements compatible with Arduino, and is being offered at a bargain price. Google "NI LabVIEW Home bundle" and you will see what I mean.

More to come, keep watching.

Tubes: A Way Forward?

I've been thinking about chamber and nozzle design a good deal recently. My motivation was to try to come up with a different method of fabricating a thrust chamber. A method that doesn't involve machining the chamber and nozzle from solid, which I've always thought was wasteful. That said, it certainly works. A superlative example is Anders Johansson's long running thread at the Jet and Turbine Owners Forum:-

 http://jetandturbineowners.proboards.com/thread/49/n2o-ethanol-bipropellant-rocket-engine?page=1

So I just wanted to try something different, to see what was possible. You'll remember from my post on cooling that I posited a notional tube bundle chamber for my calculations. What if it wasn't purely notional? I decided to see what it would take to build a tube bundle thrust chamber.

My initial thoughts were based around bending the tubes to shape and stacking them together around a circular manifold, possibly using some sort of temporary centralising mandrel or jig. The idea was to braze the tubes, but my attempts at brazing did not go very well. I had much more luck TIG welding them. After a few false starts to get the TIG parameters right I produced a reasonable weld:-

I didn't use any backing gas here and got away with it; in a production unit I would have to set up an internal argon shielding flow in the tubes. However, cheered by this result I next looked at methods of manifolding the tubes and anchoring them to a manifold. Using 10mm dia. 2mm thick wall metric hydraulic tubing meant it was possible to turn down a portion of the tube to 8mm:-

I used a collet to hold the tube, as seen. Next I envisaged the manifold ring to have a series of holes on a PCD, into which the tubes would be welded. I decided to make a rough mock up of such an arrangement using just two tubes, to see how they sat together and generally get a feel for the problem.

I took a square block of mild steel and cleaned it up in the 4 jaw chuck. I then drilled two holes in it of the correct size and pitch for the tubes. I countersunk one end of these holes. This would mate with the chamfer on the tubes so they'd sit flush to the block/manifold. The four pictures below show cleaning up the block faces, drilling the holes, the countersunk portions and the tube/block fit up.

Centre drills are very rigid and are great for starting drilled holes (as well as for creating centres!):-

The countersunk ends of the holes:-

And the tube to block fit up:-

Ideally the hole for the tube on the right should have been countersunk fractionally deeper, but you get the idea. The number of required holes and the PCD they'd need to be on for the diameter of the projected chamber would put them closer together than shown here. The gap between the tubes in this mock up is about 0.25mm. The number of tubes and the PCD required for the chamber I have in mind would put this gap at just over 0.05mm. I might need to play with the diameter a little to get an adequate gap for the welding. This would also feed into the tube bending calculations to ensure that the throat diameter was correct.

Here is a close up of the machined end of one of the tubes. The chamfer is 45 degrees and this then mates nicely into the 90 degree countersink:-

The dimension from the start of the chamfer to the tube end is 20mm. Finally, here is a photograph of the opposite side of the block showing the tube exits. In the design under consideration this is where the fuel/coolant would exit and cross over to go down the next tube. I machined the block thickness to 20mm so that the ends of the tube would be flush with it. The holes would need to have a countersink to correspond with a chamfer on the tube end to get a nice weld. I tried to do this by hand on one of the holes and made a pig's ear of it; why is it always the last operation that wrecks your part?! Anyway, it isn't too much of a worry and I think you can see what I'm trying to achieve.

I'm back at work now so there will be no more practical updates for a few weeks. You might be lucky though and get a lot of meandering nonsense with some highly suspect calculations thrown in. I bet you can't wait.

Telemetry

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:-

Accretion

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

Recycling

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 www.velleman.eu

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 www.abacom-online.de/uk

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 www.re-innovation.co.uk 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...

Cooling

I haven't posted recently, as you'll no doubt have noticed. A great deal has happened to me since the last time I made an entry here, almost none of it related to rocketry. Those who need to know, know. Suffice it to say, I'm in a much better frame of mind now than I was and I am ready to take up my project where I left off, and begin sharing ideas with all of you.

What I want to talk about today is cooling. Apparently, the engineer who was in charge of the tube bundle development for the Rocketdyne F1 was told to "make sure it doesn't melt". The goal of rocket motor cooling can't really be stated any clearer than that, so here are my thoughts on the subject.

All of my earlier attempts to estimate cooling requirements were based on the approach given in Krzycki, and I tried to compare my engine design to similar sized ones in the literature to get some idea of the heat flux that might be encountered. I decided to adopt a slightly more stringent approach. To that end, I studied various sources on the subject, the chief ones being Huzel & Huang and Humble, Henry and Larson. I also dipped into a lot of the NTRS papers, as well as The RAE's Beta Project report.

The best amateur analysis of the regenerative cooling problem I have found online is that by G N Sortino at Fubarlabs, "Thermal Analysis of Steady State Engines" which can be found here:- wiki.fubarlabs.org/fubarwiki/Thermal-Analysis-of-Steady-State-Engines.ashx

I quickly found, as did the above author, that there are a lot of tricky variables in these equations, and it is not at all easy to know where to begin. Luckily, Huzel and Huang's approach to cooling design is eminently practical. By combining their approach with an engine concept that I felt could be fabricated, I started to make some small headway.

I began by thinking about an engine composed of a tube bundle and with a thrust of 1000lbf. I arbitrarily decided on a tube ID of 6mm, purely on a rule of thumb basis. I then ran a simulation on RPA of this hypothetical engine, the propellants being a 90% ethanol/water mix with Nitrous Oxide. Here are the leading particulars for this thrust chamber as calculated by RPA:-

#---------------------------------------------------------------------------------------------------
#
# Table 1. Thermodynamic properties
#---------------------------------------------------------------------------------------------------
# Parameter Injector Nozzle inl Nozzle thr Nozzle exi Unit
#---------------------------------------------------------------------------------------------------
Pressure 2.0684 2.0661 1.1392 0.1015 MPa
Temperature 1867.3657 1867.1488 1646.1334 995.3005 K
Enthalpy -1347.9581 -1348.3832 -1778.8090 -3060.6928 kJ/kg
Entropy 11.1984 11.1986 11.1986 11.1986 kJ/(kg·K)
Internal energy -2117.3892 -2117.7249 -2457.0646 -3469.2680 kJ/kg
Specific heat (p=const) 1.9622 1.9622 1.9364 2.5923 kJ/(kg·K)
Specific heat (V=const) 1.5496 1.5496 1.5241 2.0981 kJ/(kg·K)
Gamma 1.2663 1.2663 1.2705 1.2356
Isentropic exponent 1.2662 1.2662 1.2705 1.2270
Gas constant 0.4120 0.4120 0.4120 0.4105 kJ/(kg·K)
Molecular weight (gas) 20.1788 20.1788 20.1793 20.2543
Molar mass (gas) 0.0202 0.0202 0.0202 0.0203 kg/mol
Molar mass (total) 0.0202 0.0202 0.0202 0.0203 kg/mol
Density 2.6883 2.6856 1.6796 0.2484 kg/m³
Sonic velocity 987.0341 986.9786 928.2780 708.0312 m/s
Velocity 0.0000 29.1568 928.2780 1850.8024 m/s
Mach number 0.0000 0.0295 1.0000 2.6140
Area ratio 19.9000 19.9000 1.0000 3.3900
Mass flux 78.3036 78.3036 1559.0966 459.7134 kg/(m²·s)
Viscosity 0.0001 0.0001 0.0001 0.0000 kg/(m·s)
Conductivity, frozen 0.2122 0.2122 0.1908 0.1306 W/(m·K)
Specific heat (p=const), frozen 1.9240 1.9240 1.8840 1.7340 kJ/(kg·K)
Prandtl number, frozen 0.5869 0.5869 0.5868 0.5600
Conductivity, effective 0.2177 0.2168 0.1919 nan W/(m·K)
Specific heat (p=const), effective 1.9550 1.9610 1.8920 nan kJ/(kg·K)
Prandtl number, effective 0.5814 0.5855 0.5860 nan
#---------------------------------------------------------------------------------------------------

The first step in the heat transfer calculation was to find the gas side heat transfer coefficient, hg. Before doing this, figures for adiabatic wall temperature and the actual gas side cooled wall temperature were derived.

The adiabatic wall temperature may be found at any point in the chamber by multiplying the stagnation temperature by a stagnation recovery factor, typically 0.9. I decided to model the cooling on the throat case as this would be the most stringent. At the throat, the stagnation recovery factor is 1, so it can be seen from this and the figures above that the adiabatic wall temperature at the throat is about 1867.15 K.

Taw = 1867.15 K

The next figure to determine was the gas side cooled wall temperature, or Twg. Of course there is no way to know what this is, so the approach is to state a figure that it is within the wall material's ability to withstand. I envisaged a tube wall bundle made of 316L tubes welded together. I wanted to keep this below 400 deg C so I decided on a figure for Twg of 300 deg C or 573.15 K.

Twg = 573.15 K

Next, to calculate hg:-

hg = 0.026k (pv/u)^0.8 (1/Dt)^0.2 (Cpu/k)^0.4

Where:-

k = gas thermal conductivity
p = gas density
v = gas velocity
u = gas dynamic viscosity
Dt = throat diameter
Cp = gas specific heat at constant pressure

All of the above values can be got from the RPA table, apart from Dt. For the engine under consideration, standard design equations put the throat diameter at 45mm i.e. 45 x 10^-3m.

With these values in the hg equation, the following values resulted:-

hg = 0.00494 x 861439.4 x 1.859 x 0.0516

hg = 408.2 W/m^2K

Using hg, Taw and Twg the calculation can now be moved on further to gain the throat heat flux, q:-

q = (Taw - Twg) x hg

q = (1867.15 - 573.15) x 408.2

q = 528.2 x 10^3 W/m^2

It is now possible to calculate the temperature of the cooled side of the wall Twc, as follows:-

Twc = Twg - qt/k

Where:-

t = wall thickness
k = wall material thermal conductivity

I had decided to use metric hydraulic tubing for the bundle material. Tube of 10mm OD has a 6mm ID hence the wall thickness t is 2mm. The thermal conductivity of 316L at 300 deg C is about 16 W/m^2.

Hence:-

Twc = 573.15 - [(528.2 x 10^3 x 2 x 10^-3)/16]

Twc = 573.15 - 66

Twc = 507.15 K

This figure of 507.15 K for Twc is rather apposite, as it corresponds to 234 deg C. We know that the oxidiser, nitrous oxide, sits at about 760 psi at STP. We will want to pressurise it above and beyond this value for reasons of both safety and flow homogeneity. If we assume a figure of 800 psi as our pressurant level, then we can use this for the fuel as well. The boiling point of pure ethanol at 800 psi is about 240 deg C. The wall temperature on the cooled side is below this, and this with ethanol/water. By adjusting the coolant pressure we can tune the response to induce some nucleate boiling.

It is now possible to calculate the required coolant heat transfer coefficient to permit the calculated gas side heat transfer and temperature differential. Huzel and Huang give a practical method of doing this:-

hc = q/(Tcw - Tco)

where Tco = coolant temperature. What figure must be used for this? In Huzel and Huang it is assumed that the coolant flowing through the throat tube is in a two pass circuit and has already been through the throat once. A value of 600 deg R is assigned for Tco. This is 60 deg C. I was troubled by this figure as I felt it would be neccesary to account for the temperature increase the coolant would see as it traversed the chamber, let alone the throat. As the flow of the coolant through the tubes is turbulent and is constantly being renewed, it would seem that the instantaneous coolant temperature would be unlikely to approach the values of Tcw in the various parts of the chamber. Therefore I decided to use a "film temperature" for the Tco figure. Film temperature of the coolant can be defined as:-

Tfilm = 0.5(Tcw - Tcs)

Where Tcs = coolant static temperature, i.e. the temperature on entering the coolant circuit.

So for the above case, Tfilm = 0.5(507.15 K - 293.15 K)

Tfilm = Tco = 380.15 K i.e. ~ 100 deg C

So the hc required to achieve steady state in the cooling circuit becomes:-

hc = q/(Tcw - Tco)

hc= 528.2 x 10^3/(507.15 - 380.15)

hc = 4159 W/m^2K 

Recall now that I was talking about using 316L tubes in this design. The tubes have a 10mm OD. For a 1000lbf engine, the fuel flowrate will be about 0.84 Kg/sec. The chamber diameter will be about 200mm. This means a total of 63 tubes to form the chamber. Now, the formula to calculate hc for a given flowrate and tube diameter is:-

hc = 0.023 (Cp m/A) (u/Dpv)^0.2 (k/uCp)^0.66

Where:-

Cp = coolant specific heat
m = coolant flowrate
A = coolant flow area
D = coolant flow diameter
u = coolant dynamic viscosity
k = coolant thermal conductivity
p = coolant density

The coolant transport properties (density, specific heat and so on) were all calculated at the Tco value of 380.15 K. They are detailed below:-

Density = 755.6Kg/m^3

Thermal conductivity = 0.185 w/mK

Specific heat = 3.39 x 10^3 J/KgK

Dynamic viscosity = 0.3 x 10^-3 N-s/m^2

These values were calculated for 90% ethanol/water at Tco of 380.15 K. The thermal conductivity was calculated using the Fillipov equation. Dynamic viscosity was found by using the Refutas equation to find kinematic viscosity and then multiplying this by the density.

Going back to the practical aspect of 316L tubes, I envisaged the coolant circuit as consisting of a series of tubes joined by manifolds to allow the coolant to pass up and down the chamber, thereby splitting the 63 tubes up into groups of coolant passages. It can be seen that the values to be used in the hc calculation are essentially constants. Only changing the number of tubes in a coolant passage group will alter the coolant flowrate and thus velocity. So the problem then became one of iteration to come as close to an hc value of 4159 W/m^2K as was practicable.

It was found that by splitting the 63 tubes up into 21 coolant passage groups of 3 tubes each, the following result was gained:-

21 groups of 3 tubes, each group of 3 tubes forming one coolant passage

0.84 kg/sec / 21 = 0.04 kg/sec 

0.04 kg/sec through a 6mm ID tube gives a velocity of 1.87 m/sec

then:-

hc = 0.023 ((3.39x10^3 x 0.04)/2.83x10^-5) (0.3x10^-3/(6x10^-3 x 755.6 x 1.87))^0.2 (0.185/0.3x10^-3 x 3.39x10^3)^0.66 

hc = 0.023 x 4791519.4 x 0.129 x 0.325

hc = 4620.3 W/m^2K

Recall that the figure required was 4159 W/m^2K. Do these calculations mean that this hypothetical system would be steady state? I'd say yes, tentatively. They are as far as I've got up to now and they feel right. I'm open to all comments and that is why I have posted them here. I'd be very grateful for any thoughts on all of this.

Nitrous Oxide

Apologies, Dear Reader, for the dearth of entries just lately. As you might imagine from the post title, I have finally relented. It is happening. More to follow, do stay tuned.

Hydrogen Peroxide

Definitely not.

Hydrogen Peroxide

Well, maybe...watch this space.