About ebjoew

@Matt_Is_My_Name, @Amanda, @Liz   I do believe the long drop outs have ceased. There have not been any for the past 2 days.   My thanks to whoever figured out the cause and fixed it. Soon, I can stop running my drop out monitor app now. ... View more

Thanks, @Liz. I will keep my app running that notes the longer dropouts and I will report when they appear to have stopped happening.    By the way, the one detail that I have noticed thatI have not yet reported is that the ability to bounce PING messages off of 8.8.8.8 stops roughly about a minute before the satellite modem logs any difficulties during a drop out. I first became aware of a discrepancy between how long a drop out appeared to be from the PC's point of view versus the duration of the drop out as logged by the satellite modem. So I started comparing some logged events with the times when the drop outs began as detected by failing PING messages. If it would be of any value, I could provide more detailed timing for a few drop outs.   ... View more

@Gwalk900,   (@Amanda and @Liz may find the latter part of this of interest as well.)   In working on a reply to your post, I discovered something very important. I will get to that in a moment.   First, let me point out that during these tests, at no time have I used the wireless WiFi facilities of the Belkin router. I normally connect the router only so that we have WiFi access via a Samsung tablet elsewhere in the house. All of my PING tests run on my PC which is hard wired via an Ethernet cable to either the router or directly to the satellite modem, depending on the scenario being tested.   I would suggest that there are, in fact, 3 loops when my PC is connected directly to the modem and 4 loops when the PC is connected to the router which is then connected to the modem.     What I found hard to understand was that there are far fewer, if any, dropped PING messages when the router is added to the scenario. Therefore, I was postulating that perhaps there is something about the electrical connection between my PC and the satellite modem that is aided by having the router in between them.   While writing this reply, I thought more about that and performed a PING test between the PC and the satellite modem itself with them being directly connected via an Ethernet cable. Then the scenario contains only 1 loop.   To perform this test, I typed the following statement into a command box:   PING /n 1000 192.168.0.1   Of the 1000 PING messages sent, 37% were dropped, a really poor result for a direct hard wired Ethernet connection. More than a third of all PING messages couldn't even make the round trip just across the Ethernet cable to the satellite modem and back to the PC. By the way, the longest round trip time of those messages that did make the round trip successfully was 1 millisecond.   Then I repeated the test with the router in the circuit. This constituted a 2 loop test. This time, 0% of the PING messages were dropped. Every PING message from the PC made the full round trip. However, while the average round trip time was still 1 millisecond, the maximum round trip time was 40 milliseconds. Some further testing showed that only 1.3% of the PING messages are ever taking longer than 1 millisecond in this 2 loop test.   So while it is desireable to remove my router to eliminate it as a source of problems when troubleshooting some issues, I find that my apparent overall performance is improved by having the router between my PC and the satelllite modem, even when I am not using the WiFi functionality the router provides.   I am already well aware that there is a connectivity test available for testing the link between the satellite modem and the gateway but that does not test the communications in a way that truly emulates normal traffic timing such as takes place during a PING test. It would be desireable to know the IP address of the server at the gateway which is serving my communication channel. It would be valuable to me to be able to perform PING tests between my PC and that gateway server, thereby eliminating the internet itself as a source of issues. Is there any chance I can get the IP address of that gateway server? Where would I look for it? ... View more

@Matt_Is_My_Name, @Amanda, @Liz,   Well now I am really confused. It turns out that my PING messages only enjoy a 100% success rate if I connect my Belkin WiFi router to the Ethernet circuit. Even though the computer itself is still connected by Ethernet (and not wirelessly) to the router, the router is doing something that causes the 100% PING success rate that I do not get when the computer is connected directly to the modem by Ethernet cable without the router involved at all. Perhaps the router provides a layer of retransmission protocol that covers up the dropped PING messages. Or perhaps the router is providing better Ethernet drivers or transmission cable terminations, thereby improving the success rate between my computer and the modem. In any case, I think I shall stop blaming HughesNet for my low PING message success rates, and I shall keep my router connected unless I need to remove it for a test. I will still be monitoring for the long dropouts of HughesNet service. I have been gathering some information about timing that may help the engineers. Assuming the long dropouts continue, I will be back with that information soon.   ... View more

@Matt_Is_My_Name, @Amanda, @Liz,   WooHoo!   After at least 2 full months of poor service, and after forking out $125 to have my radio replaced and then replacing the modem and then the problem remaining just as bad as ever for several days ever since, just a few minutes ago my app that tracks success rates on PING messages started registering 100% success all the time! Somebody somewhere fixed something for sure. I suspect one of those engineers did something at the gateway that really made a difference.   ... View more

