MOST bus integration into SAAB 9-3 II

[dino]

hi all

I am completely new to this topic, but I stumbled upon the PiMOST and it immediately piquet my interest.

It all started with the FM shutdown in my country at the turn of the year. My car has a great sound system, but now all that’s left is a 6-disc CD changer, an AUX port and a a very outdated navigation system. As in the past I could use my phone for navigation and stream music over the AUX port or update my car (if not already present) with a bluetooth module. Apparently, there is no replacement head unit available for my specific car (SAAB 9-3, 2006), so I thought about alternative solutions:

• I could buy one of this portable CarPlay/Android Auto units, but I don’t like the idea of mounting an additional screen on the dashboard. If it’s not the phone solution that I currently use, it would require a much more integrated solution.

• I thought about buying and disassembling a cheap small portable unit (e.g. for motorbikes) and replace my existing 5.8“ screen (connected to the AUX port). However, some of the settings (like balance e.g.) would need to be set blind on the head unit and more importantly - it may look integrated, but all the steering wheel controls would be lost. If I invest something in an integrated solution, then only with with workin steering wheel controls.

• I found an amazing project from Saab Unleashed with a Pi and a touchscreen creating the same independent solution as with the portable unit or dankfred’s super cool I-Bus integration with a Pi, an additional microcontroller and a CAN module. Both running on (the discontinued) Open Auto Pro. It might be possible to replicate dankfred’s project with available versions of Open Auto (Pro).

Looking for alternative head unit emulators I finally found Rhys React-Carplay and his unique PiMOST.

@rhys_m It looks like you invested A LOT in in your projects, creating everything from scratch - highest respect for you and your work!

@keshka Did you manage to get things working on your SAAB 9-3? I know it has been more than a year since your last post, but I would be very interested in any information that you would like to share, especially if we do have the same car generation (2003-2006). From the picture of your CD player I can see that at least the CD player has been manufactured in 2003, so it looks promising Have you managed to verify the MOST-bus frequency of 44.1kHz?

I do have a SAAB 9-3 NG (II/SS) pre facelift (YS3F) 5-door from 2006 with prestige 300 sound system.

There are three types of bus communication: P-bus (Powertrain Bus), I-bus (Instrument Bus) and O-bus (Optical bus). The audio system communicates via the O-bus together with the navigation system, the telephone system and others. The O-bus is optical and is a ring bus. Two fibre optical cables are connected to each control module on the bus, one fibre optical cable for receiving and one for sending. Messages received are converted by each control module from a fibre optic signal to electrical and then converted back to optical for sending. The O-bus data transfer rate is 25 Mbit/s.
source

Therefore, the O-bus is a MOST25 bus which would be compatible to the PiMOST, frequency most likely 44.1kHz(?). My biggest question at the moment is what would be the best/easiest way to integrate it into the existing equipment and what would be the benefits for each solution.

At the moment I see the following potential solutions:

A) replacing the ICM head unit completely, hence the PiMost would be the new MOST master. I believe this would allow to do almost anything that could be done, including a retrofit of a touch screen in the dashboard. But it also sounds like a lot of work, since all Interfaces to the ICM (P-Bus, I-Bus and other interfaces such as SID, SIDC,…). Although there is some information available for the SIDC and the I-Bus (and with access to the forum here) it seems like a lot of work that needs to be done - sniffing all the required messages for all 3 bus systems (an additional interfaces) and handling over the correct information to the correct device. Of course it would also require an additional CAN bus channel on top of the existing one in the PiMOST (like the MCP2515).

B) replacing one of the existing components such as the DVD unit (maps for the navigation system) and/or positioning unit which most likely has „the rights“ (if something like this exists?) to get notified about lot of data (maybe even microphone input?), sending audio (and video?) over the MOST. In this case it might be possible to use the existing screen in the ICM (i know it has a poor resolution, and I might run into the „change resolution carlink“ topic). In CarPlay it might be possible to cycle through the menu with the existing knobs/wheels or maybe just with Siri. I’m a bit scared of the „security on MOST“ which checks for approved serial numbers. It looks like not only some Volvo’s are protected with what they call theft-proof. It might be possible to see the required data with the divorce/marriage function of a Tech2? Adding the PiMost to the existing ring and sniffing the answer from the existing DVD unit before the PiMOST will be set to disable mode might works as well - does anyone have experience with this? Additional Information about this topic at the end of this post.

