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

Playnews

Expand Messages
  • Tim Sawyer
    Hi, I went to install the playnews script om my embedded node and got the ... Install playnews ... Now beginning the installation process: depend: mpg123
    Message 1 of 28 , Nov 11, 2006
    • 0 Attachment
      Hi,

      I went to install the playnews script om my embedded node and got the
      following message:

      ------------------------------------------------------------------------
      Install playnews
      ------------------------------------------------------------------------
      Now beginning the installation process:

      depend: mpg123 [FAILED]
      ERROR: /usr/local/bin/mpg123/mpg123, file not found.
      exists: /home/irlp/audio/custom [ OK ]
      create: /home/irlp/audio/custom/news [ OK ]
      install: confirm.wav [ OK ]
      install: confirm [FAILED]

      It wants mpg123 which is a MPEG audio player for Linux. What's the
      best way to install this? Is this something that only Dave can add?

      Thanks!
      Tim
    • Randy Hammock
      I need to update the install script, because it now uses mpg321. The confirm scriptshould have been part of the package; however, it should be available on on
      Message 2 of 28 , Nov 11, 2006
      • 0 Attachment
        I need to update the install script, because it now uses mpg321.

        The confirm scriptshould have been part of the package; however, it
        should be available on on my site.

        I picked up mpg321 from the DAG Weir site. Google it. But then again,
        I'm not really familiar with the Embedded nodes and their requirements.
        After all, most of my scripts are not exactly plug and play. I find that
        nodes vary too much from node to node to make custom scripts work plug
        and play. I know my nodes are pretty off the deep end and it gets hard
        to be backwards compat.

        On Sat, 2006-11-11 at 16:02 +0000, Tim Sawyer wrote:
        > Hi,
        >
        > I went to install the playnews script om my embedded node and got the
        > following message:
        >
        > ------------------------------------------------------------------------
        > Install playnews
        > ------------------------------------------------------------------------
        > Now beginning the installation process:
        >
        > depend: mpg123 [FAILED]
        > ERROR: /usr/local/bin/mpg123/mpg123, file not found.
        > exists: /home/irlp/audio/custom [ OK ]
        > create: /home/irlp/audio/custom/news [ OK ]
        > install: confirm.wav [ OK ]
        > install: confirm [FAILED]
        >
        > It wants mpg123 which is a MPEG audio player for Linux. What's the
        > best way to install this? Is this something that only Dave can add?
        >
        > Thanks!
        > Tim

        --
        Randy Hammock KC6HUR
        IRLP 4494 EchoLink 120688 (KC6HUR-L)
        http://kc6hur.net
        http://irlp.kc6hur.net
      • David Cameron - IRLP
        I think the embedded nodes have mpg321 on them. NOT mpg123 but mpg321. Dave Cameron On Sat, 11 Nov 2006, Tim
        Message 3 of 28 , Nov 11, 2006
        • 0 Attachment
          I think the embedded nodes have mpg321 on them.

          NOT mpg123 but mpg321.

          Dave Cameron


          On Sat, 11 Nov 2006, Tim
          Sawyer wrote:

          > Hi,
          >
          > I went to install the playnews script om my embedded node and got the
          > following message:
          >
          > ------------------------------------------------------------------------
          > Install playnews
          > ------------------------------------------------------------------------
          > Now beginning the installation process:
          >
          > depend: mpg123 [FAILED]
          > ERROR: /usr/local/bin/mpg123/mpg123, file not found.
          > exists: /home/irlp/audio/custom [ OK ]
          > create: /home/irlp/audio/custom/news [ OK ]
          > install: confirm.wav [ OK ]
          > install: confirm [FAILED]
          >
          > It wants mpg123 which is a MPEG audio player for Linux. What's the
          > best way to install this? Is this something that only Dave can add?
          >
          > Thanks!
          > Tim
          >
          >
          >
        • Tim Sawyer
          Thanks. That and a few tweaks to the scripts and it s working.
          Message 4 of 28 , Nov 11, 2006
          • 0 Attachment
            Thanks. That and a few tweaks to the scripts and it's working.

            --- In irlp-embedded@yahoogroups.com, David Cameron - IRLP
            <dcameron@...> wrote:
            >
            > I think the embedded nodes have mpg321 on them.
            >
            > NOT mpg123 but mpg321.
            >
            > Dave Cameron
            >
            >
          • David Cameron - IRLP
            Be careful using that script with the limited drive space available. That was one reason why I did not use it, as it stored some large files on the drive for
            Message 5 of 28 , Nov 11, 2006
            • 0 Attachment
              Be careful using that script with the limited drive space available.

              That was one reason why I did not use it, as it stored some large files on
              the drive for certain newscasts.

              Just a warning, because if you fill yo the remaining 80 megs, the results
              are varied as to whether the machine boots or not.

              Dave Cameron
              VE7LTD

              On
              Sat, 11 Nov 2006, Tim Sawyer wrote:

              > Thanks. That and a few tweaks to the scripts and it's working.
              >
              > --- In irlp-embedded@yahoogroups.com, David Cameron - IRLP
              > <dcameron@...> wrote:
              >>
              >> I think the embedded nodes have mpg321 on them.
              >>
              >> NOT mpg123 but mpg321.
              >>
              >> Dave Cameron
              >>
              >>
              >
              >
              >
              >
            • David
              Could a USB drive be used to store the downloads on? ... files on ... results
              Message 6 of 28 , Nov 11, 2006
              • 0 Attachment
                Could a USB drive be used to store the downloads on?

                --- In irlp-embedded@yahoogroups.com, David Cameron - IRLP
                <dcameron@...> wrote:
                >
                > Be careful using that script with the limited drive space available.
                >
                > That was one reason why I did not use it, as it stored some large
                files on
                > the drive for certain newscasts.
                >
                > Just a warning, because if you fill yo the remaining 80 megs, the
                results
                > are varied as to whether the machine boots or not.
                >
                > Dave Cameron
                > VE7LTD
                >
                > On
                > Sat, 11 Nov 2006, Tim Sawyer wrote:
                >
                > > Thanks. That and a few tweaks to the scripts and it's working.
                > >
                > > --- In irlp-embedded@yahoogroups.com, David Cameron - IRLP
                > > <dcameron@> wrote:
                > >>
                > >> I think the embedded nodes have mpg321 on them.
                > >>
                > >> NOT mpg123 but mpg321.
                > >>
                > >> Dave Cameron
                > >>
                > >>
                > >
                > >
                > >
                > >
                >
              • David Cameron - IRLP
                Sure it could. Dave
                Message 7 of 28 , Nov 11, 2006
                • 0 Attachment
                  Sure it could.

                  Dave


                  On Sat, 11 Nov 2006, David wrote:

                  > Could a USB drive be used to store the downloads on?
                  >
                  > --- In irlp-embedded@yahoogroups.com, David Cameron - IRLP
                  > <dcameron@...> wrote:
                  >>
                  >> Be careful using that script with the limited drive space available.
                  >>
                  >> That was one reason why I did not use it, as it stored some large
                  > files on
                  >> the drive for certain newscasts.
                  >>
                  >> Just a warning, because if you fill yo the remaining 80 megs, the
                  > results
                  >> are varied as to whether the machine boots or not.
                  >>
                  >> Dave Cameron
                  >> VE7LTD
                  >>
                  >> On
                  >> Sat, 11 Nov 2006, Tim Sawyer wrote:
                  >>
                  >>> Thanks. That and a few tweaks to the scripts and it's working.
                  >>>
                  >>> --- In irlp-embedded@yahoogroups.com, David Cameron - IRLP
                  >>> <dcameron@> wrote:
                  >>>>
                  >>>> I think the embedded nodes have mpg321 on them.
                  >>>>
                  >>>> NOT mpg123 but mpg321.
                  >>>>
                  >>>> Dave Cameron
                  >>>>
                  >>>>
                  >>>
                  >>>
                  >>>
                  >>>
                  >>
                  >
                  >
                  >
                  >
                • Randy Hammock
                  Assuming your internet connection is good enough, you should be able to modify the script to play the news directly from the internet. I just do the downloads
                  Message 8 of 28 , Nov 11, 2006
                  • 0 Attachment
                    Assuming your internet connection is good enough, you should be able to
                    modify the script to play the news directly from the internet. I just do
                    the downloads to eliminate the possibility of skipping and stuttering.

                    On Sat, 2006-11-11 at 15:00 -0800, David Cameron - IRLP wrote:
                    > Be careful using that script with the limited drive space available.
                    >
                    > That was one reason why I did not use it, as it stored some large files on
                    > the drive for certain newscasts.
                    >
                    > Just a warning, because if you fill yo the remaining 80 megs, the results
                    > are varied as to whether the machine boots or not.
                    >
                    > Dave Cameron
                    > VE7LTD
                    >
                    > On
                    > Sat, 11 Nov 2006, Tim Sawyer wrote:
                    >
                    > > Thanks. That and a few tweaks to the scripts and it's working.
                    > >
                    --
                    Randy Hammock KC6HUR
                    IRLP 4494 EchoLink 120688 (KC6HUR-L)
                    http://kc6hur.net
                    http://irlp.kc6hur.net
                  • Tim Sawyer
                    I m only pulling down the newsline file. Today it s 4.9Mb. I assume that the same filename is used each week and that it will get overwritten. If so, it should
                    Message 9 of 28 , Nov 11, 2006
                    • 0 Attachment
                      I'm only pulling down the newsline file. Today it's 4.9Mb. I assume
                      that the same filename is used each week and that it will get
                      overwritten. If so, it should be ok.

                      --- In irlp-embedded@yahoogroups.com, Randy Hammock <rhammock@...> wrote:
                      >
                      > Assuming your internet connection is good enough, you should be able to
                      > modify the script to play the news directly from the internet. I just do
                      > the downloads to eliminate the possibility of skipping and stuttering.
                      >
                    • David George
                      I got newsline to play on my node and all seem to be working fine till towards the end of the transmission it just stopped. I don t think it was a repeater
                      Message 10 of 28 , Nov 11, 2006
                      • 0 Attachment
                        I got newsline to play on my node and all seem to be working fine till towards the end of the transmission it just stopped. I don't think it was a repeater time out. When I disabled or enabled the node and IRLP responded with the usual announcement I could still hear newsline playing also. Any ideas?
                         
                         David George  davidgeo@...
                         


                        ----- Original Message ----
                        From: Tim Sawyer <tim@...>
                        To: irlp-embedded@yahoogroups.com
                        Sent: Saturday, November 11, 2006 6:45:40 PM
                        Subject: [irlp-embedded] Re: Playnews

                        I'm only pulling down the newsline file. Today it's 4.9Mb. I assume
                        that the same filename is used each week and that it will get
                        overwritten. If so, it should be ok.

                        --- In irlp-embedded@ yahoogroups. com, Randy Hammock <rhammock@.. .> wrote:
                        >
                        > Assuming your internet connection is good enough, you should be able to
                        > modify the script to play the news directly from the internet. I just do
                        > the downloads to eliminate the possibility of skipping and stuttering.
                        >


                      • Randy Hammock
                        ... Yep, newsline and twiar have files with the same name that can be downloaded with the same code each week. ARRL Audio News uses the month and day of month
                        Message 11 of 28 , Nov 11, 2006
                        • 0 Attachment
                          On Sun, 2006-11-12 at 00:45 +0000, Tim Sawyer wrote:
                          > I'm only pulling down the newsline file. Today it's 4.9Mb. I assume
                          > that the same filename is used each week and that it will get
                          > overwritten. If so, it should be ok.

                          Yep, newsline and twiar have files with the same name that can be
                          downloaded with the same code each week. ARRL Audio News uses the month
                          and day of month as part of the filenames. That is the reason for the
                          getFriDate command. This saves those numbers in a file for later use.
                          When I download the AAN file parts, I save them without the date code so
                          that they overwrite files each week. I'll try playing a bit more with
                          the direct URL play to see if I can figure out why it did the repeat
                          plays.

                          --
                          Randy Hammock KC6HUR
                          IRLP 4494 EchoLink 120688 (KC6HUR-L)
                          http://kc6hur.net
                          http://irlp.kc6hur.net
                        • David Cameron - IRLP
                          Just incase, I would add it to the list of files that is not updated by flash_sync... I think it is in /etc/ somewhere..... /etc/flash_sync_exclude Include the
                          Message 12 of 28 , Nov 11, 2006
                          • 0 Attachment
                            Just incase, I would add it to the list of files that is not updated by
                            flash_sync... I think it is in /etc/ somewhere.....

                            /etc/flash_sync_exclude

                            Include the filename in there.

                            Dave Cameron
                            VE7LTD


                            On Sun, 12 Nov 2006,
                            Tim Sawyer wrote:

                            > I'm only pulling down the newsline file. Today it's 4.9Mb. I assume
                            > that the same filename is used each week and that it will get
                            > overwritten. If so, it should be ok.
                            >
                            > --- In irlp-embedded@yahoogroups.com, Randy Hammock <rhammock@...> wrote:
                            >>
                            >> Assuming your internet connection is good enough, you should be able to
                            >> modify the script to play the news directly from the internet. I just do
                            >> the downloads to eliminate the possibility of skipping and stuttering.
                            >>
                            >
                            >
                            >
                            >
                          • David Cameron - IRLP
                            I think that mpg321 may actually spit back to the prompt before the audio is done... I could never get audio streaming to work reliably, so I did not include
                            Message 13 of 28 , Nov 11, 2006
                            • 0 Attachment
                              I think that mpg321 may actually spit back to the prompt before the
                              audio is done... I could never get audio streaming to work reliably, so
                              I did not include it in the first version of the embedded nodes.

                              Dave Cameron
                              VE7LTD

                              On Sat, 11
                              Nov 2006, David George wrote:

                              > I got newsline to play on my node and all seem to be working fine till towards the end of the transmission it just stopped. I don't think it was a repeater time out. When I disabled or enabled the node and IRLP responded with the usual announcement I could still hear newsline playing also. Any ideas?
                              >
                              > David George davidgeo@...
                              >
                              >
                              >
                              >
                              > ----- Original Message ----
                              > From: Tim Sawyer <tim@...>
                              > To: irlp-embedded@yahoogroups.com
                              > Sent: Saturday, November 11, 2006 6:45:40 PM
                              > Subject: [irlp-embedded] Re: Playnews
                              >
                              > I'm only pulling down the newsline file. Today it's 4.9Mb. I assume
                              > that the same filename is used each week and that it will get
                              > overwritten. If so, it should be ok.
                              >
                              > --- In irlp-embedded@ yahoogroups. com, Randy Hammock <rhammock@.. .> wrote:
                              >>
                              >> Assuming your internet connection is good enough, you should be able to
                              >> modify the script to play the news directly from the internet. I just do
                              >> the downloads to eliminate the possibility of skipping and stuttering.
                              >>
                              >
                              >
                              >
                            • Nate Duehr
                              ... Yes, Something attempted to key and unkey the rig during the newsline playback. Since the playnews script has no way to know the radio just got unkeyed, it
                              Message 14 of 28 , Nov 11, 2006
                              • 0 Attachment
                                David George wrote:
                                > I got newsline to play on my node and all seem to be working fine till
                                > towards the end of the transmission it just stopped. I don't think it
                                > was a repeater time out. When I disabled or enabled the node and IRLP
                                > responded with the usual announcement I could still hear newsline
                                > playing also. Any ideas?

                                Yes,

                                Something attempted to key and unkey the rig during the newsline playback.

                                Since the playnews script has no way to know the radio just got unkeyed,
                                it keeps playing the file out the sound card into a radio that's no
                                longer transmitting. When your node transmitted later, you got to hear
                                both the WAV file being played for the announcement and also the mpg321
                                playing newsline in the background via the audio mixer.

                                When I ran into this a couple of years ago, I found it was the
                                CALL_WAITING feature. Nodes were calling in during the playback of
                                newsline and killing the PTT.

                                We didn't want call waiting on that system, so we disabled it. There
                                would be other options including using an AUX1 keying line for
                                newsline's script, so the normal PTT isn't affected by other happenings
                                on the main PTT line, or modifying the news script on your node to use
                                forcekey and forceunkey to key the radio... etc. You could also have
                                the news script export a new value for the call waiting enable/disable
                                variable and then turn it back on after news playback.

                                There's a number of fairly normal ways to deal with it, and probably
                                other creative ones.

                                Nate WY0X
                              • Tim Sawyer
                                I added this line to /etc/flash_sync_exclude: home/irlp/audio/custom/news/* Does that look like the correct syntax?
                                Message 15 of 28 , Nov 12, 2006
                                • 0 Attachment
                                  I added this line to /etc/flash_sync_exclude:

                                  home/irlp/audio/custom/news/*

                                  Does that look like the correct syntax?



                                  --- In irlp-embedded@yahoogroups.com, David Cameron - IRLP
                                  <dcameron@...> wrote:
                                  >
                                  > Just incase, I would add it to the list of files that is not updated by
                                  > flash_sync... I think it is in /etc/ somewhere.....
                                  >
                                  > /etc/flash_sync_exclude
                                  >
                                  > Include the filename in there.
                                  >
                                  > Dave Cameron
                                  > VE7LTD
                                  >
                                • Randy Hammock
                                  ... That s why I added a sleep immediately after the mpg{321|123}. I used to cutoff the Copyright on the Newline. I adjusted the value until the Copyright
                                  Message 16 of 28 , Nov 12, 2006
                                  • 0 Attachment
                                    On Sat, 2006-11-11 at 22:06 -0800, David Cameron - IRLP wrote:
                                    > I think that mpg321 may actually spit back to the prompt before the
                                    > audio is done... I could never get audio streaming to work reliably, so
                                    > I did not include it in the first version of the embedded nodes.

                                    That's why I added a sleep immediately after the mpg{321|123}. I used to
                                    cutoff the Copyright on the Newline. I adjusted the value until the
                                    Copyright noticed played all the way through.

                                    --
                                    Randy Hammock KC6HUR
                                    IRLP 4494 EchoLink 120688 (KC6HUR-L)
                                    http://kc6hur.net
                                    http://irlp.kc6hur.net
                                  • Randy Hammock
                                    ... Anything that uses wavplay will kill the PTT during a newsplay, because wavplay ALSO uses force-key/force-unkey. I always though that force-key and
                                    Message 17 of 28 , Nov 12, 2006
                                    • 0 Attachment
                                      On Sat, 2006-11-11 at 23:28 -0700, Nate Duehr wrote:
                                      > David George wrote:
                                      > > I got newsline to play on my node and all seem to be working fine till
                                      > > towards the end of the transmission it just stopped. I don't think it
                                      > > was a repeater time out. When I disabled or enabled the node and IRLP
                                      > > responded with the usual announcement I could still hear newsline
                                      > > playing also. Any ideas?
                                      >
                                      > Yes,
                                      >
                                      > Something attempted to key and unkey the rig during the newsline playback.

                                      Anything that uses wavplay will kill the PTT during a newsplay, because
                                      wavplay ALSO uses force-key/force-unkey. I always though that force-key
                                      and force-unkey were made available so that the user could perform
                                      running operations. With force-key/unkey being used by wavplay, the
                                      system now has every opportunity to stomp all over the user. I modified
                                      my system so that wavplay uses regular key/unkey and have never
                                      experienced any more "unexpected" dropouts.

                                      --
                                      Randy Hammock KC6HUR
                                      IRLP 4494 EchoLink 120688 (KC6HUR-L)
                                      http://kc6hur.net
                                      http://irlp.kc6hur.net
                                    • Nate Duehr
                                      ... Ick, I forgot about that. Uggh, ran into it too. I can t remember why wavplay ended up having forcekey and forceunkey in it, but it s probably water so
                                      Message 18 of 28 , Nov 12, 2006
                                      • 0 Attachment
                                        Randy Hammock wrote:
                                        > On Sat, 2006-11-11 at 23:28 -0700, Nate Duehr wrote:
                                        >> David George wrote:
                                        >>> I got newsline to play on my node and all seem to be working fine till
                                        >>> towards the end of the transmission it just stopped. I don't think it
                                        >>> was a repeater time out. When I disabled or enabled the node and IRLP
                                        >>> responded with the usual announcement I could still hear newsline
                                        >>> playing also. Any ideas?
                                        >> Yes,
                                        >>
                                        >> Something attempted to key and unkey the rig during the newsline playback.
                                        >
                                        > Anything that uses wavplay will kill the PTT during a newsplay, because
                                        > wavplay ALSO uses force-key/force-unkey. I always though that force-key
                                        > and force-unkey were made available so that the user could perform
                                        > running operations. With force-key/unkey being used by wavplay, the
                                        > system now has every opportunity to stomp all over the user. I modified
                                        > my system so that wavplay uses regular key/unkey and have never
                                        > experienced any more "unexpected" dropouts.

                                        Ick, I forgot about that. Uggh, ran into it too.

                                        I can't remember why wavplay ended up having forcekey and forceunkey in
                                        it, but it's probably water so far under the bridge that changing that
                                        behavior now would break other things.

                                        I still think (as does Randy, since he went and wrote one!) that the
                                        best solution for PTT is to have a overall manager of the PTT that gets
                                        "requests" from the various things that want to key and unkey the radio.
                                        Similar to a hardware repeater controller. If three things request a
                                        key-up, then two request an unkey, the PTT stays keyed until "thing"
                                        number 3 requests an unkey. And an overall timeout timer... but in
                                        practice, such a manager doesn't fix all problems, it changes them to
                                        something new. :-)

                                        Nate
                                      • Randy Hammock
                                        ... Might work if it controlled the AUX1 line but never the PTT line. There are times where the IRLP software throws in a couple extra unkeys in an attempt to
                                        Message 19 of 28 , Nov 12, 2006
                                        • 0 Attachment
                                          On Sun, 2006-11-12 at 10:18 -0700, Nate Duehr wrote:
                                          > Randy Hammock wrote:
                                          > > On Sat, 2006-11-11 at 23:28 -0700, Nate Duehr wrote:
                                          > >> David George wrote:
                                          > >>> I got newsline to play on my node and all seem to be working fine till
                                          > >>> towards the end of the transmission it just stopped. I don't think it
                                          > >>> was a repeater time out. When I disabled or enabled the node and IRLP
                                          > >>> responded with the usual announcement I could still hear newsline
                                          > >>> playing also. Any ideas?
                                          > >> Yes,
                                          > >>
                                          > >> Something attempted to key and unkey the rig during the newsline playback.
                                          > >
                                          > > Anything that uses wavplay will kill the PTT during a newsplay, because
                                          > > wavplay ALSO uses force-key/force-unkey. I always though that force-key
                                          > > and force-unkey were made available so that the user could perform
                                          > > running operations. With force-key/unkey being used by wavplay, the
                                          > > system now has every opportunity to stomp all over the user. I modified
                                          > > my system so that wavplay uses regular key/unkey and have never
                                          > > experienced any more "unexpected" dropouts.
                                          >
                                          > Ick, I forgot about that. Uggh, ran into it too.
                                          >
                                          > I can't remember why wavplay ended up having forcekey and forceunkey in
                                          > it, but it's probably water so far under the bridge that changing that
                                          > behavior now would break other things.
                                          >
                                          > I still think (as does Randy, since he went and wrote one!) that the
                                          > best solution for PTT is to have a overall manager of the PTT that gets
                                          > "requests" from the various things that want to key and unkey the radio.
                                          > Similar to a hardware repeater controller. If three things request a
                                          > key-up, then two request an unkey, the PTT stays keyed until "thing"
                                          > number 3 requests an unkey. And an overall timeout timer... but in
                                          > practice, such a manager doesn't fix all problems, it changes them to
                                          > something new. :-)

                                          Might work if it controlled the AUX1 line but never the PTT line. There
                                          are times where the IRLP software throws in a couple extra unkeys in an
                                          attempt to make sure things are in fact unkeyed. This wrecks or wreaks
                                          havoc upon any counting scheme. Maybe, someday, I'll try the manager on
                                          AUX1.

                                          --
                                          Randy Hammock KC6HUR
                                          IRLP 4494 EchoLink 120688 (KC6HUR-L)
                                          http://kc6hur.net
                                          http://irlp.kc6hur.net
                                        • David Cameron - IRLP
                                          Recently another ham worked on a PTT manager. I have also taken out the several unkeys that ispeaker used to send. The problem is when ispeaker is killed, I
                                          Message 20 of 28 , Nov 12, 2006
                                          • 0 Attachment
                                            Recently another ham worked on a PTT manager.

                                            I have also taken out the several "unkeys" that ispeaker used to send. The
                                            problem is when ispeaker is killed, I am not sure if it was keyed or not,
                                            and it also depends on how it dies.... So there is an extra unkey there.

                                            The idea was to use a 128 bit memory space. Each core IRLP program would
                                            be assigned a bit, and there would be over 100 unused bits that could be
                                            used by whatever you want.

                                            The PTT manager would be an external process that monitors the 128 bits
                                            and if any of them are "1", it would key. Until all bits are 0, the
                                            system remains keyed. There would be a call that would set all to zero as
                                            well.

                                            Still a ways off.

                                            Dave Cameron
                                          • Tim Sawyer
                                            The answer to this problem is a PTT manager that is built into the IRLP system in all respects. All process that need to assert PTT would need to write a
                                            Message 21 of 28 , Nov 12, 2006
                                            • 0 Attachment
                                              The answer to this problem is a PTT manager that is built into the
                                              IRLP system in all respects. All process that need to assert PTT would
                                              need to write a number to a shared memory location. If the number in
                                              that shared memory location is anything other than zero, the PTT
                                              manager would assert PTT. Each process would be assigned, by
                                              convention, a number (a bit in the PTT register). For example the
                                              DTMF, iMic and other IRLP process could be assigned number 1, EchoLink
                                              number 2, the repeater controller number 3, playwav = 4, forcekey=5.
                                              etc. Each process would set and reset it's own number (bit) and the
                                              PTT manager would only unkey the radio when all bits are zero.

                                              Scripts would still use the key and unkey command as they do now
                                              except that the key/unkey command would accept an optional number
                                              argument, for example "key 10" and "unkey 10" would set and unset bit
                                              10 in the PTT shared memory location. This would allow any number of
                                              scripts, using different PTT bits, to run on your system without
                                              stepping on each other.

                                              The forcekey command would set some bit (maybe 5 as suggested above)
                                              and forceunkey would reset all bits to zero.

                                              I'm not much a C programmer but I took a whack at coding my own
                                              key/unkey, forcekey/forceunkey that write to a shared memory location.
                                              And I got a PTT manager that reads the shared memory location working.
                                              The PTT manager reads an environment variable which the user sets to
                                              ON once they are sure they have a "PTT manager ready" system. Of
                                              course I have no access to the IRLP binaries and did not attempt to
                                              rewrite dtmf, etc.

                                              Where I ran into a problem was locking and unlocking the shared memory
                                              location. Of course that needs to happen to prevent two process from
                                              writing at the same time (race condition). Linux semaphores proved to
                                              be a bit over my head.

                                              Dave and I had an email conversation about this and he agreed to at
                                              least look at my code. I sent a few samples along the way but never a
                                              "final" version as I got stuck on the semaphores. I think Dave might
                                              be convinced to write a PTT manager into the system if the code proved
                                              to be not too difficult. Of course there are migration issues to
                                              consider as well as the technical programming problems. But, I think,
                                              with one or two environment variables the migration issues could be
                                              addressed.

                                              If anyone thinks this is a good idea and wants to work on the code let
                                              me know. I'm willing to share my lousy C code with anyone that wants
                                              to look at it... just promise not to laugh too hard. If we can put
                                              together some usable code, maybe we can get Dave to fix this PTT
                                              problem once and for all.


                                              > Ick, I forgot about that. Uggh, ran into it too.
                                              >
                                              > I can't remember why wavplay ended up having forcekey and forceunkey in
                                              > it, but it's probably water so far under the bridge that changing that
                                              > behavior now would break other things.
                                              >
                                              > I still think (as does Randy, since he went and wrote one!) that the
                                              > best solution for PTT is to have a overall manager of the PTT that gets
                                              > "requests" from the various things that want to key and unkey the
                                              radio.
                                              > Similar to a hardware repeater controller. If three things request a
                                              > key-up, then two request an unkey, the PTT stays keyed until "thing"
                                              > number 3 requests an unkey. And an overall timeout timer... but in
                                              > practice, such a manager doesn't fix all problems, it changes them to
                                              > something new. :-)
                                              >
                                              > Nate
                                              >
                                            • Randy Hammock
                                              ... I did something like that for a telemetry monitor system at JPL. there were 80 screens that were controlled by shared memory system segment. I see
                                              Message 22 of 28 , Nov 12, 2006
                                              • 0 Attachment
                                                On Sun, 2006-11-12 at 19:20 +0000, Tim Sawyer wrote:
                                                > The answer to this problem is a PTT manager that is built into the
                                                > IRLP system in all respects. All process that need to assert PTT would
                                                > need to write a number to a shared memory location. If the number in
                                                > that shared memory location is anything other than zero, the PTT
                                                > manager would assert PTT. Each process would be assigned, by
                                                > convention, a number (a bit in the PTT register). For example the
                                                > DTMF, iMic and other IRLP process could be assigned number 1, EchoLink
                                                > number 2, the repeater controller number 3, playwav = 4, forcekey=5.
                                                > etc. Each process would set and reset it's own number (bit) and the
                                                > PTT manager would only unkey the radio when all bits are zero.
                                                >
                                                > Scripts would still use the key and unkey command as they do now
                                                > except that the key/unkey command would accept an optional number
                                                > argument, for example "key 10" and "unkey 10" would set and unset bit
                                                > 10 in the PTT shared memory location. This would allow any number of
                                                > scripts, using different PTT bits, to run on your system without
                                                > stepping on each other.
                                                >
                                                > The forcekey command would set some bit (maybe 5 as suggested above)
                                                > and forceunkey would reset all bits to zero.

                                                I did something like that for a telemetry monitor system at JPL. there
                                                were 80 screens that were controlled by shared memory system segment.

                                                I see forcekey/forceunkey needing its own manager. The force* functions
                                                serve an expanded function, that being, by-passing the PTT timer. Id
                                                rather not see the forceunkey being the end=all of PTTs, just the end
                                                all of the PTT timer.

                                                --
                                                Randy Hammock KC6HUR
                                                IRLP 4494 EchoLink 120688 (KC6HUR-L)
                                                http://kc6hur.net
                                                http://irlp.kc6hur.net
                                              • Mike Morris
                                                ... You would need a call that a process could use to request a number . Think of it as being like DHCP, where a new machine requests an IP address. As the
                                                Message 23 of 28 , Nov 12, 2006
                                                • 0 Attachment
                                                  At 11:20 AM 11/12/06, you wrote:
                                                  >The answer to this problem is a PTT manager that is built into the
                                                  >IRLP system in all respects. All process that need to assert PTT would
                                                  >need to write a number to a shared memory location. If the number in
                                                  >that shared memory location is anything other than zero, the PTT
                                                  >manager would assert PTT. Each process would be assigned, by
                                                  >convention, a number (a bit in the PTT register). For example the
                                                  >DTMF, iMic and other IRLP process could be assigned number 1, EchoLink
                                                  >number 2, the repeater controller number 3, playwav = 4, forcekey=5.
                                                  >etc. Each process would set and reset it's own number (bit) and the
                                                  >PTT manager would only unkey the radio when all bits are zero.
                                                  >
                                                  >Scripts would still use the key and unkey command as they do now
                                                  >except that the key/unkey command would accept an optional number
                                                  >argument, for example "key 10" and "unkey 10" would set and unset bit
                                                  >10 in the PTT shared memory location. This would allow any number of
                                                  >scripts, using different PTT bits, to run on your system without
                                                  >stepping on each other.

                                                  You would need a "call" that a process could use to request a "number".
                                                  Think of it as being like DHCP, where a new machine requests an IP
                                                  address. As the system started up (from a cold start) each process that
                                                  needs to "control" PTT requests a "number" and uses it until it exist,
                                                  at which time it returns the "number" to the available pool. This code
                                                  and algorithm is not new, back in 1981 I was involved with a radio
                                                  paging system and used it for what we called "queue elements".. each
                                                  phone call grabbed an element from the pool and it got passed from
                                                  dispatcher to DTMF decoder (there were 32) to appropriate transmitter
                                                  (14) to logging and back to pool. We had 44 real-time tasks all written
                                                  in assembly code. The version for IRLP would be considerably simpler.

                                                  >The forcekey command would set some bit (maybe 5 as suggested above)
                                                  >and forceunkey would reset all bits to zero.

                                                  Forcekey, depending on how the code is designed, could either have a
                                                  hard-coded number, or do a number request, save it for forceunkey to use
                                                  and then set it active. Forceunkey could use the saved number and clear it.
                                                  Or the number assignment call could have a query mode that a task could
                                                  use, something like "hi there, what assignment does forcekey have?" then
                                                  forceunkey could release that number and return it to the pool, or if told
                                                  that there was no assignment to forcekey handle it appropriately.

                                                  >I'm not much a C programmer but I took a whack at coding my own
                                                  >key/unkey, forcekey/forceunkey that write to a shared memory location.
                                                  >And I got a PTT manager that reads the shared memory location working.
                                                  > The PTT manager reads an environment variable which the user sets to
                                                  >ON once they are sure they have a "PTT manager ready" system. Of
                                                  >course I have no access to the IRLP binaries and did not attempt to
                                                  >rewrite dtmf, etc.

                                                  I've often thought that if it was ever rewritten it should use one of the
                                                  more advanced BIOS printer port modes that uses the data bits instead
                                                  of just the printer status bits. If done properly (unless I've slipped up
                                                  somewhere I've pretty much hacked the hardware design) it would be
                                                  backwards compatible with existing hardware but would allow for the
                                                  version 4 card to have aux inputs.

                                                  However, with printer ports going away on newer computers the
                                                  preferred path (what one local yokel has dubbed "the path of
                                                  righteousness" may be designing a DTMF / aux out / aux in
                                                  board that "talks" to the OS / applications on USB.

                                                  >Where I ran into a problem was locking and unlocking the shared memory
                                                  >location. Of course that needs to happen to prevent two process from
                                                  >writing at the same time (race condition). Linux semaphores proved to
                                                  >be a bit over my head.

                                                  I'm a hardware hacker and embedded processor type. Linux anything
                                                  (other than "user") is over my head.

                                                  (rest deleted for brevity)

                                                  Mike WA6ILQ
                                                • Tim Sawyer
                                                  ... This should be easy compared to that. I ll send you my code if you want to work on it. Let me know. ... Good point. I hadn t considered the timer aspect of
                                                  Message 24 of 28 , Nov 12, 2006
                                                  • 0 Attachment
                                                    > I did something like that for a telemetry monitor system at JPL. there
                                                    > were 80 screens that were controlled by shared memory system segment.

                                                    This should be easy compared to that. I'll send you my code if you
                                                    want to work on it. Let me know.

                                                    >
                                                    > I see forcekey/forceunkey needing its own manager. The force* functions
                                                    > serve an expanded function, that being, by-passing the PTT timer. Id
                                                    > rather not see the forceunkey being the end=all of PTTs, just the end
                                                    > all of the PTT timer.
                                                    >

                                                    Good point. I hadn't considered the timer aspect of the
                                                    forcekey/forceunkey. I think an additional PTT manager would not be
                                                    necessary. The same shared memory segment could be written to by the
                                                    forcekey/forceunkey clients and the PTT server would read it no
                                                    differently. I would envision part of the shared memory segment would
                                                    be used to communicate the state of the timer... set a bit to turn it
                                                    on, reset it to turn the timer off.


                                                    > --
                                                    > Randy Hammock KC6HUR
                                                    > IRLP 4494 EchoLink 120688 (KC6HUR-L)
                                                    > http://kc6hur.net
                                                    > http://irlp.kc6hur.net
                                                    >
                                                  • Tim Sawyer
                                                    The DCHP idea is interesting. It would be nice if the system could manage the numbers rather than assigning them by convention. That would mean less chance for
                                                    Message 25 of 28 , Nov 12, 2006
                                                    • 0 Attachment
                                                      The DCHP idea is interesting. It would be nice if the system could
                                                      manage the numbers rather than assigning them by convention. That
                                                      would mean less chance for things to step on each other. However, I do
                                                      not see it as a necessity. Main effort at this point should be to get
                                                      the shared memory segment and locking idea working. Think of it this
                                                      way... IP address were around long before DHCP.

                                                      I never looked at what it takes to actually pull the parallel port I/O
                                                      pins. I've been focused on the client/server aspects of a shared
                                                      memory segment. Your discussion of BIOS printer bits/status is above
                                                      my pay grade at the moment. I'm assuming that once the shared memory
                                                      issues are worked out, Dave will be able to easily bring in the
                                                      existing I/O code.
                                                    • Mike Morris
                                                      ... Yep...so it has. Within the last 6 months I was involved in dragging an 8-campus school district forward into the 2000s. Part of it was laying hands on
                                                      Message 26 of 28 , Nov 12, 2006
                                                      • 0 Attachment
                                                        At 05:01 PM 11/12/06, you wrote:

                                                        >The DCHP idea is interesting. It would be nice if the system could
                                                        >manage the numbers rather than assigning them by convention. That
                                                        >would mean less chance for things to step on each other. However, I do
                                                        >not see it as a necessity. Main effort at this point should be to get
                                                        >the shared memory segment and locking idea working. Think of it this
                                                        >way... IP address were around long before DHCP.

                                                        Yep...so it has. Within the last 6 months I was involved in dragging an
                                                        8-campus school district forward into the 2000s. Part of it was laying
                                                        hands on each of the 5500 PCs and Macs twice - once for inventory
                                                        and the second as we converted each campus to DHCP.

                                                        >I never looked at what it takes to actually pull the parallel port I/O
                                                        >pins. I've been focused on the client/server aspects of a shared
                                                        >memory segment. Your discussion of BIOS printer bits/status is above
                                                        >my pay grade at the moment. I'm assuming that once the shared memory
                                                        >issues are worked out, Dave will be able to easily bring in the
                                                        >existing I/O code.

                                                        That comment was directed at the phrase "irlp binaries".... one of them
                                                        reads the printer port. The five printer status bits on the common printer
                                                        port are used as four for the touchtone decoder and one for COS.
                                                        The redesign I did moves the DTMF data to the printer data bits, allowing
                                                        for four aux inputs in addition to the existing three aux outputs.
                                                        But as I said, it will probably never see production as the next generation
                                                        IRLP board will probably be USB. Even my addressable power strip design
                                                        is USB.

                                                        Mike WA6ILQ
                                                      • David McAnally
                                                        At one time, I experimented with a PTT control using a FIFO file and a little bash script daemon. The script would perform tasks, like key and unkey via a case
                                                        Message 27 of 28 , Nov 12, 2006
                                                        • 0 Attachment
                                                          At one time, I experimented with a PTT control using a FIFO file and a
                                                          little bash script daemon. The script would perform tasks, like key
                                                          and unkey via a case statement. By sending KEY and UNKEY words to the
                                                          FIFO file from other scripts with echo statements, the script would
                                                          increment or decrement a counter variable to determine when to execute
                                                          key or unkey. If the counter was greater than 0, key, else unkey.
                                                          Any thing that could write output to the FIFO file could could control
                                                          it.

                                                          By redirecting output from readinput to the FIFO, it could even
                                                          perform tasks from readinput signals, potentially becoming a repeater
                                                          controller based on COS signals from readinput.

                                                          I may have gotten the idea from someone else's scripts. Probably Randy's.

                                                          --
                                                          Regards,
                                                          David McAnally, WD5M
                                                        • Randy Hammock
                                                          ... Yup, that was mine. The manager monitored a FIFO and requests for PTT action were made via the FIFO input. ... -- Randy Hammock KC6HUR IRLP 4494 EchoLink
                                                          Message 28 of 28 , Nov 13, 2006
                                                          • 0 Attachment
                                                            On Sun, 2006-11-12 at 22:59 -0600, David McAnally wrote:
                                                            > At one time, I experimented with a PTT control using a FIFO file and a
                                                            > little bash script daemon. The script would perform tasks, like key
                                                            > and unkey via a case statement. By sending KEY and UNKEY words to the
                                                            > FIFO file from other scripts with echo statements, the script would
                                                            > increment or decrement a counter variable to determine when to execute
                                                            > key or unkey. If the counter was greater than 0, key, else unkey.
                                                            > Any thing that could write output to the FIFO file could could control
                                                            > it.
                                                            >
                                                            > By redirecting output from readinput to the FIFO, it could even
                                                            > perform tasks from readinput signals, potentially becoming a repeater
                                                            > controller based on COS signals from readinput.
                                                            >
                                                            > I may have gotten the idea from someone else's scripts. Probably Randy's.

                                                            Yup, that was mine. The manager monitored a FIFO and requests for PTT
                                                            action were made via the FIFO input.
                                                            >
                                                            --
                                                            Randy Hammock KC6HUR
                                                            IRLP 4494 EchoLink 120688 (KC6HUR-L)
                                                            http://kc6hur.net
                                                            http://irlp.kc6hur.net
                                                          Your message has been successfully submitted and would be delivered to recipients shortly.