Fire-o-matic: the home made Fire Machine

This project is firmly in the category of things you should not try making at home, but is great fun nevertheless… it’s a home made “Fire Machine” which launches jets of flames and fireballs when you switch it on:

This is obviously quite dangerous, so I seriously wouldn’t recommend making one of these. You can buy them ready made on eBay (although they are pretty expensive).

Anyway, rather than write up all the details of this project, I’ve taken some photos and videos of the main components instead. This video shows the solenoid valve components and how it was assembled (mostly out of scrap parts):

Here’s another video showing the electrical parts. It’s actually fairly simple, so there’s no real need for a circuit diagram/schematic:

This is where I originally got the inspiration from (Chinese made DMX fire machine):

Gaggia Classic Boiler: step response, lag and temperature drop rate

Partly for my own notes, here are the results of some simple experiments with the Gaggia Classic boiler, to better understand its behaviour. Prior to these tests, the machine started out at ambient temperature of around 21°C. The temperature sensor is the TSIC 306 mounted in the same position as the original brew thermostat. There was no portafilter fitted. The tests were carried out on 240V AC mains in the UK, and this is the original Gaggia Classic with an Aluminium boiler.

This first graph shows the temperature (blue line) in °C versus time in seconds for a step input of heat at full power for 4s. The red line shows the timing of the heat pulse. Note the lag of about 4s before any measurable change in temperature after the element is switched on. In this example, the starting temperature was 21.7°C, the peak temperature was 29.8°C and the temperature rise was 8.1°C.


This second graph shows a step input of heat at full power for 8s. Again, there is a lag of about 3s before the temperature changes. Here the starting temperature was 23.2°C, the peak temperature 39.1°C and the temperature rise was 15.9°C. The original data can be downloaded as a CSV file.


Here’s a longer sequence, showing the first 35 seconds of the boiler heating up from “cold” after the heating elements are first switched on. The heating elements were on for the full duration of the graph below. Again, it takes 4 seconds before the first change in measured temperature. After 12 seconds, the temperature rise becomes almost linear, with a rate of increase of about 1.83°C/s (straight line fit to a linear subset of the data in Excel). The original data can be downloaded as a CSV file.


For the final test, the machine started at about 26.9°C and was driven up to 93°C under PID control then allowed to naturally cool down, to see how fast the temperature drops. Again, the data can be downloaded as a CSV file.


The initial temperature drop from 92.9°C to 90°C takes 29.25s, which is about 1°C every 10 seconds (0.099°C/s), within the small region between 90°C and 93°C where our temperature controller operates.

Measuring Ulka EP5 Pump Inductance

Having previously tried to estimate the pump inductance of the Ulka EP5 Pump, and without really being certain of the accuracy, I decided to try and actually measure it. Unfortunately, this is made difficult by the series diode built into the EP5 pump. Although I had a spare pump, I didn’t want to completely destroy it by opening it up, so I decided to try and reach the terminal by performing “minimally invasive surgery” on the pump…

To start with, shining a torch through the plastic pump body reveals the location of the metal tab terminal on the solenoid, and the series diode:2016-05-04_ulka_exam1

Having done this, a Sharpie pen was used to mark a point above the metal tab, which was approximately where the “U” is in the ULKA logo as shown by the small black dot below:


Then a pin vice was used to carefully and slowly drill a 1mm hole until it reached the surface of the metal tab, while taking care not to drill too far:


Having done this, we can now directly access both terminals of the solenoid and completely exclude the diode from our measurements. Using a low cost LCR component tester (fish8840 Taobao) it is possible to measure the inductance and series resistance as shown below. Successive readings showed 847.8mH, 856mH and 859.3mH with an average of about 854mH. The series resistance was about 165Ω as measured previously.2016-05-04_ulka_coil_LR

As both sides of the diode are now accessible, we can also check the diode forward voltage as shown below. This shows Vf=706mV and C=40pF:

2016-05-04_ulka_diode_VFCWhen finished, the hole will be filled with epoxy to seal it back up again and make it safe.


The inductance was measured as 854mH and the series resistance was 165Ω. The diode forward voltage is 706mV. These tests are carried out at a low voltage, and without any hydraulic load on the pump. It is possible that the solenoid plunger position may also affect the measurements. Note that the measured inductance is significantly different to the previous estimate.

Heisenbugs; the Dark Side of Debugging

