To:      Users of MAP65
From:    Joe Taylor, K1JT
Subject: MAP65 update

On-the-air testing of MAP65 continues. Last week with my modest station I made 60 EME QSOs with 48 different stations in about 16 hours of operating, including WAC on 144 MHz. Most of the QSOs were made by responding to CQs that appeared on MAP65's "Messages" screen while I was monitoring the EME portion of the 144 MHz band. The Linrad-MAP65 combination works very well, and I am finding it a pleasure to use. I continue to make program enhancements, many of which are now falling into the "operational convenience" category.

A number of messages already received reflect the obvious fact that many stations do not have xpol antennas. These operators are nevertheless interested in the other capabilities of MAP65, besides polarization matching. In particular, a number of inquiries have been received about using the SDR-IQ hardware with MAP65. There may also be interest in connecting the SDR-1000 (or later models from FlexRadio) to MAP65.

In principle, any hardware that can be made to work with Linrad should also be usable with the Linrad-MAP65 combination. At present this is true only if the sampling rate can be set to 96.000 kHz (four channels, two I-Q pairs) or 192.000 kHz (two channels). If you want to try MAP65 and don't have xpol, a simple way to get started would be to put nothing into the Y channel (or perhaps put the X signal into both X and Y inputs). I have tried this in my station and it works -- although of course no polarization information is produced for the received signals.

The SDR-IQ can provide effective I-Q sampling rates of 55.555, 111.111, 158.730, and 196.078 kHz for a single polarization. MAP65 will need some modifications to be able to work with one or more of these rates. I will put this on the "To Do" list. When I get to it, I will probably provide an option for more efficient single-polarization use, as well.

Over the past weekend I confirmed that running Linrad and MAP65 on a single computer is possible -- and indeed may be the best arrangement of all. You still need two display screens, however. This can be done with two video cards in the single computer running Linrad and MAP65. Another option is to use a second computer for display only. Both Linrad and MAP65 would run on a fast computer with at least 1 (or maybe 1.25) GB of memory. The Linrad display would be done on this computer. A second computer (can be old, slow, small memory) would be used to display MAP65. Any combination of Windows and/or Linux should be usable.

In my tests I ran both Linrad and MAP65 in a 2.4 GHz Linux machine. I displayed MAP65 on Windows, after installing the the free Cygwin/X11 package. In this configuration the Linrad-MAP65 combination is stable and responsive. Linrad reports that it is using about 12% of the CPU. At the end of each minute, MAP65 decodes the previous minute's transmissions noticeably faster than when it is actually running (rather than just being displayed) on the older 1.5 GHz P4 Windows machine (which also has 1.25 GB memory).

My earlier problem with dropped multicast packets seems to be fixed in MAP65 v0.8. However, when running the Linrad-MAP65 combination on two separate computers I still have some network-related problems. Perhaps someone on this list who knows much more than I about networking can help.

My computer network looks like this:

        ADSL      10 Mb/s  --> Computer_A
DSL --> Modem --> Ethernet --> Computer_B
                  Hub            |
                           --> Computer_C

Three computers are connected to a 10 Mb/s Ethernet Hub. Computer_A is my XYL's machine. Computer_B runs Windows 2000 Pro, and Computer_C runs Linux (presently the Kubuntu 6.06 distribution). In addition to the connections of all three machines to the hub, a crossover cable makes a direct 100 Mb/s connection between computers B and C.

The ethernet interfaces on B and C appear to be configured correctly. On Linux they appear as eth0 and eth1 (occasionally they boot up as eth0 and eth2, I don't know why???). Connections to the Hub are assigned dynamic IP addresses; I assigned hard-coded addresses and for the direct inter-machine connection
between B and C.

I can use the 100 Mb/s direct line for many purposes. I can ping over it in either direction; I can ssh into Linux from Windows; I can use Cygwin/X (as described above) to display Linux X programs on the Windows screen.

However, I cannot seem to persuade Windows 2000 Pro to accept multicast packets over the direct line. When I run Linrad on computer C and MAP65 on B, the multicast traffic is always received over the slow line, through the Hub. This uses most of the 10 Mb/s link's bandwidth, and my wife can't read her email when I'm on the air. This is NOT GOOD.

By default the multicast traffic generated by Computer_C goes to eth0. I can use the Linux "route" command to explicitly tell the system to use eth0:

# route add -net netmask dev eth0

This works fine (but of course, still sends the heavy multicast traffic through the hub). If I remove this routing instruction and instead enter

# route add -net netmask dev eth1

the multicast data are not received by MAP65 running on the other machine.

If I unplug the crossover cable from the Windows machine and instead plug it into a laptop running Win/XP, the laptop receives the multicast packets without a problem.

Thus, it would seem that the problem must be in my setup of the Win2k machine -- the one with two ethernet interfaces. Can anyone shed any light on this situation for me?

I would be very happy to receive more feedback from others who have been using the Linrad-MAP65 combination. Are there problems that I may have overlooked, perhaps because MAP65 has been designed with the peculiarities of my own station in mind? Please share your experiences on this list.

        -- 73, Joe, K1JT

This message is sent to you because you are subscribed to
 the mailing list <>.
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]>

Reply via email to