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

Interoperability of FoxTrak tracker and Argent Data’s OT3

Expand Messages
  • owenvk
    I have observed recently that two Foxtraks were not decoded by OT3s and OT-USB that should have decoded them. To futher expore the problem, I pulled about
    Message 1 of 12 , Aug 6, 2014
    • 0 Attachment
      I have observed recently that two Foxtraks were not decoded by OT3s and OT-USB that should have decoded them.

      To futher expore the problem, I pulled about 16,000 records from APRS-IS and looked for evidence that a Foxtrak had been received by any OT device, and I did not find any though I know that at least two should have been decoded by at least four OT devices over some hours. Note that absence of evidence of decoding is not proof of incompatibility, but evidence of decoding would be proof that there is not absolute incompatibility.

      I am aware of the frailties and pitfalls of the above method, but it is consistent with my direct tests of Foxtrack with OT3 and OT-USB.

      One expert has advised that because Foxtraks are so popular, just dont use OTx for infrastructure.

      It is intriguing that I did find evidence of TinyTrak decoded by OTx, but they may not have been early TT. Certainly my tests with OTx on my Foxtrak with DK7IN, aprstracker and TT(1) firware all failed.

      I also monitored the traffic on a dedicated channel from a Foxtrak with a T3-135 using PASSALL and it was all jibberish, there was not even short strings of recognisable text. That suggests to me that there is a failure to decode the raw data stream.

      Nevertheless, I am interested in solving the problem if it is reasonably feasible.

      So, next step is to try and further isolate the problem.

      Thoughts include that the incompatibility might be related to clock recovery, data recovery, or packet contents.

      I am thinking of capturing the packets from a Foxtrak (as binary data) from a KISS TNC, then playing it back through a non-OT TNC to see if a OT TNC decodes it. That might indicate whether it is modulation related for packet content related.

      I don't want to repeat work already done.

      Has someone got relevant information, am I heading down the wrong track (pardon the pun).

      Owen
    • Matthew Cook
      Owen, Start with the source of the problem and then work outwards. The OT devices on your network can decode other signals but not the Foxtracks, ask why
      Message 2 of 12 , Aug 6, 2014
      • 0 Attachment
        Owen,

        Start with the source of the problem and then work outwards.  The OT devices on your network can decode other signals but not the Foxtracks, ask why first.
        • You need to confirm that the FoxTrack tones are not over driving the mic input of your radio... be careful here since there are pre-amps, clippers and pre-emphasis circuits there that can trip you up; here's a useful reference http://www.febo.com/packet/layer-one/transmit.html
        • Both of the tones out of the Foxtrack need to be of equal amplitude, clean and free of high levels of harmonics; don't rely on the microphone preamp and clipper in your transmitter to clean up a crappy waveform.  If necessary filter it yourself, one resistor and one cap set the corner freq to 2.5kHz.
        • Now take a second receiver and on another frequency look at what the tones your Foxtrack is sending actually look like, they should likewise be of equal amplitude, clean and free from distortion, if they are not then focus your investigation here; why?
        • Try your foxtrack with another transmitter, some cheap and cheerful Chinese made radios have a host of problems with their audio path that make them completely useless for use with APRS especially those that are SDR one-chip wonders.
        Now you are aware that packet signals weren't supposed be fed through pre-emphasis and de-emphasis circuits?   Provided that all radios on a APRS network use pre-emphasis and de-emphasis you're generally ok, the tone levels shouldn't be changed *much*, however problems come when everyone is doing something different. 

        For your reference *all* of the Kenwood APRS gear ie D700 & D710 use flat audio, no pre/de-emphasis; this makes life interesting.  In times gone past tones from TNC's were de-emphasised *before* sending into radios where the mic preamp and pre-emphasis circuits couldn't be bypassed.

        However in  a nutshell this depends entirely upon your local packet/APRS network as to what works best.  So if in doubt get out on the repeaters, find your local APRS network operator and ask :)

        We are lucky here where I live that the majority of our APRS digis and iGates in our area use MFJ1270b demodulators, these don't seem to care much if the tones are equal (flat audio) or unequal (pre-emphasised).  You won't be able to work this out looking at APRS.fi data.

        I also use OT devices exclusively in all of my setups as trackers, digi's, sGates and iGates.  We don't generally see any foxtracks in our network, so I have never seen your problem first hand.  However some of the early byonics stuff gave many people *alot* of problems, it was always traced back to the setup of the radio and the modulated tones. YMMV.

        73's

        Matthew
        VK5ZM

        On 7 August 2014 07:59, owenvk@... [tracker2] <tracker2@yahoogroups.com> wrote:
         

        I have observed recently that two Foxtraks were not decoded by OT3s and OT-USB that should have decoded them.

        To futher expore the problem, I pulled about 16,000 records from APRS-IS and looked for evidence that a Foxtrak had been received by any OT device, and I did not find any though I know that at least two should have been decoded by at least four OT devices over some hours. Note that absence of evidence of decoding is not proof of incompatibility, but evidence of decoding would be proof that there is not absolute incompatibility.

        I am aware of the frailties and pitfalls of the above method, but it is consistent with my direct tests of Foxtrack with OT3 and OT-USB.

        One expert has advised that because Foxtraks are so popular, just dont use OTx for infrastructure.

        It is intriguing that I did find evidence of TinyTrak decoded by OTx, but they may not have been early TT. Certainly my tests with OTx on my Foxtrak with DK7IN, aprstracker and TT(1) firware all failed.

        I also monitored the traffic on a dedicated channel from a Foxtrak with a T3-135 using PASSALL and it was all jibberish, there was not even short strings of recognisable text. That suggests to me that there is a failure to decode the raw data stream.

        Nevertheless, I am interested in solving the problem if it is reasonably feasible.

        So, next step is to try and further isolate the problem.

        Thoughts include that the incompatibility might be related to clock recovery, data recovery, or packet contents.

        I am thinking of capturing the packets from a Foxtrak (as binary data) from a KISS TNC, then playing it back through a non-OT TNC to see if a OT TNC decodes it. That might indicate whether it is modulation related for packet content related.

        I don't want to repeat work already done.

        Has someone got relevant information, am I heading down the wrong track (pardon the pun).

        Owen


      • owenvk
        Mathew, do you have an authorative reference for your statement Now you are aware that packet signals weren t supposed be fed through pre-emphasis and
        Message 3 of 12 , Aug 7, 2014
        • 0 Attachment
          Mathew, do you have an authorative reference for your statement "Now you are aware that packet signals weren't supposed be fed through pre-emphasis and de-emphasis circuits?"

          Owen
        • Kenneth Finnegan
          On Thu, Aug 7, 2014 at 3:20 PM, owenvk@yahoo.com.au [tracker2]
          Message 4 of 12 , Aug 7, 2014
          • 0 Attachment
            On Thu, Aug 7, 2014 at 3:20 PM, owenvk@... [tracker2] <tracker2@yahoogroups.com> wrote:

            Mathew, do you have an authorative reference for your statement "Now you are aware that packet signals weren't supposed be fed through pre-emphasis and de-emphasis circuits?"

            Considering how much time and effort I've put into finding this as part of my MS thesis, I can authoritatively say that such a source does not in fact exist. I haven't been able to prove that it's correct, but it's the least-wrong deviation target...

            The problem is better stated that in the ideal world, the entire audio pathway from modem to modem would be flat, but reality is far from that. pre-/de-emphasis is the most concrete source of level distortion, but I've seen microphone input and detector output impedance mismatches cause 3-8dB of difference between the two tones.

            Our modems are WAY too sensitive to these differences. Insert rant about [specific device]'s utter inability to deal with [subset of possible distortions].

            I've actually got a pending paper mentioning this for the ARRL Digital Comms Conference, but for some reason they haven't posted my paper yet... https://www.tapr.org/pub_dcc33.html Anyone interested can ping me off-list for a copy.

            --
            Kenneth Finnegan, W6KWF
            http://blog.thelifeofkenneth.com/
             
          • Scott Miller
            The demodulator code in the T3 is not the best at handling twist. The versions of the T2 that had an MX614 did better. If anyone s got any readily applicable
            Message 5 of 12 , Aug 7, 2014
            • 0 Attachment
              The demodulator code in the T3 is not the best at handling twist. The
              versions of the T2 that had an MX614 did better. If anyone's got any
              readily applicable coding suggestions, I'd be happy to hear them.

              I've been absent from the forums and behind on email and it's likely to
              stay that way for a few weeks. I've got a major tracker project to
              finish in the next two weeks, and I recently launched a non-ham product
              that unexpectedly took off. I'm spending 14 hours a day in the shop and
              Igor has come back part time to help with the load but things are still
              falling behind.

              Feel free to continue the discussion and I'll try to catch up when I'm able.

              Scott

              On 8/7/2014 5:12 PM, Kenneth Finnegan KennethFinnegan2007@...
              [tracker2] wrote:
              > On Thu, Aug 7, 2014 at 3:20 PM, owenvk@...
              > <mailto:owenvk@...> [tracker2] <tracker2@yahoogroups.com
              > <mailto:tracker2@yahoogroups.com>> wrote:
              >
              > Mathew, do you have an authorative reference for your statement "Now
              > you are aware that packet signals weren't supposed be fed through
              > pre-emphasis and de-emphasis circuits?"
              >
              > Considering how much time and effort I've put into finding this as part
              > of my MS thesis, I can authoritatively say that such a source does not
              > in fact exist. I haven't been able to prove that it's correct, but it's
              > the least-wrong deviation target...
              >
              > The problem is better stated that in the ideal world, the entire audio
              > pathway from modem to modem would be flat, but reality is far from that.
              > pre-/de-emphasis is the most concrete source of level distortion, but
              > I've seen microphone input and detector output impedance mismatches
              > cause 3-8dB of difference between the two tones.
              >
              > Our modems are WAY too sensitive to these differences. Insert rant about
              > [specific device]'s utter inability to deal with [subset of possible
              > distortions].
              >
              > I've actually got a pending paper mentioning this for the ARRL Digital
              > Comms Conference, but for some reason they haven't posted my paper
              > yet... https://www.tapr.org/pub_dcc33.html Anyone interested can ping me
              > off-list for a copy.
              >
              > --
              > Kenneth Finnegan, W6KWF
              > http://blog.thelifeofkenneth.com/
              >
              >
            • Lynn W. Deffenbaugh (Mr)
              I m sure you ve all read it, but this is the page that I find the most informative about the pre/de-emphasis issue. And I m still trying to figure out why my
              Message 6 of 12 , Aug 7, 2014
              • 0 Attachment
                I'm sure you've all read it, but this is the page that I find the most informative about the pre/de-emphasis issue.

                And I'm still trying to figure out why my T3-135 isn't copied by the local digipeater nearly as well as my D700 is, but I suspect it's got something to do with the TNC/radio connections at the digipeater itself.

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


                On 8/7/2014 8:12 PM, Kenneth Finnegan KennethFinnegan2007@... [tracker2] wrote:
                On Thu, Aug 7, 2014 at 3:20 PM, owenvk@... [tracker2] <tracker2@yahoogroups.com> wrote:

                Mathew, do you have an authorative reference for your statement "Now you are aware that packet signals weren't supposed be fed through pre-emphasis and de-emphasis circuits?"

                Considering how much time and effort I've put into finding this as part of my MS thesis, I can authoritatively say that such a source does not in fact exist. I haven't been able to prove that it's correct, but it's the least-wrong deviation target...

                The problem is better stated that in the ideal world, the entire audio pathway from modem to modem would be flat, but reality is far from that. pre-/de-emphasis is the most concrete source of level distortion, but I've seen microphone input and detector output impedance mismatches cause 3-8dB of difference between the two tones.

                Our modems are WAY too sensitive to these differences. Insert rant about [specific device]'s utter inability to deal with [subset of possible distortions].

                I've actually got a pending paper mentioning this for the ARRL Digital Comms Conference, but for some reason they haven't posted my paper yet... https://www.tapr.org/pub_dcc33.html Anyone interested can ping me off-list for a copy.

                --
                Kenneth Finnegan, W6KWF
                http://blog.thelifeofkenneth.com/
                 

              • Lynn W. Deffenbaugh (Mr)
                Oops: http://www.febo.com/packet/layer-one/transmit.html Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32 On 8/7/2014 9:28 PM, Lynn W.
                Message 7 of 12 , Aug 7, 2014
                • 0 Attachment
                  Oops:

                  http://www.febo.com/packet/layer-one/transmit.html

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

                  On 8/7/2014 9:28 PM, 'Lynn W. Deffenbaugh (Mr)' ldeffenb@... [tracker2] wrote:
                  I'm sure you've all read it, but this is the page that I find the most informative about the pre/de-emphasis issue.

                  And I'm still trying to figure out why my T3-135 isn't copied by the local digipeater nearly as well as my D700 is, but I suspect it's got something to do with the TNC/radio connections at the digipeater itself.

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


                  On 8/7/2014 8:12 PM, Kenneth Finnegan KennethFinnegan2007@... [tracker2] wrote:
                  On Thu, Aug 7, 2014 at 3:20 PM, owenvk@... [tracker2] <tracker2@yahoogroups.com> wrote:

                  Mathew, do you have an authorative reference for your statement "Now you are aware that packet signals weren't supposed be fed through pre-emphasis and de-emphasis circuits?"

                  Considering how much time and effort I've put into finding this as part of my MS thesis, I can authoritatively say that such a source does not in fact exist. I haven't been able to prove that it's correct, but it's the least-wrong deviation target...

                  The problem is better stated that in the ideal world, the entire audio pathway from modem to modem would be flat, but reality is far from that. pre-/de-emphasis is the most concrete source of level distortion, but I've seen microphone input and detector output impedance mismatches cause 3-8dB of difference between the two tones.

                  Our modems are WAY too sensitive to these differences. Insert rant about [specific device]'s utter inability to deal with [subset of possible distortions].

                  I've actually got a pending paper mentioning this for the ARRL Digital Comms Conference, but for some reason they haven't posted my paper yet... https://www.tapr.org/pub_dcc33.html Anyone interested can ping me off-list for a copy.

                  --
                  Kenneth Finnegan, W6KWF
                  http://blog.thelifeofkenneth.com/
                   


                • owenvk
                  I am interested to read your paper... but I cannot find your email address. (Mine is on QRZ.com.) I also have searched for standards documentation for the
                  Message 8 of 12 , Aug 8, 2014
                  • 0 Attachment
                    I am interested to read your paper... but I cannot find your email address. (Mine is on QRZ.com.)

                    I also have searched for 'standards' documentation for the physical layer, but not been successful... hence the reason for asking for a reference for a quite strong statement re pre/de-emphasis usage.

                    In my view, a flat channel end to end is needed, and that does not preclude the use of pre/de-emphasis, but it does preclude a mixed channel where pre/de-emphasis is implemented at one end only.

                    No link is perfectly flat, in my experience radio manufacturers fiddle the audio response to enhance the sensititivity specs.

                    I tested two radios recently to find why one was kinder to grossly overdriven AFSK signals.

                    The receivers were measured to evaluate the accuracy of the de-emphasis circuit. The test was performed with a FM signal of 3kHz deviation and modulating frequencies of 2kHz and 1kHz, and the audio output voltage for each was read and the de-emphasis calculated:

                    • Icom IC-2200H – 7.2dB
                    • Yaesu FT-2800M – 4.3dB

                    The de-emphasis should be 6dB, the Icom is over de-emphasised 1.2dB over the octave, and the Yaesu under de-emphasised 1.7dB over the octave, about 3dB less than the Icom over an octave.


                    There is a measurable difference in the receivers, and an observable one as the FT-2800M is kinder to overdriven AFSK signals (and most are in my experience).




                    Owen
                  • owenvk
                    Mathew said The OT devices on your network can decode other signals but not the Foxtracks, ask why first.Well, a more complete question is why everything
                    Message 9 of 12 , Aug 14, 2014
                    • 0 Attachment
                      Mathew said " The OT devices on your network can decode other signals
                      but not the Foxtracks, ask why first."
                      
                      Well, a more complete question is why everything else I have tried but
                      OT devices reliably decode the Foxtrak, and the OT devices reliably
                      decode everthing else I have tried except the Foxtrak (with three
                      different types of firmware including TT1).
                      
                      In all tests, transmitters were adjusted for 3kHz devn at 2200Hz (well
                      below limiter threshold), and pre-emphasis checked to be within 2dB, my
                      own receive tests were always with pre-emphasis (error < 2dB) except for
                      the T-135 which I measured no pre-emphasis in tx and I suspect no
                      de-emphasis on rx. I have no knowledge of how network OTx devices were
                      configured.
                      
                      Notably in the mix of everything I have tried is a TT3+ which is the
                      same hardware as the Foxtrak, same parts in the waveform generation, but
                      different firmware.
                      
                      So there is clearly an interoperability problem, but I would not point a
                      finger at the OT devices or Foxtrak, as the Foxtrak may or may not be
                      out of Bell202 spec, but a bunch of modem chips in TNCs I have (VK6
                      Flash TNC (AM7910), TNC-X (MX-615), Tiny2Mk2 (TCM3105), MFJ-1270B
                      (XR2206)) decode FoxTrak reliably.
                      
                      I think that what emerges from measurements and observations so far is
                      that if you want to install infrastructure such as a digi or even an
                      iGate and you want to decode Foxtrak and TT1, some OT devices have a
                      problem.
                      
                      That the TT3+ works better is an indication that more can be done with
                      the hardware than the three types of firmware I tried in the FoxTrak
                      manage. If you were biased, you might cite that as proof that problems
                      are entirely in the FoxTrak, but on balance, all the other modem chip
                      style TNCs tolerate FoxTrak/TT1 and that is to their advantage.
                      
                      Owen
                      
                    • Matthew Cook
                      Owen, I ve an ancient copy of The Hitchhikers Guide to Packet Radio sitting here on the shelf. This was the beez knees back in the late 90 s when packet
                      Message 10 of 12 , Aug 17, 2014
                      • 0 Attachment
                        Owen,

                        I've an ancient copy of "The Hitchhikers Guide to Packet Radio" sitting here on the shelf.  This was the beez knees back in the late 90's when packet radio in it's hey day.  You might find a copy in a local radio club there somewhere.

                        Regards

                        Matthew
                        VK5ZM


                        On 8 August 2014 07:50, owenvk@... [tracker2] <tracker2@yahoogroups.com> wrote:
                         

                        Mathew, do you have an authorative reference for your statement "Now you are aware that packet signals weren't supposed be fed through pre-emphasis and de-emphasis circuits?"

                        Owen


                      • Matthew Cook
                        I m curious from your observations if you have had the ability to go right back to basics and wire the modulators and demodulators directly i.e. taken the
                        Message 11 of 12 , Aug 17, 2014
                        • 0 Attachment
                          I'm curious from your observations if you have had the ability to go right back to basics and wire the modulators and demodulators directly i.e. taken the transmitter and receiver out of the equation?   It can also be helpful to switch in attenuators to get a rough idea of the SNR you require for the demodulator.  All of the tests I've done with OT's has been good so far.

                          Were you able to look at the received tones directly from your receivers demodulator, were they symmetrical or skewed?

                          Of all the demodulators I've used and designed in the past 20 years the XR2206 is the most forgiving, you can throw complete rubbish at them and they will generally demodulate something.  The others were never that forgiving.  I have a similar test line up except my AM7910 is in TAPR 220+.

                          To date we've been lucky with our local APRS network to have not had many interoperability issues, for the reasons I've already explained.  I wish you luck finding the source of the problems with your Foxtrack boards.

                          73's

                          Matthew
                          VK5ZM

                          On 14 August 2014 16:46, owenvk@... [tracker2] <tracker2@yahoogroups.com> wrote:
                           

                          Mathew said " The OT devices on your network can decode other signals
                          but not the Foxtracks, ask why first."
                          
                          Well, a more complete question is why everything else I have tried but
                          OT devices reliably decode the Foxtrak, and the OT devices reliably
                          decode everthing else I have tried except the Foxtrak (with three
                          different types of firmware including TT1).
                          
                          In all tests, transmitters were adjusted for 3kHz devn at 2200Hz (well
                          below limiter threshold), and pre-emphasis checked to be within 2dB, my
                          own receive tests were always with pre-emphasis (error < 2dB) except for
                          the T-135 which I measured no pre-emphasis in tx and I suspect no
                          de-emphasis on rx. I have no knowledge of how network OTx devices were
                          configured.
                          
                          Notably in the mix of everything I have tried is a TT3+ which is the
                          same hardware as the Foxtrak, same parts in the waveform generation, but
                          different firmware.
                          
                          So there is clearly an interoperability problem, but I would not point a
                          finger at the OT devices or Foxtrak, as the Foxtrak may or may not be
                          out of Bell202 spec, but a bunch of modem chips in TNCs I have (VK6
                          Flash TNC (AM7910), TNC-X (MX-615), Tiny2Mk2 (TCM3105), MFJ-1270B
                          (XR2206)) decode FoxTrak reliably.
                          
                          I think that what emerges from measurements and observations so far is
                          that if you want to install infrastructure such as a digi or even an
                          iGate and you want to decode Foxtrak and TT1, some OT devices have a
                          problem.
                          
                          That the TT3+ works better is an indication that more can be done with
                          the hardware than the three types of firmware I tried in the FoxTrak
                          manage. If you were biased, you might cite that as proof that problems
                          are entirely in the FoxTrak, but on balance, all the other modem chip
                          style TNCs tolerate FoxTrak/TT1 and that is to their advantage.
                          
                          Owen
                          

                        • Matthew Cook
                          Kennith I d also like to read your paper, you can find my email address on QRZ.com also. I think that many people overlook a very subtle point regarding
                          Message 12 of 12 , Aug 17, 2014
                          • 0 Attachment
                            Kennith I'd also like to read your paper, you can find my email address on QRZ.com also.

                            I think that many people overlook a very subtle point regarding pre-emphasis and de-emphasis circuits; 

                            Question:  what else do they introduce other than level distortion that is frequency dependent?

                            So why when you take the sum of all of this mysterious factor from modulator to demodulator at both of your tone frequencies would you care?

                            The other clue is the original Bell-202 standard went into great pains to discuss things like level, tone frequency error, symmetry and twist.  It is helpful to understand what in a RF chain can cause each of these things to vary, including how the FM is being generated within the modulator (there are two methods one adds to the problem the other does not).

                            It's also sometimes helpful to find a copy of a commercial Land Mobile Radio (LMR) spec and then compare this to your amateur radio.  Why were the LMR radio specs more strict than any Ham transceiver ?  The answer isn't immediately obvious, but when you stop to think about this and realise what it is and why you have to control it, then my statement "Now you are aware that packet signals weren't supposed be fed through pre-emphasis and de-emphasis circuits?" might be more apparent.

                            I am sorry for deliberately being vague in my response above, but I was asked this same series of questions as a junior Engineer by my peers many many years ago.  It made me think for a while before the answer dawned.  I'd hate to give away the surprise.   YMMV.

                            73's

                            Matthew
                            VK5ZM


                            On 9 August 2014 05:44, owenvk@... [tracker2] <tracker2@yahoogroups.com> wrote:
                             

                            I am interested to read your paper... but I cannot find your email address. (Mine is on QRZ.com.)

                            I also have searched for 'standards' documentation for the physical layer, but not been successful... hence the reason for asking for a reference for a quite strong statement re pre/de-emphasis usage.

                            In my view, a flat channel end to end is needed, and that does not preclude the use of pre/de-emphasis, but it does preclude a mixed channel where pre/de-emphasis is implemented at one end only.

                            No link is perfectly flat, in my experience radio manufacturers fiddle the audio response to enhance the sensititivity specs.

                            I tested two radios recently to find why one was kinder to grossly overdriven AFSK signals.

                            The receivers were measured to evaluate the accuracy of the de-emphasis circuit. The test was performed with a FM signal of 3kHz deviation and modulating frequencies of 2kHz and 1kHz, and the audio output voltage for each was read and the de-emphasis calculated:

                            • Icom IC-2200H – 7.2dB
                            • Yaesu FT-2800M – 4.3dB

                            The de-emphasis should be 6dB, the Icom is over de-emphasised 1.2dB over the octave, and the Yaesu under de-emphasised 1.7dB over the octave, about 3dB less than the Icom over an octave.


                            There is a measurable difference in the receivers, and an observable one as the FT-2800M is kinder to overdriven AFSK signals (and most are in my experience).




                            Owen




                            --
                            Matthew
                            VK5ZM
                            0487 653 245
                          Your message has been successfully submitted and would be delivered to recipients shortly.