Difficulties configuring the MOST section

Today, I restarted configuring piMost following exactly the instructions from the Socket-most GIT page.

In my configuration, there is a slight change: the /boot/config.txt has moved to /boot/firmware/config.txt.
Similar, I expect the system to look in the /boot/firmware/overlays directorate. For security, I moved the overlay in both the /boot/overlays as in the /boot/firmware/overlays, just to be safe.

When I run the checking routines for MOST, I get errors (see below).
==> What to do?

raspberrypi4b2:~ $ journalctl -u socketmost.service -b
Mar 04 14:57:09 raspberrypi4b2 systemd[1]: Started socketmost.service - socketmost.
Mar 04 14:57:14 raspberrypi4b2 node[837]: info: config file exists: {“version”:“1.0.0”,“nodeAddress”:272,“groupAddress”:34,“freq”:48,“mostExplorer”:true} SocketMost
Mar 04 14:57:14 raspberrypi4b2 node[837]: warn: couldn’t unlink socket, might not exist already SocketMost
Mar 04 14:57:14 raspberrypi4b2 node[837]: info: creating driver nodeAddress 0x110 groupAddress: 0x22 freq: 48 SocketMost
Mar 04 14:57:14 raspberrypi4b2 node[837]: info: GPIO config: {“interrupt”:5,“fault”:6,“status”:16,“mostStatus”:26,“reset”:17} OS8104 Driver
Mar 04 14:57:14 raspberrypi4b2 node[837]: info: starting up OS8104 Driver
Mar 04 14:57:14 raspberrypi4b2 node[837]: info: resetting OS8104 Driver
Mar 04 14:57:14 raspberrypi4b2 node[837]: info: most explorer enabled, starting server… SocketMost
Mar 04 14:57:14 raspberrypi4b2 node[837]: Listening for Most-Explorer requests on 0.0.0.0:5555
Mar 04 14:57:14 raspberrypi4b2 node[837]: info: initial reset complete carrying out init OS8104 Driver
Mar 04 14:57:14 raspberrypi4b2 node[837]: info: running config OS8104 Driver
Mar 04 14:57:14 raspberrypi4b2 node[837]: addressLow: 0x10 addressHigh: 0x1 groupAddress: 0x22
Mar 04 14:57:14 raspberrypi4b2 node[837]: warn: most error active OS8104 Driver
Mar 04 14:57:14 raspberrypi4b2 node[837]: Error 1 91
Mar 04 14:57:14 raspberrypi4b2 node[837]: error: parsing fault mask: 5b OS8104 Driver
Mar 04 14:57:14 raspberrypi4b2 node[837]: error: Error: transceiver lock error OS8104 Driver
Mar 04 14:57:14 raspberrypi4b2 node[837]: warn: transceiver unlocked OS8104 Driver
raspberrypi4b2:~ $ cd SocketMost
raspberrypi4b2:~/SocketMost $ npm run test:messaging

socketmost@2.0.31 test:messaging
ts-node testing/test.ts

Error: ENOENT: no such file or directory, unlink ‘/tmp/SocketMost-client.sock’
at Object.unlinkSync (node:fs:1881:3)
at new DataGram (/home/frits/SocketMost/testing/testclient.ts:24:10)
at Object. (/home/frits/SocketMost/testing/test.ts:3:16)
at Module._compile (node:internal/modules/cjs/loader:1356:14)
at Module.m._compile (/home/frits/SocketMost/node_modules/ts-node/src/index.ts:1618:23)
at Module._extensions…js (node:internal/modules/cjs/loader:1414:10)
at Object.require.extensions. [as .ts] (/home/frits/SocketMost/node_modules/ts-node/src/index.ts:1621:12)
at Module.load (node:internal/modules/cjs/loader:1197:32)
at Function.Module._load (node:internal/modules/cjs/loader:1013:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:128:12) {
errno: -2,
syscall: ‘unlink’,
code: ‘ENOENT’,
path: ‘/tmp/SocketMost-client.sock’
}
connecting /tmp/SocketMost.sock
connected
connected

Hi Frits,

I don’t see anything untowards in the logs. Is this connected to a MOST network or on the bench?

Thanks

Rhys

My log for comparison when the MOST network is turned off

