What are the prospects for comms with cubesats using "normal" internet connections?

Question

• Can a cubesat in orbit be operated like a R/C airplane in real time?

edit: if the link here and the end aren't clear, I'm interested in the ease and convenience of access, the frequency of possible access, and the latency that an internet connection provides, not the raw download speed.

Currently the only way I know for a lower-budget effort to communicate with a cubesat is to use SatNOGS, a crowdsourced network of Ham radio-licensed stations that can communicate with (or at least receive signals from) satellites in space. There may be others, I just don't know about them.

See How does the Satellite Networked Open Ground Station operate? How is it used? for a little more information, and note just how many new ground stations have joined in less than one year!

If you wanted to have a more regular communications schedule with your cubesat, not dependent on orbital passes coinciding with ground stations and scheduling opportunities, you might consider seeing if an Iridium transponder could be licensed and attached to it. I remember reading somewhere that that's been done already, but I don't recall where or if it was tested yet.

But with so many more companies trying to put constellations of satellites in orbit in order to bring internet or at least M2M data connections to the Earth's surface wirelessly, e.g.

• Iridium
• SpaceX
• Orbcomm
• O3B
• Globalstar
• others?

it seems like at least one of those might be accessible from a cubesat, at least more frequently than from ground stations.

Those constellations will be configured to communicate with the surface, rather than a satellite at a lower orbit of say 400 km, so there will be problems with timing and spotty coverage, so its certainly not a given that this would work without special provisions.

Question: What are the prospects for (and roadblocks to) comms with cubesats using "normal" internet connections where your cubesat has something like an IP address or similar, easily-obtained token or ID, and you can just use the same protocols you'd use to talk to say your Raspberry Pi? See this intriguing answer and demonstration for example of the kind of thing I'm thinking about.

Answer 1

What are the prospects for (and roadblocks to) comms with cubesats using "normal" internet connections where your cubesat has something like an IP address or similar, easily-obtained token or ID

Short and sweet answer. Several groups have used or plan to use Globalstar to communicate with their CubeSat.

Check Out:

• Presentation by Taylor University
• The LinkStar radio
• A NASA(?) Paper on SmallSat Networks discussion GlobalStar and Iridium
• The DaVinci CubeSat project
• The new "ThinSats" scheduled to launch this coming April all use GlobalStar radios

Answer 2

I am focusing this answer on the software roadblocks, as the question asks:

What are the prospects for (and roadblocks to) comms with cubesats using "normal" internet connections where your cubesat has something like an IP address or similar, easily-obtained token or ID, and you can just use the same protocols you'd use to talk to say your Raspberry Pi?

Touching on hardware issues (these are less of a problem now-a-days, ignoring money):

I would say the most viable form of implementation for a cube-sat architecture would be quantity over quality, with another quality layer to relay information back to earth. If you want something like this to even begin to be possible, you will first and foremost create an open source framework for the cube-sat data standard. Likely this will need to be much more robust in error checking than anything before due to signal drop on small receivers over long distances.

This brings up our second problem. I'm sure you can do the math for the size required of certain antenna configurations to be able to transmit data across a certain distance-- but if you do this in terms of cubesat sizes, we will probably see worse results th an the usual 100km to 6000km commercial ranges associated with regular communications satellites. The main issue with this is that even the NASA CubseSat 101 manual states RF is the main cubesat communication layer meaning attituse control would be a must. Unfortunately attitude control on noncommercial cubesats is generally nonexistant-- which is actually less of a problem according to this 2018 technology review for cubesat communication advances have allowed us to miniturize technology that is beyond basic RF and into higher frequency bands wothout the large payload. These can be deployed in cubesats as small as 1u from what i read depending on other electronics. Therein lies the next thing-- what are you thinking this internet will do?

The biggest roadblock (ignoring any hardware specifications):

So say you just want cubesats to greet each other when they are within a range of 100km to create a self sustaining tracking network. Cool! That actually would be simplistic. You just need to write a framework and get all parties you want as part of the network to use this framework in their code. You need to make this framework viable for nearly all cubesat platforms and you need to distribute it reliably-- likely through NASA sourced networks. After you have an opensource or control sourced internet protocol on nearly 50% of cubesats for something simple like this-- it would be as simple as updating the code with new functionalities. A simple upgradr to this system that would be substantial would be, for instance, caching all cubesats its met and transmitting it when within range of the main relay. Vada bing bada boom cubesat tracker! Provided you remembered to add the ability to update it... bringing us to our final argument towards the complexity here...

