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

6358Re: Transmit(encode)/Receive(decode) performance

Expand Messages
  • ve7did
    Feb 4, 2009
    • 0 Attachment
      Thanks for the info Mark. I will give it a go in the next little
      while. I do have a service monitor. What I was thinking of doing was
      using your audio file(s) into the service monitor. For the output I
      was thinking about using one receiver and hooking 2 tnc's in parallel
      and watching the outputs. Will have to make sure there is not loading
      problem, but should be ok.
      I am using linux with ax25 and have 2 ports which can be simultaneous
      monitored using 2 terminal screens on the monitor. This is what I was
      doing before but using 2 receivers. This will eliminate a variable.
      I am using the tracker2 & other tnc's in kiss mode.

      I can actually do some live off-air as well to see what the real world
      will show.

      Gotta get to the bottom of this as I really like the tracker2.

      ...73 Tom

      --- In tracker2@yahoogroups.com, Mark Cheavens <mcheavens@...> wrote:
      >
      > Tom,
      > Do you have a service monitor?
      >
      > I have seen many of the ways others "test" receive performance, but
      > it is too seat of my pants for me.
      >
      > Years ago I built two wave files that are a series of packets
      > (Numbered 1 through 25). The first file is a FLAT packet data
      > straight out of a modulator IC. This is used to simulate the decode
      > performance of a "remote" radio with "FLAT" audio. (OR it can be used
      > into the MIC circuit for actually testing over the air out of a radio).
      >
      > The second file is a perfectly pre-emphasized 25 packets. (6db per
      > octave) This is what should "normally" be fed into the service
      > monitor since its output is flat.
      >
      > I feed each file OUT of a computer with a audio program that I can
      > "loop" so it keeps sending the same packets in a circular fashion.
      > You monitor the TNC through a normal terminal app.
      >
      > For those not aware:
      > AFSK (Audio Frequency Shift Keying) is what was originally specified
      > in the TAPR modems for 1200 baud packet. It was done to simplify
      > hookup to a "radio" since the microphone input get pre-emphasis
      > applied before transmitting and de-emphasized before coming out if
      the speaker.
      >
      > FSK (Frequency Shift Keying) is what was specified for 9600 baud packet.
      >
      > In MOST cases where I see problems with decode performance it is
      > related to "the other end" where the transmitting signal has serious
      > issues! Some modems handle those transmitter "problems" better than
      others.
      >
      > With those two files you can ACCURATELY predict JUST the decoder with
      > both "worst case - No pre-emphasis", or "perfect" signals. You can
      > vary both the signal to noise level with a given receiver by changing
      > the attenuator AND by changing the modulation level.
      >
      > When I build Digi's I build and optimize EACH package and record the
      > results in the log book so I can test later to see if the given site
      > has a radio/tnc problem, or something else.
      >
      > The two files mentioned can be found on my web site at:
      > http://www.cheavens.com/mark/radio/
      > (bottom of the page)
      >
      > I have NOT mapped or done this to my T2-135 (YET).
      >
      > Now that all my cable and install "package" is completed and working
      > as I want, the TX and RX levels and performance will be judged.
      >
      > I DO plan on increasing the deviation "range" of the slider (Mine
      > won't go over 2.9khz deviation) on my MKIII, and the audio does not
      > meet "spec" as it has too little pre-emphasis (intentionally done by
      > Scott - and I understand why). I will also look at the receive
      performance.
      >
      > Mine has only been hooked to a load while building the cables. I did
      > notice the TX level issue when I originally installed the T2-135 in
      > the radio, but the level issue got moved to the "back burner" while I
      > worked on the GPS and "single cable" solution.
      >
      > Mark
      > KC5EVE
      >
      > At 12:11 AM 2/3/2009, you wrote:
      >
      > >Scott: Still being doing some testing in kiss mode and still can't
      > >put my finger on why the receive on the tracker2 does not match up to
      > >either a kpc3+ or a pk-96. I have checked the signal levels going in
      > >and they are within your specs you mentioned. The rx led flashes but
      > >no decode (or data going to the computer).
      > >I have done a side by side comparison with 2 identical commercial
      > >radios (Motorola mcx100's with open squelch)and watched the decoding
      > >and the tracker2 is still missing quite a few packets. I'm watching on
      > >the aprs channel on 144.390 which is quite busy. I realize the
      > >incoming signals are not perfect all of the time, but the other tnc's
      > >just seem to catch a lot more packets than the tracker2. I have
      > >switched radios around as well as antennas to try and figure out what
      > >is going on and I hate to say it but it always seems to end up with
      > >the tracker2.
      > >
      > >Do you have any suggestions which I can try to resolve this
      predicament?
      > >
      > >Have you done any comparison tests with other tnc's?
      > >
      > >...73 Tom ve7did
      > >
      > >--- In <mailto:tracker2%40yahoogroups.com>tracker2@yahoogroups.com,
      > >Scott Miller <scott@> wrote:
      > > >
      > > > I've only got Mk II units here. I haven't seen any correlation yet
      > > > between model and RX performance.
      > > >
      > > > The OT2m has a clipping circuit very much like the KPC-3's. With the
      > > > fixed level from the DR-135, though, shouldn't be necessary.
      > > >
      > > > Scott
      > > >
      > > > Mark Cheavens wrote:
      > > > >
      > > > >
      > > > > Scott,
      > > > > After reading the notes recently about receive variability I am
      > > > > curious if you have tested the receive performance on different
      > > > > versions of the DR-135.
      > > > >
      > > > > There are now three distinct versions (that I know of).
      > > > >
      > > > > The latest one is significantly different.
      > > > >
      > > > > I have access to an early and late model one that I can do testing
      > > > > with. (I have not done that yet!).
      > > > >
      > > > > I can also see some significant receive performance
      improvements that
      > > > > could be made in the circuit.
      > > > >
      > > > > (Look at the clipping / Squaring circuit in a KPC-3!)
      > > > >
      > > > > Mark
      > > > > KC5EVE
      > > > >
      > > > >
      > > >
      > >
      > >
      >
    • Show all 7 messages in this topic