TLDR; If this approach to external decoding would work, the user experience under these conditions would appear and sound like a fully integrated OEM SiriusXM experience using the Tesla SiriusXM OEM tuner with all controls using the native Tesla MCU SiriusXM client.
Another thought to a Ryzen solution: The part that is working is the UI interface, and the control plane of sending tuning commands to the tuner, and receiving control data back (confirmation of stream selection as well as song ID, etc). Can we use this part, which is 90% of the integration we want and solve the audio decoding externally? Tesla has done us a favor with the fallback behavior playing the audio stream of the last tuned FM station. Were we to decode the SiriusXM audio stream likely on the Broad R ethernet properly tuned already, we could just take the decoded analog signal and put it through an FM modulator whose audio is already playing through the MCU driven speakers in fallback to FM. The user experience under these conditions would
appear to be a fully integrated OEM SiriusXM experience using the Tesla SiriusXM OEM tuner with all controls using the native Tesla MCU SiriusXM client.
I handwaved away the hardest and most unknown part:
External decoding of the SiriusXM audio stream
However it looks like we have some pieces to start with stutech posted this response in this thread back in April 2023 to a separate question I asked.
It should be 1gig single pair Ethernet aka 1000 based broad r,
Good start! So what does audio encoded on Broad R look like? A quick read of this chapter...
...suggest:
"We focus on the current solutions for audio/video communications, i.e. Ethernet audio video bridging (AVB) specification. This specification has adapted Ethernet technology to meet electromagnetic constraints (EMC) specific to the automotive domain, and at the same time reducing the number of wires required to communicate (only one twisted pair in the current specification for at a throughput of 1 Gb/s instead of four). We review Physical (Broad R-Reach PHY) and Ethernet MAC layer in that perspective. Several new protocols including: clock synchronization (802.1AS gPTP), stream reservation and transmission protocols (IEEE 802.1Qat SRP and IEEE 1722) have been developed, and new mechanisms for forwarding and queuing frames have been proposed."
Key words I'm picking out here are these protocols: IEEE 802.1Qat SRP and IEEE 1722
Stream Reservation Protocol:
en.wikipedia.org
Both the fm and Sirius are always present and being sent to the MCU at the same time. That's how it knows the station list of currently available staying even when you were previously on Sirius just before. The Harmon tuner in the model 3 is always background scanning and sending data regardless.
This matches the description of how IEEE 802.1Qat SRP seems to work. IEEE 802.1Qat SRP and IEEE 1722 along with a number of other protocols appear to be all wrapped up in a larger standard called AVB (Audio/Video Bridging):
en.wikipedia.org
I had borrowed a friends Ryzen based car at one point and I saw in Wireshark it looks like it requests the Sirius audio for a certain channel, tuner starts sending it, then the MCU fails to open the stream, glitches out and goes back to fm. Its all in a weird non encrypted binary format it send the commands.
That "weird non-encrypted binary format" feels like it might be the AVB stream. So how do we take this stream and decode it externally? There appears to already be work on support with GStreamer and ALSA in Linux. Including a sample implementation of Talker
AND Listener! Here:
Getting Started with AVB on Linux* — TSN Documentation Project for Linux* 0.1 documentation
[/B]
gst-launch-1.0 clockselect. \( clock-id=realtime \
avtpsrc ifname=eth0.5 ! avtpcvfdepay streamid=0xAABBCCDDEEFF000A ! \
queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! \
vaapih264dec ! videoconvert ! clockoverlay halignment=right ! autovideosink \)
[B]
The above is for a video stream, but the elements are there. We'd likely be in the dark on some needed values such as clock timing and frame size. External decoding would require some amount of computing power. Would a small SoC based system such as a Raspberry Pi be able to? Do the libraries exist compiled for ARM that would be required? Alternatively could an x86 based SFF system such as an Intel Nuc survive in a hot car? Those are question to address if the decoding is successful using desktop computing power.
If stutech has those wireshark dumps from the Ryzen car, it might be enough to get started. Honestly, I'm slightly beyond the edge of my knowledge here on the software side.
Has anyone explored down this line of thinking yet? If so, what have you found?