[Linrad] Re: Linrad MAP65 Communication II

[Rein w6sz <ix.netcom.com; rein0zn@xxxxxxxxxxxxxxxx>]

On Jul 22, 10:52 am, Leif Asbrink <l...@xxxxxxxxxx> wrote:
> Hi Rein,
>
>
>
> > Perhaps time to start a new discussion.
>
> > You have in Linrad the "X" and the "B" commands.
>
> >  The problem I have with the send cycle in MAP65
> >  seeming to knock out Linrad for whatever reason, could
> > perhaps be solved by using the procedures initiated by
> > the "X" and "B" commands?
>
> > It proofs that the linrad transfer can be stopped and
> > re-started without problems.
>
> >  MAP65 sends something like a "X" command to Linrad.
> >  At the end of the send cycle , about 48 secs later for
> >  the WSJT modes, a  "B" like command puts Linrad back to
> > work and sending again data to MAP65.
>
> > I can stop data transfer to MAP65  with the "X" keystroke
> > in Linrad and restore data transfer into MAP65 with the
> > "B" stroke, This is working.
>
> Yes, but a much better solution would be to correct whatever
> goes wrong with the USB link so it would not hang on its read
> statement forever when an error has occured. Under Linux this
> problem does not exist, some data may be silently lost.
>
> I hesitate to add a function by which Linrad is stopped
> during transmit. Networking is too complex already...
>
> > It could well be of course that there is a more serious problem
> > stopping Linrad, I hope not.
>
> > This brings up another question. The par_sendrec_ip is not
> > used in the communication between Linrad and MAP65.
> > I guess it could be used in a 2 or more computer setup
> > where the input data strem is reversed.
>
> The default multicast of Linrad is not allowed to reach outside
> a local network. The netsend/netrec files allows you to adapt
> to the rules of your own network.
>
> The only info I have is what SM0ERR wrote:
>                          -----------------
> Thanks for the flexible IP adressing. Nice for us running LINRAD
> inside large corporate networks !!
>                          -----------------
>
> By the way, the idea of including par_netsend_ip in the distribution
> package would destroy a property of Linrad that I find extremely
> valuable myself. A new version does not overwrite any of the
> parameter files. Overwriting the network files every time a
> new version is installed would worsen a problem that is already
> bad enough. The "do not fix something that is not broken" problem.
> Too few users take the trouble to install the latest version to
> save their own time. That is rational of course, but it delays
> reports on mistakes that I might do and when I eventually get
> information something is wrong I have already forgotten why
> I made changes to that part of the code. These are important
> aspects of Linrad:
>
> Everything resides in a single directory. Copy *.* is a complete
> backup.
>
> The Linrad installation consists of two parts. Copy par*.* will
> save the entire configuration /setup and an install of a new
> version will not silently overwrite any of the par* files.
>
> Running a new version may sometimes change parameter files because
> now and then new parameters are introduced. Linrad would then
> select defaults for screen related stuff or else prompt for
> parameter setup.
>
>  73
>
>  Leif


Hi Leif and All,


Let me step back a bit and forgive me for all the
questions....

I started this with the intention to use 2 computers and drifted
eventually towards this solution with one computer..

Could not get the 2 computers to work together even after the
introduction of the par_netsend_ip parameter.

The introduction was via Joe's MAP65 I-Q package.


I am afraid the present problem is a timing problem in particular
as I it working sort of in one of perhaps 15 trials.
Shortage in CPU or memory.

Here are a few more questions:

Given this 1 computer setup, should I select uni- or multicast?

You say Linrad is in multicast as default.  How could I have known
this?

The only place I saw the " _cast" parameter selectable is in MAP65.

( have been given by others no conclusive answers.,( also, it has come
up in most of the exchanges)

My interpretation was with a 2 computer system uni-

one communicates with 1 computer.

multi_ with more than one "slave" computer.

For the same money, one could say uni- with a single
computer, multi- with more than 1 computer in the system.

I would also think one would need more than one IP or computer
name in order to communicate with one than one "slaved computer"

With just 2 computers waht should it really be?

SM0ERR is running linrad on a corporate system.

How does he handle the IP issue without a par_netsend_ip
and or par_netrec_ip parameter?

This question generated in my mind because you say
the introduction of a blank par_net*_ip is not such a
good idea.

I hope the answer is not: "he is running Linux and tunes his files
and the program directly to make at  work.?"

It is hard for me to imagine that he is able and to get away with
this in a corporate environment with out REALLY understanding
networking. Or, more likely that he is the corporate top IT person
himself!

I still like to hear from somebody whether in a 2 computer system
I should have "shared hard drives" for his?

More to the point,  WHY or why not.

Getting back to your idea of a problem in the USB start/stop
data flow. You are right I am sure.


In using the parameters from Joe's MAP65 I-Q fresh loaded
for SSB mode only.

I start Linrad, S and U, are done by Joe;s parameters

I press D, Linrad is working ( stand alone )

The next step is real confusing to me, given that the program
started with "netsend on" and it is suggested to do the
saving "W"

All I can do is, toggle T to remove the netsend on message,
toggle T again and do a W and then click D

Thinking make sure it is in "T" and  then save it.

One point of the confusion is that linrad comes in the
netsend on mode?

Anyway. Next is I start MAP65 I-Q and hope to not
to see "no RX data" and see a real dB number in the
noise indication window.

It leaves the selection of the cast mode in MAP65
as well as the setting of the diagnostics also in
the MAP65. program.

I hope somebody can tell me: you are all wrong it
should be this way.

Another issue is that the above is working most of
the time but not 100% solid,  I getting "no RX data"
at times.

I then start over. I have not bern able to discover
a way to correct the data stream issue with one or
2 key strokes.

Next question

Once MAP65 goes into transmit ( generating
tones via the sound card ( selected in MAP65 )
and also selected earlier for Linrad ( by Joe's
parameter file set.)

Should at that point the USB data stream form the
SDR I-Q box into linrad stop or not?
The incoming data are useless at that point anyway.

Should at the end of the send period in MAP65 the
USB data stream resume?

Suppose I did away with the USB SDR I-Q all togheter,

And change back to the delta44 what should happen
then in this respect ( linrad keeps working during the
send period? I have removed the USB factor now?


Going to put MAP65 I/Q on 3 other XP bench tops
and see what happens in transmit.


In conlusion, I get the impression of being an idiot having
to ask all these questions in the presence of 150 other
users!

73 Rein W6SZ

















--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Linrad" group.
To post to this group, send email to linrad@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to linrad+unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at http://groups.google.com/group/linrad?hl=en
-~----------~----~----~----~------~----~------~--~---


LINRADDARNIL