Some of the most difficult software bugs to track down are those that disappear when you try to study them… Heisenbugs! For example, when an issue is reproducible in a Release build, but disappears when you run the software in the Debugger.

There are many possible explanations for this which include differences in memory initialisation, timing, code optimisation, code and memory layout between Debug and Release builds. I won’t elaborate on the details here, as they are already very well covered on stack overflow.

The reason for this post is that we recently encountered an issue in some code which has the following behaviour:

  1. Has a reproducible bug in release mode (not an outright crash or exception, but fails to behave as expected).
  2. Runs perfectly well when started in the debugger, with no issues.
  3. When started without debugging, and the debugger is attached later, several first chance exceptions are seen.

My theory was that the exceptions weren’t being triggered when started from the Debugger because the memory initialisation (or other Debug/Release differences) were preventing the exceptions from occurring. However, there was some debate on this point, with someone else suggesting that attaching the Debugger later was causing spurious exceptions. Their suggestion was that if these exceptions were genuine, they would also occur when started in the Debugger.

I’ve seen this debate crop up frequently enough, that I thought it would be useful to create a very simple example to demonstrate an exception that reproduces in Release, but works fine in Debug. Also, to confirm whether the same exception would reproduce when the Debugger is attached to a running process.

Here is a first attempt at creating a very small Heisenbug demonstrator in C++, which has a deliberate access violation:

#include <iostream>

