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

RE: [tracker2] Standby mode

Expand Messages
  • scott@opentrac.org
    ... No problem, just set INTERVAL to 0. It ll answer ?APRS? queries (though I could add an option to disable that in this case) and you can send an INTERVAL
    Message 1 of 9 , Jul 7, 2006
    • 0 Attachment
      > 1) I'd like to see a standby mode where the Tracker2 is
      > listening to APRS
      > packets. Thus if my vehicle is stolen I can remotely send it an APRS
      > packet of some sort which it will then start beaconing.

      No problem, just set INTERVAL to 0. It'll answer ?APRS? queries (though I
      could add an option to disable that in this case) and you can send an
      INTERVAL command remotely to turn it on. Or you could use the power control
      option to just turn off the GPS receiver. Personally, I'd prefer to use
      that to kill the fuel pump!

      > would, in effect, contain a password which the Open Tracker
      > software would
      > recognize. Needless to say once I used it I'd want to change
      > the password

      I'm working on a couple of different authentication methods. It's a
      tradeoff between ease of use and security.

      > Now it's my understanding that the USA FCC doesn't permit
      > remote control
      > operation on the 2m band. But I'm in Canada so that

      I think that's for 1-way R/C with no ID. This should fall into the same
      category as remote commands for a digipeater or mailbox.

      > of blocks. So what would be nice is a switch on the dash
      > where I can
      > tell the Tracker2 to start beaconing. Now I'd setup a short

      You can do that with the configuration jumper or the 'transmit now' input.
      A common setup is to put the text EMERGENCY in the second profile's comment
      line, with a relatively fast beacon rate, so that you can flip a switch and
      send emergency beacons that'll set off alarms on everyone's APRS displays.

      > (What is the delay between beaconing and being seen on the
      > Internet at
      > places such as findu.com?)

      Usually not more than a second or two.

      Scott
    • Tony VE6MVP
      ... I am going to add some kind of disabler device which requires me to hit a switch of some sort which will then enable the fuel pump. Thus a thief who had
      Message 2 of 9 , Jul 7, 2006
      • 0 Attachment
        At 11:48 AM 2006/07/07 -0700, you wrote:

        >Personally, I'd prefer to use
        >that to kill the fuel pump!

        I am going to add some kind of disabler device which requires me to hit a
        switch of some sort which will then enable the fuel pump. Thus a thief
        who had hotwired the vehicle would not be able to start it.

        Besides if the vehicle is indeed moving I'd sooner have the cops stop it
        themselves and arrest the bad guys. Rather than disabling it so they'd
        abandon the vehicle. Of course if they start running then it would be
        nice to remotely disable the fuel pump. I'm sure the cops would
        appreciate that from a bystanders viewpoint. As would I as there is likely
        to be less damage to my vehicle.

        <Rest of your response snipped>

        Wow, very nice to see just how much flexibility you're putting into the
        device.

        > > (What is the delay between beaconing and being seen on the
        > > Internet at
        > > places such as findu.com?)
        >
        >Usually not more than a second or two.

        Ah, now that's nice too. You can tell the operator a few seconds after
        making the turn, "Hit the refresh button now."

        Thanks, Tony
      • juha.nurmela@quicknet.inet.fi
        ... The password would be easy enough to change at the police station parking lot ? :) No shortage of suggestions ;) but here comes another idea. In addition
        Message 3 of 9 , Jul 7, 2006
        • 0 Attachment
          On Fri, 7 Jul 2006 scott@... wrote:

          > tony> Needless to say once I used it I'd want to change the password
          >
          > I'm working on a couple of different authentication methods. It's a
          > tradeoff between ease of use and security.

          The password would be easy enough to change at the police station
          parking lot ? :)

          No shortage of suggestions ;) but here comes another idea.

          In addition to the existing remote operation;

          A code word, recognized from, say, incoming messages, which
          would just indirect into a pre-configured command. no acks no nothing.

          The command(s) intended to be idempotent, would not cause harm if Eve the
          eavesdropper replayed it (the fuelpump fuse would remain blown ;) Nor
          would Eve know what it did, if it was not obvious from subsequent tracker2
          behavior.

          codeword 'power' could be published to a larger group, to switch a power
          brick on/off for example, and the password stuff kept secret.


          Juha, OH5NXO
        • scott@opentrac.org
          ... I figured it d be better to do it once the cops had the car in sight. My Accord has a 15 amp fuse on the fuel pump, so I think the simplest way to set it
          Message 4 of 9 , Jul 7, 2006
          • 0 Attachment
            > Besides if the vehicle is indeed moving I'd sooner have the
            > cops stop it
            > themselves and arrest the bad guys. Rather than disabling it
            > so they'd
            > abandon the vehicle. Of course if they start running then

            I figured it'd be better to do it once the cops had the car in sight. My
            Accord has a 15 amp fuse on the fuel pump, so I think the simplest way to
            set it up would be to power the tracker through that circuit (the high-side
            switch can't switch a separate supply), making sure it's got adequately
            heavy cabling, and just short the output leads of the switch. When the
            switch is turned on, it'll switch up to 20 amps before the current limiting
            cuts in, but that's enough to blow the fuse. You have to get out of the car
            and open an access panel to replace it.

            A simple relay might be better, though. You could also kill the ECU, but
            I'd be afraid of causing damage to the engine. Killing the fuel supply
            shouldn't do anything more dramatic than starving the engine and making the
            car coast to a stop.

            Before anyone tries to implement this, I should point out that my auto shop
            grades were... well, not quite on par with my CS/EE grades, anyway. =]

            > Wow, very nice to see just how much flexibility you're
            > putting into the
            > device.

            It'll be able to do a lot more if I ever get a chance to implement the
            scripting language I've been thinking about. That'll have to wait until
            after the first production firmware release, though.

            Scott
          • scott@opentrac.org
            ... That could be done in the hypothetical scripting language. I think it d be fine with the authentication techniques I m working on. Right now it s all
            Message 5 of 9 , Jul 7, 2006
            • 0 Attachment
              > In addition to the existing remote operation;
              >
              > A code word, recognized from, say, incoming messages, which
              > would just indirect into a pre-configured command. no acks no nothing.

              That could be done in the hypothetical scripting language. I think it'd be
              fine with the authentication techniques I'm working on. Right now it's all
              callsign-based. Another one will be something you can calculate in your
              head or keep on paper, and the third will be a true cryptographic MAC
              that'll have to be generated by a computer.

              > The command(s) intended to be idempotent, would not cause
              > harm if Eve the
              > eavesdropper replayed it (the fuelpump fuse would remain blown ;) Nor
              > would Eve know what it did, if it was not obvious from
              > subsequent tracker2
              > behavior.

              Idempotence is actually a major concern in the command interface and
              scripting language design. It's very easy to get the same command multiple
              times due to retries and network topology, and the flash memory has finite
              write endurance. That's an issue in scripting if you say 'execute this
              configuration command when contact A is closed' - it'd be easy to erase and
              rewrite the same page in flash very quickly and eventually destroy it.

              My initial idea for a scripting language resembled a PLC's ladder logic,
              rather than a procedural language. I'm still leaning toward that sort of
              setup, but it introduces some complexity in dealing with output events that
              have to be edge-triggered.

              Scott
            • juha.nurmela@quicknet.inet.fi
              ... This code word would not require authentication, it would be a less-privileged thing. Instead of keys to the machine room, you d have a cord to pull, to
              Message 6 of 9 , Jul 7, 2006
              • 0 Attachment
                On Fri, 7 Jul 2006 scott@... wrote:

                > That could be done in the hypothetical scripting language. I think it'd be
                > fine with the authentication techniques I'm working on.

                This 'code word' would not require authentication, it would be
                a less-privileged thing. Instead of keys to the machine room,
                you'd have a cord to pull, to reset the airconditioning.

                > Idempotence is actually a major concern in the command interface and
                > scripting language design. It's very easy to get the same command multiple

                You know the cure ;) Message identifiers.

                > My initial idea for a scripting language resembled a PLC's ladder logic,

                I guess a Forth-like language is out of the question. Easy to implement,
                but, kind of crazy to usher people to code in RPN something, what
                they could write by themselves and recompile, in the first place.




                Juha
              • scott@opentrac.org
                ... Responding to commands and initiating pre-programmed actions is a big part of what I want the scripting language to be able to do. ... Yeah, not a lot of
                Message 7 of 9 , Jul 7, 2006
                • 0 Attachment
                  > This 'code word' would not require authentication, it would be
                  > a less-privileged thing. Instead of keys to the machine room,
                  > you'd have a cord to pull, to reset the airconditioning.

                  Responding to commands and initiating pre-programmed actions is a big part
                  of what I want the scripting language to be able to do.

                  > I guess a Forth-like language is out of the question. Easy to
                  > implement,
                  > but, kind of crazy to usher people to code in RPN something, what
                  > they could write by themselves and recompile, in the first place.

                  Yeah, not a lot of room.. but you're not the first to suggest Forth. I've
                  got a book on designing 'little languages' and their interpreters... I'm
                  hoping to get some insipration from that. It needs to be line-editable
                  though, so you can make code changes remotely.

                  Scott
                • Curt, WE7U
                  ... I once wrote a Forth interpreter for a 6803 processor in under 2k. -- Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer Lotto: A tax
                  Message 8 of 9 , Jul 10, 2006
                  • 0 Attachment
                    On Fri, 7 Jul 2006 scott@... wrote:

                    > > I guess a Forth-like language is out of the question. Easy to
                    > > implement,
                    > > but, kind of crazy to usher people to code in RPN something, what
                    > > they could write by themselves and recompile, in the first place.
                    >
                    > Yeah, not a lot of room.. but you're not the first to suggest Forth. I've
                    > got a book on designing 'little languages' and their interpreters... I'm
                    > hoping to get some insipration from that. It needs to be line-editable
                    > though, so you can make code changes remotely.

                    I once wrote a Forth interpreter for a 6803 processor in under 2k.

                    --
                    Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer
                    "Lotto: A tax on people who are bad at math." -- unknown
                    "Windows: Microsoft's tax on computer illiterates." -- WE7U
                    "The world DOES revolve around me: I picked the coordinate system!"
                  Your message has been successfully submitted and would be delivered to recipients shortly.