info:    config file exists: {"version":"1.0.0","nodeAddress":353,"groupAddress":34,"freq":48,"mostExplorer":true} SocketMost
warn:    couldn't unlink socket, might not exist already SocketMost
info:    creating driver nodeAddress 0x161 groupAddress: 0x22 freq: 48 SocketMost
info:    GPIO config: {"interrupt":404,"fault":405,"status":415,"mostStatus":425,"reset":416} OS8104 Driver
info:    starting up OS8104 Driver
info:    resetting OS8104 Driver
info:    most explorer enabled, starting server.... SocketMost
Listening for Most-Explorer requests on 0.0.0.0:5555
info:    initial reset complete carrying out init OS8104 Driver
info:    running config OS8104 Driver
addressLow: 0x61 addressHigh: 0x1 groupAddress: 0x22
warn:    most error active OS8104 Driver
Error 1 91
error:   parsing fault mask: 5b OS8104 Driver
error:   Error: transceiver lock error OS8104 Driver
warn:    transceiver unlocked OS8104 Driver

Dear Rhys, thank you very much for your most valuable feedback. From your non-linked MOST log, I detect an almost identical response. For your information: I see no infrared light at all from the MOST connector on the piMost HAT.

So I best now connect the unit to some form of MOST network. I have the CD unit, a SDARS and a LCD display at my disposal, but no MOST master however. I will let you know.

No problem. You will need a master to be in the network. The PiMost light won’t come on unless it achieves lock to the network in the input.

I do have it on the radar to investigate implementing master mode, but no timeline currently.

What vehicle is your benchtop set up from?

My hardware is all from XFs, but not the same. The screen boots up, emits infrared signal, but I tried today: the piMost does not trigger on that signal: the logs stay the same as above without modification. I will see to find a master (iboc?) to get things moving.

By the way: I removed the 40 pin header as delivered, since I needed a 40 band cable to mount all in a screen casing. I doubt I made any soldering errors.

I’ve just tested mine with no master, I get a small flicker for a few milliseconds and that’s it, nothing more after that.

The logs show the most status

info:    config file exists: {"version":"1.0.0","nodeAddress":366,"groupAddress":34,"freq":48,"mostExplorer":true} SocketMost
warn:    couldn't unlink socket, might not exist already SocketMost
info:    creating driver nodeAddress 0x16e groupAddress: 0x22 freq: 48 SocketMost
info:    GPIO config: {"interrupt":404,"fault":405,"status":415,"mostStatus":425,"reset":416} OS8104 Driver
info:    starting up OS8104 Driver
info:    resetting OS8104 Driver
info:    most explorer enabled, starting server.... SocketMost
Listening for Most-Explorer requests on 0.0.0.0:5555
info:    initial reset complete carrying out init OS8104 Driver
info:    running config OS8104 Driver
addressLow: 0x6e addressHigh: 0x1 groupAddress: 0x22
warn:    most error active OS8104 Driver
Error 1 91
error:   parsing fault mask: 5b OS8104 Driver
error:   Error: transceiver lock error OS8104 Driver
warn:    transceiver unlocked OS8104 Driver
info:    most status up OS8104 Driver
fault 0
fault 0
fault 0
warn:    locked OS8104 Driver
warn:    most error active OS8104 Driver
Error 1 91
error:   parsing fault mask: 5b OS8104 Driver
error:   Error: transceiver lock error OS8104 Driver
warn:    transceiver unlocked OS8104 Driver
status lost
info:    most status up OS8104 Driver
fault 0
fault 1
status lost
info:    most status up OS8104 Driver
fault 1
fault 1
status lost

As you look at the back of transceiver, which side do you see the red light on?

The jlr set up is very specific on which exact modules are on MOST compared to the ccf stored in the master, so you may find it difficult if they all come from different cars

Also for testing disable the service

systemctl disable socketmost.service

sudo reboot

Change in to your socketmost directory

git pull

then

npm run build

then

cd examples

finally

node server.js

this allows easy starting and stopping of the service

Thank you very much! I will check it out tonight.

Some side information:

My US-spec XK 5.0 was imported from the USA to The Netherlands. The radio was on US settings, meaning that I could not receive any European radio stations. My first assumption was that a European CD/radio stack would resolve that. From eBay-UK, I bought a GB-spec CD/radio stack and mounted it, with no success: still the US settings were active.

With this GB-spec stack installed, I went into SDD, tricked it to enable setting the radio mode to Europe spec, and the FM/AM radio came alive! To keep the car original, I mounted back the original CD/Audio stack and the FM/AM radio reception remained functional.

Later, I also purchased a JLR DAB module, took out the US-only SDARS module (satellite radio) and replaced it with the DAB module. After configuration in SDD and installing the right antenna equipment, I also managed to get DAB working.

