As far as the software is concerned, this is the "mounting plate":

{{mountingplate-ext.jpg?128}}
{{mountingplate-int.jpg?128}}
{{mountingplate-pcb.jpg?128}}

It is relatively uncommon, and most of them are believed to have been discarded during decommissioning.

It takes 3V3, GND, I²C SCL/SDA, and USBD+/-, and passes the rest of the pins into the (snipped) cable.  Over USB, it presents the SD card as a mass storage device, and over I²C, it presents a [[https://ww1.microchip.com/downloads/en/DeviceDoc/21189R.pdf|24LC64]] EEPROM at address ''0x50''.

The EEPROM contents look like:

  [FzgParam]
  Fahrzeugadresse=1234
  MontageplattenNr=1

''Fahrzeugadresse'' (en: vehicle address) seems to be a unique vehicle number, and ''MontageplattenNr'' (en: mounting plate number) seems to refer to a shared model number - evidence of values 1 and 2 have been observed.

[[initseilnx|The stock Linux distribution]] on the device will, at startup, check for a ''[TestMode]'' section, and, if present, treat its contents as a shell script to be executed instead of [[nx]].  We are not sure what this was used for officially, but it is useful for us to execute our own code without opening the case.

In normal operation, it appears that the mounting plate’s hardware is checked first for information (the EEPROM and SD card). If they exist, they’re mounted and used for /init and the EEPROM data read into the nx application. If the mounting plate doesn’t exist, it’ll revert back to saved EEPROM data on the internal SD, and use the internal bottom SD to store fare and application data and updates.