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!

[dino]

Hi @rhys_m

Thank you very much for your reply! Unfortunately the past few weeks were a little bit too busy to continue with my research, but I hope its better now

I’ve read your answers again and again, but still I do have some questions:

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.

I understand, that you think the USB standalone version might wouldn’t work since it can only force connect “the” amplifier - since my car has three amplifiers you are not sure if it works as intended.
Is the following assumption correct?: Every amplifier is part of the same FBlock (e.g. 0x22) but the Entertainment Head Unit (EHU) and the amplifier “front” and “back” have their own InstanceID. The connection master (in my case probably the EHU or maybe also the network master ICM) connects the source e.g. Radio to each sink (all 3 amplifiers).
→ so the “override amplifier” could work if the correct command can be sent by the USB-Standalone/PiMost and the the connection master handles the rest? However, if you replicate and imitate an existing module I guess you do not have to deal with this - you just send the commands that the original module would have sent.
→ could it also be the case, that the music is sent to a “group address” and every amplifier is just part of this group?

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.

I guess you physically added 2 PiMOSTs to the ring to imitate both nodes. I guess there is no way to replicate both devices on one PiMOST (adding 2 or more addresses to the same chip)?
Where did you place both devices in the ring: both at the end of the loop just in front of the ICM to see both messages (from the ICM and the touchscreeen) - or did you place one right after the ICM and the other one right after the touchscreen? I guess the space in the car also limits the options that you have…

When you say “the touchscreen” you are not talking about the ICM if I understand you correctly (ICM and Touchscreen are two separate nodes in your car)? In my car, the ICM (MOST master and gateway to I- and P-Bus) has a built in display, unfortunately not a touchscreen, which displays track information, a few limited settings, the old navigation system,… so I would need to replicate and imitate the ICM plus at lease one other node to achieve the same as functionality as you in your XF.

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.

Well I am not sure, but everything I have read so far points in the direction (like you said) that you would need to go to a dealer to update the list of nodes in the ICM if you add/remove a device and that it can cause issues if you add a used device, which has not been properly divorced from the previous car - but I do not have any experience.
→ When I think of it now - if you set the PiMOSTs address to the same as an existing node in the ring it should not be disabled, since the required answer from that node will be passed to the ICM, which in turn does not see that 2 devices with the same address are present, correct?
→ I’m a bit lost tho on how that works with the USB Standalone version. I guess it still requires an address, but apparently not an existing one? In this case, does it only add information to the message without being able to read anything? If something like security on MOST exists, this will cause issues if you cannot update the list in the ICM, correct?

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!

What exactly is meant by an “empty address”? Is it an address of an original component which is just not present in the car (like in my case e.g. the rear CD changer) or is it a completely new address which you know that it has never been used in this type of car for anything else?

I hope you or anyone else can guide me in the right direction Thanks!

[dino]

Hi @rhys_m

I guess you are quite busy getting the USB version ready to launch. Cool that you’re constantly improving something
At the moment there are no PiMOSTs available apparently and since the “override amplifier” might not be a good option for my multi amp set up, I guess it does not make too much sense to start with the USB version? Any idea when the next batch of PiMOSTs will be available?

If you or anyone else could try to answer my previous questions I would appreciate that
Thanks already in advance!

[rhys_m]

Hi Dino,

Sorry I missed your last post

I understand, that you think the USB standalone version might wouldn’t work since it can only force connect “the” amplifier - since my car has three amplifiers you are not sure if it works as intended.
Is the following assumption correct?: Every amplifier is part of the same FBlock (e.g. 0x22) but the Entertainment Head Unit (EHU) and the amplifier “front” and “back” have their own InstanceID. The connection master (in my case probably the EHU or maybe also the network master ICM) connects the source e.g. Radio to each sink (all 3 amplifiers).
→ so the “override amplifier” could work if the correct command can be sent by the USB-Standalone/PiMost and the the connection master handles the rest? However, if you replicate and imitate an existing module I guess you do not have to deal with this - you just send the commands that the original module would have sent.
→ could it also be the case, that the music is sent to a “group address” and every amplifier is just part of this group?

