It has been added a report on the QSO between DL2JA and I2KFX.
The idea of using digital techniques for Meteor Scatter communications is not original of Radio Amateurs. Since many years, infact, there are in service civil and military systems that use these technique for disseminating short messages on wide geographical areas. (1)
The advent of packet radio has allowed the pratical extention of this technique to radio amateurs, givig to anybody, provided with a minimum of equipment, the possibility to venture upon this fascinating activity in the past reserved only to the most powerfull stations end with very patient operators.
The AX.25 protocol was not borne for Meteor Scatter activity, it was necessary, so, some adaptation and simplification to allow frames to met meteors beams and be reflected to ground. With these ideas I started, last year, to write a program for PC able to drive a KISS TNC and implement all the actions that are more suitable for the MS technique.
In my previous article on DUBUS 3/88 I reported the details. Here I will summarize all the procedures for the benefit of who is new to meteor scatter.
Every day our planet is run over by tons of debris of different dimensions arriving from deep space. When these debris come into the atmosphere they disintegrate generating a cylinder of ionized air. This cylinder will last from few milliseconds to some minute depending on the size of the stone, and it will reflect radiowaves in the range from 30 MHz to low UHF.
We don't know the exact moment of arrival of meteors and the right position in the sky of the ionized cylinder, so we have to transmit continuously in certain windows of time agreed with the other station. For Packet Radio Meteor Scatter we have always used 15 seconds windows in our experiments up to now, but the program allows also 30 second windows.
Ionized air cylinders appear in the range 80 .. 110 Km. Because of the geometry of the earth they allow QSO's up to 2000 Km. It does not exist a minimum distance. For distances lower than 500 Km the antennas should irradiate also on the back to take advantage of meteors appearing on the back . Papers (2) and (3) report considerations about the geometry.
I was saying that meteors arrive suddenly, but something can be known in advance: few hundreds of trails have been catalogued by astronomers and we know the point in the sky from where they appear to come out, we know, besides, the period of days in which they arrive into the atmosphere. (on DUBUS you can find all these informations)
A special program in BASIC by DL5MCG allows to compute the best period of the day for a QSO between two stations. During these periods meteors arrive almost perpendicular to the path between the two stations.
We saw that for doing a QSO we have to transmit continuously hoping that meteors arrive and bounce the messagge to the other station. To do this I wrote a program in Turbo Pascal that menages all the operations. In practice the program sends to the TNC, in KISS mode, the message to be transmitted so many times as they fit in the time window in use. In the experiments we have always used a 15 seconds window. A station transmits in the first 15 seconds of the minute, then goes in receiving mode. The other station transmits in the others 15 seconds and so on.
EXPERIMENTS
Since the mid of May '89 I0VUQ and I have started a series of tests to verify the possibility of QSO's using small powers and minor Meteor Showers.
Here follows the description of the experiments, the successes and the difficulties that we met and the perspectives of future development of this activity that tries to implement the synergy between digital techniques and DX in VHF.
Following the publication on DUBUS and on Radio Rivista of my article of presentation of the program MS for PC, many OM's were interested to start experiments.
The first station that was ready was the one of Alessandro, I0VUQ, located in S.Maria Le Mole JN61hs south of Rome.
Alessandro's station is made of a PC, a TNC2 with EPROM 1.1.6, an axternal PSK modem (JARL design). The TX is an IC202 that drives a 50 W linar amplifier equipped with a QQE06/40. A TS820 is on the receiving side together with a Datong UC/1 converter. The antenna is a 9+9 crossed yagi, the same used for Oscar 13.
My station in Monza (JN45po) is made of a PS2/30, a PK80 with EPROM 1.1.4 with KISS loader and an external PSK modem. The TX is an FT201 with an home made transverter that drives a Fisher linear amplifier. The output power was 80 W due to the old tube. The RX is a Drake R4B and a preamplifier home made with N.F. of 0.9 dB. Antennas are 2 9+9 crossed yagis coupled with hibrid rings.
Both station use right circular polarization.
The distance between our stations is 507 Km, and the path is all over the Appennini chain of mountains.
Before starting tests in 144 Mhz we did verify that all the hardware were ok, so we made qso's on 20 m and also on 40 m when the 20 m were closed. By the way we found that PSK modulation was excellent even in the mess of the 40 m.
After having verified that all the hardware was right, doubting to be able to make a qso in MS with only 50 W, Alessandro moved his digital equipment to the site of the friend I0NLK. I0NLK does EME with 4 yagis 20 el. and 500 W. With these conditions we made the first try, but we were not lucky: there was tropo scatter that day. I0VUQ did decode first a packet, and later we could even exchange few words in SSB.
After that time we have always operated from our station and we have not found Tropo any more.
In the meantime I had problems with my frequency counter locked to the local Medium Waves station.
The major difficulties that I have met at the beginning have been related just at the measure of the output frequency. The PSK modem has a locking band of + or - 100 Hz. If signals are weak, on the contrary, we need a better precision: let say + or - 30 Hz. We must also take in account the error fo the other station that could be in the opposite direction. To have such a precision and stability is not so easy not having a synthesized equipment as it is in my case. First of all it takes to measure the effective output frequency sending at the microphone input a 1600 Hz tone not modulated. Not having professional instruments it remains only to use a standard frequency extracted from a very stable radio emission. Here in Italy our MW and TV RAI stations are controlled by a cesium reference oscillator. An other problem is the natural drift of both RX and TX. In my case I need to warm up at least for a couple of hours all my equipments. Later, during operations, I verify every half an hour that frequency is still correct, and eventulally I adjust for the drift.
But let's see the tests !
After having missed many appointments with major showers due to QRL, finally on saturday 13th of May we can do a test on the Nu Puscidis, a shower that arrives around the middle of the day.
Nu Piscidis are a poor shower, but we did try as well. After one hour from the beginning of transmissions we were starting to get discouraged. I made a phone call to Alessandro for askig if he had heard something. The answer was negative, but we decided to go ahead for an other hour. Few minutes later, non knowing what to do meanwhile the PC was regularly transmitting every 15 seconds, I concentrated my attention to the receiver and I heard a strange fluctuating noise. it was similar to F1 racing cars on the track: uouu uouu...what could it be ? I tried to move the tuning knob of the Drake and suddenly the green LED of the demodulator indicated a lock. Almost immediatelly I heard the printer working. A rapid adjustment of the tuning and others printed lines.
You can imagine my happiness ! it was the first message.
I0VUQ=>I2KFX UI Odd 8 <240>: cq msIt was 11:01 o'clock. I call at the telephone Alessandro and I read the message to him. During the conversation the printer continues to work.
At this point the QSO had to be finished. Also I0VUQ had to receive my signals. We did continue transmissions but he didn't receive anything. In the meantime I check the frequency moving the TX on the RX: it was 140 Hz lower. Later we discovered that the HP counter of Alessandro had not been calibrated since long time so its reading was slightly wrong.
After that day we made others attempts: on the 20th and 21st of May on the Omicron Cetidis and on the 4th of June on the Arietids. In all these tests I have received lots of frames but none of mine had been received by Alessandro.
Following this asymmetric behavior we started to analyze the phenomena. First of all, during first tries I0VUQ had no preamplifier. The signal I used to receive were normally around S1: this means that I was at the limit of the sensitivity of my station. An other matter to take in account is the geographical position. I0VUQ points his antennas towards Rome, so he loads all the noise produced bye the town; on the contrary I point East of Milan so my idle noise is much lower. In the test of the 4th of June Alessandro did use a preamplifier of unknown quality at the bottom of the cable and did modify the connection between the two antennas using an hibrid ring instead of the T connection, nevertheless he could just hear some signal from me, but no frame was correctly decoded.
On the 11th of June we made another test fron 11:30 in the morning to 16:00 in the afternoon trying to exploit both the Arietids and the Zeta Persidis. Frames did start to arrive with a certain advance respect to computed times: at the beginning one or two frames in each window, later in big quantities. At the 12:41 a shower did transport 88 frames with the message "CQMSPSK", but unfortunately nothing in the opposite direction Monza-Roma. During this test I0VUQ did change his linear amplifier getting 100 W instead of the previous 50 W. He did also use a preamplifier but installed in the shack at the bottom of the cable. (weather was not good for climbing the tower)
In the meanwhile I started to modify the program MS: the first version was in Turbo Pascal 3.0, but, shortly after having started tests on air I acquired the new version 5.0 of the same Turbo Pascal. The conversion from 3.0 to 5.0 was quite long and painful because of many subtle differences between the two compilers. Tests had showed the need of recording on the printer and on file all the received frames, so version 2.0 of MS did include such improvements.
By the time JPI came out with a Modula-2 compiler at a very reasonable price and with very interesting characteristics.
The main difference between Pascal and Modula-2, a part from the better syntax of the former, is that Modula-2 implements "Coroutines". Coroutines allow the implementation of really multitasking programs. In a multitasking program many "PROCEDURES" run at the same time ( depending on priorities ) and can exchange each other synchronization Signals.
It was just the right language for MS as many activities have to be carried on at the same time. Of these 3 are the principal: i.e.
- To receive and decode frames - To edit a new message for transmission - To run the clock that starts transmissions.As I received the compiler from the States I begun immediatelly to learn its possibilities and both for didactic pourposes and for real operative needs I started to re-write totally MS changing completely its structure.
The re-writing of MS was really a good school: the implemented improvements are really many, starting from a better hanling of the serial port: now avery character that arrives to the computer starts at interrupt a Modula-2 routine. The running clock isn't any more a TSR, but a normal Modula-2 procedure. Besides now there is a complete line editor for messages to be transmitted.
The added features are the possibility to adjust the computer timer and the fact that every received frame is reported with the exact arrival time. This last feature is very useful to analyze the time distribution of arrival of frames in the receiving window.
A detailed description of the program I will reserve it for a future paper if there will be interest in informatic techniques.
But let's come back to the activities on the radio.
Examinating the various possible reasons for the poor reception at Alessandro's site we considered also a defect on the PSK demodulator, so, during a travel to Milan for QRL, Alessandro took his TNC and Modem for a comparison with mine.
Connecting the two modems to the same radio and supplying them with weak signals showed that my modem was quite more sensible than the Alessandro's one. A further analysis showed that just the decider circuit was not working properly: the heart of the demodulator.
So we arrived to summer holidays and Perseids did pass meanwhile Alessandro was sailing in Grece and I was swimming on the Riviera. (but, you know, there is no pleasure with big showers !)
Respective businnes engagements did keep us far from meteors until Sunday 22nd of October. It was the time of the Orionids, a small shower that has the good idea of arriving at sunrise which is also the time of maximum daily arrival of meteors. (3), (4)
At 3 o'clock GMT we were already in the shack worming up the equipment. One hour and one half later we started the transmission with the usual procedure: 15 seconds window, I0VUQ on the ODD window, I2KFX on the even one. Output frequency 144.160 MHz.
At 4:48:04 I receive the first correct frame. The printer was disabled for not awaking the family, but the file recording was up and running.
Here follows the first frames received by I0VUQ.
4 :40:55 Even I2KFX=>I0VUQ UI 1 <F0> 73 AlexAnd here is my first frame:
4�:48:4� Odd I0VUQ=>I2KFX UI 1 <F0> r73AlexAt 8:24:11 GMT I receive the last frame after 1450 others, when the transformer of my linear amplifier decided to surrender shortcircuiting the plate secondary with the screen grid one.
The QSO was done !! But what was different from previous trials ? By sure on Sunday morning the noise produced by Rome is much lower than in working days, besides the Alessandro's demodulator had been revised. Furthermore the time was at sunrise. Later tests will confirm these suppositions.
Just as axample here are the receved frames during a nice burst:
5�:6�:37 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso"
5�:6�:37 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso"
5�:6�:37 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso"
5�:6�:37 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso"
5�:6�:38 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso"
5�:6�:38 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso"
5�:6�:38 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso"
5�:6�:39 Odd I0VUQ=>I2KFX UI 1 <F0> tnx fer"bel qso"
Please, note the distribution of frames in the second: four frames in the 37� and three in the 38� when were transmitted about 6 frames per second. This shows how the mode can exploit very short openings.
After that day we made a lot of others QSOs without problems. We found that at sunrise we could exchange packets in 5..10 minutes: incredibly easy ! we had days in which we could exchange packets for may hours as there were showers every few minutes.
But let's talk about another interesting test.
During a packetteers meeting in Brunico, Alto Adige/Sud Tirol, between OM from DL, OE and I, I had the luck to know DL2JA Werner.
Eating chestnuts and drinking wine it happened to speak about meteorscatter and Werner was soon enthusiastic about doing qso in this way as he had just built a PSK modem and had read my reports on the German magazine DUBUS.
The history of this qso is very interesting as it gave a lot of informations about pitfalls that exist.
The first try was unsuccessful: then I discovered that the oven of my counter had gone "fisin solt uota" so I was tuned very far from the stated frequency, 144,150.000 MHz.
After having fixed the problem I could receive Werner's packets but he couldn't receive mines. The problem was solved when Werner did switch off the BBS he is running in the same room: it was rising the noise floor just of the right ammount not to receive weak signals from meteors. The First One I-DL was officially done on the 27th October 1992 at 20:14:04 GMT and finished at 20:56:44 when we did shut down. Here is a sample from the second QSO:
DATE : 28/10/1992
6�:2�:41 Odd DL2JA=>I2KFX UI 1 <F0> just take shower hi 6�:2�:41 Odd DL2JA=>I2KFX UI 1 <F0> just take shower hi 6�:2�:42 Odd DL2JA=>I2KFX UI 1 <F0> just take shower hi 6�:2�:42 Odd DL2JA=>I2KFX UI 1 <F0> just take shower hi 6�:2�:43 Odd DL2JA=>I2KFX UI 1 <F0> just take shower hi 6�:2�:43 Odd DL2JA=>I2KFX UI 1 <F0> just take shower hi 6�:2�:44 Odd DL2JA=>I2KFX UI 1 <F0> just take shower hi 6�:2�:44 Odd DL2JA=>I2KFX UI 1 <F0> just take shower hi 6�:17:5� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:6� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:6� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:6� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:7� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:7� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:8� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:8� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:8� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:9� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:9� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:9� Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:10 Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:11 Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:12 Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:13 Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:13 Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:13 Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559! 6�:17:14 Odd DL2JA=>I2KFX UI 1 <F0> gd morning Pino, xr 559!
Here also time distribution of packets is interesting.
CAVEATS and SUGGESTIONS
After many QSOs I can point the following arguments as important to mind for this mode.
- There is no need of big powers: 100..200 Watt are enough. Of course the highest is the power the highest is the probability to exchange packets, or, you can think, the less it takes to wait for a good packet.
- There is no need for high gain antennas: nay, high gain can be negative expecially for short or medium distance QSO. Infact, if you don't know where meteors come from, you want light the wider possible part of the sky to get more chances. For short distances it is good to irradiate on the back.
- There is no need for waiting major meteors showers: it is possible to make QSO every day of the year ! The best time is at sunrise, the worst at sunset. See the bibliografy on this subject.
- 144 MHz band is very used by OMs, but 50 MHz is better. Also 28 MHz can be used. Try !.
- Meteor Scatter sounds very different from Tropo propagation. You will learn soon to distinguish the two: with tropo signals are stady, QSB is slow and sound is constant. With Meteor scatter signals have Doppler effect and QSB is rapid. It reminds me the sound of F1 racing cars passing near my QTH. You can even count the stones!
- Do not waste your time with FSK on FM, like normal packet radio ! FM is the least suitable mode for DX ! FSK on FM is a double frequency modulation...a waste of band. FSK on SSB could work: I have not tried, but, by sure, it requires more power.
- Use a good preamplifier very near to the antenna.
- Circular polarization is a good idea ! Oscar addicts are in good shape.
- If in your QTH you need to use the Noise Blanker then forget about meteors. Noise blanker kills packets ! Maybe you need to solve the interference with a good cavity or other trick.
- If your PC generates whistles and other noise on the band than you have got a problem. Put the computer very far from the antennas, put toroids on every cable coming out of the cabinet etc. or...change computer.
- Calibrate your counter or the RTX reference. Anyhow on rich trails it is possible to tune by hand.
- Check often the PC clock versus a time reference station.
- Make the suggested modifications to the PSK modem. You need the tune indicator on the modem ! You need the tune switch on the modem for a correct reading of the frequency. If you can read yourself it is a good starting point: the program sets the KISS in full douplex.
- Some TNC commits suicide when in KISS mode and fed with a lot of packets from the PC. I have seen it on the first versions of the PK232. I do not know if this problem has been solved on following releases. These TNC do not protect their buffer with hardware handshake. A TNC2 is a good alternative.
Hoping of having attracted your interest on this communication technique I invite all OM to try. The program MS.ZIP is free for radioamateurs and available on many BBS or FTP sites. I just ask to be informed of new QSOs.
Remaining QRV for any help many 73 de I2KFX
Pino Zollo I2KFX Via Negrelli,21 20052 Monza ITALY tel. xx39.39.833431 E-Mail [email protected] [email protected] I0VUQ Alessandro Surian Via San Paolo Apostolo, 65 00040 S.Maria delle Mole (ROMA) ITALY tel. xx39.6.9351825 E-Mail [email protected] DL2JA Werner Hlawatschek Goldshausen 8 D 8051 Marzling GERMANY tel. xx49.8167.1445
(1) Meteor-Burst communication bounce signals between remote sites. W.E. Day Electronics 29 Dec. 1982
(2) Communicating Via Meteor Burst at Short Ranges. J.A. Weitzen IEEE Trans. on Comm. N. 11 Nov. 87
(3) An Analysis of Meteor Burst Communications for Military Applications. J.O. Oetting IEEE Trans. on Comm. N. 9 Sept. 80
(4) Radio Propagation by Reflection from Meteor Trails. G.R. Sugar Procedings of the IEEE vol.52 Feb. 64
(5) Meteor Burst Communications Jacob Z. Schanker Artech House ISBN:0-89006-444-X
(6) Meteor Burst Communications Theory and Practice. Johon Wiley & Sons, Inc. ISBN: 0-471-52212-0