[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