USB0 disconnects. Requires RRC reboot to recover

[rx3dux]

Within a minute or so of using USB0 on the Control RRC to control the remote 746pro, the rig software gets disconnected from the remote radio. The Control RRC then needs to be restarted to reconnect to the radio again.  (the audio stream is  fine all the time)

The same setup works fine when I move from the USB0 to COM2.

The error log and the config files are attached.

Regards,
RX3DUX / NS6W

[Jan (Microbit)]

What do you mean with "COM2"? The physical COM2 maybe?

The log you attached contains many lines like:

10/13/11 8:26:01.548 AM   MacLoggerDX   sendIcomRadioCommand:bad echo:[03 66 E0 04 FD 00 ]

which seems to be some kind of error/warning as it says "bad echo".

Is it possible to get a "mldx_remoterig_ic746pro.log" when you are using COM2? Having a log from the failing USB0 and another from the working COM2 maybe could tell more about the problem.

[ha1ya]

Hi,
I have similar problem  with my IC746 when I use the USB input on the control RRC to CAT.
I tested the USB with com0com and VSPE without sucess.
In the first seconds everything works fine but after some seconds to up to 10-15mins the CAT is freeze's.
If I restart the HRD and the control RRC start to work again fine up to some time.
No problem with the audio, tx etc.
If I using  RRC Micro from same usb port,  it works fine..
Tested different PC's, different ICOM746 etc..
Seems the problem with the RRC control USB, or with the RRC  ;DUSB hardware?
I am after 20-30 hours experiments without results.
If I using the COM2 of the RRC over USB/RS232 converter everything works well.
73, Gabi

[rx3dux]

This problem only manifests when using the USB0 connection on the Control RRC.  When I connect the computer to the COM2 of the RRC, the link between the MacloggerDX and the remote 746 stays solid.

Once I go back to the USB connection between the controlling computer and the Control RRC (USB0), the link stays for a few minutes and then hangs.

I'm attaching a trace log of the communications with the remote 746 using RRC's COM2.

[Jan (Microbit)]

This problem only manifests when using the USB0 connection on the Control RRC.  When I connect the computer to the COM2 of the RRC, the link between the MacloggerDX and the remote 746 stays solid.

Once I go back to the USB connection between the controlling computer and the Control RRC (USB0), the link stays for a few minutes and then hangs.

I'm attaching a trace log of the communications with the remote 746 using RRC's COM2.

Thanks for the logs. I can see that they differ. It seems that when using USB the two first bytes of the reply are missing, and that is most likely what causes "bad echo" and eventually it fails. We will have to find some way of provoke a similar situation in order look into it.

[Jan (Microbit)]

Hi,
I have similar problem  with my IC746 when I use the USB input on the control RRC to CAT.
I tested the USB with com0com and VSPE without sucess.
In the first seconds everything works fine but after some seconds to up to 10-15mins the CAT is freeze's.
If I restart the HRD and the control RRC start to work again fine up to some time.
No problem with the audio, tx etc.
If I using  RRC Micro from same usb port,  it works fine..
Tested different PC's, different ICOM746 etc..
Seems the problem with the RRC control USB, or with the RRC  ;DUSB hardware?
I am after 20-30 hours experiments without results.
If I using the COM2 of the RRC over USB/RS232 converter everything works well.
73, Gabi

Your problem seems a little bit different than rx3dux's in that it may work as long as 10-15 minutes. We will have to try more stress tests of the USB serial ports and see if we can provoke it to freeze too.

[rx3dux]

Jan,

Thanks for looking into the situation.

Just curious, what USB chipset are you using in RRC?

Regards,
Sergey
RX3DUX

[Jan (Microbit)]

Jan,

Thanks for looking into the situation.

Just curious, what USB chipset are you using in RRC?

Regards,
Sergey
RX3DUX

USB is built-in into the microcontroller, so no dedicated separate chipset is used.

[Jan (Microbit)]

