[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linrad] Re: beta-MAP65 using

Hi Ermanno,
Many thanks for your message with comments about MAP65! Here are some initial responses... 
ik7ezn@xxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>




LINRADDARNIL