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

Re: [BPQ32] broadcast (was: New UZ7HO Modem Driver)

Expand Messages
  • Charles Brabham
    More information on multicast on HF at: http://uspacket.org/network/index.php/board,5.0.html I would wonder how well the PACSAT protocol suite would fit in
    Message 1 of 43 , Dec 26, 2011
    • 0 Attachment
      More information on multicast on HF at:  http://uspacket.org/network/index.php/board,5.0.html
       
      I would wonder how well the PACSAT protocol suite would fit in for HF operation, as it is designed for something else entirely.
       
      73 DE Charles, N5PVL
       
       
      ----- Original Message -----
      From: Andre
      Sent: Sunday, December 25, 2011 10:44 AM
      Subject: Re: [BPQ32] broadcast (was: New UZ7HO Modem Driver)

       

      Op 25-12-2011 14:09, Charles Brabham schreef:

      I don't see any mention of error detection - much less correction. Being from the CGA graphics era, one would doubt that checksums for compressed forwarding were being employed at the time it was written.
       
      If it was really useful software, I think that a lot more of us would have heard of it, and at least a  few of us would be able to say how well it works.
       
      On the other hand, hardly anybody has ever heard of GTEPMS, and it was one of the best BBS programs in its day.
       
      SPAR has developed an AMP ( Amateur Multicast Protocol ) that will transfer the data and confirm accuracy. If you would like to participate in developing this protocol, SPAR is the place to go. Nice folks there. Talk to W5ALT, who developed AMP and the AltCast AMP software suite that utilizes PSK modes.
       
       
      Backtalk is not really what I would call 'multicast', not even on a wannabee basis... At best, I would credit it as a passive monitoring system.
       
      Close - but no banana.
       
       
      73 DE Charles, N5PVL
       

       
      Not sure if AMP is the best suited multicast protocoll for forwarding purpose, I'm personaly more for implementing the pacsat protocoll suit, it is already very wel documented, it has been used for forwarding already and can broadcast on demand rather then all the time.
      Might need a bit of tweaking to accept broadcasts from more then one station but clients normaly won't have to deal with that. talking of clients, there is already a client for the pacsat protocoll called whisp on windows and there are also linux versions.

      73 Andre PE1RDW

    • Bob Unger
      Yes... development ran right thru it.  By the time I finished my HEATH 232, it passed.  BPQ brought us a long way.  We ll be forever greatful for that.  I
      Message 43 of 43 , Dec 26, 2011
      • 0 Attachment
        Yes... development ran right thru it.  By the time I finished my HEATH 232, it passed.  BPQ brought us a long way.  We'll be forever greatful for that.  I might be too old for the new one. 
         WE'll see.
        73 de Bob in Bethlehem, Pa. WB3DTG <<610-868-1112>>
        From: Charles Brabham <n5pvl@...>
        To: BPQ32@yahoogroups.com
        Sent: Monday, December 26, 2011 7:49 PM
        Subject: Re: [BPQ32] broadcast (was: New UZ7HO Modem Driver)

         
        More information on multicast on HF at:  http://uspacket.org/network/index.php/board,5.0.html
         
        I would wonder how well the PACSAT protocol suite would fit in for HF operation, as it is designed for something else entirely.
         
        73 DE Charles, N5PVL
         
         
        ----- Original Message -----
        From: Andre
        Sent: Sunday, December 25, 2011 10:44 AM
        Subject: Re: [BPQ32] broadcast (was: New UZ7HO Modem Driver)

         
        Op 25-12-2011 14:09, Charles Brabham schreef:
        I don't see any mention of error detection - much less correction. Being from the CGA graphics era, one would doubt that checksums for compressed forwarding were being employed at the time it was written.
         
        If it was really useful software, I think that a lot more of us would have heard of it, and at least a  few of us would be able to say how well it works.
         
        On the other hand, hardly anybody has ever heard of GTEPMS, and it was one of the best BBS programs in its day.
         
        SPAR has developed an AMP ( Amateur Multicast Protocol ) that will transfer the data and confirm accuracy. If you would like to participate in developing this protocol, SPAR is the place to go. Nice folks there. Talk to W5ALT, who developed AMP and the AltCast AMP software suite that utilizes PSK modes.
         
        http://www.spar-hams.org/docs/amp-protocol.html
         
        Backtalk is not really what I would call 'multicast', not even on a wannabee basis... At best, I would credit it as a passive monitoring system.
         
        Close - but no banana.
         
         
        73 DE Charles, N5PVL
         

         
        Not sure if AMP is the best suited multicast protocoll for forwarding purpose, I'm personaly more for implementing the pacsat protocoll suit, it is already very wel documented, it has been used for forwarding already and can broadcast on demand rather then all the time.
        Might need a bit of tweaking to accept broadcasts from more then one station but clients normaly won't have to deal with that. talking of clients, there is already a client for the pacsat protocoll called whisp on windows and there are also linux versions.

        73 Andre PE1RDW


      Your message has been successfully submitted and would be delivered to recipients shortly.