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

Re: [irlp-embedded] PTT Manager

Expand Messages
  • 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 1 of 28 , Nov 12 1:11 PM
      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 2 of 28 , Nov 12 2:10 PM
        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 3 of 28 , Nov 12 4:42 PM
          > 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 4 of 28 , Nov 12 5:01 PM
            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 5 of 28 , Nov 12 5:26 PM
              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 6 of 28 , Nov 12 8:59 PM
                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 7 of 28 , Nov 13 11:46 PM
                  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.