@Matt_Is_My_Name,   I wonder if you are familiar with the ethernet concept that handles packet collision. This little discussion is not related to satellite communications per se, just the transmissions between multiple stations connected by a single ethernet cable which daisy chains from one station to the next, to the next, etc. It is a typical setup that might be used for the network in an company with a lot of offices, for example. Assume there are multiple stations on an ethernet circuit and two of them decide to send a data packet at essentially the same moment. There is collision detection circuitry used to detect that multiple stations are sending at the same time. It then puts a long pulse onto the ethernet cable that blocks both messages from getting through. The transmitting stations each recognize this and respond by each one transmitting its packet again after a random delay period. The assumption is that the two stations will choose different delay periods so their retransmissions do not collide again.   I suspect that the HughesNet satellite communications system works in a similar manner with regard to the many ground stations sending packets to the satellite. As long as each ground station's transmitted packet does not overlap that of another ground station, all goes well. If multiple ground stations try to transmit at the same moment, the satellite senses the packet collision and transmits a signal telling those stations their packets failed to get through and to retransmit them after some suitable delays.   I run an application program much of the time that keeps sending PING messages and it keeps track of how many of them succeed and how many fail to make the round trip to and from a selected server on the internet. Under typical conditions when weather is not an issue and we are not in the midst of one of these outages that we have been fighting, a usual success rate for the PING messages hovers around 50%. It does vary in a rather random way, a little higher or a little lower for a minute or two at a time but generally hangs near that 50% mark. Wednesday evening, we had a lot of heavy rain cells passing through the area, replete with several tornado warnings. Not surprisingly, we had spells where no PING messages were succeeding at all. My app flagged those periods as outages but it was clear that such outages were caused by the local weather.   However, I noticed something else that happened on at least one occasion when there was no rain in my location. There was a period when the success rate for the PING messages rose considerably above the usual rate, well above the 75% success rate, and stayed there for a while. Later, it returned to its usual behavior.   I kept wondering what could have caused that. Now I can propose a scenario about what caused this that is related to my theory about the satellite handling those packet collisions that I mentioned above.   I suspect some of the heavy rain that was around the state but not in my own area was blocking transmissions from many of the other HughesNet ground stations. That gave my PING messages a much better chance of getting through.   Of course, with many people having their attention drawn to the weather, perhaps they were not so likely to be using the internet in the first place. Either way, it is a theory.   @Matt_Is_My_Name, What do you think? Can you propose another explanation?     ... View more

Thank you very much for that @Liz. I am eager to hear what comes of their work.   My system here had received a new radio earlier this month. Yesterday, I received and installed a new satellite modem. The jury is still out here on how well it is doing because we have been hit with some rough weather.   ... View more

@Matt_Is_My_Name and @Amanda,   Looking around on the forum here, I discovered that another user (@dtominski)  who is also having intermittent service issues is also on Gateway 2 and Beam 23, just like @Matt_Is_My_Name and me. I left a post on the conversation @dtominski has been in ( Connection drops intermittently ) inviting him to come join this one since so much was in common. ... View more

@Matt_Is_My_Name, Of course, we have seen nothing more about any changes to the gateway that might resolve our issue and I am still having the dropouts taking place as often as ever, both short and long ones. If anything, they are getting more numerous. I expect that you are still having the dropouts as well. Tier Level 4 Tech Support called me today. After reviewing my situation, they decided to ship me a new modem. I will report on any differences that makes when it arrives here in a few days. Based on the fact that we are both experiencing the same problem, that you have had both you radio and modem replaced without it being resolved, and I have already had my radio replaced, I am not too optimistic about a new modem taking care of my issues. Either way, it will eliminate one more piece of older equiipment and add to our information about where the issue truly lies. I will report back when I have the new modem running. Personally, I am still rather expecting the gateway issue which @Amanda mentioned to be the true source of our issues. As I have noted before, not only are we both on the same gateway, we are both on the same beam of the satellite as well. We are both on Gateway 2 and Beam 23. ... View more

@Matt_Is_My_Name   I also see that not only are we serviced through the same gateway (Gateway ID 2 which is Albuquerque, NM) but we are both on the same beam (Beam ID 23 which covers much of Ohio where we are both located). Perhaps the issue is with Beam 23 of the satellite.   I certainly hope things pan out the way @Amanda said they are expecting. I am hanging a lot of hope on her statement. I was right on the very edge of terminating my use of HughesNet. I think their tech support people need to have their scripts updated such that when the tech support people cannot provide good resolution to a recurring problem, the issue gets reported to the upper levels of technical support much more quickly. Intermittent problems can be just as disturbing emotionally to end users as solid failures. Solid failures tend to get fixed quickly because they are much easier to diagnose but intermittent issues nag at you with little hope of being found. The tech support people don't really want to believe you it seems. It may be a cultural difference thing.   I am eagerly waiting for the all-clear update from @Amanda. ... View more

