3 ms·

Hi! I'm one of the engineers working with cubesat hardware and software integration, and I've been following this project since 2023 because I agree that stand

by minetest2048 3y ago

Hi! I'm one of the engineers working with cubesat hardware and software integration, and I've been following this project since 2023 because I agree that standardizing over Ethernet over (twisted pair, UART, single pair, etc...) will solve a lot of integration pain from all of the DIY protocols that the cubesat/smallsat community uses Some thoughts: - You actually have a publicly available ICD at https://github.com/the-aerospace-corporation/satcat5/tree/main/examples/slingshot https://github.com/the-aerospace-corporation/satcat5/tree/ma... , please publicize this more in the readme! You're a very rare exception in a world of contact us and sign an NDA first and commercial in confidence ICDs, which is great, and leads me to my next point: - Compared to HTTP API documentation, space ICDs sucks. One of the ICDs that I have put its protocol documentation as screenshots instead of copy pasteable text. Of course ICDs sucks because you won't know its quality until you buy it... Anyway standardizing on ethernet for transport layer give you all the tooling at 99% of the world's computer use, and it might be a first step in making a OpenAPI / Swagger type tool but for space protocols - Any plans for 10base-T1S single pair ethernet? Our 6U cubesats barely have enough power to run its payload computers, let alone a FPGA based switch. But in a way a switched star network can be more reliable than a multidrop bus, as you can isolate babbling idiot nodes, and filter out accidental/intentional MAC/IP address spoofing