void main() {
    int *x = new int[3];
    if (x[1] != x[2]) delete [] x;
    delete [] x;

When a Release build is run in Visual Studio 2013, it demonstrates the following behaviour:

  1. When started without the Debugger and a key is pressed, it causes an exception.
  2. When started under the Debugger and a key is pressed, it exits cleanly and works fine.
  3. When started without the Debugger, and the Debugger is later attached and a key is pressed, it causes an exception.

If you run this a few times, you might find that Windows enables the “Fault Tolerant Heap” for the executable, and then you won’t be able to reproduce the exceptions. The solution is to disable the Fault Tolerant Heap for your executable, by going to these keys:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\heisenbug.exe

HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\heisenbug.exe

Then delete the Fault­Tolerant­Heap entry on both of these keys. In my case, only the HKLM version was needed.

Returning to the code to explain how this works, here’s a commented version, explaining each line:

// create an array of 3 integers, without initialisation
int *x = new int[3];

// compare elements 1 and 2 (which are not initialised)
// if they are different, delete the array and leave
// the invalid pointer in x
if (x[1] != x[2]) delete [] x;

// wait for a key press

// delete the array (potential access violation)
delete [] x;

There are two intentional bugs in this particular line of code:

if (x[1] != x[2]) delete [] x;

The first bug is that we are accessing uninitialised memory, because the array x has not beeen initialised. When we compare x[1] and x[2] the result is unpredictable. In a Release build there’s a good chance (but not absolute certainty) that these values will be different, and it will delete the array. Second, after deleting the array, the variable x still contains the (now invalid) pointer address. Later on, when this final line of code executes, it will access an invalid pointer, usually causing an access violation exception:

delete [] x;

However, when running in the Debugger, it’s very likely that the memory will have been initialised by the Debugger, and x[1] and x[2] will usually contain the same value. This prevents the pointer from being deleted, and avoids the access violation. The code runs without issue when being debugged.

This serves as a very simple example of a bug which only appears in Release, and disappears in the Debugger, due to accessing uninitialised memory (as mentioned above, this is only one of many possible causes of such an issue).

Abarth 500 Fuse Box / K1S Dashcam Wiring

I recently fitted a K1S Dashcam (Koonlung K1S) to an Abarth 500, and wanted to have a tidy install with no wires showing if possible. To avoid having it plugged into the 12V lighter socket, I needed to find a suitable place to wire it into the dashboard fuse box. Although the fuse box is described in the manual, it doesn’t indicate which fuses are permanently live, and which are switched live. This information is not readily available on the interwebs either, so I figured it out with a meter and made some partial notes in the table below.

F127.5Right dipped headlamp power supply
F137.5Left dipped headlight and headlight alignment control unit power supply
F327.5ConstantFront, rear and luggage compartment roof lights
F3610Diagnosis socket, radio, climate control, EOBD
F375Brake light switch, instrument panel node
F3820Door central locking
F4315Windscreen/rear window washer pump
F4720ConstantDriver's side electric windows
F4820ConstantPassenger side electric window
F495SwitchedParking sensor, control backlighting, electric mirrors
F507.5Airbag node
F517.5SwitchedRadio switch, Blue&Me, climate control, brake lights, clutch
F535Instrument panel node

Obviously, there are a lot of fuses there which are “safety critical” such as the Airbag, Brake Lights etc. which are best avoided. Also, the fuse layout is probably the same on the standard Fiat 500, but you know… they might not be, so use this information at your own risk!

NOTE: I wrote this article for a 2015 model. On the 2017 model, I noticed that F32 and F12 are no longer populated (no fuses are fitted in these positions, and they don’t appear in the manual!)

The picture of the fuse box in the manual is upside down (for right hand drive models) so here’s a rotated version with the fuse ratings added in blue. The Switched (S) and Constant (C) supply fuses are (partially) labelled in red:

Abarth Fuse Box

To avoid cutting any wiring, I used one of these mini “add-a-circuit” widgets, which allow you make another connection to an existing fuse:


They need to be used with some care, because you could fit the original and new fuses in the wrong places, and fit it in the wrong orientation. As there were no instructions with it, I used the resistance range on my meter to double-check the wiring before fitting the fuses.

In the picture above/below, the left blade is the input side, which needs to go to the live supply in the fuse box. The right hand pin nearest the wire is the output, after the fuse. The original fuse goes in the lower two holes. The new fuse for your added circuit goes in the top two holes, and the output of that fuse is the red wire. Pretty self explanatory really:


When installed in one orientation (12V input to left blade as described above), the input goes through F1 to item A and the input goes through F2 to item B. If either fuse blows, the other item should still have power. However, when installed in the reverse orientation, note that the input will go through F1 to item A but will go through both F1 and F2 in series to item B. So you need to consider the orientation when installing it.

The wire projecting from the side of the “add-a-circuit”, and the fuses projecting sideways can make it impossible to fit in some positions and orientations (e.g. if they interfere with the side of the fuse box). This can limit your choices on which fuses it can be connected to.

Here’s a shot of it fitted in situ on the fuse box. In this case, it’s inserted into F49 (Parking Sensor, control backlighting, electric mirrors). Using a meter, I found that the left terminal in F49 was live with the fuse removed, hence the output wire faces right when installed:


Caution: whereas the left terminal of F49 was live, I found that it was the right terminal of F47 and F48 that was live, so it isn’t the same for every fuse.

For the ground connection, I used an eyelet crimp terminal under one of the two bolts which secures the bonnet release handle to the chassis. This is a very short distance from the fuse box, so easy to run a wire.

Vectrex Buzz Fix… Enjoy the Silence

One of the famous features of the Vectrex is the annoying buzz from the speakers. After a while, it was just too irritating and I decided to try and fix it. Some purists say that the buzz is an authentic part of the Vectrex experience, but I’m sure the engineers who designed it didn’t intend it to buzz 🙂

Unfortunately, the LM386-3 audio amplifier (pictured below) is mounted on the power board, right next to the wires which drive the CRT yoke magnets. The amplifier is fed by a poorly screened audio cable which runs to the logic board. The screened cable is only connected to ground at one end (the power board). Consequently, it picks up a lot of interference…


The usual fix is to install some better quality screened cable, and disconnect one of the ground leads (the theory being that this eliminates a ground loop). However, the new cable may not completely eliminate the noise, because it doesn’t address the issue of the amplifier being located on the power board, and I didn’t like the idea of disconnecting ground. Another approach is to add a pre-amplifier to boost the level before it reaches the LM386.

I decided to try a different approach, by installing another power amplifier, well away from the power board and magnets. Originally, I planned to buy an LM386 chip and assemble an amplifier on strip-board. However, I then discovered you can buy a ready made module built around the LM386 for about the same price as the components:


These modules cost about £0.99 on eBay, and are widely available. I couldn’t find a schematic, so reverse engineered it (below):lm386_circuit

For comparison, here’s the original amplifier schematic for the Vectrex:


The main difference is that the Vectrex has pin (1) on the LM386 not connected, which sets the gain to 20. However, the new LM386 module has a gain of 200, due to the capacitor C1 bridging pin 1 and 8 on the module. With this much gain, we might still get the buzz, and we could also get clipping/distortion.

Fortunately, this is easy to fix by removing R1 from the module (actually R1 is a 0 ohm link, perhaps provided for this purpose). This disconnects the capacitor between pin 1 and 8 of the LM386, reducing the gain to 20, the same as the Vectrex.

The module has two screw terminals for the output, so a couple of short wires in these allow the existing speaker connector to push fit:


Next, I removed the Logic Board and replaced the audio cable with a higher quality foil screened cable, soldering it to the ground and wiper of the Vectrex volume potentiometer, on the component side of the Logic Board:


Although the original Vectrex LM386 is powered from the +9V rail, I decided to power the new amplifier module from the +5V rail on the Logic Board, to avoid having to run a +9V power line from the Power Board. To do this, I ran a twisted pair of red/black wires from the +5V and GND rails nearby the AY3-8192.

The audio cable, 5V and GND are installed in a 0.1″ crimp housing to fit the 4-pin head on the module. The finished assembly is shown being tested outside the Vectrex below, before it was finally installed inside the machine:


To mount the board, I used a self-adhesive cable tie base just inside the cabinet above the speaker. The module is cable-tied to this base.

The end result is a massive improvement, completely eliminating the buzz!

Here’s a photo of the final installation:

As shown above, the 5V power comes from a supply junction between the AY-3-8912 and the 6522, and the GND comes from a ground plane via near the top right of the 6522.

I recently stumbled on this nice video (in German) where someone has tried this same modification:

Vectrex Repair (Black Screen / No Vector)

I’ve wanted a Vectrex Console for quite a while, and finally acquired a broken Vectrex for a reasonable price on eBay (where else) with the idea of repairing it…

It didn’t begin well when the courier who delivered the package left it hidden behind a car… overnight… in the rain:


It was sitting in a puddle, and got a fairly good soaking. Here’s the Vectrex emerging from the box:


Fortunately, after drying it out carefully, it didn’t look like it had sustained any serious damage, so I set about trying to repair the fault.

Exactly as described by the seller, when it was powered on, the game sounds were playing, but the screen was completely black, not even a white dot visible on maximum brightness.

Looking at the troubleshooting guide, the first suggestion for “No Vector” is to “check for +/-5 VDC and -13 VDC at connector J204. Left to Right -5, GND, +5, -13”. When I checked J204 on the Logic Board, the -13V DC rail was missing (just measured about 0.67V which looks like a diode voltage drop). I checked the other end of the -13V wire on P204 on the Power Board, with the same result. This confirmed the wires and connectors were OK, and it was a problem on the Power Board.

From the service manual, here’s a diagram of the -13V power supply circuit on the Power Board:


The two lines at bottom right are the incoming power supply which is about 9~10V AC. The Diodes D106 & D107 and the Capacitors form a voltage doubler, boosting this to 18~20V, which is then regulated by a 13V Zener DZ102.

I switched off power and tested D106 and D107 in circuit with a DMM, and it looked as though D107 was short-circuit. The resistor R106 looked fine. Since there were only a few components, and the 34 year old (!) Electrolytic capacitors were probably not in the best shape, I decided to replace the whole -13V regulator circuit.

The -13V rail is only used by IC301 (the MC-1408P8 DAC) and the circuit diagram even states “TO IC301 PIN3 ONLY” next to the -13V line so, after a quick visual check of the Logic Board and connectors, I couldn’t see any obvious signs of a short on the -13V rail which might cause it to fail again. It’s always worth checking before replacing parts though!

To do this repair, the whole Power Board needs to be removed, which involves removing 5 connectors, removing the HV lead (CAUTION: ensure it is discharged first) and desoldering 2 ground leads, 3 power leads and 4 leads connecting the CRT deflection yoke. The board is secured with two small cross-head self tapping screws.

Here’s a close up of the components to be replaced (C120, C121, C122, D106, D107 and DZ102):


This picture highlights them more clearly:


After removing the components, the most difficult part of the repair was clearing solder from some of the holes connected to the ground plane…

Once the original components were removed, I was able to test them out of circuit and found the following:

  • D106 was OK
  • D107 had failed Short Circuit
  • DZ102 was OK and measured 13.2V
  • C120 measured 44.1uF, 2.1Ω ESR, Vloss 4%
  • C121 measured 49.9uF, 0.65Ω ESR, Vloss 3%
  • C122 measured 234uF, 0.13Ω ESR, Vloss 1.3%

Presumably with D107 short circuit, this may have also damaged C120 by putting AC directly across the polarised electrolytic. In any case, I decided to replace them all with new parts.

For the Zener diode, I used a 1N5243BTR (0.5W, 13V. DO-204AH). The diodes D106 and D107 were replaced with 1N4148 as used originally, and C120, C121, C122 replaced with equivalents.

After refitting all the connectors and soldering all the cables back in place, I left the connector at J204 disconnected from the Logic Board and tried measuring the -13V rail with the DMM probes touching the connector contacts. Initially, it wasn’t looking good as the -5V and +5V rails were present, but -13V wasn’t…. anyway, I decided to plug it into J204 and power on again…. and happily the Vectrex sprung back into life again! Perhaps the DMM probes were just not making a good contact with the connector?

Here’s the first power up after the repair:

For a machine that’s over 30 years old, I was astonished how beautiful and sharp the vectors looked – the display is amazing! (the video above does not do it justice). I’m very excited to finally have a Vectrex to tinker with… now I just need some more games and overlays!

The console has the famous “Vectrex buzz” from the speakers, and I think the next project will be to try and fix that…

Upgraded valve in the compressed air rocket launcher…

The first valve I used in my rocket launcher was a “direct acting” type, which has a very small aperture, limiting the flow rate. Although the launcher worked well in practice, I was curious to see if I could find a better valve, with a larger flow rate to get a more spectacular launch!

Here’s the original layout with the direct acting valve:


After a bit of research, it sounded like an “indirect acting” type would have a higher flow rate (these are also known as “servo operated” or “pilot operated” valves). There’s a good explanation of the working principles here.

As this is just a fun project, I also wanted something quite cheap! The valve I chose was a 12V solenoid with a claimed pressure rating of 0.02-0.8MPa (3psi – 116psi). Note that the minimum is typical of a servo valve, as it will not open without some pressure on the input side. The valve had two 1/2″ BSP male threads for input/output, and another removable plastic plug with 1/2″ BSP thread which is intended to provide access to clean a removable filter. In my case, I removed the filter and used that spare port to attach the pressure sensor.

The new output side of the launcher is pictured below. It’s basically a complete replacement for the assembly shown above, and connects directly to the plastic pipework.


The upright 15mm copper tube is the output, and a longer “launch tube” is attached to that with a push-fit 15mm coupler (allowing it to be removed for easier storage..) The input side is the disconnected compression fitting at the bottom left. The pressure sensor is the cylinder on the right side (car oil pressure sensor).

The new valve did not disappoint! It performs much better than the direct acting valve. The first launch at about 40psi was maybe 3x the altitude with the previous valve at 80psi, showing that the valve flow rate was the limiting factor. Unfortunately on the second launch I lost the rocket in a neighbour’s garden and had to go and ask for it back… ahem.

Estimating Ulka EP5 Pump Inductance

As part of my work to modulate the Ulka EP5 pump pressure in my Espresso machine, I decided to try and simulate the pump in SPICE. This would necessarily be a very simplified model, but might be useful nonetheless to understand the behaviour of snubber circuits for the pump PWM controller. To create the model, I needed an estimate of the pump inductance.

Previous attempts

I could only find one previous reference to the pump inductance online. It’s not clear which Ulka pump was used, but it looks like an E5 type (EP5 or EX5) and a circuit diagram refers to 41W rating (consistent with the 120V 60Hz EP5). They took the approach of measuring the current drawn by the pump at 0.57A and, assuming a line voltage of 120V, calculated the reactance as follows:

XL = V/I = 120V / 0.57A (AC) = 211

With the formula XL = 2πfL = 2π * 60Hz = 377L, the inductance L was estimated as follows (for a 120V 60Hz pump):

L = 211 / 377L = 0.56H = 560mH

However, XL = VPEAK/IPEAK and the above voltage current values may be average or RMS values rather than peak values. For 120V AC mains the peak voltage would be VPEAK =12√2 = 170V. Similarly, when measuring AC current, some multimeters only give accurate results for a sinusoidal AC waveform, and may not be accurate for AC chopped by the series diode in the Ulka pump. This doesn’t necessarily mean the result is wrong of course, just difficult to be certain.

Manufacturer data on the pump

The manufacturer data states that:

  • Ulka EP5 240V~50Hz is rated at 48W
  • Ulka EP5 120V~60Hz is rated at 41W

Estimating pump electrical properties

There’s an integrated series diode in the pump, but the type is not indicated. However, based on similar Ulka pump models described in Ulka/CEMA specifications, the diode is assumed to be 1N4007 which according to manufacturer datasheets have a typical forward voltage VF = 1.0V when IF = 1.0A (noting that there are some small variations in the specifications for 1N4007 between manufacturers).

Attempting to measure the pump coil resistance directly with a resistance meter could give misleading results, due to the internal diode. To overcome this, a known DC voltage and current can be used to estimate the resistance.

With a ~12V DC power supply connected across the Ulka EP5 240V~50Hz pump, the measured voltage was 12.33V and the measured current was 70.1mA. At this relatively low current, it is likely that the diode forward voltage will be less than 1.0V. To estimate the diode VF, an individual 1N4007 diode was connected in series with a 220R resistor and ~12V power supply, giving IF = 51.9mA and VF = 0.775mV.

Assuming that VF = 775mV at IF = 70.1mA, the actual voltage across the coil will be reduced to (12.33 – 0.775) = 11.56V and therefore a first estimate of the pump coil resistance is as follows:

R = 11.56 / 70.1×10-3 = 165Ω

To calculate the inductance, the manufacturer voltage and power ratings are used to estimate the reactance as follows:

Although the Ulka EP5 240V~50Hz model is rated 48W, the internal diode means that the pump is only active for half the cycle. Considering the coil without the series diode, we therefore assume that the AC power consumption would be 96W and use this figure to calculate the AC current:

P=VI therefore I=P/V

IRMS = PRMS/VRMS = 96/240 = 0.4A

Note that the mains line voltage and current will of course vary in practice due to local mains supply quality.

The peak voltage and current are then estimated as follows:

VPEAK   = VRMS√2 = 24√2 = 339V

IPEAK      = IRMS√2 = 0.4√2 = 0.57A

The inductive reactance for an inductor energised by a sine wave is calculated as follows:

XL = VPEAK/IPEAK =  339 / 0.57 = 599.27

The inductance can be calculated based on the reactance and frequency as follows:

L = XL / 2πf

Where f is the mains line frequency 50Hz:

L = 599.27 / (2π × 50)  = 599.27 / 314.159 = 1.91H

However, on closer inspection, I noticed that the exact pump model I tested is labelled 230V~50Hz on the side. Repeating these calculations with 230V, the following results are obtained:

IRMS = 96/230 = 0.42A

VPEAK = VRMS√2 = 23√2 = 325V

IPEAK  = IRMS√2 = 0.4√2 = 0.59A

XL = VPEAK/IPEAK = 325 / 0.59 = 550.59

L = 550.59 / 314.159 = 1.75H

So this estimate puts the pump inductance for the 230V~50Hz EP5 pump at somewhere between 1.75H and 1.91H and the resistance at 165Ω.

Simulating the pump in SPICE

Running an LTSpice model with a 240V, 50Hz AC supply in circuit with a 1N4007 diode and an inductor modelled with L=1.75H, R=165Ω gives the following results:

Iavg=0.34A, Irms=0.46A, Vrms=240V, Pavg=35.67W

This doesn’t look too far off, however it is obviously lower than the rated power of 48W indicated by the manufacturer. Adjusting the LTSpice model inductance to L=1.37H gives results closer to the manufacturer ratings:

Iavg=0.39A, Irms=0.54A, Vrms=240V, Pavg=47.93W

Measuring the pump inductance

More recently, another attempt was made to directly measure the inductance. This was achieved by drilling a small 1mm hole in the pump to access the coil terminal before the series diode. The measured inductance and resistance was L=854mH and R=165Ω. The series diode forward voltage was measured as 706mV.


Modelling the pump as a simple inductor is obviously a gross simplification, as the pump is a spring loaded solenoid, whose inductance will vary as the internal plunger vibrates. Also, the hydraulic pressure in circuit is not considered. Finally, with high frequency PWM switching, the parameters estimated at 50Hz / 60Hz frequency may not be correct.

Nevertheless, the inductance values above when used in SPICE provide a first approximation which may be useful to estimate how the system will behave in practice, and do seem to give behaviour very similar to the real system.

If anyone has any corrections, comments, improvements or information to add, drop me a line in the comments below.

First Rocket Launch

Here’s one of the first few test launches of the compressed air rocket. Please excuse the portrait video, I didn’t film it…

This was about 60psi, although the limiting factor is really the restricted flow rate through the valve. You can hear the air hissing out for a good long while after the rocket is clear of the launch tube.

It’s great fun to play with!

At some point, I plan to try an indirect acting solenoid valve, with a larger aperture. When the weather improves that is…