MOST bus integration into SAAB 9-3 II

dino · 28 July 2025 19:28

Hey Rhys,

Yeah I can imagine and I did not expect you to reply so fast! So no worries at all, take your time and enjoy - I still have a lot of work to do! funny bug indeed!
I’ll keep you posted about the progress on my side

Lappihuan · 2 August 2025 12:12

Hi @rhys_m
I’m @dino’s brother, we talked before a few months ago.
Congrats on the new born!

We were trying to find the forceSwitch recently and ended up figuring out it had to be in the firmware.
Is there any chance to make the source code of it available?
I did find this in the forums:

I think it would help anyone that is willing to look into it closer to understand whats going on since it is a missing piece of the puzzle, but only if you feel comfortable with it.
Additionally i could try and help with the triple amp setup.

rhys_m · 2 August 2025 20:07

Hi,

all that’s happening in the firmware level is the same as what is in the socketmost drivers, just implemented in C instead, if you take a look at this function it is the exact same process

github.com

rhysmorgan134/SocketMost/blob/050806f3311f10d48023ea7d03b4963afd0cde7c/src/driver/OS8104A.ts#L713


      
              case 4:
                result.answer = 'WRONG_TARGET'
                break
              default:
                result.answer = 'ERROR'
            }
            this.logger.debug(`deallocate response: ${JSON.stringify(result)}`)
            return result
          }
          
          stream({
            sourceAddrHigh,
            sourceAddrLow,
            fBlockID,
            instanceID,
            sinkNr,
          }: Stream): void {
            this.allocResult = {
              loc1: -1,
              loc2: -1,
              loc3: -1,

With the 3 amp setup, it i will just need to the connect source function for all 3 amplifiers

dino · 9 August 2025 16:56

Hey @rhys_m

Thanks! I started looking at the socketmost drivers - if I’m correct, it uses the function ID’s Allocate (0x101), DisConnect (0x112) and Connect (0x111) as discussed before, but I will need to go into more detail. In the meantime I can give an update on the project progress:

Electrical integration:
The PiMost gets powered from the permanent plus (+30). As intended, the optical signal wakes up the PiMost. The RPI gets powered from the PiMost’s “AUX Power” and starts up as soon as the optical ring starts its operation. The CarlinKit Dongle obviously receives power from the RPI.
The ICM (head unit) powers my self-designed PCB and delivers the signals for the screen brightness. My PCB controls the LED backlight for the new touch screen (with original stock behavior including nightpanel, manual brightness adjustment, automatic brightness control according to existing sensors ) and powers the screen PCBs for HDMI input and touch.
TODO: Check shutdown process of AUX Power (RPI restarts every few seconds after shutdown). Additionally check (and improve) boot time of the RPI.
TODO: Find best parameters for startup and shutdown delay (btw does React Carplay provide the functionality to shutdown the RPI once the PiMost received the shutdown message?)
Mechanical integration
The old screen will be removed from the ICM and replaced by the new touch screen once I’m sure I don’t need the old UI anymore. The dashboard will have 100% stock look, except for the screen content of course. One screen PCB will be inside the ICM, as well as my self-designed PCB. The second screen PCB will most likely sit on top of the ICM, if there is enough space below the air passage. The latter contains the HDMI and touch jacks. The RPI and PiMost will need to be placed deeper in the dashboard on the left side from the air passage (driver side).
TODO: Remove old screen (once I don’t need the ICM’s UI anymore) and integrate the new one
TODO: Integration of all PCB’s inside/on top of the ICM and check thermal management
TODO: Integration of RPI and PiMost and check thermal management and check if vent noises need to be reduced
MOST sniffing:
I somehow managed to duplicate the EHU once (with loss of music and also missing data on the ICM screen) but I found the command to switch between the available audio sources🥳 It means we have a connection master in the ICM, but additionally we do have a proprietary connection master in the EHU. With a single command I can switch between AmFmTuner, AUX and CD changer as if I would do it on the ICM or the steering wheel💪 Unfortunately, I did not manage yet to switch to the PiMost with this command until now, but maybe only known audio sources can be handled. If I switch to an unknown souce the currently streaming audio source gets interrupted/paused e.g. the CD changer.
I sniffed all the commands in the “AUDIO” section: bass, treble, fader, balance and all settings in the advanced section. Additionally I do have the steering wheel controls for skip forward/backward, SRC, volume up/down on the MOST side.
As we managed to do the force switch, followed by manual disconnection & connection of the remaining amplifiers I think, that if I want the audio to be streamed via PiMost I can send the command to the proprietary connection master to switch to an unknown audio source and then force switch to the PiMost. If I switch back to CD e.g. the audio switch happens automatically. I think it should even be possible to pause the audio streamed via the phone with the existing functionality of React Carplay, if I’m correct. Alternatively, if I manage the proprietary connection master to switch to the PiMost directly it might be even more straight forward, we will see!
TODO investigate the proprietary connection master and check if its possible to switch to the PiMost directly
TODO investigate the SrcDelay and it’s impact on the audio quality if possible
TODO test a complete manual audio switch with an allocate, disconnect and connect
TODO additional optional sniffing of available data on the MOST ring (probably once everything else is working and I still do have energy for it😅)
Software:
The most basic functionality should be implemented in React Carplay already and with the upcoming firmware for the PiMost the standalone force switch should work as intended. As you know, I’m thinking about a little bit deeper integration, where we could do something similar as you did for the JLR (maybe not on such a detailed level as you did ). I need to talk to my brother, but I think it might be worth to build the raw framework and get it to work, before I actually start with the “final” mechanical integration as described above.

As @Tigo suggested, we updated the firmware on the PiMost to v0.1.0 and the microphone started working, but we thought it has poor quality - in the meantime I realized, that we updated to the only available released firmware of v0.1.0 without noticing that it is for 48kHz → The result is stuttering music via the PiMost (and I assume as well for the mic input). Therefore, I downgraded now to v0.0.11 (3 byte feedback version → Or should I go to the 4 byte version for some reason? Btw which feedback are we talking about here?). v0.1.0 had a “reset” of the PiMost after “send to dongle”, which comes in very handy to switch between duplicating devices - nice job Rhys! Idk if it would be easy to release v0.1.0 for 44kHz as well, but I think I can wait for v0.1.1:blush:
Something that crossed my mind regarding this topic: If I remember correctly, the PiMost can work on 44kHz and 48kHz with the same firmware, as long as he’s a slave (please correct me if I’m wrong - If he would be the master it requires the correct crystal on the board). I assume that the frequency information must be available on the PiMost and I was wondering if the “soundcard” could adapt automatically as well, or if that might be too complicated? Just a thought and I have no clue of whats going on in the firmware😜

You see, there’s a big progress on my project and I’ll keep you posted! Everyone please feel free to comment… it always helps a lot!