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

{NAME} macro

Expand Messages
  • Clive Whelan
    I noticed this phenomenon last year in the FOC Marathon event but discounted it, and foolishly didn t do any further work in the meanwhile. Therefore it came
    Message 1 of 14 , Feb 1, 2009
    • 0 Attachment
      I noticed this phenomenon last year in the FOC Marathon event but
      discounted it, and foolishly didn't do any further work in the
      meanwhile. Therefore it came back this year and bit me on the bottom!

      Scenario: in ESM

      {NAME} is used in both F2 messages ( run and S&P), e.g.

      run: hi {NAME} 5nn930

      s&p: tu {NAME} foc


      The file used is a standard call-history file.

      The problem is that this works 100% in the S&P message but only about
      20% of the time in the run message without any apparent logic. No matter
      where the macro is placed in the run message, or even if it appears on
      its own the result is the same, viz intermittency. The only thing I can
      think of is that in run mode F5 is being sent before F2, but I can't see
      why this should be a problem. The most curious thing is that the
      performance is not consistent.

      Any ideas welcome.

      73


      Clive
      GW3NJW
    • Tommy
      Clive, I have basically the same macros as you have and have never heard N1MM drop the name if it was in my CallHistory file. Mine: RUN F2 hi {NAME} ur 5nn
      Message 2 of 14 , Feb 1, 2009
      • 0 Attachment
        Clive,



        I have basically the same macros as you have and have never heard N1MM drop
        the name if it was in my CallHistory file.



        Mine:



        RUN

        F2 hi {NAME} ur 5nn 1825

        F3 tks {NAME} 161 ee

        S&P

        F2 tks {NAME} 5nn 1825

        F3 tks {NAME} 161 ee



        Seems to be working for me!



        Tom - W4BQF





        From: N1MMLogger@yahoogroups.com [mailto:N1MMLogger@yahoogroups.com] On
        Behalf Of Clive Whelan
        Sent: Sunday, February 01, 2009 6:03 AM
        To: N1MMLogger@yahoogroups.com
        Subject: [N1MM] {NAME} macro



        I noticed this phenomenon last year in the FOC Marathon event but
        discounted it, and foolishly didn't do any further work in the
        meanwhile. Therefore it came back this year and bit me on the bottom!

        Scenario: in ESM

        {NAME} is used in both F2 messages ( run and S&P), e.g.

        run: hi {NAME} 5nn930

        s&p: tu {NAME} foc

        The file used is a standard call-history file.

        The problem is that this works 100% in the S&P message but only about
        20% of the time in the run message without any apparent logic. No matter
        where the macro is placed in the run message, or even if it appears on
        its own the result is the same, viz intermittency. The only thing I can
        think of is that in run mode F5 is being sent before F2, but I can't see
        why this should be a problem. The most curious thing is that the
        performance is not consistent.

        Any ideas welcome.

        73

        Clive
        GW3NJW





        [Non-text portions of this message have been removed]
      • Clive Whelan
        Tom Curiouser and curiouser! I should add that I am using the MK2R+ with its inbuilt Winkey. Hopefully, one of the gurus will cast light. One additional thing
        Message 3 of 14 , Feb 1, 2009
        • 0 Attachment
          Tom

          Curiouser and curiouser!

          I should add that I am using the MK2R+ with its inbuilt Winkey.

          Hopefully, one of the gurus will cast light. One additional thing I
          notice is that when the macro is ignored and it is e.g. at the end of
          the F2 message, then the Winkey is locked out, and I can't even
          interject on the paddle to send the name which is normally possible of
          course. This does tend to indicate some problem in the Winkey protocols.
          My best guess is that you are not using a Winkey, and perhaps letting
          N1MM do all the sending?

          73


          Clive
          GW3NJW.

          Tommy wrote:
          >
          > Clive,
          >
          > I have basically the same macros as you have and have never heard N1MM
          > drop
          > the name if it was in my CallHistory file.
          >
          > Mine:
          >
          > RUN
          >
          > F2 hi {NAME} ur 5nn 1825
          >
          > F3 tks {NAME} 161 ee
          >
          > S&P
          >
          > F2 tks {NAME} 5nn 1825
          >
          > F3 tks {NAME} 161 ee
          >
          > Seems to be working for me!
          >
          > Tom - W4BQF
          >
          > From: N1MMLogger@yahoogroups.com <mailto:N1MMLogger%40yahoogroups.com>
          > [mailto:N1MMLogger@yahoogroups.com
          > <mailto:N1MMLogger%40yahoogroups.com>] On
          > Behalf Of Clive Whelan
          > Sent: Sunday, February 01, 2009 6:03 AM
          > To: N1MMLogger@yahoogroups.com <mailto:N1MMLogger%40yahoogroups.com>
          > Subject: [N1MM] {NAME} macro
          >
          > I noticed this phenomenon last year in the FOC Marathon event but
          > discounted it, and foolishly didn't do any further work in the
          > meanwhile. Therefore it came back this year and bit me on the bottom!
          >
          > Scenario: in ESM
          >
          > {NAME} is used in both F2 messages ( run and S&P), e.g.
          >
          > run: hi {NAME} 5nn930
          >
          > s&p: tu {NAME} foc
          >
          > The file used is a standard call-history file.
          >
          > The problem is that this works 100% in the S&P message but only about
          > 20% of the time in the run message without any apparent logic. No matter
          > where the macro is placed in the run message, or even if it appears on
          > its own the result is the same, viz intermittency. The only thing I can
          > think of is that in run mode F5 is being sent before F2, but I can't see
          > why this should be a problem. The most curious thing is that the
          > performance is not consistent.
          >
          > Any ideas welcome.
          >
          > 73
          >
          > Clive
          > GW3NJW
          >
          > [Non-text portions of this message have been removed]
          >
          >
        • Tommy
          Your guess is spot on Clive! I use COM 2 into a transistor switch to key my Omni 6+ and my IC-7700. I m finding the macro delay is related to being
          Message 4 of 14 , Feb 1, 2009
          • 0 Attachment
            Your 'guess' is spot on Clive! I use COM 2 into a transistor switch to key
            my Omni 6+ and my IC-7700.



            I'm finding the 'macro delay' is related to being connected to a DX cluster!
            No delay is happening until you connect and get some spots in the band maps.



            73,



            Tom - W4BQF





            From: N1MMLogger@yahoogroups.com [mailto:N1MMLogger@yahoogroups.com] On
            Behalf Of Clive Whelan
            Sent: Sunday, February 01, 2009 9:47 AM
            To: N1MMLogger@yahoogroups.com
            Subject: Re: [N1MM] {NAME} macro



            Tom

            Curiouser and curiouser!

            I should add that I am using the MK2R+ with its inbuilt Winkey.

            Hopefully, one of the gurus will cast light. One additional thing I
            notice is that when the macro is ignored and it is e.g. at the end of
            the F2 message, then the Winkey is locked out, and I can't even
            interject on the paddle to send the name which is normally possible of
            course. This does tend to indicate some problem in the Winkey protocols.
            My best guess is that you are not using a Winkey, and perhaps letting
            N1MM do all the sending?

            73

            Clive
            GW3NJW.

            Tommy wrote:
            >
            > Clive,
            >
            > I have basically the same macros as you have and have never heard N1MM
            > drop
            > the name if it was in my CallHistory file.
            >
            > Mine:
            >
            > RUN
            >
            > F2 hi {NAME} ur 5nn 1825
            >
            > F3 tks {NAME} 161 ee
            >
            > S&P
            >
            > F2 tks {NAME} 5nn 1825
            >
            > F3 tks {NAME} 161 ee
            >
            > Seems to be working for me!
            >
            > Tom - W4BQF
            >
            > From: N1MMLogger@yahoogroups.com <mailto:N1MMLogger%40yahoogroups.com>
            <mailto:N1MMLogger%40yahoogroups.com>
            > [mailto:N1MMLogger@yahoogroups.com <mailto:N1MMLogger%40yahoogroups.com>
            > <mailto:N1MMLogger%40yahoogroups.com>] On
            > Behalf Of Clive Whelan
            > Sent: Sunday, February 01, 2009 6:03 AM
            > To: N1MMLogger@yahoogroups.com <mailto:N1MMLogger%40yahoogroups.com>
            <mailto:N1MMLogger%40yahoogroups.com>
            > Subject: [N1MM] {NAME} macro
            >
            > I noticed this phenomenon last year in the FOC Marathon event but
            > discounted it, and foolishly didn't do any further work in the
            > meanwhile. Therefore it came back this year and bit me on the bottom!
            >
            > Scenario: in ESM
            >
            > {NAME} is used in both F2 messages ( run and S&P), e.g.
            >
            > run: hi {NAME} 5nn930
            >
            > s&p: tu {NAME} foc
            >
            > The file used is a standard call-history file.
            >
            > The problem is that this works 100% in the S&P message but only about
            > 20% of the time in the run message without any apparent logic. No matter
            > where the macro is placed in the run message, or even if it appears on
            > its own the result is the same, viz intermittency. The only thing I can
            > think of is that in run mode F5 is being sent before F2, but I can't see
            > why this should be a problem. The most curious thing is that the
            > performance is not consistent.
            >
            > Any ideas welcome.
            >
            > 73
            >
            > Clive
            > GW3NJW
            >
            > [Non-text portions of this message have been removed]
            >
            >





            [Non-text portions of this message have been removed]
          Your message has been successfully submitted and would be delivered to recipients shortly.