Cubesats are pretty... nonreusable.. in terms of satellites to date. While there are exceptions-- these have been fire and forget orbiters with burn wire release mechanisms from students with limited budgets. Now-- a commercial cubesat deployment in large quantities would be exceptional in my opinion. You could have a basic network, possibly attitude control through ion engines and communication with a more robust satelite layer from a higher orbit to reliably update your framework. This way you can new functionality and perform regular calls against some sort of cubesat hivemind api. If you are a private company thinking on this scale though-- i doubt you would be opposed to considering creating a dedicated satellite (real deal satellite with commlink to earth) in a well aligned orbit to have maximum cubesat uplink capability. The problem that will come for a corporation running a 100+ cubesat network will then be maintaining the cubesats in a macro mindset.

Macro computing problems...

Most of these companies who will be launching these cube-sat swarms will be accustomed to dealing with sending updates to 1-5 satellites at a time. One of the largest challenges with macro computing is consistency across systems. For instance, I work at a company with 30,000 employees-- that's a decent amount, and we just went through a massive software update from Windows 7 to Windows 10. We had to upgrade 30,000 laptops to the new operating system, this is what happened:

• ~60% of upgrades went normally (that's higher than average).
• ~15% of upgrades were declined by the users, manual intervention required.
• ~10% of upgrades were not propagated correctly, manual intervention required.
• ~10% of upgrades pretty much destroyed the computer entirely, manual intervention required.
• ~5% other unique issues were encountered and needed intervention on a case-by-case basis.

In the beginning, this will be the biggest blocker, keeping all of the cubesats on the same page without being able to communicate with them all at the same time. If you have 50% of the cube-sats uplinked when you push a code update (and have no dedicated handler to continuously push this request when others come on-line reliably), you're gonna have a bad time.

Benefits/Summary:

Honestly Im going to assume the benefit of swarm satellites will become apparent once theyve mastered the big problems:

• Communication.
• Reusability.
• Attitude (or heck-- even altitude in this case) Control.
• Widespread Standard and Adoptance.
  • Politics are a blocker.
  • Advertisement is a blocker.
  • Source control is a blocker.
  • Source propagation is a massive blocker.

I cannot overstate that last part more. The internet was a culmination of agreement among many nations on a single protocol which was developed and communicated well enough to become standard. Id look up IEEE standards, message formats for TCP and UDP transmission alongside many other protocols if you want to know more about how the internet came to be software wise. Development of this software base is key. It must be universal and widespread to gain significant traction. With how small they are you are gonna need a lot of them. This is not a one company deal for global coverage.

I'm guessing the benefits to this style of satellite will be point based data gathering to give a picture of the solar activity around the world as a whole so approximations on orbital activity can be made globally. Once again... this is provided all hardware enables your software, and your software enables all hardware.

Sorry for typos-- I wrote this on my phone.

Answer 3

basically, how satellite internet works is you, the client, have a dish that is sending and receiving data packets to and from a satellite in space. The satellite isnt filtering these signals but is instead just relaying them to a ground station who then routes the messages. The ground station is better known as your ISP or internet service provider.

At the ground station is where they choose to reject your request or let it through to the greater internet (provided you pay them).

As long as your satellite has a dish that is aligned with the dish of your internet providing satellite then it is theoretically possible to access the internet.

However, that ignores the fact that you are constantly moving in orbit and will rarely be aligned with that satellite. This also means you will probably have to have agreements with multiple ISPs if you ever want to have some kind of reliable comms.

EDIT: If you are truly just looking for intercommunication betwen cubeSats and not satellites ambiguously then you can try this specification: https://en.wikipedia.org/wiki/Cubesat_Space_Protocol

Bare in mind this is only a specification and not law, nor does it broach the subject of authorization. It's up to the OEM's if they want your cubesat conversing with their cubesat ( which is true for all M2M communications).