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

Re: [irlp-embedded] Re: Playnews

Expand Messages
  • David Cameron - IRLP
    Sure it could. Dave
    Message 1 of 28 , Nov 11, 2006
      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 2 of 28 , Nov 11, 2006
        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 3 of 28 , Nov 11, 2006
          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 4 of 28 , Nov 11, 2006
            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 5 of 28 , Nov 11, 2006
              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 6 of 28 , Nov 11, 2006
                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 7 of 28 , Nov 11, 2006
                  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 8 of 28 , Nov 11, 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?

                    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 9 of 28 , Nov 12, 2006
                      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 10 of 28 , Nov 12, 2006
                        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 11 of 28 , Nov 12, 2006
                          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 12 of 28 , Nov 12, 2006
                            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 13 of 28 , Nov 12, 2006
                              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 14 of 28 , Nov 12, 2006
                                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 15 of 28 , Nov 12, 2006
                                  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 16 of 28 , Nov 12, 2006
                                    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 17 of 28 , Nov 12, 2006
                                      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 18 of 28 , Nov 12, 2006
                                        > 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 19 of 28 , Nov 12, 2006
                                          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 20 of 28 , Nov 12, 2006
                                            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 21 of 28 , Nov 12, 2006
                                              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 22 of 28 , Nov 13, 2006
                                                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.