Tracking the Moon (Development of the Medii Software)
Medii is the name of the software that tracks the FRARS 12 foot (3.4 m) dish with high precision onto the moon for the purpose of EME (Earth-Moon-Earth or moonbounce communications – bouncing radio signals off the moon). Medii is named after/for Sinus Medii (a crater near the centre of the moon).
This is a potted history of the Medii development and is based on a presentation which I (John M5AHQ) gave at the FRARS club in 2023.
EME had been running at the club for some years. A number of people have been involved with the project in that time, lead by the pioneering efforts of Julian G3YGF and John G0API. A history of the whole project can be found here.
This article does not cover any of the radio or modulation aspects or the EME contacts. They are better covered in the whole project history above.
I was asked by Jules G0NZO if I would write the software to automate the tracking of the dish onto the sun. If I’d known then what I know now then I would have run a million miles and said “********”. expletive deleted.
Tracking is about much more than software as will become clear. Unfortunately software does not make tracking any more accurate. If anything it makes it a little worse.
The Problem(s)
The moon, as we know, is a moving target. We need to track the moon with an accuracy of about 0.1 degrees in both Azimuth and Elevation.
The beamwidth of the dish is about 0.5 degrees. The moon, as seen from the earth, is 0.5 degrees wide so the FRARS dish nicely illuminates the full surface of the moon without wasting significant energy with a wider beamwidth.
However determining the position of the moon needs to be handled to an accuracy of about 0.01 degrees in order to achieve a full system accuracy of 0.1 degrees. More on this later.
Similarly the position of the dish needs to be determined and this needs to be better than 0.1 degrees accuracy.
There is half a ton of metal to steer. The club dish isn’t a sheet of pressed steel.
The gearbox, or rather gearboxes, have 6 degrees of backlash in azimuth.
The dish has to handle and compensate for movement due to windage.
The dish has to be aligned mechanically to ensure that movement in azimuth and elevation is true movement in azimuth and elevation. A mis-aligned dish will cause one to affect the other and degrade the operation of the automated system. This will become clear later.
How Did It Use to Be Done
Originally the dish had a boresight camera which pointed at the sky in roughly the same direction as the dish. There was a box (not actually a joystick) with 4 buttons on it which would adjust AZ and EL via motors on the back of the dish.
The dish would initially be lined up onto the moon (more about this later) and the moon should appear near the centre of the display. Once peaked a circle would be drawn around the moon with a marker pen on the TV monitor.
One person would then sit in front of the monitor and nudge the dish in AZ and EL to keep the moon in the circle. This was tedious job.
If clouds appeared in front of the moon then the task became quite difficult and it had to be based on a mixture of judgement, moon noise on the radio and a lot of luck.
Automation was clearly needed.
The Solution
The solution, or at least the chosen solution is, well, a classic linear closed loop control system. More details of the individual parts will come later. In summary…
Software is used to determine the moon’s current AZ and EL from our location on earth. Position sensors on the dish give a measurement of the dish’s current position. The two are subtracted to give an error signal which is passed into the control block.
The control block uses this error signal to provide the appropriate drive to the motors and the gears that drive the dish.
When the error reduces to zero (prediction and position are the same) then the motors stop.
Hardware / Software Split
Here the hardware and software split is shown.
The moon prediction, error signal generator and most of the control blocks are handled in software on a Raspberry Pi 3B.
The generation of the conditioning signals for the motors drives is very time critical and is handled in real time processing in a Raspberry Pi Pico.
The motor drive units generate about 80 Volt square waves to drive the motors.
All the parts of this block diagram (hardware and software) are expanded upon below.
Azimuth
The picture shows the dish drive shaft on the left, the two azimuth gear boxes below and the position sensor middle top.
This may all look a bit “Heath Robinson” and perhaps it is. However the mechanics of the system are easily capable of driving the dish and give the required accuracy. A highly engineered solution here would have been outside of the range of the club’s budget.
There are two gear boxes in series which, between them, give 1,015:1 reduction from the stepper motor at the bottom centre right of the picture.
The gear boxes give 6 degrees of backlash, which might seem to be a problem in a system requiring 0.1 degrees of accuracy. However, the moon, and other objects in the sky, always pass clockwise. So, it is possible to track by always driving on the same face of the gears. Only when parking the dish, or driving to a new position, is reverse tracking necessary.
There are a pair of counterweights, not shown in the picture, which hold the dish on the same driving face of the gears.
The position sensor at the centre top is a “selsyn”. The selsyns caused many problems and were later replaced. More about these later.
Elevation
The elevation gearing is a little different to the azimuth. The stepper motor is at the right hand side of the picture and the gear box is a long lead screw shown rising at 45 degrees to the top of the dish.
The gear box gives a maximum gearing ratio of 4,188:1. The nature of this type of gearing is that the gearing ratio is not constant for all elevation angles.
This system suffers from considerable mechanical resonance problems in the dish and lead screw. A consequence of this is that the stepper motor can only be driven to a maximum of 7,000 pulses per second before the dish starts to shake violently. Indeed the mechanical resonance changes for different angles of elevation and the elevation drive has to be profiled in the Medii software to avoid these resonances.
There is a brown protective covering shown and a similar one on the other side of the dish. One of these holds the elevation “selsyn” sensor and the other holds the more modern sensor which replaced the selsyns due to the problems which will be described later.
The picture also shows two counterweights which balance the dish in elevation and make driving the dish in elevation require much less force than would otherwise be the case.
Motor Drives
The stepper motors are driven by pulses from commercial motor drive amplifiers at 80 volts peak to peak. These drives need to handle high short instantaneous current surges. Each pulse produces a small movement in the dish in azimuth / elevation. Consequently the drives run quite hot.
The 80 v square waves with high current spikes from these drives produce a significant amount of RF noise. When first tested these drives would produce a local S9 noise across the HF bands and up to 70 MHz. Julian G3YGF spent a lot of time working on this to make the drives fully EMC compliant.
In the early incarnation of the system, the drives were in turn driven with small signal pulses from a PIC micro-controller using software written by Andy G4JNT, taking a demand value coming over an RS232 link from the main controller. This part has now been replaced, see just below.
The PIC micro-controllers and Andy’s software probably gave the best achievable performance with the technology that was available 20 years ago when this part of the system was first built.
PIC Micro-controller Replacement with Raspberry Pi Pico
The PIC Microcontroller was replaced with the Raspberry Pi Pico to provide the small signal pulses to the motor drives. These really are nice little devices and very capable with a number of built-in peripherals and very useful hardware state machines.
One of the built in peripherals is a pulse width modulation (PWM) output capable of producing 5 HZ to 60 MHz.
The hard real time control software was written, as part of the Medii suite, to run on the pico.
As well as the functionality described just above it also now provides the ramping up and down of the motors which gives us very granular control of the dish movement. It became possible to “tune” the software on this device to adapt to the mechanical response of the dish.
Medii Control Hardware
The main part of the controller hardware in the control loop is a Raspberry Pi 3B
The hardware has to provide the facilities for the MEdii software to implement the controller, motor drive communication, Position sensor communications, RS232, ethernet and a position display on an LCD display.
The Medii controller software description follows later.
Where Is The Moon?
The moon is a moving target. It orbits the earth. It takes approximately 25 hours between zenith points (highest point in the sky) on consecutive days. So, the high points get later by about 1 hour each day. It takes 27.322 days to orbit the earth. It is tide locked to the earth so we always see the same part of the surface. Looking down from the north both the earth and the the moon rotate anti-clockwise. It’s orbit is also elliptical.
The calculation is horrible!
We didn’t try to solve this from first principles but instead looked for others who had. We initially used a piece of software written by John Magliacane KD2BD, which in turn was based on some Visual Basic embedded in a spreasdheet which had come from NASA. Unfortunately this didn’t provide us with the level of accuracy that we were looking for (about 0.01 degrees).
We later found a piece of software from Thomas Alonso Albi of the Spanish space centre. This software did provide us with the accuracy that we needed and it was built into the Medii software. I don’t claim to understand how the algorithm works in this software. However, we’re grateful to Thomas for making this software freely available.
Position Detectors (Selsyns)
These position detectors (selsyns) were originally used to determine the position of the dish. Indeed they predate the Medii software by some considerable time.
A selsyn is fundamentally a synchronous motor in reverse. They were used on aircraft for position sensing. They have a stator winding which is energised at 26 V RMS 400 Hz. There are two rotor windings, 90 degrees apart. The amplitude and phase of the induced current in the rotor windings can be used to calculate the armature position.
These units can be made to give a very accurate position indication over a small range of movement. However they don’t work well over a large change of movement and in particular, suffer from dropouts at the cardinal points where the amplitude of one or the other signals from the rotor windings falls to zero.
Original Position Decoder
NEC made this decoder to work with the selsyns. Along with the selsyns, the decoder was obtained from a site decommision and was adapted to our use.
As previously said, the system was designed to provide high accuracy over a small range. The decoder has 20 trim pots on the analogue channels to calibrate out the errors over this small range. Over a large range the decoder was much more inaccurate (+/- 1.5 degrees at the worst points).
As well as the inherent errors it introduced it is likely that the components in the analogue circuitry had drifted over the years and introduced more errors.
Indeed the errors were so big in the position sensing system we were unaware that the errors were also masking errors coming from the alignment of the dish.
Rebuilt Position Decoder
The original NEC decoder was seen as the weakest link in the position decoding. I built a modern replacement for that decoder using two soundcards to do analogue / digital conversion, a Raspberry Pi and some op-amps for the higher voltage analogue circuitry.
I also wrote software for converting between the digitised inputs and the absolute position output. This included writing some some very deep digital bandpass filters in software to reduce the system noise to an acceptable level to produce a resolution of 2 decimal places in the position readings.
I can’t overstate the amount of digital filtering required to reduce the noise to acceptable levels. The digital filters in software had 200 taps on the filters.
A resolution of 0.01 degrees was achieved. However the inaccuracies in the position readings over a wide range were just as bad as with the NEC box described above, about +/- 1.5 degrees. In reality not all of this error was down to the position sensing. We would later discover that the mechanical alignment of the dish was also introducing significant errors.
After months of work trying to improve the accuracy in this system we eventually abandoned both the selsyns and analogue decoders in December 2021.
This was a real low point in the project, both in terms of technology and team cohesion. We had largely spent two years going down a blind alley and should have abandoned this solution 18 months earlier when it was determined that making this tracking technology work was going to be an uphill struggle.
New Optical Digital Encoders
These digital absolute position encoders are manufactured by the German company “Sick”. The normally sell for £700 each and we needed two. Not a cheap solution. However we managed to purchase a pair second hand for very much less.
The absolute position encoders use optical techniques internally and provide 262,000 points per revolution. The internal software processing in them gives a resolution of better than 0.01 degrees and a repeatable accuracy to any point of 0.04 degrees. This gives us the accuracy that we need.
The interface to them is ethernet using an industrial automation protocol called CIP which operates over TCP/IP. Unfortunately the specs for CIP are not published, other than in a closed industry forum. Consequently I had to reverse engineer the protocol using snippets of information that I could find on the web and by using Wireshark. This was a real pig and I came close to abandoning these device at one point. However I did get there and we now get position readings from these devices.
The Medii software was modified to work with these devices and the improvement in accuracy was immediately obvious. However it also, for the first time, revealed the errors that we were seeing in the mechanical system. More on this later.
Software Core of The Medii Controller
The software core is the block marked “Control” above. This is fundamentally a “proportional controller” within a closed loop system.
The gain of the system was set such that the system was slightly under-damped, which generally gives the quickest time to reach the demanded position.
Job done? Absolutely not!!!! See the next slides.
Backlash / Azimuth Counter-Weights
As previously stated, there are two gear boxes in series (with a gear ratio of 1,015:1 and 6 degrees of backlash) along with a stepper motor in the blue housing. Alongside you’ll see one of the azimuth counter-weights inside the metal basket. There is another on the far side of the dish.
Despite the backlash, the objective is to track objects across the sky in a clockwise direction. The mechanics have been designed to overcome the backlash for this purpose. Drive is normally always in one direction when tracking. When slewing back to another position the counter weights pull the dish back to prevent having to drive through the backlash. However this is just part of the story. See the diagram below.
This is a very crude model of a gearbox which shows the backlash. When the gears are engaged face A-A or face B-B then the gears are being driven but these is a gap between A-A and B-B across multiple gears and this leads to the 6 degrees of backlash that we see.
As previously stated, driving clockwise in not a problem because the counter-weights will hold the gears on B-B. However when slewing anti-clockwise, the drive will move into the backlash until the engagement is A-A. This effectively means “crashing” through the backlash which over time will damage the gearboxes and weaken other parts of the mechanical system.
A mathematical model was created and simulated in software to show the effect of driving down and to determine how far through the backlash the motors had driven. This would allow for some deceleration as A-A is approached until the natural speed of anticlockwise movement is matched (due to the effect of the counter-weights pulling the dish round). This would allow a soft landing on A-A.
This mathematical model was built into the Medii software and, amazingly, this technique works remarkably well.
Mechanical Resonance in Elevation Movement
The diagram shows the lead screw on the Elevation drive.
Unfortunately there is a mechanical resonance in the whole system which manifests itself when moving in elevation. The frequency of this resonance varies with elevation. Also, the speed of elevation drive to reach this resonance varies with elevation.
Driving elevation at full velocity would shake the dish and the mounting to pieces.
The elevation velocity has had to be profiled in software starting at a low velocity when the lead screw is at full length and increasing up to to 45 degrees, then full speed from 45 degrees to 60 degrees.
After 60 degrees the lead screw tightens and the velocity has be profiled to ramp down again from 60 degrees to 85 degrees.
The moon never reaches these high elevations however it was desirable to be able to drive to these high elevations to allow for future radio astronomy experimentation in the future.
Safety Limits
Unfortunately not all points are reachable with the dish. it is possible for the dish to crash into its own mounting or into the cabinet shown above at the rear of the dish. This has required generating a safe envelope of movement.
The dish cannot be allowed to crash under software control. The damage could be very expensive to repair.
The solution sounds simpler than it really is. The Medii software has to decelerate as the safe limit is reached. More tricky however is when a vector between two points passes though a zone which is outside of the safe operating envelope. Here the vector has to be be split into multiple vectors to allow the dish to move safely from one position to the other. The Medii software has been written to handle this.
Input / Output Filtering
Sudden changes in the speed of the motors is not a good thing. This stresses the mechanics and leads to failures.
The stepper motor pulse frequency is ramped up and ramped down to fit the time constant of the overall mechanical system. This is a real time filter and is written to operate in the Raspberry Pi Pico.
The input data from the sensors is not necessarily smooth. For example, the windage on the dish cause high frequency variation in the data coming from the samples from the position sensors.
To prevent the dish from twitching as it tries to react these high frequency changes in the input data, the input is filtered / smoothed to show gradual changes. This filtering takes place in the main Medii software.
In both cases, low pass digital filters are built into the Medii software.
Multi-Tasking in The Medii Software
The Medii software is executed serially in a single thread. However it has to deal with many real time processing tasks, apparently in parallel:
- Motor pulse rate output.
- Position sensor data input.
- Prediction of the next position while tracking the moon (or other object).
- Iterating the control loop.
- User I/O – HTML built in server.
A lot of consideration went into deciding whether to use thread processing or put everything into a background loop. Both techniques have their advantages and disadvantages. In the end the decision to go with a background loop driven essentially by the difficulty of debugging real time threaded programs.
So, everything above happens in the background and one iteration of the loop is 50 ms. This was tough, but not impossible to achieve on a raspberry Pi 3B. The software had to be highly tuned to meet this constraint.
Web Interface
The Medii software went though a number of iterations of the human interface in its early days. However the most flexible way of handling the user interface was to build a web server into Medii. This allowed control of the tracking not just from a browser on the desktop PC but also from a browser on a mobile phone. This made it possible to work on the dish and be able to control its tracking at the same time.
A typical display, shown above, has distinct control and status areas. The control area easily allows for tracking or for going to specific co-ordinates. The status area below shows the demanded and actual positions of the dish and the current action.
System and Control Errors
It is important that a large mechanical system system like this fails gracefully if an error occurs. This protects the dish and, more importantly, the people who may be working on it.
Medii detects communication failures with the peripherals. If a peripheral fails then the dish movement is brought to a stop and it attempts to restart communications with the peripheral and consequently recover from the situation.
A watchdog was also built in so if the background loop processing does not happen in the specified iteration time then the motors will ramp down and the system will stop.
Debugging, Tuning and Testing
it would have been very easy to damage the dish while debugging as the Medii software produced unusual and unexpected outputs in it’s early stages of development. This was considered from the outset and mitigation measures were taken.
A test mode was built into the Medii software to emulate the behaviour of the dish and emulate both the hardware and software of the peripherals. This test mode allowed for debugging to take place in a controlled environment before any software was released onto the control of the real mechanics.
The model of the dish created was very detailed and accurate and even emulated the backlash in the gear box.
The consequence of this is that debugging was quite easily undertaken and there were no real surprises when the software was run with the actual mechanics.
Work Hardening
Well, it works on paper but will it work in practice? The whole system (hardware, software, mechanics, cabling, etc) need to work together and keep working together reliably and under all environmental conditions.
Additionally, the system had to be “Julian Proofed”. Julian G3YGF will always be able to find a way of breaking a system. Once Julian can use it then you know that you’re nearly there.
The whole system has gone through considerable work hardening and Julian proofing over the last couple of years. Nevertheless there are still bugs to find. They are becoming more esoteric and much harder to reproduce and to find.
Position Errors
Position errors come from a number of sources which include:
- Dish alignment not being dead true.
- Inaccuracies in the prediction.
- Sensors not initially set to the correct directions.
- Sensors not perfectly positioned (eccentricity).
- Errors from the sensors.
As stated earlier there was an undetected dish alignment error, which was masked in the early days by the other errors. once we moved to the new position sensors, these errors manifested themselves clearly.
A dish out of alignment will produce errors in azimuth which are a function of the elevation. More on this later.
Julian G3YGF brought along his theodolite to ensure that the central drive bearing was perfectly vertical. Spirit levels were also placed on the beams at the back of the dish and the dish rotated to determine if there were alignment errors. Sometimes the error was no more than width of the meniscus in the bubble of the spirit level. This was enough to cause noticeable errors when tracking.
Hunting for the Moon
Fortunately we have two ideal references for aligning and calibrating the tracking system, the moon and the sun.
We know where both the sun and the moon are at any point in time. Also both the sun and the moon will generate noise at 10 GHz which can be detected. The moon generates noise which is about 2 dB above the cosmic background noise floor and the sun about 16 dB.
Initially the dish was totally out of calibration. The sensors were set to roughly the right position but could have had been out by as much as 45 degrees. When dealing with a dish with a beamwidth of only 0.5 degrees, finding the moon is not all that easy.
It is easier during initial calibration to find the sun, with its much larger noise footprint. This was used to set the initial offset calibration parameters on the data coming from the position sensors.
After that it was possible to steer straight to the moon and observe the small peak in noise from the RF noise coming from the moon.
The display above shows the signal strength as we move dish across the sun. It is showing about 14 dB of sun noise. This is a little bit low and the RF system has been improved since this measurement was taken.
Errors Remain!
Despite all of our efforts, large errors remained as shown in the first graph above, showing azimuth and its error from true. This was taken by tracking the moon over most of a day.
I think it’s fair to say that there was a lot of finger pointing at this stage. However I suspected that we still had alignment problems. I plotted the Azimuth against the elevation error, as shown in the second graph. This showed a near straight line and proved to be conclusive that we were still seeing alignment errors.
We re-checked the alignment of the dish, theodolite and spirit levels out again! We had indeed made a mistake in our initial alignment and the drive bearing was not vertical.
Following a re-aligment we performed another long (and tedious) calibration run on the moon. This time the errors across the whole run were no worse than 0.1 degrees and we had indeed achieved our original objective at the outset.
Tracking Other Objects
The Medii software supports the option of tracking other objects by uploading an “ephemeris” data file to it.
NASA JPL provide, absolutely free, the tracking data to a number of celestial objects in the Solar System.
Indeed any organisation that provides ephemeris data can provide a track which can be uploaded to Medii.
Long Term Predictions
Since completing the main Medii functionality, some further enhancements have taken place. One of these is to include long term predictions for the moon for the following 2 years. This allows for long term planning of EME sessions.
The graphs show the trajectory of the moon and the reachable limits of the dish combined with the tree line on the horizon. The top graph is time vs elevation on a particular day. The bottom graph is azimuth vs elevation on the same day.
If the orange line is above the line then the moon is visible to the dish.
These graphs are showing that there is only limited visibility of the moon although there are a couple of usable hours in the afternoon. On a good day the moon will reach an elevation of 60 degrees and easily clear the trees, as shown in the graph below.
Fraser Shepherd Award
It was gratifying to win the Fraser Shepherd Award at the RSGB awards ceremony in 2023. This was not just for Medii but for our whole EME system and specifically for “Research in Microwave Applications for Radio Communications”.
The photo shows the team that has worked on the system in recent years, L to R … Carl G6NLC, John M5AHQ, Julian G3YGF, John G0API and Rob M5RAO.
Others who have been major contributors over the years include Paul M0EYT, Jules G0NZO, Andy G4JNT and Alex M0GJR.
Conclusions and Next Steps
I’ll go back to my original statement. If I’d known then what I know now then I would have run a million miles. However the important thing was to achieve our objectives which we did.
This is the latest in an ongoing development that started 30 years ago. This work on the Medii software was a logical next step in the development.
In terms of next steps for Medii, an area that is bubbling away at the moment is radio astronomy and tracking bodies outside of the solar system and measuring the radio noise from them. There will be another article when this progresses.
There are also developments in other parts of the overall system. There will be more articles as these come to fruition.
If you would like more information about this or any of the other EME activities at FRARS then please contact us using the contact form here.
Article by John M5AHQ, 4 December 2023.