Pi MOST in E9X bmw's

ygoz · 13 August 2023 05:24

Hi Rhys,

I have set everything up according to your guide and tested on my E90 BMW - getting a fault and status lost:

Aug 13 14:36:45 raspberrypi node[573]: { version: '1.0.0', nodeAddress: 272, groupAddress: 34, freq: 48 }
Aug 13 14:36:45 raspberrypi node[573]: running config
Aug 13 14:36:45 raspberrypi node[573]: 16 1 <Buffer 22>
Aug 13 14:36:45 raspberrypi node[573]: 0 138
Aug 13 14:36:45 raspberrypi node[573]: 1 1
Aug 13 14:36:45 raspberrypi node[573]: 0 139
Aug 13 14:36:45 raspberrypi node[573]: 1 16
Aug 13 14:36:45 raspberrypi node[573]: 0 137
Aug 13 14:36:45 raspberrypi node[573]: 1 <Buffer 22>
Aug 13 14:36:45 raspberrypi node[573]: 0 131
Aug 13 14:36:45 raspberrypi node[573]: 1 6
Aug 13 14:36:45 raspberrypi node[573]: 0 128
Aug 13 14:36:45 raspberrypi node[573]: 1 67
Aug 13 14:36:45 raspberrypi node[573]: 0 130
Aug 13 14:36:45 raspberrypi node[573]: 1 195
Aug 13 14:36:45 raspberrypi node[573]: 0 140
Aug 13 14:36:45 raspberrypi node[573]: 1 64
Aug 13 14:36:45 raspberrypi node[573]: 0 129
Aug 13 14:36:45 raspberrypi node[573]: 1 80
Aug 13 14:36:45 raspberrypi node[573]: 0 136
Aug 13 14:36:45 raspberrypi node[573]: 1 7
Aug 13 14:36:45 raspberrypi node[573]: 0 133
Aug 13 14:36:45 raspberrypi node[573]: 1 15
Aug 13 14:36:45 raspberrypi node[573]: fault 1
Aug 13 14:36:45 raspberrypi node[573]: Error 1 223

Didn’t find docs for E9X, but a BMW bus systems overview doc shows the bus operates at 44.1khz - this is very likely the reason - would you be able to provide instructions on how to switch the board and driver to 44.1khz?

Happy to test this out

rhys_m · 13 August 2023 07:58

Hello!

I’ll give you a bit of an overview, as two heads will be better than one!

The original OS8104 chip didn’t actually use the oscillator to synchronise to the bus. All it did (if it was a slave device) was lock onto the incoming signal over the fibre bus. This caused some blip issues at time of lock, but it is what you will find in the majority of devices.

The OS8104AAQ brought a new feature, enhanced bypass, this now uses the oscillator to sync the chip to, then when lock has been achieved, it then switches over to the fiber network. The OS8104AAQ can use both modes, you can choose legacy by pulling a pin low (or it might be high, I can’t remember) or by wiriting to certain registers. I have attempted to include this in the drivers, but it’s entirely untested.

If you go to config.json then change the freq value to 44, then do a reboot, is should hopefully then achieve lock.

Let me know how it goes!

Rhys

rhys_m · 13 August 2023 08:06

Also thanks for sharing the document, interesting that so much bandwidth is used on the nav unit. Perhaps it sends out video over MOST? That would be very interesting if it did!

ygoz · 15 August 2023 10:55

Have an update - had another try today after updating the config file.

Now the cars MOST ring wont break as it did before - seems that the chip gets the new config and is able to lock on the frequency.
The log does not show that the “status lost” as it did before, however it does still print faults and errors - perhaps the driver needs an update as well.

Current state of logs:

Aug 15 20:30:50 raspberrypi systemd[1]: Started socketmost.
Aug 15 20:30:53 raspberrypi node[576]: file exists
Aug 15 20:30:53 raspberrypi node[576]: { version: '1.0.0', nodeAddress: 272, groupAddress: 34, freq: 44 }
Aug 15 20:30:53 raspberrypi node[576]: running config
Aug 15 20:30:53 raspberrypi node[576]: 16 1 <Buffer 22>
Aug 15 20:30:53 raspberrypi node[576]: 0 138
Aug 15 20:30:53 raspberrypi node[576]: 1 1
Aug 15 20:30:53 raspberrypi node[576]: 0 139
Aug 15 20:30:53 raspberrypi node[576]: 1 16
Aug 15 20:30:53 raspberrypi node[576]: 0 137
Aug 15 20:30:53 raspberrypi node[576]: 1 <Buffer 22>
Aug 15 20:30:53 raspberrypi node[576]: 0 131
Aug 15 20:30:53 raspberrypi node[576]: 1 0
Aug 15 20:30:53 raspberrypi node[576]: 0 128
Aug 15 20:30:53 raspberrypi node[576]: 1 99
Aug 15 20:30:53 raspberrypi node[576]: 0 130
Aug 15 20:30:53 raspberrypi node[576]: 1 195
Aug 15 20:30:53 raspberrypi node[576]: 0 140
Aug 15 20:30:53 raspberrypi node[576]: 1 64
Aug 15 20:30:53 raspberrypi node[576]: 0 129
Aug 15 20:30:53 raspberrypi node[576]: 1 80
Aug 15 20:30:53 raspberrypi node[576]: 0 136
Aug 15 20:30:53 raspberrypi node[576]: 1 7
Aug 15 20:30:53 raspberrypi node[576]: 0 133
Aug 15 20:30:53 raspberrypi node[576]: 1 15
Aug 15 20:30:53 raspberrypi node[576]: fault 1
Aug 15 20:30:53 raspberrypi node[576]: Error 1 95
Aug 15 20:30:53 raspberrypi node[576]: fault 1
Aug 15 20:30:53 raspberrypi node[576]: fault 0
Aug 15 20:30:53 raspberrypi node[576]: fault 1
Aug 15 20:30:53 raspberrypi node[576]: fault 1
Aug 15 20:30:53 raspberrypi node[576]: fault 1
Aug 15 20:30:53 raspberrypi node[576]: fault 0
Aug 15 20:30:53 raspberrypi node[576]: fault 1
Aug 15 20:30:53 raspberrypi node[576]: fault 1
Aug 15 20:30:53 raspberrypi node[576]: fault 1
Aug 15 20:30:53 raspberrypi node[576]: fault 1
Aug 15 20:30:53 raspberrypi node[576]: fault 0
Aug 15 20:30:53 raspberrypi node[576]: fault 0
Aug 15 20:30:53 raspberrypi node[576]: fault 0

ygoz · 15 August 2023 11:19

Regarding the documentation I posted - I do have a TV function in my car - and the tuner box is supposed to be connected to the MOST bus as well - I imagine it sends video over MOST for the nav unit to play

rhys_m · 15 August 2023 15:28

Progress atleast! Does the ring stay healthy now, with the PiMost in place? Does the cd player etc all function?

I can see a few other registers that may need changing, I’ll update the repo with probably a separate branch.

Out of curiosity whereabouts are you plugging in? I may see if I can play with my neighbours’ one, but wouldn’t want to strip half the car apart to get it in.

rhys_m · 15 August 2023 19:56

Right, hopefully this may prove more fruitful! I’ve made a legacy mode branch, every register that gets affected with legacy mode should now be written to, I’ve tested and I can lock onto 48khz cleanly with it

ygoz · 17 August 2023 01:17

More progress, and good news!

TLDR - I think it works, in both the legacy mode and the main branch when set to 44khz - I must have missed something the first time i checked. I also didnt bother running test.js last time as i saw faults.

But scrolling through the log fully, we can see, on the main branch:

Aug 16 21:19:20 raspberrypi node[574]: 1 15
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: Error 1 95
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 0
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 0
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 0
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 0
Aug 16 21:19:20 raspberrypi node[574]: fault 0
Aug 16 21:19:20 raspberrypi node[574]: fault 0
Aug 16 21:19:20 raspberrypi node[574]: fault 0
Aug 16 21:19:20 raspberrypi node[574]: fault 1
Aug 16 21:19:20 raspberrypi node[574]: fault 0
Aug 16 21:19:20 raspberrypi node[574]: fault 0
Aug 16 21:19:20 raspberrypi node[574]: fault 0
Aug 16 21:19:21 raspberrypi node[574]: master found

