Connecting radio telescopes over the Internet is a great challenge for amateurs.
On the other hand this will provide totally new opportunities in the area of
observing radio astronomy sources to all members of the European Radio Astronomy
Club (ERAC). For the first time it will be possible to visualize observation data
online that has been received by one or multiple remote radio telescopes located
somewhere around the globe. Certainly this will make the Radio Astronomy hobby
even more popular especially for people not running a full-blown radio telescope
by their own yet.
In order to generate software that meets the needs of radio astronomers, those
needs have to be determined with regard to the expectations of the later users.
Therefore, this document aims at defining the high-level requirements that the
software should come close to. Furthermore, current specification document is the
basis for discussions that will most likely go into much more detail. Any comment
is welcome and can be sent to the mailing list firstname.lastname@example.org or to the author
The distance between two subsequent Radio Astronomy Congresses is a suitable time frame for defining, developing, testing and implementing a complex software package like this in the ERAC. However, basic requirements should be established quickly during the next few weeks. This will allow to start the software development soon and to make first modules available for testing after a few month, most likely early next year 2001.
[2000-11-11 21:52 email@example.com]
There will be different platforms to be supported dependent on the function of the particular software modules. The user interface will be available on Windows platforms as well as on Linux. However, the radio telescope controlling software as well as the data processing software will also run on DOS and may be also on a PC without any operating system because making use of the full hardware performance is essential for those parts.
Most functional requirements are derived from the ALLBIN project that intends to connect radio astronomy stations in order to perform radio interferometry. However, since other projects came up with similar requirements the software will be called ERAC software in this document.
The ERAC software will run on PCs, to be more precise - on multiple PCs. This means that certain functions belonging to the ERAC software will run on separate machines that will communicate one to each other either in a local network or more generally - over the Internet.
It is important to know beforehand what functions are intended to run remotely in order to design and to implement the necessary communication between them properly. For example, the radio telescope could be connected to one poorly equipped PC running mainly the hardware interface, however, the data repository with huge storage capabilities could be located on a second machine equipped with a huge harddisk with a lot of GBytes.
The third PC with a convenient user interface would allow to control observation parameters, to visualize the observation results and to provide online communication with other radio astronomers. However, time-consuming calculations could be done by a fourth machine with a very fast processor. Since this is only one function split example, there will be much more scenarios where subsequent software modules could interact one to each other.
This software module will work next to the radio telescope. It has to provide all
needed control commands for steering the pointing position of the radio telescope.
At the same time it will accept the huge data stream coming out of the A/D converter
that works on analogue signals from the receiver. In case the receiver's parameters
like frequency, bandwidth, etc. are software-controlled this will also be done here.
On the other hand this module will connect to all other ERAC software modules using
a network connection in a local network respectively an Internet connection.
Controlling the telescope's pointing position
The first supported radio telescope interface will be the Microcomputer-Controlled Radio-Telescope-Interface developed by Franz-H. Knüttel and published by him at page 760 in Newsletter 14&15. This interface allows to control and measure the following parameters of an radio telescope:
[2000-11-11 21:52 firstname.lastname@example.org]
Based on those basic controls a pointing by equatorial coordinates will be implemented.
Controlling receiver parameters
As far as receiver parameters are software-controllable, they will be remotely
controlled by this module. For example, a TV tuner allowing for switching to an
arbitrary frequency in the range from 50 MHz to 850 MHz will be remotely controlled
regarding frequency. However, in case of a high-end microwave receiver like AR-5000,
other parameters like bandwidth, antenna in use, and others will also be controlled.
Reading digitized signals
One of the simplest ways of digitizing analogue signals for radio astronomy purposes
is to use a sound card that can be found in almost every PC nowadays. Another
possibility is to let specialized integrated circuits do that work and to transfer
the resulting data stream into the PC using either one of the PC's standard ports,
e.g. serial port or installing a specialized A/D converter card into one of the PC's
slots. In a first version the ERAC software will most likely support reading
digitized signals from a serial port. Other variants will follow subsequently.
Connecting to the outside
The Radio Telescope module is supposed to receive control signals and to provide appropriate output signals to other ERAC software modules where the other ERAC modules can be either on the same machine or on another machine in the local network or somewhere in the Internet. In case of control modules in the local network a network card is needed in the PC. In case of an Internet connection a modem or ISDN card is needed as far as the Internet connection is not established over the local network where also a network card would be required.
The ERAC Radio Telescope software module will support all choices mentioned above. To avoid abuse of the system, access rights will be applied in order to allow only the owner of the system respectively other people with sufficient access rights to set the observation parameters to intended values. A strong encryption will be implemented in order to give only intended people control over the Radio Telescope. More encryption related information will be provided later in a separate chapter.
The amount of data generated by the A/D converter depends on the sample rate and on converter's resolution. Given 100 samples per second and a 12 bit A/D converter, this will result in
Application of higher or lower sample rates respectively resolutions will result in
appropriate higher or lower amounts of data.
In order to maintain large amounts of data without overloading the system's storage capability, the data repository will be organized as a loop buffer. This means that subsequent data will be written into the buffer until the end of the buffer is reached. Afterwards, the writing process starts from the buffer's beginning where old data will be overwritten.
All data in the buffer will be available for analyzing and visualization purposes until they are overwritten. Given a 100 Mbytes buffer and a sample rate as well as a resolution like described above this will result in a storage capability of about 8 days.
2000-11-11 21:52 email@example.com
The standard data format for interferometer image data (FITS) will be used for data export from and data import into the loop buffer.
ERAC Network Interface
On the other hand the data repository will also be equipped with the ERAC network interface that allows both, to write into the data repository and to read data out of it as long as they are available in the loop buffer.
In order to allow others to perform calculation tasks remotely on your PC, some rules have to be established regarding the prerequisites and the limitations of such an automated collaboration of two or many PCs.
First of all the owner of a PC with a preferably fast processor has to agree that others can use part of the processor time for their calculations. Also, the algorithms have to be agreed that will be processed on delivered data, e.g. a fast Fourier transform. The software will contain switches that allow to activate respectively to deactivate the remote calculation functions.
Furthermore the owner of the PC will decide what percentage of the processor time can be used by others automatically in order to perform their calculation tasks. This ensures that the PC stays operable to the operator and can never be excausted by remote calculation tasks.
In case all conditions are fullfilled the PC will function as a calculation server offering the enabled algorithms to a user group. Every PC in the same user group that needs additional calculation power can automatically ask for and exploit the offered calculation services. This way a PC can speed up data processing almost unlimited only dependent on the number and the speed of the available calculation servers.
The operator of the radio telecope will have full control over all parameters that can be controlled by software. Since the user interface is remote with regard to the Radio Telescope module, it can run on any PC having a connection to the PC with the Radio Telescope module either in a local network or over the internet. Therefore the radio telescope can be controlled from any point of the globe.
However, sufficient access rights are required to control a radio telescope. Therefore the owner can grand access rights to any radio astronomer belonging to the same user group and he can also limit or revoke the access.
In most cases the final goal of running a radio telescope is to visualize the
data on screen and to print them out. Dependent on the needs there are several
possibilities how to visualize data:
A power chart displays the signal power how it changed during the observation
cycle. Normally a certain time scale will be defined and the signal power will be
shown during the time period visable on the chart. The time scale can be adjusted
In case of three continious parameters to be displayed the two-dimensional
chart would be not sufficient. Given the frequency has also to be displayed in
addition to the signal power and the time, a waterfall diagram is capable of giving
a good control over all three parameters. Normally the time scale will go from top
to the bottom and the frequency from left to right. The signal power, however, has
to be displayed as the brightness or color of each point in the two-dimensional
Another kind of a three-dimensional data presentation is to show the signal density on the background of the sky. Most likely the program EasySky will be expanded by the program author, Matthias Busch, in order to show the sky background along with the signal density on it.
The ERAC software includes a network component that is needed to connect the particular program modules to each other. This network component works in a local network as well as over the Internet. Therefore it can also be used to provide for communication between two or multiple radio astronomers.
In a first implementation it will be possible to chat using the keyboard and to exchange documents. Dependent on the bandwidth the communication module can be expanded later in order to allow for transferring voice and pictures over the same channel that connects the particular ERAC software modules.
The huge amount of date that will grow over the time from the many information exchanges will be collected in a morphic memory. This type of memory stores sentences as a sequence of references to entries in a dictionary. Therefore searching for certain information based on keywords will be easy since all information is fully indexed.
At the same time also translations of sentences or of whole documents can be stored in the morphic memory. This allows to offer translations of any piece of information contained in the morphic memory to anyone in the user group. Interesting articles in an arbitrary language can this way be exchanged in the original language as well as be translated into English in order to allow everyone to read it also if he can not read it in the original language.
Connecting systems over the Internet implies that other Internet users can disturb
the systems by accident or in a targeted way. In order to reduce the security risk to
a reasonable level some protection means are needed to be built into open systems.
Security systems are based on identities. If access rights are granted to an identity then a person that evidently has this identity will be accepted by the protected system. Otherwise the person will not get into that system.
The simplest way of identifying a person is to ask for her name. However, this simple method will fail in case of two people with the same name or worse, if a person claims to be another person but she isn't. Therefore some additional piece of information is needed that is a secret of the person that really has the appropriate identity. Often a Personal Identification Number (PIN) is used to provide for secure identification. The problem with a PIN is that it works only as long as it is not compromised. As soon as another person gets hold of a PIN of someone else that PIN becomes compromised and is basically useless.
The risk of compromising a PIN when using it in the Internet is relatively high
since the data traffic in the Internet is almost open and can be monitored by others
easily. Especially the fact that the secret PIN has to be given away in order to
identify yourself makes it very difficult to keep it secret.
Public Key Encryption
The way out is to split the key into a private and a public key. The private key will never be given away but remains in the hands of the owner, whereas the public key will be given to all parties that needs to identify the key's owner. The public and the private keys are calculated in such a way that after applying both of them in sequence to any message the result will be the same message. Identifying a person to a protected system will therefore follow a certain procedure:
The protected system generates an arbitrary message, e.g. a simple number that is chosen randomly and passes this as a challenge to the user's computer. The user's computer will encrypt the challenge using the private key. Normally the user has to type in a pass phrase in order to allow the computer to perform a private key encryption. The result will be a cipher text that will be passed back to the protected system. Since the protected system knows the user's public key it will perform a decryption based on the public key. Finally the decrypted message will be compared to the original challenge sent to the user's PC. If they are equal the user will get access to the protected system and can perform all tasks that have been enabled for the user's account.
The described procedure was invented in the early 70s and it was used from then on
in almost all cases in business live where identification was needed and a PIN was not
sufficient. There was a patent (RSA) on that procedure in US that expired in September 2000.
The main question to make the procedure work properly is how to generate key pairs of a public and a private key and how to distribute the public key in a reliable way. Important things are both, to keep the private key secret and to get the right public key into the protected system. The first will be the responsibility of the owner who should take care about the private key. The confirmation that a public key really belongs to the person who claims it, however, can be done in several ways. Most often a reliable person like the administrator of a user group will sign a public key in case there is no doubt that the public key really belongs to the person that claims it. Group members normally rely on a public key electronically signed by the administrator.
Pairs of public and private keys require some calculation based on input values that should never be possible to be regenerated by others. Therefore some really random values are needed. In case of the European Radio Astronomy Club the keys will be derived from several values that are random on the one hand but can be regenerated by the key's owner and only by him on the other hand. This will result in some advantages regarding getting into the ERAC user group when not being home on the PC where the private key is stored. It will generally allow every member of the ERAC to use any PC running the ERAC software to log into the ERAC user group.
Since the software to be designed and to be developed for radio astronomers' needs is a complex software, it was not possible to describe all functionality in detail. Furthermore, in most areas the detail software requirements are subject of discussions to be provided in the European Radio Astronomy Club. In this sense the description above should be seen as a proposal listing some but not all requirements. From every member of the ERAC being interested in contributing to the ERAC software and also from others any feedback to the requirements listed so far will be very appreciated.
I've read your requirements document and I'm very pleased to see that somebody is on a *professional* approach for planning a software package for the amateur radio astronomers.
Some comments and ideas:
1. (Chapter "Functions")
You wrote that the software will run on PCs. I agree to that, for the PC gives us the cheapest computer hardware available on the market. But specifying the PC as the preferred platform nails down the hardware only. It doesn't say anything about the operating system. Maybe, for controller functions the software could run on the "naked" PC without operating system or within a simple DOS environment. That could make the behaviour more real-time than running the software on WINDOWS.
But when we're coming to Data Processing and the User Interface we clearly have to come to a decision on the operating system. We have the choice between WINDOWS and LINUX (in my opinion we don't have to look for other OSs).
A WINDOWS-based UI will be based most likely on the MFC while LINUX-based UIs will depend on some X11-based libraries. Porting software from one platform to the other will be at least very difficult, perhaps impossible. An alternative could be to develop the UIs in Java, knowing that the performance could be poor.
Data processing might result in software that could be ported from WINDOWS
to LINUX more easily if we clearly separate it from the User Interface.
2. (Chapter "Radio Telescope,
controlling the telescope's pointing position")
When we are thinking of combining all ERAC radio telescopes to an interferometer we should keep in mind that it would be a real great thing to track the source instead of having transit instruments. I'm aware that today many of the telescopes are lacking the mechanical ability to track a source. Anyway, I think we should put into the requirements list the item "pointing by equatorial coordinates".
3. (Chapter "Data Repository")
There is a standard data format for interferometer image data. The format is called FITS. I've got the standard definitions and I'm just checking if we could use them for all of our data. Unfortunately, I don't have the URLs at hand. If somebody is interested, he/she can find pointers by asking an Internet Search Engine or send me an e-mail. I don't want to attach the files to this mail for they are about 800 kBytes each.
Armin und Charlotte Falb
Am Knippelsacker 6
Tel.: +49 6209 5860