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

Re: [tracker2] Another script example (AC monitoring)

Expand Messages
  • Scott Miller
    ... The analog telemetry values are grabbed right before transmission, and are only kept on the stack until the transmission is done. I will probably add an
    Message 1 of 11 , Aug 5, 2011
    • 0 Attachment
      > shack, and if bit 7 changes, send an intrusion alarm. Hmm, analog
      > telemetry values should be stored somewhere in memory as well...

      The analog telemetry values are grabbed right before transmission, and
      are only kept on the stack until the transmission is done. I will
      probably add an explicit 'read ADC' command at some point, though.

      For the digital inputs, check the schematic to see which port the pin
      you want is connected to. Addresses for the port data registers are:

      PTA: 0
      PTB: 1
      PTC: 2
      PTD: 3

      Those you should be able to PEEK any time, assuming the relevant pin is
      an input.

      Scott
    • James Ewen
      ... Hmm, the shroud of mystery is slowly being pulled back to reveal the mystical hardware! 8) The CFG input available on the accessory port pin 6 which shows
      Message 2 of 11 , Aug 5, 2011
      • 0 Attachment
        On Fri, Aug 5, 2011 at 12:20 PM, Scott Miller <scott@...> wrote:

        >> shack, and if bit 7 changes, send an intrusion alarm.
        > For the digital inputs, check the schematic to see which port the pin
        > you want is connected to.  Addresses for the port data registers are:
        >
        > PTD: 3
        >
        > Those you should be able to PEEK any time, assuming the relevant pin is
        > an input.

        Hmm, the shroud of mystery is slowly being pulled back to reveal the
        mystical hardware! 8)

        The CFG input available on the accessory port pin 6 which shows up in
        the telemetry reports as bit 7 is actually PTD6.

        Hmm, just found an error on the telemetry page... I have IRQ listed as
        pin 6, and CFG as pin 1, backwards from the schematic! Don't any of
        you people check up on me so I'm not confusing myself? Sheesh!!! I'll
        double check things here as I go along with this next round of
        experiments.

        So now the thought process goes like this for using the CFG pin as a
        digital telemetry input, and having a magnetic sensor on the shack
        door tied into that input...

        If Peek 3 & 64 = 64
        Do Once
        PrintA "Someone opened the door!"
        End Block
        End Block

        This would allow condition testing against the actual input rather
        than needing to use profile switching to determine the state of the
        input like I was doing with the Send Email on Event with Delay script
        example. Profile switching could still be used to test the condition
        of an analog value such as the battery voltage. I can add an external
        relay onto the CFG pin monitoring the AC, and still have battery level
        alarms as well...

        Now my only issue is I want battery voltage monitoring, AC loss
        monitoring, and I want to watch the door as well!

        What's PTD7/KBI7 on pin 33 doing Scott? Is it just sitting there
        looking for something to do? If I added in a pull up resistor like
        found on PTD6/KBI6, would that be able to be tested against in a
        similar manner, or is that pin doing some other function? You know me,
        I'm going to squeeze all the telemetry out of these OT2s that I can,
        one way or another!

        Then there's also the possibility of using the counter input on a
        magnetic reed switch to watch the door, or AC for that matter...

        If Pulse Count > 0
        Do Once
        PrintA "Someone opened the door!"
        End Block
        End Block

        You would need a Macro to reset the Pulse Count back to zero to clear
        that alarm. You would also be able to tell how many times the door was
        opened and closed!

        Okay, I've got temperature monitoring, battery level monitoring, AC
        outage monitoring, intrusion alarm... still another analog ADC
        available which could probably be used to watch a second battery stack
        voltage. If PTD7/KBI7 can be tested against, then there's another
        digital input.

        Hmm, now I think the big issue is going to be fitting all the code
        into 512 bytes available in the scripting engine!

        What better way to fill a Friday night than writing scripts for
        monitoring a site via an OT2? It doesn't get much better than this!

        --
        James
        VE6SRV
      • Scott Miller
        ... Which page are you looking at? The manual page for the accessory connector matches the schematic. ... It s connected to the solid state relay. ... If you
        Message 3 of 11 , Aug 8, 2011
        • 0 Attachment
          > Hmm, just found an error on the telemetry page... I have IRQ listed as
          > pin 6, and CFG as pin 1, backwards from the schematic! Don't any of
          > you people check up on me so I'm not confusing myself? Sheesh!!! I'll

          Which page are you looking at? The manual page for the accessory
          connector matches the schematic.

          > What's PTD7/KBI7 on pin 33 doing Scott? Is it just sitting there
          > looking for something to do? If I added in a pull up resistor like

          It's connected to the solid state relay.

          > Hmm, now I think the big issue is going to be fitting all the code
          > into 512 bytes available in the scripting engine!

          If you find yourself using a lot of repetitive constructs, let me know
          and maybe I can implement some new commands. The DO ONCE command is a
          good example of that - it saves a lot of messing with flags and makes it
          more readable, too.

          Scott
        • James Ewen
          The messed pinout is in the Wiki on the telemetry page. Find out who created that page and give that guy a smack! ... -- James VE6SRV
          Message 4 of 11 , Aug 8, 2011
          • 0 Attachment
            The messed pinout is in the Wiki on the telemetry page.

            Find out who created that page and give that guy a smack!



            On 8/8/11, Scott Miller <scott@...> wrote:
            >> Hmm, just found an error on the telemetry page... I have IRQ listed as
            >> pin 6, and CFG as pin 1, backwards from the schematic! Don't any of
            >> you people check up on me so I'm not confusing myself? Sheesh!!! I'll
            >
            > Which page are you looking at? The manual page for the accessory
            > connector matches the schematic.
            >
            >> What's PTD7/KBI7 on pin 33 doing Scott? Is it just sitting there
            >> looking for something to do? If I added in a pull up resistor like
            >
            > It's connected to the solid state relay.
            >
            >> Hmm, now I think the big issue is going to be fitting all the code
            >> into 512 bytes available in the scripting engine!
            >
            > If you find yourself using a lot of repetitive constructs, let me know
            > and maybe I can implement some new commands. The DO ONCE command is a
            > good example of that - it saves a lot of messing with flags and makes it
            > more readable, too.
            >
            > Scott
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            >


            --
            James
            VE6SRV
          • Matt Cook
            James, I ve got a question. How does the email you re generating with the OT2 scripts get onto the net and delivered to your email box? Is this something
            Message 5 of 11 , Aug 8, 2011
            • 0 Attachment
              James,

              I've got a question.  How does the email you're generating with the OT2 scripts get onto the net and delivered to your email box?  Is this something you've cobbled together on your local APRS network?  You're scripts have got me thinking about what I could do at my remote HF site :)

              73's

              Matthew
              VK5ZM

              On Fri, Aug 5, 2011 at 2:44 PM, James Ewen <ve6srv@...> wrote:
               

              Added another script example.

              Using an AC driven relay on the profile switch input. When AC power
              goes out the OT2 will switch to profile 2. After 5 minutes with the
              power out, an email will be sent alerting about the power outage.
              After an outage, if the unit stays in profile 1 for 10 minutes a
              second email will be sent alerting to the return of AC to the site. An
              alarm acknowledge macro resets the triggers to keep from having
              multiple messages sent. Triggers could be automatically reset if
              desired by the script instead of latching until acknowledged...

              http://wiki.argentdata.com/index.php/Script_Examples#Send_Email_on_Event_with_Delay

              I still need to be able to test against telemetry values. I want to be
              able to test against the bit 7 of the telemetry input. That should be
              stored in memory at a fixed location... can I do a peek at a memory
              location and test against that? I'd like to monitor the door to the
              shack, and if bit 7 changes, send an intrusion alarm. Hmm, analog
              telemetry values should be stored somewhere in memory as well...

              --
              James
              VE6SRV


            • James Ewen
              ... I send an APRS message to a special callsign, which is monitored by a computer which moves the APRS message from the APRS-IS and forwards it onto the
              Message 6 of 11 , Aug 8, 2011
              • 0 Attachment
                On Mon, Aug 8, 2011 at 7:04 PM, Matt Cook <vk5zm@...> wrote:

                > I've got a question.  How does the email you're generating with the
                > OT2 scripts get onto the net and delivered to your email box?

                I send an APRS message to a special callsign, which is monitored by a
                computer which moves the APRS message from the APRS-IS and forwards it
                onto the internet email services.

                > Is this something you've cobbled together on your local APRS network?

                Not this puppy... have a look: http://www.aprs-is.net/Email.aspx

                > You're scripts have got me thinking about what I could do at my remote
                > HF site :)

                That's great, that's why I've been posting my scripts as examples.
                They are to give people a bit of an idea of the power that is
                available with scripting. It's hard to appreciate what we have
                available to us, unless you really dig into the documentation. By
                posting some examples, perhaps others will start to experiment with
                scripting.

                Just to emphasize Bob's mantra, APRS is not just about tracking vehicles.

                With these scripts, I can monitor quite a bit of what is happening at
                the digipeater shack. It helps when the shack is hours away, or up on
                a mountaintop. If you get an AC out alert, then watch the battery
                stack voltage drop before the digipeater disappears, you know what
                happened. If all you know is the digipeater went off air, you might
                end up going to a long drive just to find the site working fine by the
                time you get there because the power company has fixed the issue.

                If you can't figure out how to get something to work, feel free to
                post a query. Perhaps we can figure out a way to make it happen.

                --
                James
                VE6SRV
              • Matt Cook
                ... Thanks, must test this out and see if I can get it working. ... The script examples are a little difficult to find coming in through the front door of the
                Message 7 of 11 , Aug 9, 2011
                • 0 Attachment
                  On Tue, Aug 9, 2011 at 11:20 AM, James Ewen <ve6srv@...> wrote:

                  > Is this something you've cobbled together on your local APRS network?

                  Not this puppy... have a look: http://www.aprs-is.net/Email.aspx

                  Thanks, must test this out and see if I can get it working.
                   

                  That's great, that's why I've been posting my scripts as examples.
                  They are to give people a bit of an idea of the power that is
                  available with scripting. It's hard to appreciate what we have
                  available to us, unless you really dig into the documentation. By
                  posting some examples, perhaps others will start to experiment with
                  scripting.

                  The script examples are a little difficult to find coming in through the front door of the tracker2 website, so your link took me straight there.
                   
                  Just to emphasize Bob's mantra, APRS is not just about tracking vehicles.

                  No it's good for HAB car to car comms, monitoring the voltage in your boats batteries remotely and all sorts of things :)
                   
                  With these scripts, I can monitor quite a bit of what is happening at
                  the digipeater shack. It helps when the shack is hours away, or up on
                  a mountaintop. If you get an AC out alert, then watch the battery
                  stack voltage drop before the digipeater disappears, you know what
                  happened. If all you know is the digipeater went off air, you might
                  end up going to a long drive just to find the site working fine by the
                  time you get there because the power company has fixed the issue.

                  I know this pain.   The remote HF site we're using is 90kms (55mi) from home on the far side of a significant river.   The location has wireless internet (Wimax) but it's not 100% reliable.  So it's a three hour round trip to press the reset button, which happened to me recently.   I'm starting to think that some customised messages and a small amount of programming I should be able to remote control all sorts of things like reset buttons and mains/dc power and things etc.   Oh and AC monitoring and Battery voltage telemetry are an extra boon.

                  If you can't figure out how to get something to work, feel free to
                  post a query. Perhaps we can figure out a way to make it happen.

                  Will do.

                  73's

                  Matthew
                  VK5ZM
                • James Ewen
                  ... Hmm, how are you going to do the remote control stuff? There s only one controllable output, the rig power control output. If you add another device onto a
                  Message 8 of 11 , Aug 9, 2011
                  • 0 Attachment
                    On Tue, Aug 9, 2011 at 9:08 PM, Matt Cook <vk5zm@...> wrote:

                    > I'm starting to think that some customised messages and a small
                    > amount of programming I should be able to remote control all sorts
                    > of things like reset buttons and mains/dc power and things etc.
                    > Oh and AC monitoring and Battery voltage telemetry are an extra boon.

                    Hmm, how are you going to do the remote control stuff? There's only
                    one controllable output, the rig power control output. If you add
                    another device onto a port, and have it able to decode incoming
                    messages, you could probably have that device control multiple items.

                    Of course if you have some secret way to control multiple outputs on
                    the OT2, I'm all ears... I'd like to have the capability as well.

                    --
                    James
                    VE6SRV
                  • Matt Cook
                    ... Nothing ground breaking. A few years ago I repurposed a SMS controller ( http://www.siliconchip.com.au/cms/A_102670/article.html ) to receive commands
                    Message 9 of 11 , Aug 10, 2011
                    • 0 Attachment
                      On Wed, Aug 10, 2011 at 3:33 PM, James Ewen <ve6srv@...> wrote:
                       

                      Hmm, how are you going to do the remote control stuff? There's only
                      one controllable output, the rig power control output. If you add
                      another device onto a port, and have it able to decode incoming
                      messages, you could probably have that device control multiple items.

                      Nothing ground breaking.  A few years ago I repurposed a SMS controller (http://www.siliconchip.com.au/cms/A_102670/article.html ) to receive commands thru my Codan NGT HF radio, it took commands off the Codan selective calling subsystem and switched antennas and amplifiers on and off.  Allowed me to test and play with my remote HF station while at home or in the car (NVIS path), this was before I got the internet connected.

                      The SMS controller hardware has multiple transistor outputs, uses a common as mud Atmel micro and more importantly a genuine serial port.   So I'm simply thinking of parsing targeted ARPS messages out of the OT2 serial port and switching the outputs, the best part is the embedded code in this SMS controller is capable of answering with an ACK to tell you it heard you.  Shouldn't be too hard and I've already got the hardware built and the necessary ICE.

                      Of course if you have some secret way to control multiple outputs on
                      the OT2, I'm all ears... I'd like to have the capability as well.

                      If Scott is still considering features for the OT3 then I'd cast a vote to have the 1-wire bus feature capable of being disabled and allow two serial shift registers to be attached for general purpose outputs.  For latching take the last output of the shift register and jam this into the latch input with a monostable delay.  Simple !   Expanding the macro language to allow these output's to be switched would give us all sorts of telemetry and remote control type things we could do.  YMMV.

                      73's

                      Matthew
                      VK5ZM


                       
                      --
                      James
                      VE6SRV


                    • Scott Miller
                      ... POKE a port s data direction register to set one of those extra inputs to output, and use another POKE to change the output state. Not pretty, but it ll
                      Message 10 of 11 , Aug 15, 2011
                      • 0 Attachment
                        > Of course if you have some secret way to control multiple outputs on
                        > the OT2, I'm all ears... I'd like to have the capability as well.

                        POKE a port's data direction register to set one of those extra inputs
                        to output, and use another POKE to change the output state. Not pretty,
                        but it'll work.

                        Scott
                      Your message has been successfully submitted and would be delivered to recipients shortly.