[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linrad] Re: MAP65 Beta Testing
- Subject: [linrad] Re: MAP65 Beta Testing
- From: Joe Taylor <Princeton.EDU; joe@xxxxxxxxxxxxxxxx>
- Date: Fri, 06 Jul 2007 08:55:16 -0400
Alex and all,
I apreciate if some body tell me how integrate Linrad and MAP65 via
the network, I have no idea.
I am anything but an expert in networking; in fact, I have
some network-related questions of my own, as you will see below.
Of course, the Linrad --> MAP65 network connection should(?)
work without much effort on the user's part! I suppose my
own setup is a more-or-less typical situation, so I will
describe it first.
At K1JT, MAP65 runs on Computer "A" under Windows 2000.
Linrad runs on Computer "B" under Linux (currently, Kubuntu
6.06). Both computers are connected to a network hub
through RJ45-style CAT-5 cables, and from there to the
outside world through a dedicated ADSL line. My XYL's
computer is also connected to the hub, and occasionally a
laptop is connected as well. The Linrad - MAP65 combination
works OK without changing anything in this normal network
setup (but more on this later).
Linrad 02.34 is set up to do its first forward FFT using
"version 5" (SIMD /SSE instructions) and first backward FFT
with version 1. This forces Linrad to multicast its TIMF2
in 16-bit format, the format expected by MAP65. To start
the multicasting of TIMF2 data, hit "N" (Network setup) on
Linrad's opening screen, and turn ON format 8. All other
multicast options should be OFF. Then enter 0 to go back to
the opening screen, hit "T" to toggle multicasting on, and
then select mode "A" (weak-signal CW) for normal operation.
Now start MAP65 on Computer A. It should immediately begin
receiving the multicast packets from Linrad; at the end of
each minute its waterfall displays should update and the
JT65 decoder will be invoked.
Now for the part where I am still scratching my head...
MAP65 checks the serial block numbers of each incoming
packet, so it can tell when any packet(s) have been missed.
In my setup this happens all too often -- no doubt as a
result of something I am doing wrong. MAP65 displays the
percentage of dropped packets in the status bar at the
bottom of its main window. In my present setup this number
may be 3% or even larger for the first few minutes after
starting MAP65; it then settles down to about 0.6% thereafter.
For reasons I have not yet identified, my system works
better with the network speed set at 10 Mb/s. If I set it
to 100 Mb/s things still work, but the percentage of dropped
packets increases to about 2.6% in steady state. Moreover,
these numbers stay essentially the same (0.6% lost data at
10 Mb/s, 2.6% lost data at 100 Mb/s) if I disconnect both
computers from the network hub and simply connect the two
through a "crossover" cable. Probably I am doing something
stupid in the "recvpkt()" routine in MAP65; or perhaps I
need to set some parameter differently in the Linux and/or
Windows computers. If anyone can shed light on the
situation, or suggest some suitable diagnostics, I would be
grateful.
I use a completely different pair of computers for
development work. One runs Debian Linux (installed from
Knoppix) and the other runs Win XP/Pro. Between these
machines the number of dropped packets is smaller but still
not necessarily zero. With the network supposedly running
at 100 Mb/s, I fairly often see a few (0-20, say) dropped
packets (out of a total 33103) in a minute.
Loss of 1% of the data is arguably not very important. It
does not degrade JT65 decoding noticeably. Nevertheless, i
would like to understand what I am doing wrong.
-- 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