on the legacy branch:

Aug 16 21:10:03 raspberrypi node[572]: 1 15
Aug 16 21:10:03 raspberrypi node[572]: Error 1 91
Aug 16 21:10:04 raspberrypi node[572]: network status up
Aug 16 21:10:04 raspberrypi node[572]: fault 1
Aug 16 21:10:04 raspberrypi node[572]: fault 0
.... // it logs quite a lot of fault 0 or 1 here
Aug 16 21:10:04 raspberrypi node[572]: fault 0
Aug 16 21:10:04 raspberrypi node[572]: fault 0
Aug 16 21:10:04 raspberrypi node[572]: fault 0
Aug 16 21:10:04 raspberrypi node[572]: fault 1
Aug 16 21:10:04 raspberrypi node[572]: fault 1
Aug 16 21:10:04 raspberrypi node[572]: status lost
Aug 16 21:10:04 raspberrypi node[572]: network status up
Aug 16 21:10:04 raspberrypi node[572]: fault 0
Aug 16 21:10:06 raspberrypi node[572]: master found

both branches, when running test.ts will output MOST data:

{
  eventType: 'newMessage',
  type: 2,
  sourceAddrHigh: 1,
  sourceAddrLow: 0,
  data: {
    type: 'Buffer',
    data: [
      202,  0, 36, 124, 4, 0, 2,
      211, 70,  0,   0, 0, 0, 0,
        0,  0, 84
    ]
  }
}
{
  eventType: 'newMessage',
  type: 1,
  sourceAddrHigh: 1,
  sourceAddrLow: 0,
  data: {
    type: 'Buffer',
    data: [
      1, 1, 0, 1, 0, 0, 0,
      0, 0, 0, 0, 0, 0, 0,
      0, 0, 0
    ]
  }
}
{
  eventType: 'newMessage',
  type: 2,
  sourceAddrHigh: 1,
  sourceAddrLow: 0,
  data: {
    type: 'Buffer',
    data: [
      202,  0, 36, 124, 4, 0, 2,
      211, 70,  0,   0, 0, 0, 0,
        0,  0, 85
    ]
  }
}

The cars MOST ring is healthy - when it isn’t the nav system always shows an error and there is no audio - audio plays, and although my original CD changer is disconnected, I have an multimedia box that emulates one can mirror my phone, stream audio and other goodies - it works without issues.

I am actually connecting this in the trunk, where the CD changer is - i have a MOST termination loop there and i remove it and connect the pi for testing - it also has 12 i can use later to permanently power it.

But you can also connect to it if you remove the nav unit - quite involved.
Easiest way is - on the drivers side - in the foot well if you look on top - there is a MOST port with a terminator, that is used by BMW to write software update to the cars modules quickly, vs using k-dcan.

Which btw - can probably be reverse engineered and applied with this board from the Pi

Are you getting some faults before locking in on a signal too? is this expected? - it doesn’t affect anything, just wondering how it is with the jag and land rover.

The legacy branch is slower actually and takes a few second to lock in - the new mode is nearly instant and all faults are logged within the span of 1 second.

rhys_m · 17 August 2023 03:06

Awesome, that’s great news!

For the faults I do see some. Not that many, however I believe it likely needs a debounce on the fault pin, or I have a slight bug in the error interrupt routine. The log that shows error and a number relates to the registers that hold the specific fault. The start up faults are no lock achieved, so in legacy mode I would expect a small period of fault whilst it syncs to the RX signal. This was the reasoning behind releasing the Q version of the chip with the enhanced mode. However hardware needs to be physically different to allow 48 or 44.1.

Next time you are plugged in, if you shutdown the most network in the car then bring it back up, I believe the original branch may run in to issues, however the legacy branch I think should handle it fine.

The Mostexplorer app is all functioning, doing a short video on each of the features as I do them, it gives a much nicer output of messages!

Thanks for the help testing this and getting it going, also thanks for the pointers, diagnostic ports seems like it will be easiest!