MOST USB standalone project

[Jellepepe]

Interesting. If I understand correctly 1 most node is the ‘master’ and usually this is the headunit or gateway in the car system. I would have assumed that the main usecase for these boards is to use them in master mode, but I suppose that may not be the case.
I would have also assumed that (at least a 1st revision) of the USB most board would expose the relevant headers/pads to use it as a defacto hat as well, but from your comments I take it that this is not the case?

I understand you’re probably not willing to share the source for your firmware but I would be more than happy to assist in development if/where needed.

I think I could probably use a headunit to act as a master node if needed, though I would ideally end up writing the relevant firmware to completely replace it, so not only injecting audio, but also changing settings/coding parameters or flashing firmware updates to the most-connected devices.
I have a lot of existing experience with reverse engineering canbus networks, so I expect this should be relatively quick assuming I can get set up, since I have all the relevant modules ready to test on the bench.

I am assuming that since you are working on a Jaguar yourself the usb boards also have the ‘wrong’ timing crystals to work as a master node in a BMW?

[enfive]

Hey rhys_m,

progress looks awesome. I’m also waiting on the release of the USB version and I am dropping in every week to see if there’s something new. I went ahead and build my own custom Mercedes infotainment software, thats true to the original design. All running on a custom Yocto linux OS. The goal is to replace the complete headunit while still looking OEM, but adding features like bluetooth, touchscreen and Carplay. Recently I’ve got bluetooth audio working, so a first test in the car would be my next step. Thats were your project will be coming into play. I also have some experience with in-car programming, so if I can help just hit me up.

Also nice to see you here Jellepepe. I remember your ID7 Launcher and CarRadio App I once had in my old BMW and the old android headunit discord server. I don’t know what you plan exactly is, but replacing the headunit completely in a BMW is not an easy task. I once wanted to do something similar as these chinese headunits, but running my own custom software. For that purpose I was developing an interface board to hijack the LVDS Display signal and offer a hdmi port to connect a raspberry pi. Switching between the original signal and the hdmi input was also possible. Sadly i had a mistake in the board design so i never got a valid signal from the hdmi input to the original CCC display. As i was selling my BMW I never finished it. If that is something up your alley I can give you more info about that.

[rhys_m]

Interesting. If I understand correctly 1 most node is the ‘master’ and usually this is the headunit or gateway in the car system. I would have assumed that the main usecase for these boards is to use them in master mode, but I suppose that may not be the case.

The main use so far has not been as a master, there’s definitely a use case for it, however I am unsure if the HAT may serve a better purpose here, having the canbus channel too is useful when the original gateway also handles the CAN communication. I personally use a HAT version as a 44…1khz master, and use this to test the USB board on at 44.1khz, it does work quite well

I would have also assumed that (at least a 1st revision) of the USB most board would expose the relevant headers/pads to use it as a defacto hat as well, but from your comments I take it that this is not the case?

The HAT does direct spi comms to the MOST chip. The USB version, the MCU does this comms to the MOST chip, however it accepts the same (and currently more) commands that the HAT does over spi, it is just these commands are transmitted/received over USB CDC instead so much more compatible and easy to set up. You can see in the beta version of socketmost the api similarity between the HAT and the USB version. The USB version just also supports standalone mode when the extra features are not needed.

I understand you’re probably not willing to share the source for your firmware but I would be more than happy to assist in development if/where needed.

I will likely release the source code for the firmware when it’s a bit more mature, still lots of learning and development happening, and likely will do for some time as people are testing/feeding back.

I think I could probably use a headunit to act as a master node if needed, though I would ideally end up writing the relevant firmware to completely replace it, so not only injecting audio, but also changing settings/coding parameters or flashing firmware updates to the most-connected devices.
I have a lot of existing experience with reverse engineering canbus networks, so I expect this should be relatively quick assuming I can get set up, since I have all the relevant modules ready to test on the bench.

