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

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

Expand Messages
  • ve7did
    Did some more testing tonight and hooked up one radio to 2 tnc s and got some interesting results. I was only looking at stuff off air as that was the
    Message 1 of 7 , Feb 4, 2009
      Did some more testing tonight and hooked up one radio to 2 tnc's and
      got some interesting results. I was only looking at stuff off air as
      that was the simplest to do at the time.

      The commercial radios I am using were running rx from the
      discriminator were there is noise all the time. Basically I just
      listened to signals for a fixed period of time and counted the packets
      on the screen. A bit laborious but it worked. I won't give all the
      results but here are some.

      I did have a pk-96 and a kpc3 connected up first and the packets were
      within 2 or 3 out of 150. So I used the pk-96 as the reference for
      the rest. This was over a period of time of 15 minutes.

      So here is the results of the Motorola radio:
      Eq IN pk-96 184 tracker2 128 15 minutes
      Eq OUT pk-96 115 tracker2 48 10 minutes

      Changed radios to an ICOM2720
      Eq OUT Icom 117 tracker2 95 10 minutes

      I tried various combination's of eq IN/OUT, changing to 9.6 connector,
      changing to setup to 9.6/1.2 and results were all roughly the same.

      But the big difference was the NO (RF) signal audio levels coming from
      the different radios with the Icom having a very low level of audio
      with no RF coming in, whereas the Motorola radio had very high noise
      levels up the order of 8 volts P-P. When the actual audio was present
      the level was 1.0v P-P

      So I went back and put the Motorola radio back to squelched audio and
      success. Here are the results. I cut the time back to 5 minutes
      because I was getting tired of waiting.

      So here are the results of the Motorola radio:
      Eq IN pk-96 32 tracker2 29 5 minutes
      Eq IN pk-96 35 tracker2 27 5 minutes

      Eq OUT pk-96 60 tracker2 55 5 minutes
      Eq OUT pk-96 41 tracker2 38 5 minutes

      So the PK-96/KPC3 is still a bit better, but not like it was before.

      I guess the bottom line is that the tracker 2 does not like high noise
      on the input, when no signal is present, as it must mess up the
      filters when the proper signal comes along.

      Hope all this makes sense, still doesn't explain the lousy performance
      of the ICOM radio (never liked this radio anyways!!!)


      ...73 Tom ve7did







      --- In tracker2@yahoogroups.com, "ve7did" <ve7did@...> wrote:
      >
      > 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
      > > > > >
      > > > > >
      > > > >
      > > >
      > > >
      > >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.