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

Re: Playnews

Expand Messages
  • David
    Could a USB drive be used to store the downloads on? ... files on ... results
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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.