[Linrad] Linrad MAP65 Communication II

[Leif Asbrink <sm5bsz.com; leif@xxxxxxxxxxxxxxxx>]

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

--~--~---------~--~----~------------~-------~--~----~
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