Hi Ermanno,
Many thanks for your message with comments about MAP65! Here are some
initial responses...
[EMAIL PROTECTED] wrote:
Hi Joe .
This morning I have tried for the first time "on-line" MAP65.
1) As soon as shaped the program didn't decode . The PC with
Linux and Linrad didn't have the time sincoronizzated, but
as soon as fact then MAP65 has begun to decode. Does MAP65
use the time of Linrad that receives in the packets from
the network or that of the pc on which run MAP65?
Good question. In MAP65 v0.7 r474, things are set up so that T/R
sequencing is based on time kept in the MAP65 computer, but
decoding is based on time received from the Linrad computer. I did this
so that the processing of recorded data could be properly synchronized
within MAP65. This could certainly be changed.
As it is now, it is important that BOTH computers have their clocks set
to the correct time, within a second or so. I do this by starting
Linrad with a short script that first executes "ntpdate", then xlinrad.
2) The frequency of MAP65 is superior as regards the real
frequency. This morning for example transmissions to 144.116
came suitable to 144.117 like 144.109 to 144.110 [etc]..
The frequency scale used in MAP65 follows the convention always used for
WSJT modes: frequencies are specified as that of the suppressed carrier
of the upper-sideband SSB signal. The sync tone is higher by 1270.5 Hz.
In addition, with my own WSE converters (receiving with 144.125 placed
at band center) there is a calibration error of about 330 Hz, and in
MAP65 v0.7 r474 this number has been "hard-wired" into the program.
Therefore the frequencies read out by MAP65 are 1600 Hz lower than the
frequencies displayed by Linrad.
The next version of MAP65 will have a "Frequency Calibration" box in
which you can enter your own constant frequency offset. For my system,
this number will be 330 Hz.
3) The DT seems to be around between 1.5 and 2 inferior seconds to
what it should be.
Hmmm, in your screen shots I see EME signals with DT values mostly
around 1.9 or 2.0 s. This would seem to be only about 0.6 s too low.
Of course, the value will depend on clock settings on one or both of
your computers (I think it is only the Linrad computer, at present), and
also on the transmitting station's clock setting. In addition, there
will be a constant offset that depends on exactly how Leif defined the
time-stamps in the TIMF2 data packets. If it seems desirable, I could
add a user-settable time offset to the setup screen, to allow
fine-tuning of displayed DT values.
4) The RX-noise indication does thing point out? I have seen between
4 and 5 dB
Yes, those numbers are consistent with what is seen on my system. They
give the relative level of the signals received from Linrad. (The
zero-point is arbitrary, and there is no reason to try to set a
particular value.)
You can use these numbers to measure Sun noise, etc. They are also used
in MAP65's "Measure" Mode (but this mode was not finished when r474 was
packaged). With the Sun as a signal source, I have been using the Rx
Noise measurements to calibrate the offsets in my Az and El readouts.
I attach you any files from which you could see any errors of
decodes; for example in the BAND MAP comes brought again like
a CALL the OOO relationship or part of a text free envoy at
the end of the qso.
Yes, I know about this. When preparing the "Band Map", the program
looks at decoded messages and takes the second "word" of each one to be
the callsign of the transmitting station. Usually this is the correct
assumption, but occasionally you will see something like
HXR1+QOTZ2OVS OOO
which is obviously a garbage decode. The second word in this message is
"OOO", so that appears in the Band Map. I have plans on how to minimize
this problem, but have not implemented them yet.
The first impression is extremely positive particularly way the
management of the automatic polarization also on signals that I
was not able to see on the screen of Linrad.
I am delighted that MAP65 is working so well for you! I continue to be
amazed at the signals it finds and decodes.
I have written directly to you because on the mailing I don't
succeed to send attached files.
possible improvments:
1) Set tx-frequency as QSO Freq. even using the same routine
of the Linrad (users_tr.c)
Yes, we will definitely want to have something like this. At present
MAP65 writes the "QSO frequency" into the file azel.dat, along with
tracking and Doppler information. At my station, another program reads
this file and controls the antenna positioners and the TS-2000X radio.
You can see a screen display of this program at
http://physics.princeton.edu/pulsar/K1JT/Station_1.jpg .
2) syncronize the time from a PC to the other so that they have
lined up perfectly or ignore the time sent from Linrad completely.
I will think about this one. As I mentioned, at present I run ntpdate
on the Linrad computer just before starting Linrad. On the MAP65
computer I run Dimension 4. I will probably put second ethernet cards
into each computer so that the Linrad -> MAP65 connection has a
dedicated line; then each computer can have good access to the internet,
as well, and keep its own clock set accurately.
Please continue to share your impressions of the MAP65-Linrad
combination, and your good suggestions for program improvements!
-- 73, Joe, K1JT
#############################################################
This message is sent to you because you are subscribed to
the mailing list <linrad@antennspecialisten.se>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>