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

Re: [irlp-embedded] Re: Playnews

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