The Eleventh Hour Result
With deadlines looming, it is a small comfort to know that there are finally some sensible numbers to present.
Proof of a meaningful Power vs Time series was the first glimmer of hope when I logged onto the machine this morning to receive last nights 12 Hour drift scan.
(Right click “Save As” or your local browser equivalent)
- Raw Intensity Plot
The Tin Man and His Brain
Posted by Corsair in Project 301 on April 21st, 2009
With the Day Star burning bright and hot above, both SRTs were subjected to a full service. After noticing extensive oxidation on almost every contact within the mount drive system, it was decided to completely rewire, replace and refurbish all that could be stripped from the machines. What we believed to be of the most importance was the state of the grounding connection on the Southern SRT. In its heavily corroded state it was more than likely the cause of the frequent tracking errors and arbitrary “stow” behaviour.
Tinned Tips
The reed switch magnets were secured to the azimuth drive shaft using a silicon adhesive to prevent slipping, ruling it out as a possible cause for loss of magnet counts. In addition, the homing pin in the limit switch for azimuth control on the Northern SRT was missing its insulation, and while this should not cause a short circuit, I prefer to have my Ship squared away. Liberal coatings of anti-rusting agents and CRC finished the job, and tomorrow a coating of silicon film spray will ensure the machine remains weather resistant for the near future.
Insulated Homing Pin
Corroded Contacts
**EDIT**
After a full service, the Southern SRT did not respond to any input the very next morning. Multimeter tests show that current is present at the drive housing, however the control software does not recognise the hardware. After a further full day of troubleshooting (and some Linux Voodoo Magic on behalf of Dr A Hotan), it turns out our Tin Man just needs a new brain; that is, the hardware interface module. It would appear that the previous interface module has an issue with sending signal, but not power to the SRT itself. Swapping the interface module out with the SRT-North’s resolved this, and so a new box will be ordered.
It may be prudent to order more than one…
Where O’ Where has My Calibration File Gone?
Posted by Corsair in Frustrations, Musings on April 3rd, 2009
It would appear that in the past week, something has happened to the Calibration .cat file I have been compiling for the equipment. Namely, it has dissappeared and in its stead is a string of garbled text. If anything, this serves to remind me that constant backing up and duplicating of documents is an essential part of any scientific undertaking. Interestingly, before the file went missing, a 25 point scan of the sun produced a (semi)-nice, (semi)-round representation of the Solar Disk. After attempting a 25 point scan post-calibration loss, I was greeted with no less than six suns, and a strongly emitting “V” of th 21cm wavelength spectrum.
A 25 point scan is a simple 5×5 grid of bins that are interpolated about the sun’s position in the sky. By using half beam-width bins to map across the sun in two dimensions, we can acheive a rudimentary contour graph of the intensity of the 1419.75 MHz emission line that eminates from our local star. This is purely useful as a calibration tool, as a correctly calibrated machine should produce a perfectly round disk of evenly spaced intensities. Unfortunately, I did not manage to capture an image of the mythical 6-star system that my first readings suggested we exist in, however below is a comparison of an uncalibrated system with a quasi-calibrated system that was aquired six hours into the reconstruction. As can be seen, the Pre-Calibration 25-Point scan shows two coherant sources plus noise, while the Post-Calibration 25-Point scan shows a single (and expected) coherant source with poor pointing.
25-Point Scan Pre- and Post-Calibration
After recompiling the srt.cat and tweaking parameters, I have managed to tighten the 25-point solar scan to a single coherant signal, however the pointing is still off-centre and the shape of this circle does not do justice to the greater circle community.
Operations Safety
I Was perusing the SRT Manual once again today and wrote a simple script to simulate a 24 hour scan of the sky directly above the dish, allowing the rotation of the Earth itself to scan a path. As I was wondering about writing more complicated scripts that would automate the SRT over a period of 24 hours or more, I came to realise an oversight. If the automation script is set to slew the dish at preset times (UT or LST) then there is a good chance there will be significant movement of the dishes during University opening hours. As such, there should be adequate signage to alert anyone on the observation deck that the SRT dishes may move without warning during operation. Whether the signage be permanent and broad in nature, or specific and able to be deployed only during use; there should be some way of warning people not to stand near them while they are in operation.
Additionally, when running extended automation scripts, 6 hours or longer in length, it is unlikely the operator will be present for the entire time (unless the operator is particularly diligent, or has little better to do with his/her time). As such, it would then be astute to assume that one might not foresee potential damage to the devices while running unsupervised. This reiterates Dr Hotan and my prior assessment, stating the need to belay the loose cables and clear the deck of detritus. I must endeavour to find out how the Control programme responds to interference with the SRT movement. If there is no back-emf sensor, if the dish becomes stuck while in operation and the Control programme does nothing to stop the dish movement, then serious damage could occur.
I will explore the feasibility of a webcam to monitor the dish while either being used remotely, or monitoring while an extended script is running.
Supervisor Meeting 050309
Posted by Corsair in Supervisor Meetings on March 5th, 2009
Meeting scheduled for 1300, March 05 2009.
Dr Hotan suggests swapping the Windows based box that is currently attached to the SRTs with a Linux based one. While I have succesfully demonstrated the software can be run on modern Windows environ (namely Vista and W7 Beta 7000), I would rather work in a Linux environ where I feel in control. The Debian Dell in the Astro lab is not curretly being used by the department, and we shall enquire if it can be employed as the SRT control box in the interim period.
A preliminary examination of the mount and its mechanics has been scheduled for this Sunday (080309) where it has been proposed that a full breakdown of the Alt-Azimuth mount is in order. I hope to attempt a series of freehand sketches that show the structure of the mount for future reference, especially in the realm of troubleshooting errors; they are as inevitable as the universal heat death. On this point, Dr Hotan nod that the points most likely to offer up trouble are the extension switches that measure the extension of the altitude arm. In addition, we believe the bearings that guide the arm may have suffered oxidation, and it is they who are responsible for the terribly “jerky” action of the Alt-Extention arm.
My current reading consists of previous student’s reports on using the SRT; Jeff Hodgeson’s Radio Astronomy with the Small Radio Telescope (2008), and Andrew Brown’s The Small Radio Telescope (2007). The SRT Manual itself is of course an invaluable resource. I plan on printing these documents and starting to compile a file for them for quick reference, potentially to be kept with the SRT Control box.
Future Prospects:
- Remote Access to the SRTs via VNC client
- Wirelessly connecting to/from the SRT Control box; 802.11 to Curtin w/less vs 802.11 Ad Hoc vs Secure Bluetooth
- Stress test of SRT capabilities
- Thermal Noise contribution to signal