This tells me that the MOST devices seem to be inter-exchangable, as long as their specs are corresponding. Possibly, SDD programs the module accordingly during their activation in the CCF. I doubt that any VIN-related information is exchanged on the MOST bus. There is no need to do so.

This leads me to a next question: which module is actually the MOST master?

I read from the XK Workshop Manual:

Control signals from the integrated control panel are relayed on the medium speed CAN (controller area network) bus to the information and entertainment module. The information and entertainment module relays the control signals to the rest of the audio system on the Media Orientated System Transport (MOST) ring. The information and entertainment module is the timing master for the MOST ring and also hosts a gateway function between the medium speed CAN bus and the MOST ring.

On premium audio systems the audio signals are sent on the MOST ring from the integrated audio module to the amplifier. The control signal from the remote audio switches to the information and entertainment module consists of an analogue voltage from a resistive ladder.

From this, I deduct that the CD/radio stack is officially called the “Integrated audio module”, whereas the “Information and entertainment module” is a small control unit mounted on top of the CD/radio stack.

Searching for the part on eBay is cumbersome, since many sellers confuse the two modules. However, I found C2P16945 as the Jaguar part reference for XK X150 cars. Prices on eBay are absurd, considering that the module only bridges between MS-CAN and MOST, and nothing else…

Very interesting read, thankyou. The modules are interchangeable, it’s just the specification of module that must match, 8 channel amp vs 12 channel etc etc.

The master is the small black module underneath the cd player, prices are very cheap in the uk for them, since they are pretty much useless off the car, these do check VIN from CAN and all the CCF messages. The one I purchased off of ebay luckily had the vin written on it in marker. So I put the VIN into SDD, retrieved the asbuilt config, then modified every CCF message in my can dump from my car, to match the same options as the asbuilt, and also the vin. Then boom everything came to life and was happy.

I always tended to buy the CD player with the black module included, here’s an example now on ebay, for £25 for both, unsure how prices compare in the Netherlands though, but cheapest I have gotten one for is £15

it’s just the specification of module that must match, 8 channel amp vs 12 channel etc etc.

I doubt this. I believe that all audio sent over MOST is 2 channel stereo. It is very common that the amplifier extracts 4 channel or 5.1 channel stereo from this. This can easily be done by using some DSP settings and possibly some minor audio delays. Subwoofer and center channel simply get the common from left and right combined, whereas the remaining left and the remaining right are the differences between their root signal minos the L+R common. So no need to send multiple channel over MOST.

I ordered a complete XF set just today: front panel + CD/Radio (== IAM) + IEM control module for 50 quid. Will probably arrive next week.

Actually, if the functioning of the IEM could be reverse engineered, it could be completely replaced by the piMost configuration: Steering wheel input signals (“resistive ladder”) can be read straight from the Raspberry, and MOST+MS-CAN signals can be handled by the piMost HAT.

Conversion of analogue to digital using a Raspberry Pi is illustrated by the following video: https://www.youtube.com/watch?v=Qgazac5v8P8

I can guarantee this 100%, I have 3 versions of amplifier and two set ups (one for the fl2 and one for the xf, generally same modules) If I put a medium line amplifier on the network, the system will refuse to boot. Replace it with high line, and away it goes. Likewise I have a premium one, and that will behave the same.

I’ve used an arduino in my xf to tap into the steering controls, and then it plugs into a pi and emulates a keyboard for each button press.

Although I wouldn’t want to be replacing the Master with the PiMost. A huge amount of stuff is actually translated over, and the master does a nice job of translating each bit/byte that’s relevant to a seperate fktID

Dear Rhys, some progress today. I bought an XF dashboard wire loom and a CD/amp/control stack. I connected all up, with an 120 ohm resistor in the HS-CAN line of the connector to the central junction box and another 120 ohm resistor in the MS-CAN line of the connector to the climate control module. The other 120 ohm resistors are already available in the instrument cluster (speedometer). Although I cannot get the instrument cluster to light up (probably needs LIN BUS confirmation), I got the audio stack to work. This is possible because the sound on switch on the integrated control panel allows listening to the radio with ignition off. The Raspberry Pi with the piMOST was included in the MS CAN bus and the MOST network.
The result: I got sound from the audio stack, could listen to a CD via the amp speaker output and I could operate this from the integrated control panel and see the effect on the media screen.
This means that:

  • the MS CAN bus works, because button presses translate into CD changes
  • the MS CAN to MOST works, for exactly the same reason
  • the MOST bus works, including the piMOST HAT of the Raspberry Pi, since otherwise MOST commands should not be able to go around.
  • no HS or MS can bus triggering is required to get audio working
  • no configuration of the modules was necessary

