The best I could find is a die-hard DIY option based on an L2 switch IC like Microchip’s KSZ8567 (or similar) or NXP’s SJA1105 family. Being L2 devices, they are unable to manage IGMP (or any other protocol for that matter) at L3 and above (makes sense).
KSZ8567, for instance, captures IGMP packets and forwards them to the host port, where there is expected to be a computing device (an MCU perhaps) responsible for managing the IGMP state machine at L3. SJA1105 doesn’t really mention IGMP in its documentation at all, which is also fair for an L2 solution.
I am perhaps missing something here, so any tips would be welcome.
Interesting. At a first glance it seems rather similar to the Microchip option, but it’s hard to tell. I filled out the info request form to give it a closer look.
I don’t expect TSN and IGMP to manage the same traffic, these are independent requirements.
I’ve been looking at AVB/TSN since you first mentioned it a rather long time ago and I wish we could dedicate some attention to it. Recent advances on the Ethernet side of things in UAV might create a good opportunity to prioritize this.
“IEEE AVB protocol stack (IEEE 802.1AS Time Synchronization and IEEE 802.1Qat SRP)” is pretty thin information. Some of the most interesting parts of the TSN standards are as new as 2020 (e.g. 802.1AS-2020 supporting redundant gPTP time domains) so you have to dive deep into these parts to see what they really mean by “AVB” or “TSN”. Anything that is older than 2018 is probably missing critical features for high-criticality networks.
These standards started to support audio and video but it wasn’t until the 2012 renaming and refocus of the AVB task force that reliability was properly considered (i.e. audio and video care about timing but not as much about reliability at the level that, say, a drive-by-wire system cares)
What would be the scenario over Ethernet? Would it be UAVCAN packets over Ethernet, or MAVLINK packets? I see numerous CAN to Ethernet bridges too. Will this require adding a TCP/IP stack to Ardupilot? Is it just CAN over Ethernet?
There are two configurations using Ethernet that are interesting.
UC1/UDP/TSN is a good, light-weight replacement for systems that would otherwise consider DDS.
UC1/UDP/[CAN OR 802.3cg] is a really compelling story for both heterogenous redundancy (aka “dissimilarity”) and as a migration strategy for automotive systems that are evolving away from CAN and towards automotive ethernet.
For all these cases UC1 provides a stable application layer on the network allowing the platform to evolve independently. Basically, this is what I think the future could look like:
This is very sensible but I would prefer to avoid making TSN a hard requirement to avoid losing a significant portion of non-critical/soft-real-time/experimental systems that can tolerate the conventional IGMP multicast. So far I don’t see any problem with making the transport compatible with either TSN or traditional multicast by means of a simple switch without altering the UDP packet format.
This is not really related to CAN at all (and certainly not related to MAVLink which is a separate application-layer protocol). You may be missing this context:
@pavel.kirienko there will be a development board out soon with 50x80mm size based on NXP’s SJA1110 havin 6 100base-T1 (automotive 2 wire ethernet) , one 100base-TX on RJ45 and one 1000base-TX on a iX connector.
I’m using it on all of my test drones to connect the FMUK66 to the NavQ companion as well as to the T1 802.11p D2X data modem since a while.
@pavel.kirienko
The SJA1110 EVB likely supports this type of development.
Once software is arranged and tested, it could be moved to the MR-T1ETH8 application example board that @dk7xe.g mentioned.
This is the MR-T1ETH8 board using the SJA1110 the NXP Mobile Robotics team is preparing. 6x T1, 1x Gigabit on IX Industrial connector, 1x 100BaseT on RJ45, Secure element on board with NFC for potential provisioning keys into a system.
It is fully built and tested, just need to get it through the process to have it available to sell.
