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

DTMF

Expand Messages
  • Mike Mullarkey
    My question here is I moved from Oregon where I had my UHF link system. We have a IRLP there node 3153, and my node here in Colorado node 3003. Both system use
    Message 1 of 13 , Dec 2, 2007
    • 0 Attachment

      My question here is I moved from Oregon where I had my UHF link system. We have a IRLP there node 3153, and my node here in Colorado node 3003. Both system use the RLC-4 controllers. Is there a way to allow the standard DTMF pass through while connected to a node and not a reflector. I can usally get the DTMF string to go through if I use my Kenwood radio with the DTMF auto dialer but if not using it there is no way to get the full string to pass.

       

       

       

      Mike Mullarkey (K7PFJ)

      IRLP Node 3003

      6886 Sage Ave

      Firestone, CO 80504

    • Nate Duehr
      ... Mike, You might be looking for the DTMF_REGEN feature. It can be enabled in the nodes in their /home/irlp/custom/environment file. Set it to YES and
      Message 2 of 13 , Dec 2, 2007
      • 0 Attachment
        On Dec 2, 2007, at 7:16 AM, Mike Mullarkey wrote:

        > My question here is I moved from Oregon where I had my UHF link
        > system. We have a IRLP there node 3153, and my node here in Colorado
        > node 3003. Both system use the RLC-4 controllers. Is there a way to
        > allow the standard DTMF pass through while connected to a node and
        > not a reflector. I can usally get the DTMF string to go through if I
        > use my Kenwood radio with the DTMF auto dialer but if not using it
        > there is no way to get the full string to pass.

        Mike,

        You might be looking for the DTMF_REGEN feature. It can be enabled in
        the nodes in their /home/irlp/custom/environment file. Set it to
        "YES" and restart the irlp node with /home/irlp/custom/rc.irlp as root.

        It will "copy" any DTMF at the local node and then regenerate that
        DTMF on the far end in a node-to-node connection.

        However, it comes with the pitfall that the first digit from the user
        radio triggers the muting, and sometimes gets through in-band.

        Example: If you were trying to dial "1234" from node 3003 and have
        that copied by a controller on the 3153 node, you would key up and hit
        1234 here in Colorado.

        Upon hitting the "1" here locally the IRLP audio would be muted toward
        the internet by the mixer moving the input from Line to CD. The very
        beginning of the "1" would pass through the standard IRLP audio path.
        So your controller in Oregon might copy:

        "11234".

        There are a few ways to deal with this, usually by sending some
        "nonsense" digit that your particular controller will "ignore" on the
        far end. I don't use the RLC controllers, but an example would be the
        standard (it can be changed) "clear buffer" DTMF digit for S-Com
        controllers of "#". So if you sent "#1234" from this end, the far end
        might copy "#1234" or it might just get "1234". Since in the S-Com
        the "#" just says "clear the command buffer" the controller would see
        it but do nothing from it.

        Hope that helps. You have my phone number if that doesn't make any
        sense -- give me a call. Maybe it's useful information for someone
        else here on the embedded list.

        Dave also added some environment settings recently for setting the
        duration and the volume (in relation to "100%" PCM audio in the sound
        mixer) to the DTMF Regeneration system in IRLP, but my nodes are too
        old to have the variable in the environment file, so I don't know what
        they are. If you find that the DTMF being generated it "too hot" or
        "too slow" you may need to tweak those.

        In addition, other "fancier" solutions could easily be coded into the
        custom_decode script that wouldn't be just regenerating all DTMF to
        the far side, such as setting up passwordless (key-based) SSH
        connections between the two nodes and scripting to drive the DTMF
        dialing commands remotely on the far-end node. Look in the /home/irlp/
        scripts and /home/irlp/bin directories for the various DTMF
        commands... I usually install Randy KC6HUR's fastdtmfdial script,
        which just "tweaks" the standard DTMF commands to allow for a standard
        level and digit length that's lower and shorter for things I need
        dialed.

        In our local area here, you may have heard 447.575's link send a blast
        of very quick DTMF to the repeater whenever a connection starts up
        from either IRLP or EchoLink. This is just fastdtmfdial in the
        custom_on script -- it uses a macro pre-programmed in the S-Com 7K at
        the mountain to put the repeater into CTCSS TX only on user CTCSS
        input mode, for linking in-band. Having custom_on set this every time
        makes sure the repeater is in "link mode" just in case we've set it
        back to "normal CTCSS on TX tail" mode for some reason.

        73,
        --
        Nate Duehr, WY0X
        nate@...
      • Mike Mullarkey
        Is there a way to allow the DTMF to pass through the to another node to control another part of a system. Is there a special script that will make this work.
        Message 3 of 13 , May 12 8:40 PM
        • 0 Attachment

          Is there a way to allow the DTMF to pass through the to another node to control another part of a system. Is there a special script that will make this work.

           

          Thanks,

           

          Mike Mullarkey (K7PFJ)

           

          NODE 3003

           

          Firestone,CO

          Denver Metro

        • Nate Duehr
          ... Hi Mike, DTMF_REGENERATION=YES in the /home/irlp/custom/environment file (default it s set to no) on the remote IRLP node will cause IRLP to regenerate any
          Message 4 of 13 , May 12 11:35 PM
          • 0 Attachment
            On May 12, 2008, at 9:40 PM, Mike Mullarkey wrote:

            > Is there a way to allow the DTMF to pass through the to another node
            > to control another part of a system. Is there a special script that
            > will make this work.

            Hi Mike,

            DTMF_REGENERATION=YES in the /home/irlp/custom/environment file
            (default it's set to no) on the remote IRLP node will cause IRLP to
            regenerate any DTMF it hears from a connected node (including voice
            falsing of DTMF) to the far-end.

            The problem with it is... IRLP takes a small amount of time to mute
            the locally received DTMF audio, which gets passed through also... so
            what it sounds like on the far-end is a tiny short blip of the first
            digit, and then a muted (no audio) key up, and then regenerated DTMF
            created in software in the node.

            If you have a way to teach the remote device to ignore that first
            "blip" of the first digit (many decoders are so fast, they'd detect
            it) then it's usable. Otherwise, it doesn't work well.

            Example: You call my node that has DTMF_REGENERATION turned on from
            your node.

            1.You punch "12345" into your rig.
            2. On my end, I get...
            A little audio blip of "1", and then a few seconds of silence (muted)
            while you punch "2345" on your end, then you unkey.

            3. And then I get "12345" regenerated from my node and then it unkeys.

            So... if something were being controlled from my node by you, it MIGHT
            receive:

            "112345".

            That make sense?

            I know some guys in California are successfully doing remote control
            with it, and maybe they've added digital audio delay boards to "cut
            off" that early DTMF digit or something... not sure.

            I've always wanted Dave Cameron to add a "unkey timer" prior to the
            DTMF being regenerated. That way whatever is decoding on the far end
            gets this:

            <Key>
            "1" (the audio blip)
            <Unkey>

            <Pause>

            <Key>
            "12345"
            <Unkey>

            That would work better.

            Dave's probably reading along, and we can poke at him to add something
            like that. The unkey delay would have to be adjustable since
            different radios turn around faster or slower than others.

            Or maybe he's already added it, and it's a "hidden" function? Dave???

            --
            Nate Duehr, WY0X
            nate@...
          • Randy Hammock
            ... When configured for _FD operation, I recall there being a way to disable regeneration and allow DTMF pass-through if both nodes agreed on the method. I
            Message 5 of 13 , May 13 12:02 AM
            • 0 Attachment
              On May 12, 2008, at 11:35 PM, Nate Duehr wrote:

              >
              >
              > On May 12, 2008, at 9:40 PM, Mike Mullarkey wrote:
              >
              >> Is there a way to allow the DTMF to pass through the to another node
              >> to control another part of a system. Is there a special script that
              >> will make this work.
              >
              > Hi Mike,
              >
              > DTMF_REGENERATION=YES in the /home/irlp/custom/environment file
              > (default it's set to no) on the remote IRLP node will cause IRLP to
              > regenerate any DTMF it hears from a connected node (including voice
              > falsing of DTMF) to the far-end.
              >
              > The problem with it is... IRLP takes a small amount of time to mute
              > the locally received DTMF audio, which gets passed through also... so
              > what it sounds like on the far-end is a tiny short blip of the first
              > digit, and then a muted (no audio) key up, and then regenerated DTMF
              > created in software in the node.
              >
              > If you have a way to teach the remote device to ignore that first
              > "blip" of the first digit (many decoders are so fast, they'd detect
              > it) then it's usable. Otherwise, it doesn't work well.
              >
              > Example: You call my node that has DTMF_REGENERATION turned on from
              > your node.
              >
              > 1.You punch "12345" into your rig.
              > 2. On my end, I get...
              > A little audio blip of "1", and then a few seconds of silence (muted)
              > while you punch "2345" on your end, then you unkey.
              >
              > 3. And then I get "12345" regenerated from my node and then it unkeys.
              >
              > So... if something were being controlled from my node by you, it MIGHT
              > receive:
              >
              > "112345".
              >
              > That make sense?
              >
              > I know some guys in California are successfully doing remote control
              > with it, and maybe they've added digital audio delay boards to "cut
              > off" that early DTMF digit or something... not sure.
              >
              > I've always wanted Dave Cameron to add a "unkey timer" prior to the
              > DTMF being regenerated. That way whatever is decoding on the far end
              > gets this:
              >
              > <Key>
              > "1" (the audio blip)
              > <Unkey>
              >
              > <Pause>
              >
              > <Key>
              > "12345"
              > <Unkey>
              >
              > That would work better.
              >
              > Dave's probably reading along, and we can poke at him to add something
              > like that. The unkey delay would have to be adjustable since
              > different radios turn around faster or slower than others.
              >
              > Or maybe he's already added it, and it's a "hidden" function? Dave???

              When configured for _FD operation, I recall there being a way to
              disable regeneration and allow DTMF pass-through if both nodes agreed
              on the method. I forget the settings.

              --
              Randy Hammock KC6HUR
              http://kc6hur.net/~rhammock/
              http://irlp.kc6hur.net/
              If there are no horses in heaven, then when I die, I want to go where
              they went.
            • David Cameron (IRLP)
              Actually, there is (or should be) and unkey between the initial send and the regen. If not, you can always add delay into the dtmfregen script. Dave Cameron
              Message 6 of 13 , May 14 1:17 PM
              • 0 Attachment
                Actually, there is (or should be) and unkey between the initial send and
                the regen. If not, you can always add delay into the dtmfregen script.

                Dave Cameron
                VE7LTD

                Nate Duehr wrote:
                >
                >
                >
                >
                > On May 12, 2008, at 9:40 PM, Mike Mullarkey wrote:
                >
                > > Is there a way to allow the DTMF to pass through the to another node
                > > to control another part of a system. Is there a special script that
                > > will make this work.
                >
                > Hi Mike,
                >
                > DTMF_REGENERATION= YES in the /home/irlp/custom/ environment file
                > (default it's set to no) on the remote IRLP node will cause IRLP to
                > regenerate any DTMF it hears from a connected node (including voice
                > falsing of DTMF) to the far-end.
                >
                > The problem with it is... IRLP takes a small amount of time to mute
                > the locally received DTMF audio, which gets passed through also... so
                > what it sounds like on the far-end is a tiny short blip of the first
                > digit, and then a muted (no audio) key up, and then regenerated DTMF
                > created in software in the node.
                >
                > If you have a way to teach the remote device to ignore that first
                > "blip" of the first digit (many decoders are so fast, they'd detect
                > it) then it's usable. Otherwise, it doesn't work well.
                >
                > Example: You call my node that has DTMF_REGENERATION turned on from
                > your node.
                >
                > 1.You punch "12345" into your rig.
                > 2. On my end, I get...
                > A little audio blip of "1", and then a few seconds of silence (muted)
                > while you punch "2345" on your end, then you unkey.
                >
                > 3. And then I get "12345" regenerated from my node and then it unkeys.
                >
                > So... if something were being controlled from my node by you, it MIGHT
                > receive:
                >
                > "112345".
                >
                > That make sense?
                >
                > I know some guys in California are successfully doing remote control
                > with it, and maybe they've added digital audio delay boards to "cut
                > off" that early DTMF digit or something... not sure.
                >
                > I've always wanted Dave Cameron to add a "unkey timer" prior to the
                > DTMF being regenerated. That way whatever is decoding on the far end
                > gets this:
                >
                > <Key>
                > "1" (the audio blip)
                > <Unkey>
                >
                > <Pause>
                >
                > <Key>
                > "12345"
                > <Unkey>
                >
                > That would work better.
                >
                > Dave's probably reading along, and we can poke at him to add something
                > like that. The unkey delay would have to be adjustable since
                > different radios turn around faster or slower than others.
                >
                > Or maybe he's already added it, and it's a "hidden" function? Dave???
                >
                > --
                > Nate Duehr, WY0X
                > nate@natetech. com <mailto:nate%40natetech.com>
                >
                >
              • Nate Duehr
                ... Hmm.... if it s there, I ve never heard it, but I wasn t listening all that closely either. :-) That would fix it, just fine. Cool. -- Nate Duehr, WY0X
                Message 7 of 13 , May 14 1:53 PM
                • 0 Attachment
                  On May 14, 2008, at 2:17 PM, David Cameron (IRLP) wrote:

                  > Actually, there is (or should be) and unkey between the initial send
                  > and
                  > the regen. If not, you can always add delay into the dtmfregen script.
                  >
                  > Dave Cameron
                  > VE7LTD


                  Hmm.... if it's there, I've never heard it, but I wasn't listening all
                  that closely either. :-)

                  That would "fix" it, just fine. Cool.

                  --
                  Nate Duehr, WY0X
                  nate@...
                • Mike Mullarkey
                  Hi David, I think that if the audio is lowered the DTMF will work but the voice audio cant be herd. I have my embedded node hooked to my RLC-4controller with
                  Message 8 of 13 , May 14 5:06 PM
                  • 0 Attachment

                    Hi David,

                     

                    I think that if the audio is lowered the DTMF will work but the voice audio cant be herd. I have my embedded node hooked to my RLC-4controller with the jumper taken out of the controller for flat or spkr audio. The audio is great and balanced so not sure why it wont work. I know Shorty K6JSI controls his network and has no issues. Must be something im doing here or Chris K7UND on his node 3153.

                     

                     

                     

                    Mike Mullarkey (K7PFJ)


                    From: irlp-embedded@yahoogroups.com [mailto: irlp-embedded@yahoogroups.com ] On Behalf Of David Cameron (IRLP)
                    Sent: Wednesday, May 14, 2008 2:17 PM
                    To: irlp-embedded@yahoogroups.com
                    Subject: Re: [irlp-embedded] DTMF

                     

                    Actually, there is (or should be) and unkey between the initial send and
                    the regen. If not, you can always add delay into the dtmfregen script.

                    Dave Cameron
                    VE7LTD

                    Nate Duehr wrote:

                    >
                    >
                    >
                    >
                    > On May 12, 2008, at 9:40 PM, Mike Mullarkey wrote:
                    >
                    > > Is there a way to allow the DTMF to pass through the to another node
                    > > to control another part of a system. Is there a special script that
                    > > will make this work.
                    >
                    > Hi Mike,
                    >
                    > DTMF_REGENERATION= YES in the /home/irlp/custom/ environment file
                    > (default it's set to no) on the remote IRLP node will cause IRLP to
                    > regenerate any DTMF it hears from a connected node (including voice
                    > falsing of DTMF) to the far-end.
                    >
                    > The problem with it is... IRLP takes a small amount of time to mute
                    > the locally received DTMF audio, which gets passed through also... so
                    > what it sounds like on the far-end is a tiny short blip of the first
                    > digit, and then a muted (no audio) key up, and then regenerated DTMF
                    > created in software in the node.
                    >
                    > If you have a way to teach the remote device to ignore that first
                    > "blip" of the first digit (many decoders are so fast, they'd
                    detect
                    > it) then it's usable. Otherwise, it doesn't work well.
                    >
                    > Example: You call my node that has DTMF_REGENERATION turned on from
                    > your node.
                    >
                    > 1.You punch "12345" into your rig.
                    > 2. On my end, I get...
                    > A little audio blip of "1", and then a few seconds of silence
                    (muted)
                    > while you punch "2345" on your end, then you unkey.
                    >
                    > 3. And then I get "12345" regenerated from my node and then it
                    unkeys.
                    >
                    > So... if something were being controlled from my node by you, it MIGHT
                    > receive:
                    >
                    > "112345".
                    >
                    > That make sense?
                    >
                    > I know some guys in California
                    are successfully doing remote control
                    > with it, and maybe they've added digital audio delay boards to "cut
                    > off" that early DTMF digit or something... not sure.
                    >
                    > I've always wanted Dave Cameron to add a "unkey timer" prior to
                    the
                    > DTMF being regenerated. That way whatever is decoding on the far end
                    > gets this:
                    >
                    > <Key>
                    > "1" (the audio blip)
                    > <Unkey>
                    >
                    > <Pause>
                    >
                    > <Key>
                    > "12345"
                    > <Unkey>
                    >
                    > That would work better.
                    >
                    > Dave's probably reading along, and we can poke at him to add something
                    > like that. The unkey delay would have to be adjustable since
                    > different radios turn around faster or slower than others.
                    >
                    > Or maybe he's already added it, and it's a "hidden" function?
                    Dave???
                    >
                    > --
                    > Nate Duehr, WY0X
                    > nate@natetech. com <mailto:nate% 40natetech. com>
                    >
                    >

                  • Nate Duehr
                    ... The DTMF_REGEN dtmf comes out at 100% I think by default, or it s settable somewhere... Dave may have added that later on, I can t remember... 50% of
                    Message 9 of 13 , May 14 5:42 PM
                    • 0 Attachment
                      On May 14, 2008, at 6:06 PM, Mike Mullarkey wrote:

                      > Hi David,
                      >
                      > I think that if the audio is lowered the DTMF will work but the
                      > voice audio cant be herd. I have my embedded node hooked to my
                      > RLC-4controller with the jumper taken out of the controller for flat
                      > or spkr audio. The audio is great and balanced so not sure why it
                      > wont work. I know Shorty K6JSI controls his network and has no
                      > issues. Must be something im doing here or Chris K7UND on his node
                      > 3153.
                      >

                      The DTMF_REGEN dtmf comes out at "100%" I think by default, or it's
                      settable somewhere...

                      Dave may have added that later on, I can't remember...

                      50% of full PCM audio is more than plenty on a properly set up node
                      that was set up with a Service Monitor... so if REGEN doesn't have a
                      way to turn that DTMF down digitally when it's generated Dave, it
                      needs it...

                      But I think it's already in there as a setting somewhere, Mike. I'll
                      have to go look... got a Net to get on in 15 minutes first, though...
                      (GRIN).

                      --
                      Nate Duehr
                      nate@...
                    • Chris Underwood
                      BCC d Steve @ Link Communications Hello Everyone, Mike and I have been doing a BUNCH of testing and we have it narrowed down to this as our issue. The first
                      Message 10 of 13 , May 15 1:14 PM
                      • 0 Attachment
                        BCC'd Steve @ Link Communications
                         
                        Hello Everyone,
                         
                        Mike and I have been doing a BUNCH of testing and we have it narrowed down to this as our issue.  The first part of the digit that is being heard at the far end (here in Oregon) is screwing up the repeater controller because it hears it and hangs on to it.  So, if Mike enters 12345, because the "1" is shortly played, my controller hears 112345.  So, if there is a way to get the script for DTMFREGEN to do an unkey before it keys up again to do the DTMF regen that would work because an unkey will clear the buffer on the controller.  It sounds like it is supposed to do this but it is not.  When Mike in Colorado keys up and enters 12345, here in Oregon I hear 1....12345 with NO unkeys between the first blip of the digit and the string to be entered.
                         
                        Does this make sense?  Can the DTMF Regen script be modified to first UNKEY after DTMF is heard and then Re-key to generate the DTMF?  I would think for people like myself that have to use the IRLP machine on the repeater frequency pair would be having this issue and a simple unkey of the node before a re-key to generate the DTMF would fix it.  Unfortunately I know nothing about scripts or writing them.
                         
                        Please help....
                         
                        Thanks!
                         
                         
                        Chris Underwood
                        christopher.underwood@...
                        (541) 744-9674 - Home
                        (541) 510-9895 - Cell

                        From: irlp-embedded@yahoogroups.com [mailto: irlp-embedded@yahoogroups.com ] On Behalf Of Nate Duehr
                        Sent: Wednesday, May 14, 2008 2:54 PM
                        To: irlp-embedded@yahoogroups.com
                        Subject: Re: [irlp-embedded] DTMF

                         


                        On May 14, 2008, at 2:17 PM, David Cameron (IRLP) wrote:

                        > Actually, there is (or should be) and unkey between the initial send
                        > and
                        > the regen. If not, you can always add delay into the dtmfregen script.
                        >
                        > Dave Cameron
                        > VE7LTD

                        Hmm.... if it's there, I've never heard it, but I wasn't listening all
                        that closely either. :-)

                        That would "fix" it, just fine. Cool.

                        --
                        Nate Duehr, WY0X
                        nate@natetech. com

                      • David Cameron (IRLP)
                        A 2 second delay was added earlier today. Perform a update files or reset your nodes, and try the system again. Dave Cameron VE7LTD
                        Message 11 of 13 , May 15 1:31 PM
                        • 0 Attachment
                          A 2 second delay was added earlier today. Perform a update files or
                          reset your nodes, and try the system again.

                          Dave Cameron
                          VE7LTD

                          Chris Underwood wrote:
                          >
                          > *BCC'd Steve @ Link Communications*
                          >
                          > Hello Everyone,
                          >
                          > Mike and I have been doing a BUNCH of testing and we have it narrowed
                          > down to this as our issue. The first part of the digit that is being
                          > heard at the far end (here in Oregon) is screwing up the repeater
                          > controller because it hears it and hangs on to it. So, if Mike enters
                          > 12345, because the "1" is shortly played, my controller hears 112345.
                          > So, if there is a way to get the script for DTMFREGEN to do an unkey
                          > before it keys up again to do the DTMF regen that would work because an
                          > unkey will clear the buffer on the controller. It sounds like it is
                          > supposed to do this but it is not. When Mike in Colorado keys up and
                          > enters 12345, here in Oregon I hear 1....12345 with NO unkeys between
                          > the first blip of the digit and the string to be entered.
                          >
                          > Does this make sense? Can the DTMF Regen script be modified to first
                          > UNKEY after DTMF is heard and then Re-key to generate the DTMF? I would
                          > think for people like myself that have to use the IRLP machine on the
                          > repeater frequency pair would be having this issue and a simple unkey of
                          > the node before a re-key to generate the DTMF would fix it.
                          > Unfortunately I know nothing about scripts or writing them.
                          >
                          > Please help....
                          >
                          > Thanks!
                          >
                          >
                          > Chris Underwood
                          > christopher.underwood@...
                          > (541) 744-9674 - Home
                          > (541) 510-9895 - Cell
                          >
                          > * From: * irlp-embedded@yahoogroups.com
                          > <mailto:irlp-embedded@yahoogroups.com> [mailto:
                          > irlp-embedded@yahoogroups.com ] *On Behalf Of *Nate Duehr
                          > *Sent:* Wednesday, May 14, 2008 2:54 PM
                          > *To:* irlp-embedded@yahoogroups.com
                          > <mailto:irlp-embedded@yahoogroups.com>
                          > *Subject:* Re: [irlp-embedded] DTMF
                          >
                          >
                          >
                          >
                          > On May 14, 2008, at 2:17 PM, David Cameron (IRLP) wrote:
                          >
                          > > Actually, there is (or should be) and unkey between the initial send
                          > > and
                          > > the regen. If not, you can always add delay into the dtmfregen script.
                          > >
                          > > Dave Cameron
                          > > VE7LTD
                          >
                          > Hmm.... if it's there, I've never heard it, but I wasn't listening all
                          > that closely either. :-)
                          >
                          > That would "fix" it, just fine. Cool.
                          >
                          > --
                          > Nate Duehr, WY0X
                          > nate@natetech. com <mailto:nate%40natetech.com>
                          >
                          >
                          >
                        • Mike Mullarkey
                          HI David, I just spoke with Chris K7UND in Oregon and he is resetting his node. I belive the problem is with his side since he can control my embedded node
                          Message 12 of 13 , May 15 1:36 PM
                          • 0 Attachment

                            HI David,

                             

                            I just spoke with Chris K7UND in Oregon and he is resetting his node. I belive the problem is with his side since he can control my embedded node just fine but when I try to control his controller that is where things get dicey.

                             

                            Mike Mullarkey (K7PFJ)


                            From: irlp-embedded@yahoogroups.com [mailto: irlp-embedded@yahoogroups.com ] On Behalf Of David Cameron (IRLP)
                            Sent: Thursday, May 15, 2008 2:32 PM
                            To: Chris Underwood
                            Cc: Mike Mullarkey; irlp-embedded@yahoogroups.com ; nate@...
                            Subject: Re: [irlp-embedded] DTMF

                             

                            A 2 second delay was added earlier today. Perform a update files or
                            reset your nodes, and try the system again.

                            Dave Cameron
                            VE7LTD

                            Chris Underwood wrote:

                            >
                            > *BCC'd Steve @ Link Communications*
                            >
                            > Hello Everyone,
                            >
                            > Mike and I have been doing a BUNCH of testing and we have it narrowed
                            > down to this as our issue. The first part of the digit that is being
                            > heard at the far end (here in Oregon )
                            is screwing up the repeater
                            > controller because it hears it and hangs on to it. So, if Mike enters
                            > 12345, because the "1" is shortly played, my controller hears
                            112345.
                            > So, if there is a way to get the script for DTMFREGEN to do an unkey
                            > before it keys up again to do the DTMF regen that would work because an
                            > unkey will clear the buffer on the controller. It sounds like it is
                            > supposed to do this but it is not. When Mike in Colorado
                            keys up and
                            > enters 12345, here in Oregon
                            I hear 1....12345 with NO unkeys between
                            > the first blip of the digit and the string to be entered.
                            >
                            > Does this make sense? Can the DTMF Regen script be modified to first
                            > UNKEY after DTMF is heard and then Re-key to generate the DTMF? I would
                            > think for people like myself that have to use the IRLP machine on the
                            > repeater frequency pair would be having this issue and a simple unkey of
                            > the node before a re-key to generate the DTMF would fix it.
                            > Unfortunately I know nothing about scripts or writing them.
                            >
                            > Please help....
                            >
                            > Thanks!
                            >
                            >
                            > Chris Underwood
                            > christopher. underwood@ comcast.net
                            > (541) 744-9674 - Home
                            > (541) 510-9895 - Cell
                            >
                            > * From: * irlp-embedded@ yahoogroups. com
                            > <mailto:irlp-embedded@ yahoogroups. com>
                            [mailto:
                            > irlp-embedded@ yahoogroups. com
                            ] *On Behalf Of *Nate Duehr
                            > *Sent:* Wednesday, May 14, 2008 2:54 PM
                            > *To:* irlp-embedded@ yahoogroups. com
                            > <mailto:irlp-embedded@ yahoogroups. com>
                            > *Subject:* Re: [irlp-embedded] DTMF
                            >
                            >
                            >
                            >
                            > On May 14, 2008, at 2:17 PM, David Cameron (IRLP) wrote:
                            >
                            > > Actually, there is (or should be) and unkey between the initial send
                            > > and
                            > > the regen. If not, you can always add delay into the dtmfregen
                            script.
                            > >
                            > > Dave Cameron
                            > > VE7LTD
                            >
                            > Hmm.... if it's there, I've never heard it, but I wasn't listening all
                            > that closely either. :-)
                            >
                            > That would "fix" it, just fine. Cool.
                            >
                            > --
                            > Nate Duehr, WY0X
                            > nate@natetech. com <mailto:nate% 40natetech. com>
                            >
                            >
                            >

                          • Chris Underwood
                            YEA!!!!!! That did it Dave! Now, there is an unkey before a re-key and now the DTMF is working GREAT! Thank you so much for your attention to this. Chris
                            Message 13 of 13 , May 15 2:01 PM
                            • 0 Attachment
                              YEA!!!!!!
                               
                              That did it Dave!  Now, there is an unkey before a re-key and now the DTMF is working GREAT!  Thank you so much for your attention to this.
                               
                              Chris Underwood
                              christopher.underwood@...
                              (541) 744-9674 - Home
                              (541) 510-9895 - Cell
                              ----- Original Message -----
                              Sent: Thursday, May 15, 2008 1:31 PM
                              Subject: Re: [irlp-embedded] DTMF

                              A 2 second delay was added earlier today. Perform a update files or
                              reset your nodes, and try the system again.

                              Dave Cameron
                              VE7LTD

                              Chris Underwood wrote:
                              >
                              > *BCC'd Steve @ Link Communications*

                              > Hello Everyone,

                              > Mike and I have been doing a BUNCH of testing and we have it narrowed
                              > down to this as our issue.  The first part of the digit that is being
                              > heard at the far end (here in Oregon) is screwing up the repeater
                              > controller because it hears it and hangs on to it.  So, if Mike enters
                              > 12345, because the "1" is shortly played, my controller hears 112345. 
                              > So, if there is a way to get the script for DTMFREGEN to do an unkey
                              > before it keys up again to do the DTMF regen that would work because an
                              > unkey will clear the buffer on the controller.  It sounds like it is
                              > supposed to do this but it is not.  When Mike in Colorado keys up and
                              > enters 12345, here in Oregon I hear 1....12345 with NO unkeys between
                              > the first blip of the digit and the string to be entered.

                              > Does this make sense?  Can the DTMF Regen script be modified to first
                              > UNKEY after DTMF is heard and then Re-key to generate the DTMF?  I would
                              > think for people like myself that have to use the IRLP machine on the
                              > repeater frequency pair would be having this issue and a simple unkey of
                              > the node before a re-key to generate the DTMF would fix it. 
                              > Unfortunately I know nothing about scripts or writing them.

                              > Please help....

                              > Thanks!


                              > Chris Underwood
                              > christopher.underwood@...
                              > (541) 744-9674 - Home
                              > (541) 510-9895 - Cell
                              >
                              >     * From: * irlp-embedded@yahoogroups.com
                              >     <mailto:irlp-embedded@yahoogroups.com> [mailto:
                              >     irlp-embedded@yahoogroups.com ] *On Behalf Of *Nate Duehr
                              >     *Sent:* Wednesday, May 14, 2008 2:54 PM
                              >     *To:* irlp-embedded@yahoogroups.com
                              >     <mailto:irlp-embedded@yahoogroups.com>
                              >     *Subject:* Re: [irlp-embedded] DTMF
                              >
                              >     
                              >
                              >
                              >     On May 14, 2008, at 2:17 PM, David Cameron (IRLP) wrote:
                              >
                              >     >  Actually, there is (or should be) and unkey between the initial send
                              >     >  and
                              >     >  the regen. If not, you can always add delay into the dtmfregen script.
                              >     >
                              >     >  Dave Cameron
                              >     >  VE7LTD
                              >
                              >     Hmm.... if it's there, I've never heard it, but I wasn't listening all
                              >     that closely either. :-)
                              >
                              >     That would "fix" it, just fine. Cool.
                              >
                              >     --
                              >     Nate Duehr, WY0X
                              >     nate@natetech. com <mailto:nate%40natetech.com>
                              >
                              >    
                              >
                            Your message has been successfully submitted and would be delivered to recipients shortly.