ooterness 3y ago
Thanks for a very thoughtful reply! Regarding the Slingshot ICD: Noted, I'll make a point to update the readme. That document is literally the payload ICD for the Slingshot-1 cubesat that launched in July 2022 [1][2]. Future missions may take things in a slightly different direction, but that ICD is a flight-proven point design that shows what's possible. The space industry's NDA-by-default attitude definitely creates a lot of unnecessary friction. I totally agree that off-the-shelf tooling is a huge benefit of leaning into Ethernet. In particular, Wireshark has been essential in winning over hesitant developers; it's just light-years ahead of what you usually get for debugging microcontrollers. I've been watching the various 10BASE-T1S / 100BASE-T1 / 1000BASE-T1 standards, but company interest has been limited. AFAIK none of them can be attached directly to FPGA GPIO/SERDES/etc., so you need a separate PHY chip on both ends of the link. For us, the competition is SGMII over coax (for FPGA payloads) or SPI/UART over 4 wires (for microcontroller payloads). Cubesat cable runs are so short that the ability to directly attach to GPIO typically outweighs potential size and weight savings in the cable harness, plus it's one less chip with unknown radiation tolerance, etc. That said, the good news is that -T1 PHYs typically have one of the usual *MII options (RMII, SGMII, etc.), so many are already compatible with SatCat5. The bad news is 10BASE-T1S requires CS/MA and PLCA logic that is not yet supported. (But if anyone wants to contribute cool features to this open source project, please reach out.) [1] https://aerospace.org/sites/default/files/2022-08/Slingshot_0822.pdf https://aerospace.org/sites/default/files/2022-08/Slingshot_... [2] https://aerospace.org/article/aerospaces-slingshot-1-demonstrates-pathway-accelerating-space-innovation https://aerospace.org/article/aerospaces-slingshot-1-demonst...
- johnwalkr 3y ago
  Great work on this, it looks really promising! The industry is really a mess with a mix of interfaces. On one end there is stuff like RS422 which is simple but only the hardware layer is really standard and normally its not set up or tested to more than 1Mbps. On the other end there is stuff like spacewire which is a good standard but it's not something a university payload team can dive into with COTS parts. Question: what's the power consumption like? When I was an aerospace grad student, I tried really hard to use ethernet to interface everything for a cubesat-sized spacecraft. But it turned out each port consumes about 0.25W at 10Mbps and 0.5W at 100Mbps. That's per port, so up to 1W just to connect 2 devices. That is a lot when your main cpu consumes 1W, and payloads and other devices often use much less. It would have almost tripled total power consumption. I looked into the EEE (energy efficient ethernet) standard and it didn't seem workable for using COTS things, it only seemed workable if you had design authority over everything. I kind of knew changing the physical layer was possible but I didn't know where to start, and anyway the microcontrollers I had picked out at the time because they "had ethernet" turned out to be very hard to use with more standard devices, defeating the point. Another couple of questions. I like gecko connectors but why not choose the ones with mating screws? Also interested in criteria for selecting the Tyco connectors. By the way, there is a small company that makes very tiny ethernet switches[1] for drones. There are 100Mbps and 1Gbps versions and they have nice connectors you are probably already familiar with. They are very nice for development of embedded stuff, even if you don't integrate it in your project and just use it for the sake of getting a pile of routers off of your desk. [1] https://gadgetsmyth.com/shop/ https://gadgetsmyth.com/shop/ Note: My opinions are my own and not those of my employer.
  - ooterness 3y ago
    Power consumption varies a lot with the number of ports and the FPGA platform. The "ac701_proto_v1" example design for the Xilinx Artix7-200T has 4 SPI/UART ports and 4 gigabit ports (a mix of RGMII and SGMII). That design hits around 150-700 mW [1], depending on how many gigabit ports are active. One way we've saved a lot of power is by skipping the Ethernet PHY. Last time I looked, a 100BASE-T PHY was about 130 mW each and a 1000BASE-T PHY was about 480 mW each. Double that because both ends of the link need a PHY, and that roughly lines up with your numbers. The upside of using a PHY is that "real Ethernet" can drive hundreds of meters of cable. The PHY chip is effectively a converter from the local interface (*MII) to the long-distance interface (10/100/1000BASE-T). But on a cubesat or a small UAV, cables are short, so you can skip that conversion to save power on both ends. The downside is that the many *MII flavors are not mutually compatible. Regarding the Gecko connectors, the very simple reason to avoid screws is floorspace. The "Handle" payload interface unit [2] has 12 Gecko connectors in a 4x3 grid. The screw mounts add enough width that it wouldn't fit in the allotted space. The retention clips are quite robust, though you do need a small tool to remove them. There's no reason you couldn't have screws on one end of the cable and clips on the other. Regarding the Tyco connectors, it's definitely a compromise that we might revisit. Size and signal integrity were the main concerns. The space industry is quite risk-averse, so something with provable signal integrity for 1250 Mbaud SGMII signals was a necessity. The GadgetSmyth product line is quite interesting. I had not heard of that company before. I'm surprised that their 1000BASE-T pigtails are not using twinax or STP cable, but the switch cards are definitely aligned with what we're trying to accomplish. [1] https://digitalcommons.usu.edu/smallsat/2020/all2020/174/ https://digitalcommons.usu.edu/smallsat/2020/all2020/174/ [2] https://github.com/the-aerospace-corporation/satcat5/blob/main/examples/slingshot/ATR-2022-01270%20-%20Slingshot%20Payload%20Manual.pdf https://github.com/the-aerospace-corporation/satcat5/blob/ma...

ooterness 3y ago

Thanks for a very thoughtful reply! Regarding the Slingshot ICD: Noted, I'll make a point to update the readme. That document is literally the payload ICD for the Slingshot-1 cubesat that launched in July 2022 [1][2]. Future missions may take things in a slightly different direction, but that ICD is a flight-proven point design that shows what's possible. The space industry's NDA-by-default attitude definitely creates a lot of unnecessary friction. I totally agree that off-the-shelf tooling is a huge benefit of leaning into Ethernet. In particular, Wireshark has been essential in winning over hesitant developers; it's just light-years ahead of what you usually get for debugging microcontrollers. I've been watching the various 10BASE-T1S / 100BASE-T1 / 1000BASE-T1 standards, but company interest has been limited. AFAIK none of them can be attached directly to FPGA GPIO/SERDES/etc., so you need a separate PHY chip on both ends of the link. For us, the competition is SGMII over coax (for FPGA payloads) or SPI/UART over 4 wires (for microcontroller payloads). Cubesat cable runs are so short that the ability to directly attach to GPIO typically outweighs potential size and weight savings in the cable harness, plus it's one less chip with unknown radiation tolerance, etc. That said, the good news is that -T1 PHYs typically have one of the usual *MII options (RMII, SGMII, etc.), so many are already compatible with SatCat5. The bad news is 10BASE-T1S requires CS/MA and PLCA logic that is not yet supported. (But if anyone wants to contribute cool features to this open source project, please reach out.) [1] https://aerospace.org/sites/default/files/2022-08/Slingshot_0822.pdf https://aerospace.org/sites/default/files/2022-08/Slingshot_... [2] https://aerospace.org/article/aerospaces-slingshot-1-demonstrates-pathway-accelerating-space-innovation https://aerospace.org/article/aerospaces-slingshot-1-demonst...

