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

Re: [V4Protocol] text

Expand Messages
  • 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 1 of 3 , Jul 3, 2011
      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
      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 ?


      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.