TGLX and PGXL Utilities randomly disconnecting.

KH6XX

I am running TGXL v1.2.11, PGXL v3.8.8, AG v4.1.8, and SmartSDR v3.7.4 and the radio is the 6600M. I am getting random disconnects on the TGXL and PGXL utilities. I get the disconnect for a second or so the reconnects. It seems both the TGXl and PGXL both disconnect at the same time. It is random. Can happen a few times in a short time then go for days without happening. This seems to happen more when the devices are in Standby mode. However, when it happens in transmit, I do not see any message on the PGXL or TGXL, the transmit appears fine when looking at the power output and SWR on the FRStack3 meter. I do not hear any antenna port noise due to switching when it happens. It is as if the API? is disconnecting but independent of the actual operation of the TGXL or PGXL. The TGXL, PGXL and AG all connect directly to the router while the PC is connected to a switch. When I used a router with more ports and connected the PC to the router too, same thing happens. Anyone else experiencing this?

Randy KH6XX

Russ Ravella

Yup, the exact same thing happens to me. And to be clear, it happens when I'm not transmitting so it's not RFI getting into the Ethernet cable. Nothing else on the same switch does it, just the utilities. And just like you said, I can go quite awhile without it happening then suddenly it will happen over and over again. By the way, I'm on PG v3.8.8, AG v3.1.5, TG v1.1.20 and SSDR v3.7.4 but it also happened when I tried AG v4.1.7 and TG v1.2.11 as you have. So there's something basic to both sets that's not right.

As I mentioned in another thread, since Flex's currently recommended versions do not work properly in SO2R mode (3.1.5/1.1.20 more or less do work properly) I'm hoping Flex is communicating with 4O3A to fix them, including this disconnect issue.

Russ KR6W

David Decoons, wo2x

Almost sounds like a network issue. Is this a full Flex/4O3A station? If so, in the TG XL under Genius Integration the Power Genius should be unchecked. Antenna Genius checked and s/n of AG selected.

Dave wo2x

KH6XX

Yes, it is a full Flex/403A station with the configuration as you stated.

Russ Ravella

Hi Dave,

Yeah, it's the full set in my case. Set up per your recommendations. I don't think it's the network since nothing else is ever affected. I would see it immediately if it were and Randy and I are both seeing the same thing. I wonder if other's are as well so I'm keeping an eye out for other responses to Randy's post.

Thanks for the reply as always Dave,

Russ KR6W

Mike-VA3MW

Download PingPlotter and run it on the PC with SmartSDR.

https://www.pingplotter.com/

Have it ping the TG every 0.5 sec for as long as it takes.

When you lose a connection, do you see a Red bar on the graph?

It might start to show you if you are having network communication issues.

Like Dave said, it is likely a network issue and using PingPlotter, hopefully we can try to gather some data points that might get us to the root cause.

Alan

I have the same experience with the Windows PG Utility loosing communication. I do not see the same disconnection when using the MacSmart SDR PG Utility.

At the same time the Windows PG utility looses communication, I know the PG TCP connection is good. I use Node-Red via the PG API. Node-Red "polls" PG every 150ms for status. I monitor the status message from PG as an indiction of a good TCP connection (same as Mike's suggested ping test). The Node-Red PG status message remains good, at the same time the WindowsPG utility looses connection.

The successful status message, and Mac SmartSDR not having the same problem, leads me to believe the problem is within the Windows PG Utility, not the firmware.

Its a minor inconvenience but needs attention on the next utility update.

Alan. WA9WUD

KH6XX

I also use MacSDR in addition to the Windows version and I do not experience the drop on the Mac, just like you are seeing. Agree, it is just a minor issue and can live with it.

Mike-VA3MW

Hi Alan

The last time I discussed it with them, a few weeks ago, they are not working on any networking issues in terms of network connectivity as they do not see those problems at all and therefor have a strong feeling that the problem is external to the application. This came up as an issue I have going on with my AG and I am the only one reporting it.

Along with that is only a few people are reporting any sort of issue or they are working fine. That comes down to the usually statement that if everyone had the same issue and they could recreate it then they can debug it and solve it. Such is not the case.,

All the application does is open a socket on Windows and then Windows and the NIC card drivers actually do the communications via the Switch and the LAN.

I guess, said another way, we write the letter and it isn't our fault if the post office doesn't actually deliver it. :)