Matt,   This surely sounds a lot like what is happening on my system. However, due to the physical layout of my house, the location of the modem, and the location of my computer, I almost never get to see the lights on the modem as the problem occurs. (For one thing, I am 71 years old and I just don't move that fast any more.)   My system is a Gen4 system that is 3 years old. It seemed to work well for most of that time but perhaps around the early part of April, I began to be concerned about apparent occasional outages lasting typically about 4 minutes or so. I detect them about 3 or 4 times per day but they certainly seem to occur at random times.   Like you, I simplified the system by removing my WiFi router and reverting to a direct EtherNet cable directly from the modem to my computer which is a Windows 10 system. I have become so fed up with this problem that I am right on the verge of throwing in the towel and just junking the whole thing. I have been fighting with tech support over this for days.   Very similar to your case, a service tech was sent to my house who replaced the transmitter/receiver electronics on the dish itself. Because it is an intermittent problem, I was unable to know if this resolved the issue or not but by the very next day, it was clear that the problem was still there. I called on the service tech for some advice. He suspects the modem is faulty but is unable to authorize its replacment himself. He also suggested that I try powering the modem from a different power circuit in the house and checking that all connections were good and secure. With the power off, I disconnected each connector several times to be sure good contact was being made. Then I restored the power. One other thing that seemed very odd was that the service tech had suggesting termporarily substituting a barrel connector for the grounding block in the RG6 coax between the dish and the modem. It turns out there is no grounding block present. I suspect the original installer did not do this part of his job properly.   Attempts to get tech support to agree to provide a replacement modem always meet with stalling around. They resist replacing it until they find direct evidence themselves that the modem is faulty.   I know that HughesNet has launched a new satellite (EchoStar 19) which their new Gen5 uses. Since my system is a Gen4 system, it is using the aging EchoStar17 satellite. I am beginning to wonder if the outages are being triggered by something to do with the old EchoStar 17 satellite.   I have been satisfied with the speed and data limits imposed by my Gen4 service and have no wish to switch to Gen5. Even with the introductory offers, the cost per month in the long run will be more expensive. I have grown weary of everyone at HughesNet trying to sell me the upgrade to Gen5. I just want my system to work like it always has.   I am not aware of where to see a log of events recorded by the HughesNet modem. My modem is an HT1100 model. I have been told that the gateway I was assigned to is Albuquerque, NM. I have verified that when these outages occur, the weather is not the cause neither at my location nor at the gateway.   I get frustrated with the tech support folks because many of them seem to know very little about the use of Ping commands. If they do know of them, then tend to want to focus on the elapsed time associated with the Ping messages and direct me to think about how far a message must travel from my house up to the satellite, down to the gateway, through the internet to the destination, and the return trip backwards through the same path. I keep having to explain to them that I am not concerned about the elapsed time but rather the fact that more than half of them are being dropped altogether.   That is, if I go to a CMD window and enter a command such as this:   PING /n 1000 8.8.8.8   ... a thousand Ping messages will be sent to 8.8.8.8 and each will be expected to return. This test takes a little while but when it is over, I find that typically more than 50% of all the messages get totally lost and never return.   My current method of detecting the beginning of these intermittent outages consists of a program that I wrote that triggers the sending of a Ping message every 5 seconds and waiting to see if a response returns or is dropped. When one of the outages occurs, Ping messages start getting dropped not some of the time but all of the time. When my program detects this, it announces over the computer speakers that I have been disconnected.   Having been shown by tech support how to see state codes for the HT1100, I have recorded the sequence of these codes that occur during the outage. This is a typical sequence of what I see...   0.0.0 Fully operational 0.0.0 Fully operational 0.0.0 Fully operational 0.0.0 Fully operational 23.1.4 TCP acceleration operating in degraded state 21.1.5 Connecting to gateway (connection error - cannot display the web page) 21.1.4 Discovering a gateway 0.0.0 Fully operational 0.0.0 Fully operational 0.0.0 Fully operational    Then communication is restored.   NOTE: I am not sure if the connection error occurs before or after the 21.1.4 Discovering a gateway code. (It is hard to hurriedly record these codes using pencil and paper.)   On one occasion, I was able to run to the modem when an outage was underway and see that the System light was out, the Power light was on steady, and the LAN, Transmit and Receive lights were on but blinking a bit. After a few seconds, the System light came back on as the system appeared to recover.   On one occasion, I had kept a CMD window, waiting for an outage to commence. I had a: PING /n 40 8.8.8.8   .... command standing by ready to be intiated. When an outage began, I started the PING command running. I was a bit surprised to see this resulting sequence:   Request timed out  (26 times) General Failure  (7 times) Request timed out  (1 time) Reply received  (4 times with times of 631, 786, 928, and 611 milliseconds) Request timed out (1 time)   What do you suppose "General Failure" is? I rather suspect it corresponds to being unable to reach the modem for a state code in my state code list. I bet the Ping program cannot access the modem for a short time there.   So how do you see the event log for the modem?   I am glad that I am not the only person in the world who is fighting this problem!     ... View more