I like the Perspectives project:  the Firefox plugin gives me confidence that I am not about to be the victim of a MITM attack, and it also gives me enough confidence in the longevity of a certificate that I can usefully accept self-signed certificates for many sites.

One minor concern that I have is that my browsing habits could be determined by those that run the notary services.  The Notary Server Privacy Policy states:

All notary servers adhere to a strict policy of never recording client IP addresses, period.  The Perspectives project and its software will only contact Notary servers that follow this privacy policy. Your privacy is important to us.

I trust these people (although I’ve never met them!), but I’d prefer not to need to trust them.  For all I know, the traffic to/from CMU might already be monitored by some 3rd party unbeknownst to them.

I like the Tor project for several reasons, but I find it too slow for normal use.  However, if I could use Tor for my notary requests…

FoxyProxy is a useful Firefox plugin.  Once installed with Tor support, I can add the following URL pattern to my Tor proxy rule:

*.ron.lcs.mit.edu:8080/*

And all the notary lookups will be performed over Tor!

If you plan to do this yourself, I’d recommend confirming correct operation with Wireshark.  Periodic checking with Wireshark also strikes me as wise, in case the notary addresses change and you need to update the rule.

Gyroc 1 was the first actively stabilised model rocket developed and flown in the UK (to our knowledge). Using a custom gyroscope to give an inertial platform, a digital flight computer and a gimbal-mounted rocket motor, Gyroc 1 was able to remain vertical whilst under power. The project has been predominantly developed by James Macfarlane and Michael Procter, although others have also made valuable contributions.

Please note that this project has nothing to do with the Estes model rocket kit of the same name.

Gyroc 1

My involvement with Gyroc 1 began in 1996, a few weeks before the International Rocket Weekend in Largs. Prior to this, James had already developed much of the hardware and mechanics. Hoping to complete the maiden flight at the IRW, he enlisted my help for the software. The first flight computer (based on a PIC16C84) was built and the majority of the software was written in one rather frantic weekend. Subsequent refinements took place (particularly of the software, which I had hacked together somewhat too rapidly for bug-free maintainable code to emerge) before and during the IRW. Finally, we were in a position to launch the rocket. In what was to become the traditional launch schedule for Gyroc, the launch pad was set up as dusk started to fall. All but the most foolhardy (myself and James) were sent to retire to an extremely safe distance, and the countdown began.

The first flight was made on a D12, giving an initial peak thrust of around 12-14 Newtons, tailing off to just under 10 Newtons. The all-up mass of Gyroc was around 1kg. Consequently, Gyroc managed to clear the 1-foot launch rail, but only just. It managed to hover next to the rail until the motor burnt out, whereupon it fell to Earth. The crowd cheered – we had all just witnessed the first amateur actively stabilised rocket to be launched in the UK, and the flight had been a success.

This pattern was not to be repeated for several more launch attempts. James and I accepted that the first flight was probably more down to luck than judgement, and various changes were made to improve the reliability and repeatability of stable flight. With hindsight, it seems clear that if that first flight had not been a success, we may not have had sufficient confidence in the approach to make it work. But with the tantalising carrot of that first flight, we continued developments over the years.

Gyroc 2

Gyroc 2 was first flown in February 2002. Whilst externally, little appeared to have changed, there were some substantial internal developments. The most significant change was the removal of the custom gyro and the installation of 2 commercial solid-state gyros (at a not inconsiderable expense). We had come to the conclusion (correctly, as it turned out) that many of our problems could be traced to the mechanical soundness (or lack of) of the custom gyro. Repairing the graphite bearing and containment box after every flight should have been a warning that the structure was not ideally suited to the task in hand. Replacing the gyro was a major step forward in the development of Gyroc.

In addition, the avionics was rebuilt around a PIC16F877, thus removing the need for an external ADC. Since the custom gyro was no longer fitted, the gyro spin-up circuit could be disposed of. Finally, the original parachute timer was removed and firing the parachute was entrusted to the microcontroller. The final change was to enhance the gimbal motor mount to support larger motors. Now, with Aerotech 32mm motors, high altitude (>20′) testing was possible.

After another frantic weekend of software development (changing the processor, adding calibration offset code for the gyros, implementing a small integrator), Gyroc 2 was ready to fly. As was customary, the launch took place as late in the day as the RSO would permit. All the extra development proved to be worthwhile, as the flight appeared to be almost flawless. The rocket ascended gently under power, drifting slightly downwind. It remained pointing vertically throughout the burn, with barely discernible deviation. The parachute deployed on schedule, but failed to deploy completely due to the presence of excess masking tape. Since that flight, Gyroc 2 has flown twice more. An mpeg of one of these flights is linked below.

What next?

Since we are now in the rather pleasant position of having achieved our primary goal (namely to actively stabilise a model rocket), we are able to decide where we wish to take the project from here. There are one or two obvious directions that could be taken, but only tentative plans have been made at this stage. I haven’t done anything of note in the last 6 years on this project, although James occasionally makes productive-sounding noises. I’m still at the tentative plans stage!

Further information

I have omitted much technical information concerning Gyroc from this page, for two reasons. Firstly, I didn’t have all the details to hand during the initial composition, and secondly because a friend has already recorded much of the information on another site. Over time, I anticipate adding more material to this page, as I remember and also as I scan suitable pictures. In the meantime, a large MPEG of Gyroc 2 in flight is available. This flight was made in February 2002 in Lincolnshire. Many thanks to David Warman for providing me with the footage.

a ^= b ^= a ^= b;

There are other operators that can be used to do the swap, but in the degenerate case, this essentially becomes the XOR trick again.

Firstly, I ought to address the fact that the above statement isn’t strictly valid C. Multiple side effects within a single expression leads to undefined results. Most compilers will get the ‘right’ answer, but why take the risk for the sake of a few extra characters? It is easy to rewrite correctly (I’ll also remove the combined xor-assignment operator, for clarity later):

a = a ^ b;
b = a ^ b;
a = a ^ b;


If you haven’t seen this trick before, it is probably worth working through an example or two on paper. There are quite a few explanations on the net, if you get stuck.

The reason this works is that xor is a reversible operation. It is further simplified by the fact that xor is its own inverse – that is to say:

(a ^ b) ^ b = a

You can use other operations instead of xor, such as addition and subtraction. Subtraction is the inverse of addition, so you can write the swap as:

The 2nd and 3rd columns show how the values change during execution, and that the end result is that the values in a and b are swapped. It isn’t quite as neat as xor since you need to use two different operators (+ and -) rather than just one, but it is easier to grasp since most of us are more familiar with + and – than with xor. The similarities in structure to the xor version above should be clear.

One thing to note in the above is that I have completely ignored the issues associated with finite register width. What happens when the intermediate values generate a carry? I’ll work through an example, assuming a 4-bit register width. We should use large numbers, since we are interested in seeing what happens when we overflow a 4-bit number. Lets try to swap 15 and 14. In this example, the numbers in brackets indicate what the full-precision result is, before truncating to a 4-bit unsigned representation.

So, both a and b end up with the right (swapped) values. This means that instead of using xor, we can swap values using addition and subtraction and ignoring any carry. By truncating all the numbers in these examples to 4 bits, we are simply doing modulo 16 arithmetic.

We can go further than this, by shrinking the register width. Instead of 4 bits, lets think about 1-bit registers (which will be modulo 2 arithmetic). Rather than work through some examples, we can look at the truth tables for 1-bit addition and subtraction. We can compare them to xor too.

Once you move down to single-bit operations, and ignore the carry, an odd thing happens. Addition and subtraction become the same operation, and both are the same as an xor. This modulo 2 equivalence of operators should start to suggest another way of looking at the original xor formulation. We could say that it is equivalent to performing multiple 1-bit additions/subtractions, in parallel. In other words, it is simply the vector processing version of the addition/subtraction approach with each bit being calculated with modulo 2 operations!

Assumptions

The first assumption to note is that this technique should be applied to single-source/single-sink buffers. That is to say there should be only one ‘setter’ and one ‘getter’ using this buffer.

The second assumption is that in the following sequence, the italicised items happen in order:

1. Put the item into the write buffer.
2. If the next buffer is free, make the free buffer become the write buffer, and the current write buffer becomes free.

(There is a corresponding pair in the algorithm for retrieving data too.) When this assumption breaks down, we can find both the producer and consumer accessing the same underlying buffer whilst assuming that they have exclusive access. This assumption is the crux of the problem discussed by MenTaLguY.

None of these problems are insurmountable, but solving them requires the use of some form of synchronisation (from scattering volatile around to putting a lock or two in place). This seems to defeat the point of Spin Buffers, so instead, let’s find some applications where the assumptions hold true.

Embedded Systems

One place where efficiency of buffering techniques is often paramount is within the embedded systems world. Embedded systems often use (by modern PC standards) underpowered processors, lacking in such features as multiple processors or bus transaction reordering. This sort of environment is one in which the assumptions required for Spin Buffers can hold true. Not all embedded platforms are like this, but they are far from being rare.

In this sort of environment, a traditional ring buffer is a popular choice. By ensuring that data is written and read at the right times relative to the pointer increments, you can make a safe ring buffer without locks. This is based on the fact that memory writes occur in a specific order, which can be verified and confirmed on many embedded platforms.

Comparing Spin Buffers with Ring Buffers

So, given a platform where the Spin Buffer approach would work, and where a simple ring buffer would also work, why would you choose Spin Buffers over ring buffers? What differentiates Spin Buffers from ring buffers?

For Spin Buffers, you can avoid dealing with writing data over a buffer boundary (the buffer wrap problem), since you only need to write up to the end of each of the individual buffers. This is an advantage when writing multiple elements at once, but a fairly minor one in most cases.

Another difference is the total capacity for a given allocation of n elements for buffering. For a simple ring buffer, the total capacity is usually n-1 (an element is often sacrificed to simplify full/empty disambiguation). For Spin Buffers, the capacity is limited to 2/3 n, because at any one time the ‘free’ buffer must be empty. Sacrificing a third of your buffer is not always possible due to memory constraints.

The code required to implement a Spin Buffer compared to a ring buffer is more complex. Examining the author’s examples for both techniques shows that a Spin Buffer implementation is approximately twice as long as a ring buffer implementation. Whilst the execution time for Spin Buffers is likely to be marginally slower, I think a more important aspect is that greater complexity often leads to more bugs and higher maintenance costs. An example of this can be seen in the author’s implementation of the ‘put’ routine for the Spin Buffer. There is a bug which will cause a lock-up if the current write buffer ever becomes completely full.

Finally, if a partially full buffer is not written to for a period of time, then the entire Spin Buffer can seize up preventing the items in the last buffer used for writing from being read. The author highlights this in the caveats section, along with a workaround, but this adds additional complexity.

Conclusions

To conclude, I think that using Spin Buffers in certain environments can be safe. But in such environments, the advantages over a traditional ring buffer are slim and do not outweigh the costs in terms of code complexity and sacrificed capacity.