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

Re: [tracker2] OT2m / T2-135 / T2-301 / ADS-WS1 - Time & Scripting etc.

Expand Messages
  • James Ewen
    We talked about this a while back. The SETTIME function would be nice. Being able to grab time from a GPS would be nice as well, but that means having a GPS on
    Message 1 of 6 , Aug 3, 2010
      We talked about this a while back. The SETTIME function would be nice.
      Being able to grab time from a GPS would be nice as well, but that
      means having a GPS on a static station (digipeater) just to resolve
      time once a day/week.

      What I think would be real cool would be to have the unit able to
      parse time out of an APRS packet that it sees on air.

      I know Scott has come up with reasons why this wouldn't work, but I
      think it could be feasible. I think Scott was worried about the
      variability of the encoded time in the packets. It is true that people
      could have incorrect time signatures. What about only using time
      stamps from a limited number of stations. Maybe only the ones in the
      authlist. The unit could look for a time correction timestamp once a
      day or so.

      James
      VE6SRV

      On 8/3/10, Keith VE7GDH <ve7gdh@...> wrote:
      > Scott - re scripting... would there be enough code space for the OT2m /
      > T2-135
      > and T2-301 to get the time from an attached GPS receiver? Also could the
      > same
      > function be added to the ADS-WS1 for resetting the rain gauge at a certain
      > time?
      >
      > For a "battery save" option, a script could turn the power on to the GPS
      > receiver
      > just once a week, or however often it was needed for reasonable accuracy,
      > but I
      > can see that would only be useful for people that weren't using power
      > switching
      > for the radio.
      >
      > However, I see that James has also asked about setting the time remotely. If
      > this
      > was a standard feature, I could see it being better than having a GPS
      > connected
      > all of the time just to set the clock... SETTIME YYYYMMDDHHMMSS
      > It could listen to anyone sending the message, or could only listen to
      > messages
      > from callsigns in the access list.
      >
      > 73 es cul - Keith VE7GDH
      > --
      > "I may be lost, but I know exactly where I am!"
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
    • Keith VE7GDH
      James VE6SRV wrote... ... To me, it would be worthwhile to have a GPS connected if it was the only way to set the time while not on site. My only arguement
      Message 2 of 6 , Aug 3, 2010
        James VE6SRV wrote...

        > We talked about this a while back. The SETTIME function would be nice.
        > Being able to grab time from a GPS would be nice as well, but that
        > means having a GPS on a static station (digipeater) just to resolve
        > time once a day/week.

        To me, it would be worthwhile to have a GPS connected if it was the
        only way to set the time while not on site. My only arguement against a
        GPS would be if there was a limited power budget. However...

        > What I think would be real cool would be to have the unit able to
        > parse time out of an APRS packet that it sees on air.

        That would be good too.

        > I know Scott has come up with reasons why this wouldn't work, but I
        > think it could be feasible. I think Scott was worried about the
        > variability of the encoded time in the packets. It is true that people
        > could have incorrect time signatures. What about only using time
        > stamps from a limited number of stations. Maybe only the ones in the
        > authlist. The unit could look for a time correction timestamp once a
        > day or so.

        Variability might be an issue. If the time could be set remotely with a
        SETTIME message, accepting it only from those on the AUTHLIST
        would be good enough for me.

        73 es cul - Keith VE7GDH
        --
        "I may be lost, but I know exactly where I am!"
      • Lynn W. Deffenbaugh (Mr)
        ... Variability would also be an issue with an APRS-messaged cmd SETTIME , but I don t think we re really worried about down-to-the-second accuracy here.
        Message 3 of 6 , Aug 3, 2010
          Keith VE7GDH wrote:
          > Variability might be an issue. If the time could be set remotely with a
          > SETTIME message, accepting it only from those on the AUTHLIST
          > would be good enough for me.
          >

          Variability would also be an issue with an APRS-messaged "cmd SETTIME",
          but I don't think we're really worried about down-to-the-second accuracy
          here. With the examples I've seen of time-based scripts, accurate to a
          minute or two is probably sufficient.

          I'll throw my hat in the remote SETTIME message restricted to those
          sources on AUTHLIST and the other security around remote command
          execution via APRS messages.

          Lynn (D) - KJ4ERJ - Adding my $0.02 for whatever it's worth in today's
          economy
        • Keith VE7GDH
          Lynn KJ4ERJ wrote... ... You re right. Down the second probably isn t needed. To me, it would just be a matter of knowing the day of the week and the time
          Message 4 of 6 , Aug 3, 2010
            Lynn KJ4ERJ wrote...

            > Variability would also be an issue with an APRS-messaged
            > "cmd SETTIME", but I don't think we're really worried about
            > down-to-the-second accuracy here. With the examples I've seen
            > of time-based scripts, accurate to a minute or two is probably sufficient.

            You're right. Down the second probably isn't needed. To me, it would
            just be a matter of knowing the day of the week and the time (within a few
            minutes, but there's nothing wrong with down to the second if it's do-able)
            so that scripts could be run weekly, or so that the weather station could
            reset the rain gauge somewhere around midnight with some consistency.

            > I'll throw my hat in the remote SETTIME message restricted to those
            > sources on AUTHLIST and the other security around remote command
            > execution via APRS messages.

            I think that it would be a reasonable solution. The T2 series can already
            accept remote commands. It would just be a matter of adding a variable
            to store the time and then counting ticks until the next time that the time
            was set again.

            73 es cul - Keith VE7GDH
            --
            "I may be lost, but I know exactly where I am!"
          • Scott Miller
            Forgive my out-of-sequence replies, I ve fallen way behind on email again. See my post about the T2 code development... I ll see what there s space for when
            Message 5 of 6 , Aug 10, 2010
              Forgive my out-of-sequence replies, I've fallen way behind on email
              again. See my post about the T2 code development... I'll see what
              there's space for when the HCS08 port and testing is done.

              Scott

              Keith VE7GDH wrote:
              >
              >
              > Scott - re scripting... would there be enough code space for the OT2m /
              > T2-135
              > and T2-301 to get the time from an attached GPS receiver? Also could the
              > same
              > function be added to the ADS-WS1 for resetting the rain gauge at a
              > certain time?
              >
              > For a "battery save" option, a script could turn the power on to the GPS
              > receiver
              > just once a week, or however often it was needed for reasonable
              > accuracy, but I
              > can see that would only be useful for people that weren't using power
              > switching
              > for the radio.
              >
              > However, I see that James has also asked about setting the time
              > remotely. If this
              > was a standard feature, I could see it being better than having a GPS
              > connected
              > all of the time just to set the clock... SETTIME YYYYMMDDHHMMSS
              > It could listen to anyone sending the message, or could only listen to
              > messages
              > from callsigns in the access list.
              >
              > 73 es cul - Keith VE7GDH
              > --
              > "I may be lost, but I know exactly where I am!"
              >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.