That is the reality at the moment. (I am just the messenger)

Mike-VA3MW

Let me share what I see to my AG at the moment. You should see something similar if you run PingPlotter and use it as a good tool to look for network dropout.

I am pinging from my house via the VPN over the internet to the remote and then through 200' of 120VAC power cable (Power Line boxes) to the AG at the base of the tower. Not really the best practices, but I always try the easy way first.

(PC-Switch-Router-VPN (internet)-Router-Switch-PowerLine-AG)

This is what the PingPlotter graph looks like.

This, so far, tells me that the AG is on the network and communicating well.

If you are losing communications than you should see it on PingPlotter as well.

The next stop would be to run PP targeting another device on the LAN. Next time you lose communications to the AG, see if you are also seeing problems on PP. If no on PP but yes on AG, then now you have good data to bring forward to 4O3A.

Yes, it is painful to do, but the good reporting data does help narrow things down.

There might be other ways to narrow this down, but this is how I am doing it.

73

KH6XX

For what is worth, I had really bad disconnects with the AG using v3.5.1and was why I jumped on v4.1 as soon as it was released. I use a stack and it did not work well due to the dropping. I was actually disconnecting the antenna ports momentarily. Those problems seemed to have gone away so far when I used v4.1.7. Just started using v4.1.8.

Alan

Mike

We are leaving to visit grandkids and will be back next week. When I return, I will set up a WireShark Capture to/from the PG.

I suspect, I will see some ACK packet errors. This could mean the the TCP handshake from the PG to the Utility is not always working, but does explain why the polling/status message to/from Node Red shows a good connection. As I recall, the utility uses a heartbeat to maintain the connection with the Utility.

I will compare the PG ACK exchange between Mac and Windows PG Utilities….Perhaps this will show something.

More end of next week.

Alan. WA9WUD

Mike-VA3MW

If you get some good data, please share it with 4O3A. The more reports they get, the better.

Mike VE3CKO

I am running TGXL v1.2.11, PGXL v3.8.8, AG v4.1.8, and SmartSDR v3.7.3 on a 6700 and I am not seeing any disconnects and haven't for a very long time since it was fixed a few years ago. Note I haven't upgraded to v3.7.4 as this was a hotfix for Maestro C users.

Dewey WØYWW

What model Router and Ethernet Switch are you using?

Mike-VA3MW

What model Router and Ethernet Switch are you using?

For me, I use pfSense routers on both ends and all my switches are now TP-Link SG-1024D Managed switches. I don't, at the moment, manage anything but at least I can see if one of the ports is in a re-try. For example, my KMTronic web switches seem to retry alot but they don't impact anything and it is a trivial amount of errors.

I also tossed out all old LAN cables and replaced them all with CAT 8. I can 100% confirm that some cables I made and some of the cheesy blue cables that come with everything did impact performance. I wrote it all up here:

https://community.flexradio.com/discussion/8028378/network-cleanup-and-the-results

I am thinking of isolating the PC's from the Radio in some way as, for some reason, if the remote PC does a big web page reload, it impacts the UDP audio stream from the radio.

There may not be a way around this as UDP audio is not high priority. (I need to talk to Tim about this). And, it might not be fixable since all the smarts in the switch are working as designed. More things to learn here for me.

I think it is pretty easy to assume a network is flawless, but the more I dig and learn the more I learn it really isn't.

BTW, a good test is to be on the air listening and if you have a PC on the local net, do a speedtest and see if the audio breaks up. If it does, the problem isn't the radio but the network management.

I hope that helps a bit… Mike

David Decoons, wo2x

what is running 10 meg half duplex? Seems like data collisions in data to the device while the device is transmitting data. All your errors are on the half duplex devices.

Mike-VA3MW

The KMTronic Web Switches as those NIC cards run in that mode. No matter how I have the switch ports set, the errors are the same. :) Their traffic is so small that it doesn't matter.

Sergey KN7K

Never seen TGXL disconnect message, PGXL is doing it for years with every new version release. I did not install the latest one since there some weird reports coming out, still on ver3.8.4

Sergey

Sergey KN7K

Today replaced Cat5e cable to PGXL to a brand new CAT8 - PGXL Utility welcomed me with Reconnect message few minutes after power up. Since only PGXL shows that behavior it is not a cable or switch as all 6600, AG and TGXL connected to the same switch.

Annoying to see but I hope it is not disconnect/reconnect PGXL physically as it can be costly.

