As I mentioned in the earlier post, being able to daisy-chain devices is an important goal of the star tracker project. Longer term, I want this to be an entry point to a broader family of small-satellite modules built around SatCat5.

By “daisy-chain”, I mean there’s an upstream host that provides power and data to the first module. The first module is connected to the second, the second to the third, and so on up to some reasonable limit. In a satellite, the host is probably the vehicle’s flight computer. On a lab bench, the host is probably a dongle attached to a regular PC. Let’s assume for now that all the modules are star trackers:

A flight computer attached to a chain of three star trackers.

The advantages of the daisy-chain interface are that the host only needs to supply a single port, there’s less cable weight than a star topology with a central hub, and it’s easy to add more modules to an established design.

The disadvantage with a daisy-chain interface is that all modules in the chain share resources. That means if one fails, everything further down the chain will lose communications. (Connecting everything in a ring could add some redundancy to mitigate that concern.) The chain topology also means that whatever design choices we make now will forever constrain the types of future modules that can maintain compatibility. In terms of power, star trackers will draw about 1 to 2W each when active, but a radio could easily consume 5-10W, and power-heavy modules like a GPU might draw 30W or more. Similarly, star-trackers that handle image-processing internally will need very little data (say 50 kbps each), but what about a larger network? A chain with five star trackers, a few reaction wheels, and a radio could be satisfied at 1 Mbps. A chain that’s streaming video data from a camera module to a GPU module could easily consume 1 Gbps or more.

In any case, here’s a block diagram showing the inside of each star tracker module:

Block diagram showing the star tracker’s upstream, downstream, and internal connections.

In this design, power flows through the chain as a single power rail and return rail, with local modules tapping off their own power as needed. Within defined limits, hosts would pick a supply voltage at design time, based on what’s convenient and the maximum expected power draw of attached modules. Remember: cables and connectors have current limits, not power limits per se, so maximum power delivery is proportional to the supply voltage.

For compatibility with various hosts, modules should accept the broadest practical input range. Depending on size, smallsats often have power systems at 5V, 12V, 24V, 28V nominal. Those voltages may be regulated, or they may vary with battery state. Ideally, modules would be able to accept any of these with comfortable margin, but wider ranges increase power supply complexity and decrease worst-case efficiency. A range of 4V to 32V might be a reasonable compromise, though increasing the upper limit to 48V would match common standards like PoE and the latest versions of USB-C power delivery. (I definitely wouldn’t want something as complicated as USB-PD on a critical spacecraft bus, but compatibility with widely-available power bricks increases low-cost accessibility for development hardware on the ground.)

Data flows through the chain one hop at a time, using an Ethernet switch on each module. To avoid breaking the chain, this part of the FPGA will need to be powered and running at all times, even when the rest of the module is asleep to save power. Use of Ethernet means that any module can talk directly to the host or to any other module in the chain, which is a big advantage over USB.

One big question is what flavor of Ethernet should be used for the chain. For future-proofing, it should be at least 10 Mbps, preferably 100 or 1000. Options such as 100BASE-T1 are appealing (bidirectional data over a single coax connector, wow!) but require a lot of power. At time of writing, a quick survey of available PHYs showed 180 - 500 mW per chip, and each module would need two. Since the entire chain needs these to operate even when the module is asleep, this would be unacceptable. Standards like LVDS or RS-422 would be more practical.

The other big question is connector(s). Connectors set a lot of important tradeoffs for physical robustness, size, maximum current, and signal integrity concerns. Having a single connector for power and data is convenient, but results in other unpleasant tradeoffs. Candidates include:

  • Harwin Gecko: high current per pin, lots of backshell and retention options, poor high-speed signal integrity
  • Samtec ARC6 or ARM6: excellent high-speed signal integrity, power would need to be a separate cable
  • SATA: excellent high-speed signal integrity, inexpensive connectors and cables, power would need to be a separate cable
  • USB-C: excellent high-speed signal integrity, inexpensive connectors and cables, limited mechanical robustness

In conclusion: The daisy-chain concept can work, I have a decent idea of the design tradeoffs, and have some design decisions to make. Lots to think about.