How is SpeedFusion and/or PepVPN performing over Starlink for those lucky enough to have Starlink now? Any issues?
2 Likes
SpeedFusion has been tested with Starlink and it works just like any other WAN would.
It is possible to use it for bonding as the latency is much lower than traditional satellite connectivity.
I have just placed my preorder for Starlink!
1 Like
I have deployed Starlink and LTE in the UK countryside. Bonding over starlink works perfectly.
Am going back to site with some external antennas to improve LTE experience though.
5 Likes
Excellent news! Just preordered too!
For your boat? Starlink locks to your nearest ground station. It will not allow you to travel and receive internet, at least at this time, and for the foreseeable future. I also dont think it will work offshore, as it requires a ground station nearby to beam internet up to the satellite.
Also requires the antenna to be on a non moving platform.
The Starlink antenna does move but that is to track the satellites not to correct the movement of a boat.
I was actually curious about that. That kinda stinks but makes sense that it cant correct for movement of boat. Boats even move at the dock due to wind. 
I just received my Starlink terminal yesterday. (Part of the Feb 8th expansion) I finished the OOB management connections this morning.
SF works fine. The only limitation is that you have to use one of the workarounds to access the management interface at 192.168.100.1. That limitation will continue until Peplink gives us static routes on the WAN interfaces.
I suspect that after Starllink supports moving the terminal from time to time (RV’s when parked) That fully mobile terminals will come, but they will probably not be the standard consumer kit. A motion stabilized or motion feed back phased array suitable for the aircraft and marine environments will probably be an order of magnitude more expensive, like the current marine VSAT antennas aren’t the same as the Hughesnet that you bolt onto your house.
2 Likes
I do not think that is correct. It does not use a ground station at all. It is talking directly to the satellites.
However, I do not think that t this time it can track quickly enough to deal with a rocking/moving boat.
Starlink definitely relies on groundstations. There is one a few towns over from me. They are all over the USA. The satelites get the internet from the groundstations scattered all over.
1 Like
ah - based on the wording of the reply I replied to, I read it as saying that the terminal was using a base station, which it does not.
I do not think your terminal is locked to a base station. it is just that the constellation above you is always using that base station. If the temrinal moved enough for the sats to need to use a different base station it would…once starlink allows you to move at all. Right now they are limiting movement due to having only a small percentage of coverage in place.
what kind of speeds are you seeing on Starlink?
Up to 150Mbits down, 30up. Reliably in the 100Mbit range. Intermittent 20 second outages (I’m tuning the health checks to see if they are really smaller than that).
The statistics tell me 1 min of no sats… 3 mins of “other” outages. No obstructions.
So, fine for streaming and downloading… but you need another WAN for full stability and a SFtunnel for critical applications.
2 Likes
The groundstation you are referring to is a “Teleport” or at least that is what my VSAT provider calls their sites. It is basically where the trunk of information from the satellite is passed back down for real-world connectivity. Our large VSAT provider has five teleports across the globe as they provide world-wide coverage. My beams typically connect through three locations in the USA (Houston, California, and Maine). The StarLink is a two-way satellite terminal where it downloads and uploads directly to the spacecraft within a spotbeam of service. StarLink doesn’t currently allow you to travel outside your spotbeam but I see that capability coming once they have the network built out more. I am very interested in it for disaster response as it is far more powerful and less expensive than my 1.2M Driveaway dish. My current package costs in the neighborhood of $58,000 and around $12,000 annually for unlimited service for 10 days a month. Each additional day is another $1200 (30 minutes counts as a whole day).
I am waiting on my Beta approval too!
I’m assuming these “outages” are while the dish re-points to the next satellite and the handover doesn’t work flawlessly…
How often are these outages?
The outages are not during regular satellite handover, since that happens at most every 10 mins. They are on the order of 45mins to an hour apart and for only 5-10 seconds. I need to gather some more data from the sat and run some smoke pings. One theory is that the earth rotates under the shells on the order of about 45mins, Therefore each ring of sats will go from directly overhead vs max oblique angle. Some of the outages correlate to a 45min cycle… others don’t. I should be able to correlate the times of “no sat” to when the 36shell areas are overheard vs an already populated 72 shell area.
Starlink categorizes outages as either “obstructed” which is loss of signal, but the terminal expected to have a sat in sight. “No Sat” where there is a signal loss but the system calculates that no sats were in the correct geometry. and “Beta downtime” Which is just a catch all of ping loss and not the other two categories. So it could be rebooting routers, packet loss on the backhaul, other things like that. I have zero obstructions, so all my loss is No sat or Beta. About 75% Beta, 25% no sat. The maximum has been 4mins/day total.
|Feb 20 10:47:23|WAN: Starlink connected (100.72.190.228)||—|—|
|Feb 20 10:47:21|WAN: Starlink disconnected (WAN failed HTTP test)|
|Feb 20 09:46:23|WAN: Starlink connected (100.72.190.228)|
|Feb 20 09:46:15|WAN: Starlink disconnected (WAN failed HTTP test)|
|Feb 20 09:32:23|WAN: Starlink connected (100.72.190.228)|
|Feb 20 09:32:15|WAN: Starlink disconnected (WAN failed HTTP test)|
|Feb 20 09:26:06|System: Changes applied|
|Feb 20 09:24:40|System: Changes applied|
|Feb 20 06:05:13|WAN: Starlink connected (100.72.190.228)|
|Feb 20 06:05:10|WAN: Starlink disconnected (WAN failed HTTP test)|
|Feb 20 06:04:43|WAN: Starlink connected (100.72.190.228)|
|Feb 20 06:04:39|WAN: Starlink disconnected (WAN failed HTTP test)|
|Feb 20 05:19:14|WAN: Starlink connected (100.72.190.228)|
|Feb 20 05:19:09|WAN: Starlink disconnected (WAN failed HTTP test)|
|Feb 20 04:33:33|WAN: Starlink connected (100.72.190.228)|
|Feb 20 04:32:26|WAN: Starlink disconnected (WAN failed HTTP test)|
|Feb 20 03:57:49|WAN: Starlink connected (100.72.190.228)|
|Feb 20 03:57:41|WAN: Starlink disconnected (WAN failed HTTP test)|
1 Like
I think this link will largely explain the situation. The down-times can be mostly be predicted based on constellation density and geometries. Coverage is far better (even virtually 100%) at higher latitudes but gets rather rough as one proceeds farther south – as expected and acknowledged by Starlink. Of course, one would add to that any outages caused by obstructions due to the user’s siting of “Dishy.”
That simulation is over six months old and used the satellite data from July. It does not update in real time.
I have taken that code and run both the 35° and 25° calculations with data from Feb 4 2021 (there hasn’t been any new complete shells since then) It indicates 25° coverage all day down to about 31° latitude. and 1 min of outage for 35° at my location on the 4th…
This one is an updated visualizer for current data.
The issue is that all of those “draw circles” around the satellite models have a flaw, the terminal is not oriented straight up, and it does not have a 130° field of view, only 110°. The next time I am outside I will measure the terminal’s angle at my Latitude.
I guess we should write some test code to simulate the # of sats in view at a particualar location given the known limitations. 25° minimum elevation angle, 110° view path, ##° tilt. calculated second by second for a 24 hours span.
Operationally my observed No Sat downtime matches the 35° simulation fairly closely, and that is a simulated 110° view angle pointed straight up.
That address is pretty common with cable modems and we generally write simple outbound policies to get there. That does not work for you?
No it doesn’t, as detailed in this thread:
Peplink will need to add WAN static routes to properly support Starlink terminals.
An Outbound policy will send the packet to the MAC address of the default WAN router. If the out of band management interface uses a different MAC address, then it will not see the traffic. Starlnk and other DSL modems use seperate MACs and therefore need a static route. DOCSIS cable modems seem to use the same MAC address and therefore an outbound policy is enough.