I’ve spent a huge amount of time now reversing CAN and MOST. I would say MOST is generally more straight forward, alot of the devices I have looked in to generally follow the MOST specification making it very easy. Sometimes, such as in JLR certain FBlocks like the AmFmTuner are completely custom, which then make it more of a pain. The way I have found best is to take the same address as the OEM FBlock, and then you can see all the messages that come in on any actions you perform. Then you can take the address of the device sending those messages and see the messages sent in to it aswell, it’s easier if you have two MOST Hats, but perfectly do-able with one.

I am assuming that since you are working on a Jaguar yourself the usb boards also have the ‘wrong’ timing crystals to work as a master node in a BMW?

I will do the same as the HAT and offer a version with the correct crystal for both 44.1khz (BMW, Mercedes, Saab) and also one for 48khz (JLR, Volvo etc). When not in master mode, if the board is set to legacy mode the crystal doesn’t matter.

[rhys_m]

Hi @enfive

That sounds like quite the project! Would love to know more about what you have done in Yocto Linux, what language are developing in? Any screenshots or project info?

[enfive]

Basically it is a Flutter application which sits on top off a yocto linux distro. Same approach as Toyota actually uses with their current infotainment systems. I also use some stuff from AGL (Automotive grade Linux) for my distro. I originally wanted to use QT like everybody else, but as their license stuff is very complicated I decided to do it differently.

In the yocto distro itself there is actually not much going on. Basic stuff to get the raspberry pi to boot, some display and touchscreen drivers as well. The audio is handled by pipewire which also talks to blueZ to enable bluetooth audio. So all the connectivity stuff is handled by the OS itself. The application only tells the OS what to do. Also chose yocto, because it easily allows you to cross-compile for different hardware. Makes switching the SBC very easy in the future.

Visually it is close to the Mercedes NTG 1 infotainment found in the W211 E-Class. But mostly the Mercedes models from around 2003 - 2008. Reason being is Mercedes in their infinite wisdom has only MOST25 and power going to the headunit itself. everything else is handled in the back of their cars. That makes replacing the headunit very annoying since you basically need to install a new wiring harness from front to back. and even then it won’t really work with higher end audio amplifiers from harman kardon.

All i want is bluetooth with steering wheel controls and maybe carplay, but as this is not easily archieved with chinese headunit (and i also hate them because they are verry poorly designed) I started to build my own. I added some Screenshots of the current (but early) state of the app. There are more menus and screens, but they are not that interesting.

And this is what i am trying to copy:

[Jellepepe]

Hi @enfive Very cool to see you recognising me haha

I’m currently initially working on an approach to fully integrate the newer oem bmw infotainment in older bmw cars, but retaining all functionality. One of the issues is that the older most amplifiers don’t work correctly with the newer headunits, and the newer amplifiers dont have the appropriate coding/offsets to work well with the older chassis/speaker setups. My car has the individual audio package and I want to retain as much of that quality as possible.

My end goal would be to completely replace the headunit though like you said, The original system (even the newer ones) don’t really offer much beyond what I am able to make myself other than better integration with the canbus/most networks, so I am working on that now. If I do use an original screen I would want to use the newer screens though (apix2 w/ touch) so I doubt that your work on the LVDS CCC screens would be very relevant anymore, but I appreciate the offer.

Also, very cool to see you are also using Flutter, in my experience its great for creating relatively complex UI while remaining performant & easy to maintain.

@rhys_m Very nice to hear! Being able to use the USB mode in ‘passthrough’ (aka using USB CDC to basically communicate directly with the MOST chip) was what I was hoping to hear. I will likely design my own pcb for a final solution to install in my car, so I don’t mind the lack of a complete all-in-one solution for now (for example the lack of canbus is irrelevant, I have my own hardware for that during testing if need be).
Also cool to hear you are considering releasing the firmware source, that would be interesting to have a look at when I getting to the stage of implementing my own solution to install in the car.

Keep us updated on when you are ready to send some boards out!