Question on Serial Settings

[K3TN]

I've gotten a pair of RRCs working on the local LAN,  the goal is a PC-based Remote Control application. FT-1000 at the radio side, connected per the Yaeus section. On the Control side, a PC with no serial port, so USB to the Control RRC. The PC at the control end will run N1MM and/or Ham Radio Deluxe and need to control the and CW key the remote FT-1000.

To make that work, I will need to control PC to talk to the Radio CAT and to think there is Winkeyer at the radio end.

Tested all audio/CW/PTT functions on the local LAN, works fine with microphone and paddle connected to the Control RRC. Had the wrong (male to female) DB9 serial cable, so couldn't test the Radio RRC connection to the FT-1000 yet.

I'm confused about the serial settings beyond the 4800 8N2 for the Yaesu CAT. I am assuming COM 1 Mode 6 is correct, with Use USB Com Port for COM1? If so, would I then configure N1MM to use Com 1 for CAT of the remote radio?

Similar question for COM 2 serial setup: I assume I use Mode 6, and tell N1MM that Winkey is on COM2? And also set Use USB Com Port for COM@?

Any other settings needed I haven't listed?

Final question: the manual and setting mention Telnet and port 23 quite a bit, but the firewall/port forwarding section never mention putting in a rule for Telnet/port 23 - is such a rule required?

Thanks, John K3TN

[sm2o]

Hi

Connect the cables to com 2 then the the instructions are matching
Use program mode 3 (see manual Yaesu FT-8x FT-1k etc chapter) set 4800 baud 8 bits 2 stopbits no parity, also set "COM0 Program mode 3 char timeout = 60.
Set com2 to "logical parallell with com 0"
Set com1 to inactive to start with
in both units

73 de mike

[K3TN]

Thanks, Mike - Will try those settings. One question:

If I get the settings correct and the Control RRC has a data path to the Radio RRC, will the RRC status show RADIO: ON even if I don't have N1MM or other software yet running on the Control PC? Or do I need software to start trying to communicate that will then cause the status to show RADIO;ON?

Actually, another question: Telnet - if I don't  intend to use terminal mode, do I need to have port 23 forwarded? The RRC manual did not say to do so, so I currently do not have it opened up.

[sm2o]

No, the Radio ON is a hardware signal which will not change in  that setup.

You do not need telnet

/mike

[K3TN]

OK, followed those settings. Control RRC connects to Radio RRC and I hear RX audio and get a solid yellow LED on the Control RRC AUX/MIC jack.

However, the audio drops out many times per second - essentially more drop outs than audio. This is with Mode 1 for Audio Quality.

If I change to mode 0, no real improvement. If I change to mode 7, slightly worse.

An Internet speed test from the radio site shows 4.5Mbs download speed, 1.5 Mbs upload, ping time 53 ms, jitter 43 ms. Not sure about the jitter number, but bandwidth seems enough, no?

Status readings below.

What could be causing audio problems?


Control RRC Status:
Name   Value
Control panel   OFF
Radio   OFF
Connection status   OK
SIP status   Connected/transfering
Last SIP error   None
RTP status   Excellent(60)
UDP cmd status   OK(24)
SIP command timeout   0
Rx Jitter buffer size   4
Rx Jitter delay   3
Dual Rx   0
Current audio packet size   20
Current audio quality   1 - Linear 12 bits 8 kHz
SIP Out port   13000
SIP In port   13000
Audio Out port   13001
Audio In port   13001
Command Out port   13002
Command In port   13002
External SIP In port   13000
External Audio In port   13001
External Cmd In port   13002
Other party   208.72.79.36
Input 0   High
Input 1   High
Input 2   High
Output 0   High
Output 1   Low
Output 2   Low
DNS status   OK, remoterig.com = 193.202.110.185
Active profile:   K4VV FT1000
PTT status:   OFF


