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

Re: Tracker3 model T3-135

Expand Messages
  • Ron N9SZV
    update I used Tracker3 beta build 56133 7/25/2012 I have installed the current firmware build, today thanks for all the info...can any one tell me what the
    Message 1 of 21 , Oct 18, 2012
    • 0 Attachment
      update I used Tracker3 beta build 56133 7/25/2012

      I have installed the current firmware build, today thanks for all the info...can any one tell me what the current build updates?


      Ron N9SZV

      --- In tracker2@yahoogroups.com, "Ron N9SZV" <n9szv@...> wrote:
      >
      > I have installed the current firmware build, today thanks for all the info...can any one tell me what the current build updates?
      >
      >
      > Ron N9SZV
      >
      >
      >
      >
      >
      > --- In tracker2@yahoogroups.com, Bob Burns W9RXR <w9rxr_@> wrote:
      > >
      > > On Tue, Oct 16, 2012 at 8:33 AM, Ron N9SZV <n9szv@> wrote:
      > >
      > > > Morning Lynn!! where is this OTWINCFG Web option? the only thing I find is
      > > > about the T2 and there were last updated in 2009
      > > >
      > >
      > > First off, the wiki article for the Tracker3 is available here:
      > >
      > > http://wiki.argentdata.com/index.php?title=OT3m
      > >
      > > Per the wiki, the Tracker3 manual is available here:
      > >
      > > http://www.argentdata.com/support/tracker3_manual.pdf
      > >
      > > Now, open the Tracker3 manual to page 15. This begins the instructions for
      > > use of OTWINCFG. On page 16 is a screen shot of OTWINCFG. About half way
      > > down on the right side, you will see "Load Firmware From" followed by two
      > > buttons: File, Web. If you run OTWINCFG while connected to the Internet and
      > > you click on the Web button, a screen will pop up that will list the
      > > available firmware files.
      > >
      > > Bob...
      > >
      >
    • Angelo Glorioso
      Hello All, A group of us in the Louisiana area started to use the Tracker3 model T3-135 as aprs digi for the sites. The reason for the use was that it seemed
      Message 2 of 21 , May 20, 2014
      • 0 Attachment
        Hello All,
         
         A group of us in the Louisiana area started to use the Tracker3 model T3-135 as aprs digi for the sites.  The reason for the use was that it seemed simple to setup and fast.
         
         I do have a couple of questions though. During one of our installs we noticed that a group of aprs operators are
        sending out beacons of nets, repeater, and club meetings that are going beyond their local area which causes nothing but added traffic to the area. 
         
         We have tried the diplomat route but it seems this will not pan out so I started to look into budlist function in the
        T3-135. To my surprise, there is non. I even went to Dayton and talked to Bob WB4APR about this and he was surprised.
         
         Also after doing some testing with the T3-135 and with MFJ-1270C, we noticed that the MFJ received better. I am wondering if it is because of the narrow band mode the dr-135 needs to be in???  
         
        We would like to purchase 5 more of these units for additional sites but with he budlist being omitted, we are wondering if this could be added???
         
          
        7 3 de Angelo
      • James Ewen
        On Tue, May 20, 2014 at 1:08 PM, Angelo Glorioso n5uxt@hotmail.com ... The unit probably meets these goals. ... That s kind of what APRS is all about. Sending
        Message 3 of 21 , May 20, 2014
        • 0 Attachment
          On Tue, May 20, 2014 at 1:08 PM, Angelo Glorioso n5uxt@...
          [tracker2] <tracker2@yahoogroups.com> wrote:

          > A group of us in the Louisiana area started to use the Tracker3 model
          > T3-135 as aprs digi for the sites. The reason for the use was that it
          > seemed simple to setup and fast.

          The unit probably meets these goals.

          > I do have a couple of questions though. During one of our installs we
          > noticed that a group of aprs operators are sending out beacons of nets,
          > repeater, and club meetings that are going beyond their local area
          > which causes nothing but added traffic to the area.

          That's kind of what APRS is all about. Sending information out over
          the air. If people didn't do that, there would be no need for
          digipeaters, or even receivers on the radios.

          > We have tried the diplomat route but it seems this will not pan out so I
          > started to look into budlist function in the T3-135. To my surprise, there
          > is non. I even went to Dayton and talked to Bob WB4APR about this and
          > he was surprised.

          You need to try harder at educating the users. Bob shouldn't be
          surprised that there's no BUDLIST in the OpenTracker units. He's been
          told about that many times over. Besides, BUDLIST is not an acceptable
          method of limiting access to the APRS network. Any and all user
          packets should be serviced as requested by the originator. Hop limits
          have been determined to be an appropriate way of limiting the maximum
          number of hops supported by the APRS digipeater network.

          > Also after doing some testing with the T3-135 and with MFJ-1270C,
          > we noticed that the MFJ received better. I am wondering if it is because
          > of the narrow band mode the dr-135 needs to be in???

          I don't have a DR-135, so I can't say for sure, but if you search the
          archives, you'll probably find messages about narrow band and the
          DR-135. You should not have to be in narrow band mode. That will
          overdrive the receiver causing poor decode.

          > We would like to purchase 5 more of these units for additional sites
          > but with he budlist being omitted, we are wondering if this could be added???

          A BUDLIST is a bad thing... APRS is part of the amateur radio world,
          where anyone has access to the airwaves if they hold a valid license.
          There are a number of things you can do to keep people from using your
          digipeater.

          1) Remove it from service. That way these unwanted users won't be
          using your equipment.
          2) Move to a different frequency. The unwanted users won't be on your frequency
          3) Remove the digipeater alias they are using from your supported aliases.
          4) Educate the users about the operation of their station, and how to
          be more courteous.
          Then there's a final solution.
          Put your digipeater on the air and allow the users to use it.

          Bob should have told you that these repeater objects and other data
          like nets, etc. should be sourced from the digipeaters, so they "don't
          use up any airtime". (That's Bob's concept). By having the digipeaters
          source the information, they have the best chance of not clobbering
          other users, and the data can be limited to a specific area easily.

          Sourcing objects from home stations usually requires asking for a hop
          from a digipeater, and subsequently, the possibility of clobbering
          another user's packet in the process. Quite often the software
          sourcing the packets doesn't have the provisions to be able to send
          each packet with a unique path, hence all packets no matter their
          desired destination, end up going out over the default path.

          Putting bandaids on the network (BUDLISTs) does nothing to solve the
          root problem, work on educating the users about the "problem". Educate
          EVERYONE in your area, not just the problem users. If EVERYONE
          complains to the source of the problem, perhaps one day they might
          listen and learn. If it's only you squeaking, you'll be the problem to
          the guy making all the noise.

          --
          James
          VE6SRV
        • n5uxt
          ... I think you are missing the point. Sending out messages out side of a city service area does nothing but add unnecessary traffic to the outside network.
          Message 4 of 21 , May 22, 2014
          • 0 Attachment

             

            > I do have a couple of

            questions though. During one of our installs we
            > noticed that a group of aprs operators are sending out beacons of nets,
            > repeater, and club meetings that are going beyond their local area
            > which causes nothing but added traffic to the area.


            >>That's kind

            of what APRS is all about. Sending information out over
            >> the air.
            If people didn't do that, there would be no need for

            >> digipeaters,
            or even receivers on the radios.

            I think you are missing the point. Sending out messages out side of a city

            service area does nothing but add unnecessary traffic to the outside

            network. These messages should be local to the area to which the event

            is being held.

             

             

            > We have tried the

            diplomat route but it seems this will not pan out so I
            > started to look into budlist function in the T3-135. To my surprise, there
            > is non. I even went to Dayton
            and talked to Bob WB4APR about this and
            > he was surprised.


            >> You need

            to try harder at educating the users. Bob shouldn't be
            >> surprised
            that there's no BUDLIST in the OpenTracker units. He's been

            >> told about
            that many times over. Besides, BUDLIST is not an acceptable
            >> method of
            limiting access to the APRS network. Any and all user
            >> packets
            should be serviced as requested by the originator. Hop limits
            >> have been
            determined to be an appropriate way of limiting the maximum
            >> number of
            hops supported by the APRS digipeater network.

             

             So James, several emails, over 10  phone calls, APRS message to the

            Club member ( Vice President) is as hard as I am going to go. Not sure

            when it was the last time you talk to Bob, but he feels very differently about

            no budlist.  It is not what we want but it is something that needs to be done

            to control the unnecessary traffic in our area. The hop limit is what we 

            are trying to get them to change. Don't misunderstand me, it is not the messages

            but it is the amount of hops the messages are going.   


            > Also after doing some

            testing with the T3-135 and with MFJ-1270C,
            > we noticed that the MFJ received better. I am wondering if it is because
            > of the narrow band mode the dr-135 needs to be in???


            >>  I don't have a DR-135, so I can't say for

            sure, but if you search the
            >> archives,
            you'll probably find messages about narrow band and the

            >> DR-135.
            You should not have to be in narrow band mode. That will
            >> overdrive
            the receiver causing poor decode.

             

            I have and that is why I am bringing  it forward again. No solution has been found.

             

            > We would like to

            purchase 5 more of these units for additional sites
            > but with he budlist being omitted, we are wondering if this could be
            added???


            >> A BUDLIST

            is a bad thing... APRS is part of the amateur radio world,
            >> where
            anyone has access to the airwaves if they hold a valid license.

            >> There are
            a number of things you can do to keep people from using your
            >> digipeater.

            I agree but something has to give. Why is other MFG and the UIDIGI have this feature if is it so bad ?????

             


            >> 1) Remove
            it from service. That way these unwanted users won't be
            >>  using your equipment.
            >>  2) Move to a different frequency. The unwanted users
            won't be on your frequency
            >>  3) Remove the digipeater alias they are using from
            your supported aliases.
            >>  4) Educate the users about the operation of their
            station, and how to
            >>  be more courteous.
            >>  Then there's a final solution.
            >>  Put your digipeater on the air and allow the users to
            use it.

              It is nice to see that you live in the bubble James. One shoes does not fit all.  Your above suggestions are not an option but thanks.

             

            While you may think a budlist is a bandaid, this bandaid is what we need. We don’t

            Like this method but we are left to this option.

             

             

            73 de Angelo

             

             

             

          • James Ewen
            Angelo, please read all the way through to the end before going crazy on a reply! I m not after a war, but I would like to discuss the concept rationally with
            Message 5 of 21 , May 22, 2014
            • 0 Attachment
              Angelo, please read all the way through to the end before going crazy
              on a reply! I'm not after a war, but I would like to discuss the
              concept rationally with you. I know it's easy to get defensive and
              read the wrong tone into issues like this... I've interspersed by
              replies, but at the end hopefully there's enough reasoning to allow
              you to understand what I'm trying to get across.

              On Thu, May 22, 2014 at 12:28 PM, n5uxt@... [tracker2]
              <tracker2@yahoogroups.com> wrote:

              > >>That's kind of what APRS is all about. Sending information out over
              > >> the air. If people didn't do that, there would be no need for
              > >> digipeaters, or even receivers on the radios.
              >
              > I think you are missing the point. Sending out messages out side of a city
              > service area does nothing but add unnecessary traffic to the outside
              > network. These messages should be local to the area to which the event
              > is being held.

              I understand fully, and endorse the concept of local information needs
              to stay local. I push that concept daily. I get flak all the time when
              I try to convince the balloon crews to use a zero hop path when
              flying. There's no need at all to ask for digipeater hops from
              anything flying over 1000 feet AGL.

              > >> You need to try harder at educating the users.
              >
              > So James, several emails, over 10 phone calls, APRS message to the
              > Club member ( Vice President) is as hard as I am going to go.

              Were any of the emails received, phone calls answered? Did he read the
              APRS message? Have you discussed the concept with this person, and
              found out his reasoning behind sending the information out over the
              distance he is sending it? I've had my fair share of "Go piss off, you
              don't know me, and can't tell me how to run my APRS station!", type
              responses... I know what you might be up against. But then again, if
              you can actually sit and talk with people and get into a reasoned
              discussion, you can sometimes get that education thing working! It can
              be tough with some people.

              > Not sure
              > when it was the last time you talk to Bob, but he feels very differently about
              > no budlist.

              He must be flip-flopping yet again. How can a BUDLIST entry fulfill
              the requirement of reducing the impact of a poor path selection?

              > Don't misunderstand me, it is not the messages
              > but it is the amount of hops the messages are going.

              I got the concept. Without knowing who is sending the packets, I can't
              search for them to find out the path being used.

              Let's say that the path is WIDE2-2, and the desired area is one
              digipeater hop away from you. You put the source callsign in your
              digipeater BUDLIST. The packets still get sent out, they still get
              handled by EVERY digipeater around, except yours. How does that
              BUDLIST entry help anything except for keeping your digipeater from
              acting on the packet?

              Correct the source rather than band aid patch one element in the whole network.

              > >> A BUDLIST is a bad thing...
              >
              > I agree but something has to give. Why is other MFG and the
              > UIDIGI have this feature if is it so bad ?????

              BUDLIST was in TNCs before APRS was a twinkle in Bob's eye.

              How many entries should a BUDLIST have? If everyone starts following
              the lead of your poor example, you're going to need an extremely large
              BUDLIST.

              > >> 1) Remove it from service. That way these unwanted users won't be
              > >> using your equipment.
              > >> 2) Move to a different frequency. The unwanted users won't be on your frequency
              > >> 3) Remove the digipeater alias they are using from your supported aliases.
              > >> 4) Educate the users about the operation of their station, and how to
              > >> be more courteous.
              > >> Then there's a final solution.
              > >> Put your digipeater on the air and allow the users to use it.
              >
              > It is nice to see that you live in the bubble James. One shoes does not fit all.
              > Your above suggestions are not an option but thanks.

              I don't live in a bubble. I play APRS in a large network of
              digipeaters that spans hundreds of thousands of square miles. (I run
              about a dozen local digipeaters) I share the frequency with many other
              users. I understand that one shoe does not fit all, which is why I
              gave you a number of options as listed above, rather than your single
              BUDLIST solution. Every one of the options above would work to keep
              your digipeater from repeating these unwanted packets. All of the
              suggestions above are indeed options... perhaps not desirable options,
              but they are indeed options.


              > While you may think a budlist is a bandaid, this bandaid is what we need. We don’t
              > Like this method but we are left to this option.

              Why is a BUDLIST the ONLY option you have?

              How much traffic is this station putting out per hour? Is it really
              affecting the availability of the APRS network in your area? How will
              BUDLISTing this one station increase the availability of the APRS
              network? Your digipeater will still be tied up listening to all the
              packets from this source station being digipeated by other digipeaters
              in the area, so you're not going to gain a whole lot of newly freed up
              airtime.

              I'm not trying to be argumentative just to start a fight, but rather
              to try and work through the reasoning behind why BUDLIST seems to be
              the only solution to this "problem", and what you expect to see as an
              end result gain by implementing a BUDLIST.

              Trust me, I have similar things happening in my area... I know what
              you are talking about, but it's not the end of the world.

              Have a look...

              http://aprs.fi/info/VA6JL

              Take a look at all of the objects... not all go out all the time, but
              there are a bunch of repeater objects that get sent out from an i-gate
              over RF using a path of WIDE1-1,WIDE2-1. They easily propagate 100
              miles north to my area.

              http://aprs.fi/?c=raw&call=VE6HM-13

              All these packets are generated and shoved into the APRS-IS stream,
              and then gated out over RF into the network 24/7...

              Do they need to be there? Nope. Do they degrade the network to the
              point where no one can use that system? Nope.

              So really, the crux of the matter is... do you REALLY need to BUDLIST
              this one station? What will you gain?

              --
              James
              VE6SRV
            • n5uxt
              James, I appreciate your continued drilling of what I have done or have not done, but the facts are the same. Crazy or not ( I would never use wording like
              Message 6 of 21 , May 24, 2014
              • 0 Attachment
                 James, I appreciate your continued drilling of what I have done or have not done, but the facts are the same. Crazy or not ( I would never use wording like crazy ) the need for this function is needed. Whether or not budlist was in the code before aprs, does not matter. It is there in the UIDIGI software.

                I hope you have a great day James!!


                  
              • Lynn W. Deffenbaugh (Mr)
                Just because a function is available on one platform (UIDIGI which I thought was a command in the KPC TNC series, not particularly user-oriented software ),
                Message 7 of 21 , May 24, 2014
                • 0 Attachment
                  Just because a function is available on one platform (UIDIGI which I thought was a command in the KPC TNC series, not particularly user-oriented "software"), doesn't mean that another platform is required to implement it (the T3-135 in this case).  Different platforms have different capabilities and constraints.  Choose the one with the features you need and run with it.  Or ask for a change, but demanding a feature on a new platform just because "we had it on the old platform" won't necessarily get you satisfaction, and may be impossible to deliver.

                  Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

                  PS.  Just as an aside, do Kenwood APRS radios with internal TNC with digipeater capabilities provide a Budlist-type filter function?


                  On 5/24/2014 11:26 AM, n5uxt@... [tracker2] wrote:
                   James, I appreciate your continued drilling of what I have done or have not done, but the facts are the same. Crazy or not ( I would never use wording like crazy ) the need for this function is needed. Whether or not budlist was in the code before aprs, does not matter. It is there in the UIDIGI software.

                  I hope you have a great day James!!


                    

                • n5uxt
                  I am lost here!! Where is the word DEMAND in any of my posts??? Please everyone, this all started as a observation and later why it would be a good feature if
                  Message 8 of 21 , May 24, 2014
                  • 0 Attachment

                    I am lost here!! Where is the word DEMAND in any of my posts??? 

                     

                    Please everyone, this all started as a observation and later why it would be a good feature if you plan on using T3-135 as a standalone digi at a tower site. Maybe I am totally wrong with wanting to use a great product like the T3-135 by Argent Systems as a standalone digi.

                     

                     Again if the use of the word needed or should is considered a demand, I am sorry.

                    In the words of others, might want to read the original post.

                     

                    https://groups.yahoo.com/neo/groups/tracker2/conversations/messages/16576

                     

                    Lynn, I have a better question. How many Kenwood Mobiles are being used as a permanent digi at a tower site??????

                  • James Ewen
                    On Sat, May 24, 2014 at 9:26 AM, n5uxt@hotmail.com [tracker2] ... Sorry if you interpret my interest in your request as drilling , I was simply attempting to
                    Message 9 of 21 , May 24, 2014
                    • 0 Attachment
                      On Sat, May 24, 2014 at 9:26 AM, n5uxt@... [tracker2]
                      <tracker2@yahoogroups.com> wrote:

                      > James, I appreciate your continued drilling of what I have done or have not done,
                      > but the facts are the same.

                      Sorry if you interpret my interest in your request as "drilling", I
                      was simply attempting to discuss the issue that you are faced with,
                      and your perceived sole solution to that issue.

                      > Crazy or not ( I would never use wording like crazy ) the need for this
                      > function is needed.

                      Sorry again if you took offense to my choice of wording. There are
                      people who get on the defensive whenever someone with a differing
                      viewpoint engages in a discussion. No matter what is said after that,
                      the whole conversation turns into a war of words without anyone taking
                      the time to read the words to understand the content. Arguments are a
                      good thing, you use them when debating a subject. Many people think
                      somehow that an argument must mean there's a fight going on, rather
                      than a reasoned discussion.

                      > Whether or not budlist was in the code before aprs, does not matter.

                      Well, it does matter for you, if you need to implement a BUDLIST as
                      the only way to deal with your issue. You will need to chose hardware
                      that supports BUDLIST.

                      > It is there in the UIDIGI software.

                      Yup, and in the Kantronics line as well. (Lynn, you're not crazy...
                      UIDIGI is a command in the Kantronics and also the Tasco modems {which
                      are used in the Kenwood and Alinco radios}) UIDIGI is also firmware
                      that can be loaded into a TNC2 style TNC as well. Some people don't go
                      to a lot of trouble to come up with good names for their software.
                      They reuse existing acronyms, or change them slightly, which leads to
                      confusion for those who aren't up on exactly what's out there.

                      > I hope you have a great day James!!

                      I hope you do as well, Angelo! I've already pulled down a TriBand HF
                      beam and 48 foot tower for a local ham this morning, mowed the lawn,
                      and moved the fish from the indoor tank to the outdoor fish pond. I'm
                      hoping spring has sprung! Unfortunately my wife has about 200 more
                      jobs hiding in wait for me...

                      Have fun with APRS, and I hope your troublesome user takes the time to
                      learn a little more about APRS and proper etiquette. That would be a
                      bonus for all users in the area.

                      Lynn, the Tasco Modem does not support a BUDLIST feature. And Angelo,
                      there are a number of Kenwood radios that I know of that are being
                      used as digipeaters in traditional digipeater installations. The
                      Pacific Northwest Group around Seattle use a number of them as dual
                      band/dual speed digipeaters. The internal TNC is configured to operate
                      as a VHF or UHF 9k6 baud digipeater, and then they hang an external
                      TNC off the radio and have that operate on VHF at 1k2 on 144.390. They
                      work fairly well even though the limitations of the radio only allow
                      for one transmitter to be keyed at a time. And then if you consider
                      that every D710 comes out of the factory configured as a digipeater,
                      there are literally thousands of Kenwood radios being driven around
                      the country every day configured as a digipeater. Most users don't
                      even realize they are running a digipeater.

                      --
                      James
                      VE6SRV
                    • Scott Miller
                      If I do get a chance to implement it, it s not going to be a block list. My plan is to add script functions to test incoming packets for range, callsign,
                      Message 10 of 21 , May 26, 2014
                      • 0 Attachment
                        If I do get a chance to implement it, it's not going to be a block list.
                        My plan is to add script functions to test incoming packets for range,
                        callsign, sector, and so forth, and make digipeating decisions based on
                        those inputs. You could code a short script to exclude digipeating from
                        named stations, but I'm not implementing the traditional sense of a BUDLIST.

                        Scott

                        On 5/24/2014 9:22 AM, 'Lynn W. Deffenbaugh (Mr)' ldeffenb@...
                        [tracker2] wrote:
                        > Just because a function is available on one platform (UIDIGI which I
                        > thought was a command in the KPC TNC series, not particularly
                        > user-oriented "software"), doesn't mean that another platform is
                        > required to implement it (the T3-135 in this case). Different platforms
                        > have different capabilities and constraints. Choose the one with the
                        > features you need and run with it. Or ask for a change, but demanding a
                        > feature on a new platform just because "we had it on the old platform"
                        > won't necessarily get you satisfaction, and may be impossible to deliver.
                        >
                        > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                        >
                        > PS. Just as an aside, do Kenwood APRS radios with internal TNC with
                        > digipeater capabilities provide a Budlist-type filter function?
                        >
                        >
                        > On 5/24/2014 11:26 AM, n5uxt@... [tracker2] wrote:
                        >> James, I appreciate your continued drilling of what I have done or
                        >> have not done, but the facts are the same. Crazy or not ( I would
                        >> never use wording like crazy ) the need for this function is needed.
                        >> Whether or not budlist was in the code before aprs, does not matter.
                        >> It is there in the UIDIGI software.
                        >>
                        >> I hope you have a great day James!!
                        >>
                        >>
                        >
                        >
                      • n5uxt
                        controversy. It was not my intention. Like other have stated it is much easier to educate, but you need to be willing to listening. HI HI. Once again, thanks
                        Message 11 of 21 , Jun 3, 2014
                        • 0 Attachment

                          controversy. It was not my intention. Like other have stated it is much easier to educate, but you need to be willing to listening. HI HI.

                           

                           Once again, thanks for your effort and help.

                           

                          73 de Angelo

                           


                        • James Ewen
                          On Tue, Jun 3, 2014 at 10:37 AM, n5uxt@hotmail.com [tracker2] ... Maybe send a care package with soap and water to his house so he can clean his ears out! :)
                          Message 12 of 21 , Jun 3, 2014
                          • 0 Attachment
                            On Tue, Jun 3, 2014 at 10:37 AM, n5uxt@... [tracker2]
                            <tracker2@yahoogroups.com> wrote:

                            > Like other have stated it is much easier to educate, but you need to
                            > be willing to listening. HI HI.

                            Maybe send a care package with soap and water to his house so he can
                            clean his ears out! :)


                            --
                            James
                            VE6SRV
                          Your message has been successfully submitted and would be delivered to recipients shortly.