C) Adding the PiMOST to the MOST without removing anything would require to update the list of control modules in the ICM. It looks like this would be possible with a Tech2, but maybe only for predefined OEM components (such as the CD changer rear)? Anyone knows more about that or how to achieve it without a Tech2? In this case it might be possible to get notified about all available data and also have „the rights“ to stream audio/video over the MOST

Does this make any sense? Or would there be easier ways to achieve the integration of the PiMOST?

I guess any input from anyone would help me a lot, since you most likely had to take care about the same topics for your project.

If I misunderstood something, please also give me a hint - I am willing to learn

For anyone who would like to read more information about the MOST in my car and maybe give a specific advice/answer here’s a collection source:

- I-bus, one lead:

When the key is inserted into the ignition, the CIM (Column Integration Module) wakes the other control modules on the I-bus by briefly sending B+ over the bus. The CIM then sends regular reports over the bus of the key position.

- P-bus, two leads:

The P-bus system has a +15 lead coming directly from the ISM (Ignition Switch Module). With the ignition switched on, communication goes on continuously. Communication stops as soon as the ignition is switched off. The P-bus does not have a wake-up function similar to that of the I-bus.

- O-bus, MOST25 ring bus:

None of the modules on the O-bus have a +15 lead. All the modules wake up when they receive a light pulse and remain awake so long as a module is communicating. Pressing a button on the ICM (Infotainment Control Module) is the most reliable way to wake the bus immediately.

The ICM is the master in the MOST bus and also acts as a gateway to the two CAN bus systems I-Bus and P-Bus. The ICM (with its own display) is also the control unit for the Saab Information Display „SID“ and the SID control Panel „SIDC“ (5V 960Hz PWM signal). Both connected through what they call a C-cable (serial bidirectional 10kbit/s single wire bus for slow communication between two modules).

source
MOST-Bus Components (italic assumingely not present in my car):

