Loading ...
Sorry, an error occurred while loading the content.

RE: [BPQ32] BPQ32, RMS Packet & WinLink, some thoughts

Expand Messages
  • Rick Muething
    A clarification: WL2K does not encourage or support HF keyboard connections and Keyboard commands on HF Pactor are very limited to basically just killing a
    Message 1 of 70 , Dec 7, 2009
    • 0 Attachment

      A clarification:


      WL2K does not encourage or support HF keyboard connections and Keyboard commands on HF Pactor are very limited to basically just killing a pending message.  The reason for this is simple. Keyboard commands and use are slow and waste precious HF bandwidth (Pactor or WINMOR are connected ARQ and only support one connection at a time on a frequency).  To allow keyboard connections on HF would dramatically reduce the capacity of the limited HF channels. Even on VHF/UHF packet where connections can “share” a frequency Keyboard is inefficient as it is does not use compression and so reduces the channel capacity by about half compared to binary compression of text using the WL2K B2 format and encapsulation.

       

      There are several client programs now that support auto forward on HF to Winlink including AirMail, Paclink and the new RMS Express which currently supports just WINMOR. RMS Express will be expanded to include packet capability (using native KISS drivers) and Pactor 2/3 capability. There is no plan to support Pactor 1 on RMS Express as WINMOR will outperform Pactor 1 and is lower cost.


      Although Pactor 1, 2 and 3  will continue to be supported by WL2K we expect Pactor 1 usage to decline once WINMOR is fully deployed.

       

      Rick Muething, KN6KB  Winlink Development Team

       

       

       


      From: BPQ32@yahoogroups.com [mailto: BPQ32@yahoogroups.com ] On Behalf Of WA4ZKO
      Sent: Monday, December 07, 2009 11:50 AM
      To: BPQ32@yahoogroups.com
      Subject: [BPQ32] BPQ32, RMS Packet & WinLink, some thoughts

       

       

      Comments inserted below....

      73
      Jeff
      WA4ZKO

      --- In BPQ32@yahoogroups. com, "John Wiseman" <john.wiseman@ ...> wrote:

      >
      > Each Pactor port only supports one connect at a time.
      >
      > The KAM VHF port supports up to 10 sessions (with the code about to be
      > released).

      Nice, very nice. Will make the KAM's a nice option for those for which Pactor 1 will suffice for their HF link needs versus the bigger $$$$ for the SCS modems. A nice option for folks looking for something a bit more robust than HF packet without breaking the bank so bad. With this and a KAM-XL you can have HF 300bd or Pactor 1 on TNC port 1, then 1200 or 9600 on TNC Port 2, pretty darn nice!

      How well the KAM's do Pactor 1 versus the SCS modem is probably a good question. I've heard mixed reports that the KAM-XL is just as good at P1??? Obviously you're stuck at Pactor 1 speeds, but for many that may be just fine when you get it for about half the cost.

      >
      > I'm not sure what you are saying regards RMS packet. The whole point of
      > adding BPQ32 support to RMS Packet is to give all users (HF or VHF)
      > access to the Winlink system. Either as a keyboard user, or using a B2
      > protocol compatible client to forward mail. Why not mention it?
      >

      That was half tongue in cheek. Basically if you have a HF port on BPQ32 node and RMS Packet running on top of it..you have at least basic HF access to WinLink (via the node). How usable this is with airmail and so forth?

      I THINK the WinLink "leadership" has wanted to keep HF entry point access somewhat constrained/ controlled. RMS Packet was focused on VHF/UHF access. For HF they have the RMS HF software and don't openly offer it for download, see here:

      http://www.winlink. org/SysopSoftwar e

      Specifically note the following on their web page above:

      "RMS HF software distribution is currently limited to existing WL2K HF stations."

      They may not be too fond of what we're doing? Do we really care, grin? The WinLink leadership can be a tad "odd" about things and with a doze of "control factor" from what I've seen. Granted I think they're going to open the gates more as WINMOR matures, so maybe that "attitude" is changing. Maybe I've misread their intentions.

      Obviously depending on the range of your HF port, you might get into the 3rd party content issues and so forth. Foreign stations coming in on your HF port, pulling up RMS and tx/rx messages. Again not necessarily a bad thing, but something a HF node sysop needs to be aware of if RMS Packet is running on the node.

      The other angle of this is if word spreads that your node offers this, you could wind up with a very BUSY HF port due to WinLink folks piling onto it! Maybe I'm overly concerned here or missing something on what the pactor port can/can not do, but I do think it's something to consider if you have RMS Packet running on your BPQ32 node.

      > The issue of gatewaying to frequencies that you are not licensed to
      > operate has been around since the first BPQ and Kantronics KANODE
      > systems. My understanding is that it is fine in the
      w:st="on"> UK , but as all
      > administrations have different rules it is up to the sysop to check what
      > is allowed before setting up such gateways.
      >
      > 73,
      > John
      >
      >
      > -----Original Message-----
      > From: BPQ32@yahoogroups. com
      [mailto:BPQ32@yahoogroups. com] On Behalf Of
      > WA4ZKO
      > Sent: 07 December 2009 00:58
      > To: BPQ32@yahoogroups. com
      > Subject: [BPQ32] Re: A problem wirh Pactor support for BPQ32.
      >
      >
      >
      >
      >
      > Can there be more than one concurrent inbound connection to the node on
      > the Pactor port?
      >
      > Probably shouldn't mention this one publicly, but if you've got RMS
      > Packet running on top of your BPQ32 node that has a HF port....some cool
      > flexibility there. EMCOMM handy even if all they can do is pull up an
      > interactive session to WinLink (text only email), but maybe some legal
      > or more monitoring issues?
      >
      > Also, what is the legality of say letting a VHF/UHF user (that doesn't
      > have HF privileges) make outbound connects on HF? No lawyer, but I'm
      > guessing this is fine even when running unattended? Thoughts?
      >
      > 73
      > Jeff
      > WA4ZKO
      >
      > --- In BPQ32@yahoogroups. <mailto:BPQ32% 40yahoogroups. com>
      com, ke7xo
      > <ke7xo@> wrote:
      > >
      > > number one does defeat the purpose of a 'node'... however, it will
      > allow
      > > multiple in connects.
      > >
      > > if absolutely necessary, I can turn on the digi function to allow
      > users
      > > to go thru me to another station.
      > >
      > > I vote for number one...
      > >
      > > Richard
      > >
      > >
      > >
      > > John Wiseman wrote:
      > > >
      > > > I've found a serious flaw with outbound connects.
      > > >
      > > > If I connect to your node, then connect out on Pactor the call
      goes
      > > > out with your callsign. I 'm currently testing a fix for the KAM
      > > > version, and will be working on the SCS tomorrow.
      > > >
      > > > I've also got ax.25 working on the KAM VHF port. so it can be
      used
      > for
      > > > Pactor on HF and packet on VHF as the same time. Unfortunately
      is is
      >
      > > > not so easy to fix the outgoing call problem with ax.25, as it
      > > > supports multiple connects, and changing MYCALL would mess
      things
      > up.
      > > > The options seem to be
      > > >
      > > > 1. Don't allow outbound calls on the VHF port, unless originated
      > from
      > > > a local application.
      > > >
      > > > 2. Limit the VHF port to a single user at a time.
      > > >
      > > > My preference is for the first. It seems a port which allows
      user
      > > > access and BBS outbound forwarding is better than nothing, but I
      > would
      > > > be interested in your views.
      > > >
      > > > The dual mode KAM code should be available for testing tomorrow.
      > > >
      > > > 73,
      > > >
      > > > John
      > > >
      > > >
      > >
      >

      No virus found in this incoming message.
      Checked by AVG - www.avg.com
      Version: 9.0.709 / Virus Database: 270.14.91/2541 - Release Date: 12/06/09 14:37:00

    • John Wiseman
      A user is having problems getting the VHF port of a KAM+ working with the Pactor dirver. I ve only tested it with a KAM XL, and was wonderig if anyone has it
      Message 70 of 70 , Dec 9, 2009
      • 0 Attachment
        Message
        A user is having problems getting the VHF port of a KAM+ working with the Pactor dirver. I've only tested it with a KAM XL, and was wonderig if anyone has it working with other versions of the KAM.
         
         
        Thanks,
        John
         
      Your message has been successfully submitted and would be delivered to recipients shortly.