johnwalkr 3y ago
Great work on this, it looks really promising! The industry is really a mess with a mix of interfaces. On one end there is stuff like RS422 which is simple but only the hardware layer is really standard and normally its not set up or tested to more than 1Mbps. On the other end there is stuff like spacewire which is a good standard but it's not something a university payload team can dive into with COTS parts. Question: what's the power consumption like? When I was an aerospace grad student, I tried really hard to use ethernet to interface everything for a cubesat-sized spacecraft. But it turned out each port consumes about 0.25W at 10Mbps and 0.5W at 100Mbps. That's per port, so up to 1W just to connect 2 devices. That is a lot when your main cpu consumes 1W, and payloads and other devices often use much less. It would have almost tripled total power consumption. I looked into the EEE (energy efficient ethernet) standard and it didn't seem workable for using COTS things, it only seemed workable if you had design authority over everything. I kind of knew changing the physical layer was possible but I didn't know where to start, and anyway the microcontrollers I had picked out at the time because they "had ethernet" turned out to be very hard to use with more standard devices, defeating the point. Another couple of questions. I like gecko connectors but why not choose the ones with mating screws? Also interested in criteria for selecting the Tyco connectors. By the way, there is a small company that makes very tiny ethernet switches[1] for drones. There are 100Mbps and 1Gbps versions and they have nice connectors you are probably already familiar with. They are very nice for development of embedded stuff, even if you don't integrate it in your project and just use it for the sake of getting a pile of routers off of your desk. [1] https://gadgetsmyth.com/shop/ https://gadgetsmyth.com/shop/ Note: My opinions are my own and not those of my employer.
- ooterness 3y ago
  Power consumption varies a lot with the number of ports and the FPGA platform. The "ac701_proto_v1" example design for the Xilinx Artix7-200T has 4 SPI/UART ports and 4 gigabit ports (a mix of RGMII and SGMII). That design hits around 150-700 mW [1], depending on how many gigabit ports are active. One way we've saved a lot of power is by skipping the Ethernet PHY. Last time I looked, a 100BASE-T PHY was about 130 mW each and a 1000BASE-T PHY was about 480 mW each. Double that because both ends of the link need a PHY, and that roughly lines up with your numbers. The upside of using a PHY is that "real Ethernet" can drive hundreds of meters of cable. The PHY chip is effectively a converter from the local interface (*MII) to the long-distance interface (10/100/1000BASE-T). But on a cubesat or a small UAV, cables are short, so you can skip that conversion to save power on both ends. The downside is that the many *MII flavors are not mutually compatible. Regarding the Gecko connectors, the very simple reason to avoid screws is floorspace. The "Handle" payload interface unit [2] has 12 Gecko connectors in a 4x3 grid. The screw mounts add enough width that it wouldn't fit in the allotted space. The retention clips are quite robust, though you do need a small tool to remove them. There's no reason you couldn't have screws on one end of the cable and clips on the other. Regarding the Tyco connectors, it's definitely a compromise that we might revisit. Size and signal integrity were the main concerns. The space industry is quite risk-averse, so something with provable signal integrity for 1250 Mbaud SGMII signals was a necessity. The GadgetSmyth product line is quite interesting. I had not heard of that company before. I'm surprised that their 1000BASE-T pigtails are not using twinax or STP cable, but the switch cards are definitely aligned with what we're trying to accomplish. [1] https://digitalcommons.usu.edu/smallsat/2020/all2020/174/ https://digitalcommons.usu.edu/smallsat/2020/all2020/174/ [2] https://github.com/the-aerospace-corporation/satcat5/blob/main/examples/slingshot/ATR-2022-01270%20-%20Slingshot%20Payload%20Manual.pdf https://github.com/the-aerospace-corporation/satcat5/blob/ma...