You are pretty much correct, however it is just speculation until the messages have been sniffed from the vehicle

I guess you physically added 2 PiMOSTs to the ring to imitate both nodes. I guess there is no way to replicate both devices on one PiMOST (adding 2 or more addresses to the same chip)?
Where did you place both devices in the ring: both at the end of the loop just in front of the ICM to see both messages (from the ICM and the touchscreeen) - or did you place one right after the ICM and the other one right after the touchscreen? I guess the space in the car also limits the options that you have…

Physically the position does not matter, its more just that the loop is continuos. The chip itself only indicates a message has been received if the it is addressed to the address set inside the chip. For the ICM vs touchscreen, my ICM is seperate so you don’t have to replicate both, you just need to know what messages the touchscreen (or other module you want to simulate) needs to send to the ICM

Well I am not sure, but everything I have read so far points in the direction (like you said) that you would need to go to a dealer to update the list of nodes in the ICM if you add/remove a device and that it can cause issues if you add a used device, which has not been properly divorced from the previous car - but I do not have any experience.
→ When I think of it now - if you set the PiMOSTs address to the same as an existing node in the ring it should not be disabled, since the required answer from that node will be passed to the ICM, which in turn does not see that 2 devices with the same address are present, correct?
→ I’m a bit lost tho on how that works with the USB Standalone version. I guess it still requires an address, but apparently not an existing one? In this case, does it only add information to the message without being able to read anything? If something like security on MOST exists, this will cause issues if you cannot update the list in the ICM, correct?

You are spot on with this, it doesn’t matter two nodes have the same address, both stay present on the ring. In terms of security I think you are confusing security with configuration. In JLR the ICM has a copy of the CCF which stores that the car has for example a 12 channel amp, radio, cd player bluetooth but no usb module. The modules should respond to mirror this same configuration. Volvo seem to implement something more based upon serial numbers for security. The standalone mode is purely an extra feature of the USB version. If standalone is switched off it functions the same as the HAT version, and messages are sent to the host, and the host can send messages to the MOST network too.

What exactly is meant by an “empty address”? Is it an address of an original component which is just not present in the car (like in my case e.g. the rear CD changer) or is it a completely new address which you know that it has never been used in this type of car for anything else?

And empty address is one just not used by another module!

At the moment there are no PiMOSTs available apparently and since the “override amplifier” might not be a good option for my multi amp set up, I guess it does not make too much sense to start with the USB version? Any idea when the next batch of PiMOSTs will be available?

The HAT version is likely to be discontinued, the USB versiond does exactly the same (minus a CAN channel) and more

[dino]

Hi @rhys_m

No worries at all! We all have other stuff to do I guess

Your answers seem pretty clear to me now.
One thing I did not realize until now is, that the incoming information also gets passed through the ICM and on the other way out. I thought mistakenly about it, like each loop would be finished once it returns to the master and then a new loop with new information will be startet. Apparently, the master is just a piece in the ring with some special role, but he also repeats the previous information.
Totally makes sense - looking at the picture below the CD changer front (CDCF) only can stream music to the amps if it’s like you described. Thanks for the hint and your answers!

If you could tell me your thoughts about my plan that would be awesome:

My current plan would be to add two PiMOSTs to the ring to sniff the messages. Depending on the situation with the amps (and if there is any security on MOST) I will need to find out if it could work in standalone mode or if I would need to replicate one or two other nodes of the existing ring. If there is security on MOST, this might be the only reason to locate the PiMOSTs between the node I would like to replicate and the master to see the answer from this node to the ICM. I guess the ICM will not pass that information again for the next loop?

To start I would try to find the easiest access to the ring, most likely after the DVD player in the trunk.
I would disconnect the optical connector and place a fibre optic splitter like the one below: To be able to add the DVD player as well as a second fibre optic splitter with the two PiMOSTs connected.

One PiMOST will get the address of the ICM, the other the address of the CD changer front. With this setup it should be possible to sniff the messages between those devices.

