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

text

Expand Messages
  • DAVID
    have noticed on all versions, that when receiving and FEC CQ call, that the text is always run togeather with no spaces. think the space is being filled with
    Message 1 of 3 , Jul 3 7:55 AM
    • 0 Attachment
      have noticed on all versions, that when receiving and FEC CQ call, that the text is always run togeather with no spaces. think the space is being filled with the 0.

      from the debug log:

      011/07/03 14:39:10 {FEC Rcv} CQ0KB0E0
      2011/07/03 14:39:15 {FEC Rcv} CQ0KB0E0
      2011/07/03 14:39:20 {FEC Rcv} CQ0KB0E0
      2011/07/03 14:39:26 {FEC Rcv} CQ0KB0E0
      2011/07/03 14:39:31 {FEC Rcv} CQ0KB0E0
      2011/07/03 14:39:36 {FEC Rcv} CQ0KB0E0


      anyone ?

      david/wd4kpd

      ps...v301 still wanders off into God knows where during ARQ attempts.
    • Rick Muething
      David/All, This is exactly as designed. The Connect request and CQ frame have the same syntax and that syntax packs both call signs (including optional
      Message 2 of 3 , Jul 3 9:29 AM
      • 0 Attachment
        David/All,
        This is exactly as designed.  The Connect request and CQ frame have the same syntax and that syntax packs both call signs (including optional –ssid) into a 16 character frame.  To do this a simple but effective and efficient coding scheme is used:
        Characters 1-8  Target call sign   defined as:
        The call sign (up to 7 characters) + a following character  0-F   . “0” defines no ssid used, “1” defines ssid of –1, ...”F” defines ssid of –15.
        If a call sign with ssid desgnator is < 8 characters it is null padded (note a null is not the character “0” but a byte of value 0 which is not printable)
         
        Characters 9-16 are as above but are for the calling call sign.
         
        So  “CQ0KB0E0”  is really the 16 character string representing:
        “C”, “Q”, “0”, nul,nul,nul,nul,nul,”K”,”B”,”0”,”E”,”0”,nul,nul,nul
        and is interpreted as
        Calling call sign “CQ” with no –ssid from call sign KB0E with no ssid
         
        The syntax is exactly the same for one station calling another except the CQ is replaced by the target station call sign.
         
        The software decodes the above as a connect request (if not connected) and checks the validity (proper MARS or HAM call sign) syntax. Since “CQ” is not a valid call sign there should never be a station that would answer a call to CQ.  It serves the same purpose it does on CW or Phone...to indicated to any station listing that the calling station wishes to connect to anyone. It is followed by (just as in the CW or SSB case) with a return call to the station calling CQ.
         
        It is possible to suppress the printing of such special decodes but in the interest of allowing monitoring it is displayed in both FEC and ARQ modes.
         
        Hope this answers the question.  I will make sure it is explained clearly in the protocol document.
         
        Rick KN6KB
      • Fred G -w1wyc
        David, Check out Rick KN6KB s write-up from earlier today. He describes the o as seen in the text. If you didn t get it I have included it below. Fred, W1WYC
        Message 3 of 3 , Jul 3 11:11 AM
        • 0 Attachment
          David,
           
          Check out Rick KN6KB's write-up from earlier today. He describes the "o" as seen in the text.
          If you didn't get it I have included it below.
           
          Fred, W1WYC
           
          David/All,
          This is exactly as designed.  The Connect request and CQ frame have the same syntax and that syntax packs both call signs (including optional –ssid) into a 16 character frame.  To do this a simple but effective and efficient coding scheme is used:
          Characters 1-8  Target call sign   defined as:
          The call sign (up to 7 characters) + a following character  0-F   . “0” defines no ssid used, “1” defines ssid of –1, ...”F” defines ssid of –15.
          If a call sign with ssid desgnator is < 8 characters it is null padded (note a null is not the character “0” but a byte of value 0 which is not printable)
           
          Characters 9-16 are as above but are for the calling call sign.
           
          So  “CQ0KB0E0”  is really the 16 character string representing:
          “C”, “Q”, “0”, nul,nul,nul,nul,nul,”K”,”B”,”0”,”E”,”0”,nul,nul,nul
          and is interpreted as
          Calling call sign “CQ” with no –ssid from call sign KB0E with no ssid
           
          The syntax is exactly the same for one station calling another except the CQ is replaced by the target station call sign.
           
          The software decodes the above as a connect request (if not connected) and checks the validity (proper MARS or HAM call sign) syntax. Since “CQ” is not a valid call sign there should never be a station that would answer a call to CQ.  It serves the same purpose it does on CW or Phone...to indicated to any station listing that the calling station wishes to connect to anyone. It is followed by (just as in the CW or SSB case) with a return call to the station calling CQ.
           
          It is possible to suppress the printing of such special decodes but in the interest of allowing monitoring it is displayed in both FEC and ARQ modes.
           
          Hope this answers the question.  I will make sure it is explained clearly in the protocol document.
           
          Rick KN6KB

          ----- Original Message -----
          From: DAVID
          Sent: Sunday, July 03, 2011 10:55 AM
          Subject: [V4Protocol] text

           

          have noticed on all versions, that when receiving and FEC CQ call, that the text is always run togeather with no spaces. think the space is being filled with the 0.

          from the debug log:

          011/07/03 14:39:10 {FEC Rcv} CQ0KB0E0
          2011/07/03 14:39:15 {FEC Rcv} CQ0KB0E0
          2011/07/03 14:39:20 {FEC Rcv} CQ0KB0E0
          2011/07/03 14:39:26 {FEC Rcv} CQ0KB0E0
          2011/07/03 14:39:31 {FEC Rcv} CQ0KB0E0
          2011/07/03 14:39:36 {FEC Rcv} CQ0KB0E0

          anyone ?

          david/wd4kpd

          ps...v301 still wanders off into God knows where during ARQ attempts.

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