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

Re: [irlp-embedded] Re: Playnews

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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.