• Control panel, infotainment, ICM (736)
• Communication unit, Positioning unit, CU/PU (468/635)
• Unit, DVD (729)
• CD Changer Rear, CDCR (355R)
• Audio System Amplifier, rear speakers, AMP2 (354R)
• Audio System Amplifier, front speakers, AMP1 (354F)
• Entertainment head unit, EHU (353)
• CD player/changer, front, *CDF/*CDCF (355F)

The prestige 300 sound system involves two additional physical amplifiers (connected through the O-Bus) on top of the amplifier in the Entertainment Head Unit (EHU).
@rhys_m Is it possible to add more than one amplifier in the react-Carplay configuration?

source

• Entertainment head unit, EHU (353)
• Audio System Amplifier, front speakers, AMP1 (354F)
• Audio System Amplifier, rear speakers, AMP2 (354R)
• Control panel, infotainment, ICM (736)
• SID (541)
• Speakers, dashboard, left/right (266 FL/FR)
• Speakers, rear, left/right (266 RL/RR)
• Speaker, dashboard, centre (266 FC)
• Speakers, front door, left/right (266 LH/RH)
• Speakers, woofer, rear (266 RCW)
• Antenna (625 RL/RR)
• Antenna amplifier, radio (624 RL/RR)
• Steering wheel controls (633)
• Column Integration Module, CIM (703)
• Connection, AUX (771)

The audio system communicates via the O-bus together with the navigation system, the telephone system and others.
source

source

• Electrical centre, dashboard (22)
• Speaker (266 FR, FL)
• Entertainment Head Unit, EHU (353)
• Antenna, GPS/GSM (467)
• Navigation unit, CU/PU (468/635)
• SID (541c)
• Steering wheel controls (633)
• Rear Electrical Centre, REC (701)
• DVD unit (729)
• Control panel, Infotainment system 3, ICM3 (736c)

Additional information about components MOST, „marriage“ to the car, respectively security on MOST in my car:

Additional control modules can be connected. Each control module must be connected to a specific place in the ring as compensation has been made for the short delays in communication.
source

It is very important that everything connected to the O-bus is connected in a specific order, see illustration, and that the ring is closed the whole time. Connection in any other way than that described in these fitting instructions may result in several of the car’s systems failing to work.
source

ICM contains a list of the control modules on the O-bus and can compare this list with incoming bus messages to determine the location of a break on the O-bus. The diagnostic tool is used to update the list of control modules in ICM when a new control module is fitted to the O-bus. The P-bus and I-bus are wired to the data link connector. Tech 2 can be connected with an adapter to the data link connector and communicates directly with the various control modules on the P-bus and I-bus. Diagnostics communication with O-bus systems takes place via the ICM, which acts as a gateway.
source

… , all O-bus control modules provide diagnosis and generate a DTC if they receive a corrupt message. All messages received are converted into electrical signals, reconverted into light and retransmitted. The ICM is the bus master and, unlike the other modules, never resends a corrupt message. If a control module receives a corrupt message, the fault must have occurred upstream, somewhere between the control module and the ICM. This means that a fault will generate a DTC for an intermittent bus fault in all the control modules downstream.
source

The ICM contains lists of all the control modules on the three busses in the car in question. When you read out DTCs, Tech2 always starts by contacting the ICM to check which control modules should be present in the vehicle. Tech2 then checks which control modules in the car are communicating. If a control module is missing, or if an additional control module has been fitted, this is displayed. Nothing is displayed if the numbers of identities agree. If there is a difference, you are given the opportunity to start fault diagnosis or to accept the new control module configuration. You may wish to accept the new configuration if a control module has been fitted or permanently removed. Tech2 will then update the lists in the ICM so that no warning is displayed in the future. Tech2 displays if a control module on the bus is missing. This means that if all control modules connected to the buses are communicating correctly, the diagnostic tool does not display a warning. If one of the O-bus systems is missing, the entire O-bus will be down, and in which case there will be a DTC in the ICM. To find out where the break is, disconnect then reconnect the battery cable. All O-bus systems will then be initiated at the same time, allowing the ICM to calculate how many control modules sent a light signal, in other words, how far back along the ring the break is.
source

[rhys_m]

Hi @dino

There’s a wealth of information there! I’ll start with some current working implementations.

1. “overriding amplifier” in a MOST set up the amplifier is connected to 4 channels, when you choose a source, lets say switching from radio to CD the following happens

• message is sent to the CD player to start streaming on to the network (aka allocating)
• CD player requests an allocation of 4 bytes
• network master responds with those 4 bytes
• CD player is no sending audio out on those 4 bytes
• radio then receives a message to deallocate it’s own 4 bytes
• amplifier then receives a message to disconnect it’s sink from the 4 bytes that the radio was playing on
• amplifier then receives a message to connect it’s sink to the 4 bytes from the CD Player

what we can do with a pimost is to override the sink connection on the amplifier and directly connect it to the pimosts 4 bytes. This is easy and works great, the only issue is it’s not “integrated” so if you then press aux, amplifier will switch to aux and the pimost has no knowledge that the amplifier is no longer connected to it’s own audio. This is how “standalone” mode on the new usb board works. When a host device opens up the soundcard interface on the board it then force connects the amplifier to it.

2. Replacing an imitating an existing module. This is what I have done in the XF, actually I am imitating 2 modules, the touchscreen and also the ipod module. This required a bunch of reverse engineering on the MOST signals. I would set two PiMosts up, one duplicating the master (both are actually present and active) and the other duplicating the device to replace. I would then power the system on, and log messages on them both. From this I can then filter the messages to see the message sent to a module, and also the response from the module. I then implemented my own version where I responded to the messages in the same manner the original module did, removed the module and it works great. The best part of this, is if I had the original screen in, and chose ipod source, I would receive all those automated messages listed in the flow above. And can even update song names, albums, time playing etc etc as if it were a standard module. I had issues as the whole connect/disconnect flow was wrapped around some non standard messages and fblocks but I was able to do it. If you have a connection master fblock (not one in the JLR setup, they created their own) then it is likely much more straight forward.

In terms of streaming video over most, it is capable, but I haven’t seen this implemented anywhere in MOST 25 systems.

Another issue with Saab, @mahnat has done a bunch of testing (yes it’s 44.1khz), is the strange multi amp set up. We can likely no longer do the override in the usual way since you have multiple sinks that need connecting, I am unsure how Saab handle this as I haven’t been able to test myself, but I suspect it may use a connection master, either the standard one or a proprietary one.

MOST is a great way to look to do this, it just depends how much you want to investigate yourself, @Tigo can verify but audio quality is vastly superior to using aux, which when like yourself you have a decent sound system in your car, you really get the benefit from it.

[dino]

hi @rhys_m

Thank you for taking the time to answer my questions! I think most of it makes sense to me, in other places I’m probably still a bit lost.

I understand your first point as follows: during initialisation the PiMOST sends the amplifier the command to use its own 4 bytes instead of those from the previous source (analogous to the network master when changing the music source). Is the previous source also told to deallocate its 4 bytes at this moment? In any case, if the network master now sends a new command to switch the source, the PiMOST is not informed to deallocate its 4 bytes, as the master probably thinks that the previous source is still streaming. The PiMOST then streams into the void, so to speak. Correct?

From this perspective, your second proposed solution makes more sense to me. Again, I understand most of your explanation and I don’t yet know whether SAAB has orientated itself on the standard template or has also gone its own way. Input from @mahnat or other SAAB & PiMOST owners would of course be very helpful here.
What I still can’t figure out is how exactly to put the beginning of your description into practice. Physically, both PiMOSTs (one downstream of the master and one downstream of the device to be replaced?) are integrated into the ring. From my research so far, I have also understood that the PiMOST can also have messages addressed to other devices in the ring sent to it (if its FBlock and instance ID are known). If SAAB has not adhered to the standard template, then the respective addresses of the master or device to be replaced would first have to be filtered out of the entire message traffic by deliberately addressing the corresponding device from the master, for example, I assume. However, this can only work if both PiMOSTs are not deactivated (bypass mode) by the master after a short time (security on MOST), or must there simply be enough time for this?

Thanks for the hint about the video, I assumed that the maps (displayed on the ICM) on the DVD will be provided from the DVD player to the navigation unit over MOST, which in turn then provides a video signal over MOST to the ICM. But that was just an assumption, appearently there might be an additional cable for that - guess it should not be too difficult to find out if I remove a few covers.

I assume that the 3rd possibility to replace the ICM head unit completely could propably work as well (and for sure be a bunch of work), but you would not suggest that necessarily.

Thanks as well for the feedback regarding the frequency - and I hope you will find time to stay in the loop

[rhys_m]

I understand your first point as follows: during initialisation the PiMOST sends the amplifier the command to use its own 4 bytes instead of those from the previous source (analogous to the network master when changing the music source). Is the previous source also told to deallocate its 4 bytes at this moment? In any case, if the network master now sends a new command to switch the source, the PiMOST is not informed to deallocate its 4 bytes, as the master probably thinks that the previous source is still streaming. The PiMOST then streams into the void, so to speak. Correct?

Pretty much spot on. If the board (USB version) is running with a host attached, you can send a command built in to the driver to force it to reconnect. I personally tie this to the button used on the touchscreen for carplay

From this perspective, your second proposed solution makes more sense to me. Again, I understand most of your explanation and I don’t yet know whether SAAB has orientated itself on the standard template or has also gone its own way. Input from @mahnat or other SAAB & PiMOST owners would of course be very helpful here.

Every manufacturer I have seen so far do an amalgamation of their own implementation and other bits standard.

What I still can’t figure out is how exactly to put the beginning of your description into practice. Physically, both PiMOSTs (one downstream of the master and one downstream of the device to be replaced?) are integrated into the ring. From my research so far, I have also understood that the PiMOST can also have messages addressed to other devices in the ring sent to it (if its FBlock and instance ID are known). If SAAB has not adhered to the standard template, then the respective addresses of the master or device to be replaced would first have to be filtered out of the entire message traffic by deliberately addressing the corresponding device from the master, for example, I assume.

I think you are a bit off on this one, all messages are analysed by the OS8104 chip, only if the message is addressed to the address of that chip does it even allow you to read that message out. Otherwise it just repeats it off to the next node. The trick here is that you can set the address of the pimost to the same as another module, you then receive those messages for that module and so does the original module. Doing this works 95% of the time, sometimes you may miss a message as once the target node has received that message, another node may then overwrite that space on the loop, however in practice this is pretty rare and I have successfully figured out all the messages from the touchscreen in my XF using this method. Having 2 pimosts makes it a bit easier as you can capture messages into a node, and also responses from that node. Think of a basic message such as parking sensors on. ICM for me sends a message to the touchscreen. Touchscreen then sends a response back. If I have a pimost duplicating the addres of the touchscreen and another of the ICM, I can then see the entire 2 way message from them both.

However, this can only work if both PiMOSTs are not deactivated (bypass mode) by the master after a short time (security on MOST), or must there simply be enough time for this?

Are you sure that Saab has security on MOST? I have only heard of it implemented in volvos, however in practice we are yet to see it cause any issues. I don’t think it’s so much security, I think it’s just to force you to go to a dealer if you want a new module fitted. In volvos @Tigo has been using a pimost on an empty address and hasn’t seen any MOST issues so far. We have also done the duplicate address in his car and still not seen any issues!