A first rather quick stress test of the whole chain: PC program -> USBCOM0 -> Control RRC - > Radio RRC -> Control RRC -> USBCOM0 -> PC Program gave no clue what is happening since I had it sending messages every 30 ms and had it doing so for more than an hour without any sign of missing characters,  nor did it "hang". Hmmm....

[ha1ya]

Hi Jan,
You tested it with HRD and ICOM CI-V?
Maybe the problem only on case ICOM commands?
We will try out the same installation with another ( YAESU) radio.
73, Gabi

[Jan (Microbit)]

Hi Jan,
You tested it with HRD and ICOM CI-V?
Maybe the problem only on case ICOM commands?
We will try out the same installation with another ( YAESU) radio.
73, Gabi

No, not yet with HRD as it is harder to debug the "fundamentals" that way. Trying other things first.

[ha1ya]

Hi Jan,
We tested everything with guys yesturday.
The USB port is freeze's with YAESU  FT817 radio also.
We checked the input and output datas.
Was no problem, but after 5...10 minuts the CAT is stopped.
Must be switch off and on the control RRC and  it is going again up some mins.
If your side  this setup  works fine seems any problem  only in our RRC control box.
I will send it back to repair or change.
We experimented with RRC more than 40 hours, and we checked yet  every possibilities.
73, Gabi HA1YA

[Jan (Microbit)]

Hi Jan,
We tested everything with guys yesturday.
The USB port is freeze's with YAESU  FT817 radio also.
We checked the input and output datas.
Was no problem, but after 5...10 minuts the CAT is stopped.
Must be switch off and on the control RRC and  it is going again up some mins.
If your side  this setup  works fine seems any problem  only in our RRC control box.
I will send it back to repair or change.
We experimented with RRC more than 40 hours, and we checked yet  every possibilities.
73, Gabi HA1YA

We are currently tracking down something similar to what you experience. It looks like USB starts to need a lot of  the cpu's resources and so it might seem that it "freezes" as other parts of the program not are able to run at normal speed. Sending back the RRC won't help you get the problem fixed since it seems to be a problem with the software. If possible I would ask for you to have a little more patience while we continue our work to fix it.

[rx3dux]

Summary of running RRCs for one week:

1. OS used: Windows, Linux, Mac os
2. Programs tried: HRD (win and Linux), MacloggerDX (mac), Commander (win)
3. All programs tested with direct connections to the rig to baseline the performance (ic746pro, microham USB interface II), and with RRCs running across Internet (average ping time 6-10 ms, fiberoptic ISP connections at both ends, routers set up in DMZ mode for the remote RRC IP, all SIP/NAT/DDOS filtering off).

I. Regardless of OS, application and network setup, the direct USB0 control of the rig stops working after a short time (minutes).
II. When operating remote using serial interfaces between the computer and the control RRC, the setup worked without freeszing, but there were considerable Icom response delays when rapidly changing the frequency through the software.

III. MacloggerDX reported "poll errors".  Further debugging revealed the following messages associated with those errors.

RadioController:getRadioReport:elapsed time: [176.227987] ms

The elapsed time would vary from 100ms to 1000ms.  The constantly running ping tests did not show any network degradation.

Most likely the RRCs were choking on frequency change data running across the link. (CPU overrun?)

If you need any specific log data, please ask.

Regards,
Sergey
RX3DUX.

[Jan (Microbit)]

Thanks for the detailed and comprehensive  feedback!

Regarding using USB0, as I previously mentioned there are issues with current firmware that could lead to the RRC freeze/hang after a variable time of use. Just like you see. We have been working hard this week to find a remedy for that and we now have a new version that so far promise significant improvements.

Regarding using the serial interface, did you have the USB cable connected while doing that test too? If so, try without connected USB cable. We have seen that although not using the virtual COM ports it still can effect performance by just being connected.

Would you like to test the new version although it is still to be considered as being in beta stage?