home    builders  

builders ➜ Debug A Poor Link

Debug A Poor Link

Pardon the lack of organization here. This page will need polishing.

There are many things which can compromise a link.

The way digital receivers behave is disconcerting in that they can be on the threshold of failure, yet behave perfectly. Then when they cross the threshold into failure, they fail completely, only to recover all by themselves. This can happen on a several‑second cycle; or minutes; or hours; or entire seasons.
To a human brain this is akin to having a great big suspension bridge across a river be there one day, missing completely for a couple of hours the next day, then suddenly re-appear after lunch.
Well, we're talking about radio here. If this was voice radio, we'd be able to understand signals that were rough to here but were still useable. They'd dip into being really rough once in a while. Being gone completely for a short period is just not natural, it would seem.

Steps to debug a link:

  1. Verify the routes and port numbers on each side.
  2. With the receiver driving a speaker on one side, have the other transmit a signal. It should be full quieting. Repeat with the other direction.
  3. Set up a monitor receiver to listen to both ends at the same time. The receive signal from the distant station need not be full quieting to the monitor receiver, you just have to be able to hear the entire packets from the other end.
  4. Verify that the TXDELAY leaves an audible lead-in tone from each station to your monitor receiver. Set the TXDELAY long, just to make sure.
  5. Run BPQterm on each end.
  6. Set the transmit audio on each end such that the audio is not distorted on a a local monitor receiver.
  7. Do password on each end and set these parameters -- replace # with the port number:
    On both ends do frack # 5
    On the receive end:
    retries # 1
    On the transmit end:
    retries # 150
    What this will do is silence the link for normal traffic, and make the transmit test end generate consistant connect requests every several seconds for minutes.
    Note: When you are done, set the retries back to 20 and the frack back to 12.
  8. Send packets from one end, using c # x1xxx    where # is the port number. Set the receive audio level at the other end to minimum and then walk it up until you see the DCD light come on. Now bring the audio to the maximum where the DCD light comes on. Now set the receive audio in the middle of that range.
  9. Repeat on the other end
  10. Observe the BPQterm monitoring the link. On the other end of the link start a transmit cycle connecting to a non-existant callsign, as above, but now observe the timing of the transmits. At the receive end watch for packets which do not show on the BPQterm by looking for gaps in the expected traffic. You should be able to listen to the other end transmit and know if there are any changes in the period between packets. Fine tune the receiver's volume knob to optimize until no packets are missed.
  11. Repeat in the other direction
  12. Connect to both ends of the link and grab the current numbers from R R for the link you are working on.
  13. Now connect to the far end, connect back, connect out, back, out, back. Now do a STATS command.
  14. Listen to the exchanges and verify that there are no times of dead air until the STATS is fully received at your end
  15. Use BPQterm's monitor window to verify that every transmit has a response. See whose messages are being sent but not being received at the other end.
  16. Observe the INFO-frames sent value vs the INFO-frames-retried value. Compare against the starting value. You can use these values from both ends and identify which side is having difficulty sending to the other.
  17. There are still several things that can go wrong, including multi-path distortion. The clue that there is multipath is that the received signal from the other end of the link sounds distorted, but when listend to at the transmit end, is not distorted. Multipath can be caused by having a reflection which is as good as the direct path. It can be exacerbated by badly aimed directional antennas, or a major RF attenuator or hill directly in line between the two sites. If the antennas can't be moved or improved, the best thing to do is to change frequencies or even bands between the sites.
  18. If you do get it to work well, set the TXDELAY down to where it the lead-in is noticeable but not finicky short and not tedious.

to be continued

© Tadd Torborg, 2016↝2017 -- all rights reserved