Sergey

WX7Y

maybe you got a bad cable

Sergey KN7K

"maybe you got a bad cable" - what do you mean,Bret?

I am saying that random PGXL disconnect message shows up before and after cables replacement, so it is not a cable. I replaced switch a year ago, it did not solve the issue either.

Since many of us noticed random PGXL Utility reconnect message, we should stop blaming cables or switches.

It would be nice to hear from Ranco what is going on and how severe this issue could be - if we have this message on Utility - I do not care. If PGXL really losing connection during TX - it could be a very costly repair.

And it is not RF related - I see reconnect messages during receiving.

Sergey

WX7Y

Oh sorry I misunderstood I thought you was saying it was working before and with the CAT8 it was failing.

W7NGA

TGXL disconnects are real and annoying ..

KH6XX

I don't know if this was just coincidental, but I just had a very frequent bout of misconnects on both the TGXL and PGXL almost continuously. I am running FRstack with almost identical global profiles, except for the mode. As soon as I selected the alternate similar profile, everything being the same on that profile except for the mode, the disconnects stopped. I went back to the original FRStack global selection and all was fine…. no disconnects. Again, I don't know if this was a one-off but wonder if others are seeing this. When I watch the metering in FRstack, there is no disconnect with FRstack and the amp temp, output and SWR are all being reported normally, even as the disconnects occur on the PGXL and TGXL utilities. It also makes no difference if in transmit mode or rcv… the disconnects are occurring. It is the infrequent and intermittent disconnects difficult to test, but this time I had a continuous string of them and any type of switching apparently reset something. It looks like this has to do with the PGXL and/or the TGXL.

KH6XX

Meant to say… it looks like this has to do with the PGXL and/or the TGXL utilities, or some interaction with FRStack.

KH6XX

I think it is doubtful this is a hardware network issue after having the results I got simply by changing a global profile with FRStack. Something reset. Maybe this is why Sergey had no success swapping out cables with CAT8.

Sergey KN7K

KH6XX, not sure I saw TGXL "missconnects" messages on other threads, while PGXL issue reported many times. Quick search on Flex community shows number PGXL issues, but I do not see TGXL issues were reported. It could lead to the isolated TGXL issue at your setup. Worth to try to troubleshoot your connectivity - router-switch-cables.

I replaced everything trying to get rid of PGXL reconnect messages without solution. Meaning, the problem with PGXL Utility/PGXL HW-ethernet. This is my conclusion.

Sergey

KH6XX

It is usually the PGXL app that disconnects only but when that starts up, sometimes the TGXL app disconnects as well. The problem seems to be centered around the PGXL utility. It is the one that disconnects first all the time. This time I had both disconnecting and reconnecting at the same time. Since all these pieces of equipment seem to talk to each other, could one app be bringing the other app down? I run FRStack all the time as well. Could this be a factor? With multiple AG's, a 6600M, PGXL , TGX and FRStack each polling each other frequently as well as their apps and FRStack, could something be going on?

My configuration set up is fine. Its hard to mess that up with an all Flex Station.

Dewey WØYWW

I also live with PGXL random "reconnecting" Windows 10 Pro 4O3A app error message issue, but never seen it occur on the TGXL or any other software app. It happens whether using Flex-6700 or Flex-6600. This is not a RFI issue as it rarely happens while transmitting (almost always occurs in receive mode). The time it takes to reconnect is about 1-sec, and duration between reconnect events, varies from a few minutes to several hours, and occurs whether using SmartSDR on computer or Maestro. My setup is Antenna Genius (SO2R), Tuner Genius, and Power Genius XL. I've changed network cables (currently using CAT-8), changed ethernet switch (currently using D-Link 10/100MB), and router (currently using tp-link AX11000). I'm using lastest SDR v3, Flex/4O3A firmware/software updates. I've lived with this issue for the last 2 years; it continues to occur regardless of whether using other software (including virus/malware/firewall) on my computer or not… all my attempts to find the root cause have failed. The only item that I've not changed is my network provider-supplied modem.
Dewey/WØYWW

Sergey KN7K

Dewey, I have the same setup.

To KH6XX - I personally do not have answers. I think we pretty much isolated issue to some bug or ethernet HW on PGXL (not sure about TGXL).

It would be nice for 4o3a team to acknowledge the issue and let us know the timeline for solution.

Sergey