Interesting was that the screen mentioned potential, but disabled, presence of the iPod/USB module and the AUX connection. Navigation was also disabled. All disabling is obvious in lack of the equipment on the MOST bus.

I like this result, because it means that I can keep the devices alive by playing a CD, allowing reading/writing and programming the devices on the bus.
I got this far now, and will explore the piMOST functionality later, in particular configuring the MOST parameters in the CarPlay app.

1 Like

Hi Frits, great news, glad you got it going.

You can get the cluster to turn on by replaying the candump. However there is a chance of the MOST devices then going into a locked state, this is due to the below.

The cars CCF message is broadcast on CAN IDs 400, 401 and a couple of others. When the gateway receives a full CCF message, it stores it, and it’s at that point it compares the VIN on the CAN messages, and also the configuration of the CCF with the presence of the modules on MOST. If there is a mismatch, that is when you will likely run into the screen never going past the Jaguar Logo.

The PiMost by default will be in the all bypass mode, so any traffic received is directly transmitted out, when you run server.js in examples, it will come out of bypass mode and start interacting with the MOST bus.

Let me know how you get on!

PS there are a few messages you can use to simulate Ignition on

OFF - 07E#003B80A00001C020

Half on - 07E#003B88A00004C020

All on - 07E#003B9D636404E020

You also have a 120ohm resistor on the PiMost, enabled with the jumper inplace in front of the can connector.

Thanks

Rhys

Great for providing these ignition codes. I tried them, both on CAN0 (MS_CAN) and CAN1 (HS_CAN), but they did not have any affect at this moment.

I also ran the XF startup and XF dump logs you provided in your GITs, but they did not work either. On the XF startup log, I got a single beep from the Instrument Panel Cluster (IPC), but after a while, the sending got quite sluggish and almost came to a grinding stop. I bet the IPC is sending out some HALT signals to slow things down on the Can bus.

Unfortunately for me, running the XF Startup (or dump), put the Integrated Control Module (ICM) in a non-operative state: the display is now just showing the boot logo, and does no longer proceed to the menu screen. Running audio no longer works, but the audio button can switch on/off the screen, so some MS_CAN to MOST seems to work.
Does the socketmost service need to be active to have MOST operative? I understood that the piMOST HAT will be on pass-through when not active.

BTW: I used the 120 ohm termination on the wire loom, so I do not have to open the raspberry case to set/unset the termination. I have two Raspberries active: one with a dual CAN attached to the OBD2 connector, so I can monitor and operate both can busses. The other Raspberry has the piMOST HAT, and is connected to MS_CAN and MOST, as required for running your socket most applications. Except for the MOST connection, I can therefore add or remove the Raspberries, without affecting the termination of the CAN busses.

Via SDD, I tried to reprogram/reset the audio part to get it operative again. I have the VIN of salvaged XF which provided the audio stack, but to no avail yet. SDD does see the IPC (instrument panel on HS-CAN), the ICM (integrated control module on MS-CAN), the FACP (front audio control panel on MS-CAN) and the amplifier on MOST.

When I run the XF startup log, the climate (Auto) switches on or off now and then. There is a lot of activity on Can0, but the sending of the log file is very very sluggish, as reported above. The instrument panel is completely inoperative: no signs of life whatsoever.

You can get the cluster to turn on by replaying the candump. However there is a chance of the MOST devices then going into a locked state, this is due to the below.

The cars CCF message is broadcast on CAN IDs 400, 401 and a couple of others. When the gateway receives a full CCF message, it stores it, and it’s at that point it compares the VIN on the CAN messages, and also the configuration of the CCF with the presence of the modules on MOST. If there is a mismatch, that is when you will likely run into the screen never going past the Jaguar Logo.

Hi Frits, this is what I meant with this message. With how you are now the CCF messages in the candump need to match the expectation of the ICM to enable it to turn back on. This can be done using the exml files in SDD which then allow you to figure out the required bytes and bits in the 400 range messages.

If you can send me the VIN and also the asbuilt ccf file for you car I can take a look at it when I get time, and send customised dump over to you.

There is no need for the pimost to be “active” for the MOST network to become healthy.