Once this works, the PiMOST that had the address from the ICM will get the address of the AMP1 and later AMP2 (maybe even EHU) to see how the music distribution to the amps works.
The CDCF could be the best node to replicate, however alternative nodes might also be an option to maintain the 6 disk CD changer
After that the best plan can be evaluated how to integrate at least one PiMOST into the ring. Mechanical screen removal from the ICM can be accomplished, replacement screen and carlinkit dongle can be ordered…

Does this sound like plan or would you propose something else?

[dino]

Hey Rhys,

Thank you very much! Today, the PiMOST arrived safe and sound.
I’m very curious to do some first tests and see how the integration will work. Hope I’ll find time this weekend

[rhys_m]

Great news! Thanks for confirming, to get started the beta version of most-explorer will work with the usb board, I am doing my best to get some documentation written up. If you get stuck at all feel free to join the slack channel and I can help in real time on there!

Thanks

Rhys

[dino]

Hey Rhys,

This weekend I did the initial setup with help from my brother. We accomplished the following:

• physical integration of the PiMost (power from the car and optical splitter on the ICM)
• power the Pi 5 from the PiMOST (AUX ON)
• setup the Pi with ReactCarplay, SocketMost and MostExplorer
• change config.json clock frequency from 48 to 44
• when switching the ignition on everything starts up and streaming music from e.g. the CD player still works, no errors - however the system has small interruptions from time to time. → In this case “REQUEST REGISTRY” and “GET FUNCTIONS” did not work as you explained in your MostExplorer videos
• However, when powering the Pi with a separate power supply it works for the first 10sec or so. It is possible to register and see the functions of one device. For us it looks a lot like security on most could be the malefactor, or does this sound familiar to you?
• We did not manage to get the carlinkit ccpa to work which I buyed locally second hand, probably a mistake. It seems that it draws a lot of current, especially when charging the phone. The PiMOST was not capable to power the adapter, but it also did not work with a seperate 3A power supply for the Pi. I have the impression something is wrong with the dongle or might be a cheap copy. We have the LIBUSB_ERROR_NO_DEVICE, altought lsusb looks good as well as the udev rules do. Guess I need to buy a new adapter and see if we have more luck.

I would say it was quite successful, altough there’s still a lot of work to do. We did not have the time to investigate more, but maybe you have some good ideas to start with

Thanks!

[rhys_m]

Wow great progress I can definitely help you with some bits!

I’d probably leave react car play for now until the MOST side is all figured out.

The frequency in config.json is no longer needed, no harm it being there but has no functionality. Also for testing sockemost is also not needed, using the beta version of most-explorer it all comes bundled in the app and it connects direct via usb.

Your interruptions and also inability to run request registry is actually a quite straight forward one (I suspect atleast!). I believe you already have a device with the same default address of the PiMost on the network. Using a duplicate address is ok for reverse engineering etc, but it can lead to missed messages. The registry request in particular is many messages long, and if just a single one gets missed then they all get discarded as out of sequence.

For the power, the PiMost should easily power the pi plus dongle, I have that set up running and have never ran into issues, it is very important to use a good quality usb-c cable.

[dino]

Hi Rhys,

Yes you’re right, I’ll focus on the MOST side at the moment, however I’ll probably delete the manual installation of React-Carplay and try the setup-pi script and see if we have more luck with that

Oh, nice to know that socketmost is included in the beta, at least we tried

Wow, that sounds interesting, the default address of the PiMost could already exist in the car! Makes sense with the missed messages too and the short interruptions. We had a heartbeat like message coming trough every few seconds, unfortunately I did not copy it, but there where almost only 0’s, so looked quite empty to me.
We had the opportunity to collect all the node addresses in the ring (which are a lot ) - how exactly can we set the PiMost’s address to a specific one? You do that in the settings > USB, with the node address high and low? On Sunday time ran out and we did not have the chance to find out how this exactly works, so a little help would be great

Yes, I mean thats what you built it for… so I thought it must be the dongle. I used the original usb-c cable from my Airpods Pro, but this might not be enough. I’ll try it again with a thicker and hopefully better cable that I organized in the meantime

Hopefully I can start some new investigations on Friday