Radio RRC Status:
Name   Value
Radio   OFF
Connection status   OK
SIP status   Connected/transfering
Last SIP error   None
RTP status   Excellent(60)
UDP cmd status   OK(17)
SIP command timeout   0
Rx Jitter buffer size   4
Rx Jitter delay   3
Dual Rx   0
Current audio packet size   20
Current audio quality   1 - Linear 12 bits 8 kHz
SIP Out port   13000
SIP In port   13000
Audio Out port   13001
Audio In port   13001
Command Out port   13002
Command In port   13002
External SIP In port   13000
External Audio In port   13001
External Cmd In port   13002
Other party   173.73.28.110
Input 1   High
Input 2   High
Output 0   Low
Output 1   Low
Output 2   Low
Dynamic DNS status   Unknown
Ping status (watchdog)   Off
DNS status   OK, remoterig.com = 193.202.110.185
Active profile:   K4VV FT1000
PTT status:   OFF
Antenna-Switch (IP)   not connected

[sm2o]

You probably have a very bad connection then, maybe with lots of packet losses. Jitter can be handled by increasing jitter buffer size and Jitter buffer delay at the receiving RRC (see manual), but it can not recover lost packages so you have to find out where your connection problem is.

73 de mike

[K3TN]

The ISP to this site is a wireless ISP - there is no wired Internet to the site. Problems getting Mumble or Skype to work reliably over that connection was one of the drivers for trying out Remote Rig, but I understand the lost packet issue.

I changed the audio packet size to 40ms and that made dramatic improvements. I increased the jitter parameters and got more improvement, but if I went back to 20 ms packet size, not so good. I'm going to try increasing the jitter settings more.

So, a question or two about that:

1. Do the settings for those three parameters have to be the same on the Control and Radio RRCS? You seem to say can increase only at the Radio side, which makes sense.

2. My reading of the manual makes me believe Jitter buffer size is more important setting at the Radio RRC side and Jitter buffer delay is more important at the Control side, as far as receiving audio at the Control side. Am I correct? And the reverse would be true if there are drop out problems with mic audio from the Control side to the Radio side.

I will try to run a speed test that includes the packet loss statistics - I am afraid you may be right about that being the problem.

[sm2o]

The jitter buffer settings can be different in Control and Radio RRC, the buffering are only at the receiving end so you increase it in the end where you have problem. problems hen receiving = adjust @ Control end, Problems when transmitting = adjust  @  radio end.

changing from 20 ms packets to 40 ms reduce the packets sent by 50%. In cases of packet losses it may make improvments

/mike

[I4GAD Enrico]

Hi John,

I'm not sure this will help in your case, but audio interruptions are quite often caused by some wide band device (i.e. WEB Cams) on the LAN. At the beginning of my remoting experience, I suffered for such problem until I realize that my two Mobotix Web Cams use to upload a big screen shoot every minute into ftp site used for remote access to the images.
During the upload phase of the images (some ten of MB each), all the band was taken by that process and the audio of my remote rig was almost unacceptable for the heavy interrupions.
After reducing the frequency and the priority of the WEB Cams upload, the audio is now perfect even if my ADSL has limited performances (4/5 Mb download - 0.38 Mb upload) and I'm using a dual RX with an Elecraft twin setup.
Good luck and have fun with your remote rig !
Enrico I4GAD

[K3TN]

Thanks, Enrico - unfortunately, the situation is this: the remote station (K4VV) is in a rural/country area where the only Internet service is via wireless Internet service providers. One of the towers at K4Vv actually hosts the ISPs antennas and the shack gets free Internet service - but that service is shared with several houses in the same area. So, I bet there are web cams, and Netflix downloads, and You Tube viewing etc going on - but we can't control that!

I pretty much increased the jitter buffer/delay settings to the maximum and got the audio drop outs to decrease significantly - but not away completely. OK for casual QSO, but not good enough for CW in a contest. I ran some speed tests and the performance is dramatically different every time I run it - some times low jitter/low ping time, some times twice as high, sometimes even higher.

We are going to try to work with the ISP to see if there is some way to improve the performance of the shack connection, I can see anything else to do at the Remote Rig side.

73 John K3TN

[sm2o]

Hi

If you have control over the routers etc you can use QoS and set higher prio or reserv bandwidth to the RRC trafic

73 de mike