v1.16
Modularer Grabber Baukasten (MGB) is an electronic device developed for grabbing video from VW concern displays (ZR, ABT, FPK, etc.). It was developed by Digiteq Automotive (former e4t – electronics for transportation) company in cooperation with AUDI, Volkswagen and Skoda. MGB connects directly to video bus between video source (ZR) and video sink (display). It grabs video data, compresses and sends them to PC via 1 Gbit ethernet. It is able to save screenshots and record a video to SD card or USB device.
MGB can stream grabbed video in different formats. Lossy codecs like H264 or MJPEG and lossless RAW can be used. Screenshots are stored in lossless RAW or much more space-saving PNG format.
MGB user can select an area of interest which is cut out of the video stream and streamed separately to PC. This capability is convenient for space savings and framerate acceleration.
MGB has a trigger functionality. Optional actions (MGB start/shutdown, screenshot taking, video recording, etc.) can be configured as responses to some trigger events (digital inputs, trigger button, CAN messages, etc.).
Current available interfaces:
These interfaces are capable of grabbing all LVDS systems used in VW concern.
Input video signal parameters (resolution, signal active level) are detected automatically and user does not need to set them manually. In some cases it is necessary to set the proper link settings (single or dual) according to the video interface type.
Technical specifications:
| Interface | LVDS FPD Link 2, 3 |
| Video | H264, MJPEG, RAW |
| Screenshot | PNG, RAW |
| Network | 1 Gbit/s - TCP, UDP |
| Interfaces | LVDS FPD Link, HDMI, CAN, UART, I2C, 2x digital input, 1x digital output |
| Power supply | 9 V to 30 V |
| Power consumption | 10 W |
| Temperature | 0°C to 70 °C |
| Dimensions | 17 x 17 x 6 cm |
Here is a step by step description how to start with MGB:
To switch MGB on, push power button for short time (< 500ms).
To switch MGB off, push power button for long time (> 3000ms).
| LED signal | Meaning |
|---|---|
| Green blinking | Booting |
| Green light | Ready |
| Red blinking | Shutting down |
| Red light | Error |
| Blue light | Streaming video |
| Yellow blinking | Recording video |
| Pink flash | Screenshot taken |
| Orange blinking | Updating firmware |
| Red light | Error |
MGB is capable of streaming video. To make use of this feature, enable it by checking the appropriate checkbox in web interface (Video → Video).
Video can be encoded by various codecs and streamed by various transport layers, all this is configurable in web interface (Video → Protocol). Supported options:
The actual video format information is available via Samba share at URL \\<mgb‑ip>\ramfs\videofmt.txt and via HTTP protocol at URL http://<mgb‑ip>/videofmt.txt. The content of videofmt.txt file consists of these pure text lines:
<width of video frame in pixels> <height of video frame in pixels> <fourcc (encoded as hexadecimal number prefixed by 0x)> <Protocol selected in web interface (Video → Protocol)>
The videofmt.txt file is guaranteed to be available only when MGB is streaming.
It is important to note, that for all the above options the underlying colour encoding is YUV 4:2:0. Currently the original colour encoding at LVDS FPD Link is RGB, so it is internally transcoded.
MGB is capable to stream only specific area of the original full-frame area. To make use of this feature, enable it by checking the appropriate checkbox in web interface (Video → Area of interest). Then set the specific area of interest parameters to some valid values.
Note, that the values must represent valid configuration. AOI width must be greater or equal 50 pixels and must be even number. Selected area of interest must be non-empty subset of the original full-frame area, but with one exception. You are allowed to set the combination of AOI y and AOI height in such a way that a bottom of required AOI is at most 16 pixels below the original full-frame. In this case new lines will be added to the bottom of the frame. The new lines can be any combination of these colors:
The added area can be used for various purposses, e.g. for placing of in-picture timers.
In case of any invalid configuration full-frame video will be streamed.
The frame dimensions are always (even regardless the configured AOI) rounded-up to the next number divisible by 16. The reamaining area is padded with color encoded as 0x00 (Y), 0x00 (U), 0x00 (V) in YUV 4:2:0 color space.
No-signal frames are streamed when there is no signal present at the MGB input and one of these conditions is met:
The color of no-signal frames can be set in web interface (Video → No-signal color):
When enabled in web interface (Video → HDMI output), then video preview is available on HDMI interface. Note that it can slow down the LAN video framerate because it utilizes the same CPU. To avoid undefined behaviour, connect/disconnect external monitor to/from MGB's HDMI only if video preview is disabled.
MGB is capable of recording video stream triggered by some user defined event. These so called triggered video streams are stored to SD card. To get more information about trigger events see section Triggers.
Triggered video streams are stored into video folder of the SD card. The video filenames are constructed in this way:
mgb_<YYYY-MM-DD_HH-MM-SS>.<suffix>
where <YYYY-MM-DD_HH-MM-SS> represents screenshot local (in configured timezone) timestamp consisting of
YYYY – year, MM – month, DD – day, HH – hour, MM – minutes, SS – seconds
The video stream encoding is determined by setting in web interface (Video → Protocol). Video recording feature is available only for these options:
Currently there are some issues when recording stream encoded by MJPEG, so the recording feature is disabled in this case.
For purpose of preserving some part of video stream, that precedes the trigger event, the video stream is steadily buffered. The size of this pre-trigger buffer is configured in web interface (Video → Pre-trigger buffer). The supported buffer size ranges between 0 and 60 seconds.
For purpose of having exactly marked the time of trigger event, a small T character mark is inserted into video stream. It is inserted to the top-left part of the video frame and it is visible for 3 seconds. To make use of this trigger-mark feature enable appropriate checkbox in web interface (Video → Trigger mark).
During video recording the leaving disk free space is checked each 10 seconds. When the free space falls below 100MB, recording is stopped automatically.
Active video recording is signalized by fast yellow blinking. Start of recording has very quick response, but when stopping recording, MGB has to copy all the buffered data to SD card and properly close the container file. This can take several seconds, so be patient please.
MGB is capable to provide in-picture 64-bit binary timestamps. To enable this feature, check the appropriate checkbox in web interface (Video → Timestamp). The timestamp is rendered as sequence of 64 bits with MSB at the left side and LSB at the right side. The initial position (in pixels) of rendered timestamp can be configured in web interface (Video → Timestamp horizontal/vertical positon). When the position is greater or equal zero, then it specifies the initial position of MSB relative to the top/left picture corner. When the position is lower than zero, then its value increased by one specifies the initial position of LSB to the bottom/right picture corner. E.g. the initial position [0,0] renders timestamp to the top-left corner, the initial position [-1,-1] renders timestamp to the bottom-right corner. The size (in pixels) of each rendered bit can be configured in web interface (Video → Timestamp bit width/height), valid values are from 0 to 10. The timestamp rendering coordinates are computed with modulo, so the bits exceeding the picture right/bottom/left/top border continue to render again from left/top/right/bottom border. Three types of timestamps may be configured (Video → Timestamp type):
The timestamp is encoded into all three color components of YUV 4:2:0 video data. For each pixel, bit 0 is encoded as 0x00 (Y), 0x80 (U), 0x80 (V), bit 1 is encoded as 0xFF (Y), 0x80 (U), 0x80 (V). Remember, that each U and V component represents 4 neighbouring pixels, so it has more sense to set the timestamp position and dimensions as even numbers.
An ordinary IP camera viewer can be used for MGB video visualisation. Here the VLC (VideoLAN) player is described. According to the Protocol option configured in web interface use one of the next settings.
H264-RTP-UDP: use this sdp file. Edit the file to set the correct ip address and tcp port to the right values.
JPEG-RTP-UDP: use this sdp file. Edit the file to set the correct ip address and tcp port to the right values.
H264-MPEGTS-TCP and JPEG-MUX-TCP: select Media → Open Network Stream. Then
set a network URL to tcp://<mgb-ip>:<video-port> (e.g. tcp://192.168.1.200:50000).
RAW-TCP: it is necessary to set the video parameters in VLC Demuxer settings.
1. Select Tools → Preferences
2. Check All radio button down in the Show settings
3. In Demuxers subtree select Raw video demuxer
4. Set the video parameters. Some of them can be read from samba share at URL
\\<mgb-ip>\ramfs\videofmt.txt or from HTTP server at URL http://<mgb-ip>/videoftm.txt.
Keep in mind, that video dimensions are rounded-up to the next number divisible by 16. Set Force chroma option
to I420. Set Aspect ratio option to 1:1. Set Frames per Second option to value from
1 to 20.
5. Press Save and then continue the same way as for the H264-MPEGTS-TCP and JPEG-MUX-TCP protocols.
MGB is capable of taking periodical screenshots. They can be stored to SD card or MGB RAM disk and at these locations accessed via Samba share or HTTP server. MGB is able to directly stream screenshots via TCP protocol.
If enabled in web interface (Photo → Periodic screenshots), MGB takes periodical screenshots. If enabled in web interface (Photo → Store to filesystem), MGB stores these screenshots to filesystem. If SD card is inserted, screenshots are stored to the SD card. If SD card is not inserted, screenshots are stored to the internal MGB RAM disk. Internally this is achieved by mounting SD card device (when inserted) over MGB RAM disk. MGB RAM disk is much faster than SD card, but also it is a volatile memory, so screenshots are lost when MGB shutdowns. Either SD card or RAM disk are accessible via Samba share at the same path \<mgb‑ip>\sdcard\periodic_screenshots. When SD card is inserted, periodic_screenshots folder accesses data on SD card, when SD card is removed, periodic_screenshots folder accesses data on MGB RAM disk.
Period, format and maximum number of screenshots can be configured in web interface (Photo → Period, Photo → Format, Photo → Max stored frames).
There are two possible formats the screenshots will be encoded with, PNG and RAW. When RAW is selected, the screenshot consists of header and image data. Header (4 bytes) consists of width (uint16) and height (uint16), represented in little-endian order. Image data consists of pure sequence of RGB data, where each colour takes one byte (uint8). So the byte order of RAW screenshot looks like this:
WWHHRGBRGBRGBRGB… etc.
Storing of screenshots uses concept of steadily overflowing filesystem ring-buffer. The size of this buffer is determined by web interface option Max stored frames. The screenshot filenames are constructed in this way:
mgb<cnt>.[png|raw]
where <cnt> represents screenshot counter, consisting of 10 decimal digits. The first taken screenshot encoded in PNG is stored into file of this name: mgb0000000000.png
When the number of screenshots reaches the configured maximum, overflow occurs and it is processed in such way the oldest screenshot is deleted and then the new one is stored. The counter is not affected by this overflow and it still counts-up.
There is another Samba shared path, namely \\<mgb‑ip>\ramfs\screenshot. This path is actually a link to the most recently stored periodical screenshot.
Another way to access the screenshots is via MGB’s HTTP server at URL http://<mgb‑ip>/screenshot. This URL is actually a link to the most recently stored periodical screenshot. To make use of this access, enable both Periodic screenshots and Store to filesystem options in web interface.
See section Streaming screenshots via TCP protocol.
MGB is capable of taking screenshots upon some user defined trigger events. These so called triggered screenshots can be stored to SD card or directly streamed via TCP protocol. To get more information about trigger events see section Triggers.
Triggered screenshots are stored into screenshots folder of the SD card. The screenshot filenames are constructed in this way:
mgb_<YYYY-MM-DD_HH-MM-SS-MMM>.[png|raw]
where <YYYY-MM-DD_HH-MM-SS-MMM> represents screenshot local (in configured timezone) timestamp consisting of
YYYY – year, MM – month, DD – day, HH – hour, MM – minutes, SS – seconds, MMM - milliseconds
The screenshot file format is determined by setting in web interface (Photo → Format).
See section Streaming screenshots via TCP protocol.
MGB is able to directly stream both the periodical and triggered screenshots via TCP protocol.
TCP server is listening on port, whose value can be configured in web interface (Photo → Server port). Screenshots are always streamed in raw format (agnostic to option Photo → Format) and it is the same format as used to store raw screenshots to SD card.
The screenshot consists of header and image data. Header (4 bytes) consists of width (uint16) and height (uint16), represented in little-endian order. Image data consists of pure sequence of RGB data, where each colour takes one byte (uint8). So the byte order of RAW screenshot looks like this:
WWHHRGBRGBRGBRGB… etc.
If periodical screenshots are enabled in web interface (Photo → Periodic screenshots), MGB can stream the screenshots to all connected TCP clients. Each client can individually enable or disable streaming of these periodical screenshots. Remember, that mentioned web interface option acts as master. When TCP client wants to receive the periodical screenshots, it has to be enabled both in web interface and at TCP socket level. By default (because of backward compatibility) at TCP socket level the streaming of periodical screenshots is enabled. Scroll below to see the commands.
Whenever appropriate trigger event occurs, MGB streams the triggered screenshot to all connected TCP clients. There is no possibility to enable or disable the streaming at TCP socket level.
Moreover, each TCP client has the possibility to individually request a screenshot. Such a screenshot is streamed only to the requesting TCP client. Scroll below to see the commands.
Currently only these simple one-byte commands can be issued by the TCP clients:
MGB is capable of performing some actions upon some events. Triggering events and responding actions can be configured in web interface (Triggers).
This event fires when MGB’s main/power button is released. Note, that the preceding pushed state may not last for too long time, because long push causes switching MGB off.
These ones are the hardware pins located at the back side of MGB box. Rising or falling levels at these pins can be configured as triggering events. These trigger inputs can be used two ways:
These events fire when configured CAN matches occur. The match occurs only when this expression evaluates to true:
(ID == id) && ((DATA & mask) == (data & mask))
| ID | - | received CAN message identifier |
| DATA | - | received CAN message data |
| id | - | configured CAN message identifier (Triggers → Identifier) |
| data | - | configured CAN message data (Triggers → Data) |
| mask | - | configured CAN message data mask (Triggers → Data mask) |
LVDS FPD Link 3 interface has a special bidirectional data channel called Backchannel. In some systems the Backchannel is used to transfer a special data using a special protocol.
MGB provides UART and SPI Backchannel sniffer. The sniffed communication may be directly forwarded to the connected TCP client. Three communication scenarios exist. UART, SPI Forward channel and SPI Reverse channel. User must set the communication scenario properly. If not, then the communication between ZR and peripheral is broken (MGB does not resend data correctly through FPD Link channel). Settings of Backchannel communication can be done in Interface tab of web interface. Backchannel option sets the type of scenario. Back channel sniffer option enables the forwarding of data to the connected TCP client. Back channel UART baudrate option is valid only for UART scenario.
Sniffed communication is transmitted in 4 bytes long frames. The first byte is a header describing content of another 3 bytes. Another 3 bytes may or may not hold real data sniffed from UART busses. The frame layout is as follows:
0 0 VC VB VA UC UB UA | C C C C C C C C | B B B B B B B B | A A A A A A A A
where
bit VC log 1 indicates that C byte is valid, UC log 1 indicates that C byte holds uart1 byte and UC log 0 means it holds
uart0 byte,
bit VB log 1 indicates that B byte is valid, UB log 1 indicates that B byte holds uart1 byte and UB log 0 means it holds
uart0 byte,
bit VA log 1 indicates that A byte is valid, UA log 1 indicates that A byte holds uart1 byte and UA log 0 means it holds
uart0 byte.
An example of two captured UARTs (uart0 and uart1) follows. Uart0 is an output from MGB serializer (sent by display deserializer) and Uart1 is an output from MGB deserializer (sent by ZR serializer). The frame may look like:
0 0 0 1 1 0 1 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 1 1 1 1 | 1 0 1 0 1 0 1 0
This means, that only bytes A and B are valid and byte C is unused. Byte A holds uart0 byte 0xAA and byte B holds uart1 byte 0x0F. This is a way how to preserve UARTs byte orders with minimum overhead.
Sniffed communication is transmitted in 4 bytes long frames. The first two bytes are unused and second two bytes hold real data sniffed from SPI bus. The frame layout is as follows:
D D D D D D D D | C C C C C C C C | B B B B B B B B | A A A A A A A A
where
bytes D and C are unused,
byte B holds SPI data from MGB serializer (sent by display deserializer),
byte A holds SPI data from MGB deserializer (sent by ZR serializer).
Some interface modules contain deserializers providing information their lock-status (if they are locked on signal of remote serializer). MGB allows to monitor this lock-status and to count the lock-drops. The lock-status monitor feature is fully controlled via control socket and partially in web interface.
Lock-drop counter can be enabled via control socket configuration property iface_lockdrop_counter_enabled or in web interface (Interface → Lockdrop counter).
Lock-drop counter is incremented when two conditions are met. First, it is enabled. Second, the lock-status (signaled by interface deserializer) is down for a time longer then a configured timeout, called lock-drop timeout. This timeout can be set via control socket configuration property iface_lockdrop_counter_timeout or in web interface (Interface → Lockdrop counter timeout). Timeout can be set from 1 to 42949672 microseconds. The counter is 32bit unsigned integer overflowing from 0xFFFFFFFF to 0x00000000.
Lock-drop counter can be reset by control socket command reset_iface_lockdrop_counter.
Lock-drop counter can be read as control socket status property iface_lockdrop_counter.
The lock-drop counter feature is supported only for LVDS FPD Link 3 modules.
MGB has it's own battery backed real-time clock IC. The time can be set manually (Other → Datetime) or by NTP. Remember that manual setting considers local time, so the timezone (System → Olson timezone) is taken into account.
MGB runs NTP 4 software in client/server mode. NTP is configurable in web interface. You can set up to four NTP servers, that will be used to synchronize MGB time with. MGB serves as NTP server as well. When no NTP servers are available or configured, then NTP may go into so called Orphan mode and use the system time as source. This time is then provided to all NTP clients. The transition to Orphan mode is controlled by Orphan stratum and Orphan wait parameters.
Some information about the running NTP can be obtained from web interface (Other → NTP).
NTP peers info provides information about all available peers including related statistics. Peer prefixed by * is declared the system peer and lends its variables to the system variables.
NTP system variables info lists some NTP system variables. When sync_ntp variable exists, then NTP is synchronized.
See http://www.ntp.org to get more information about NTP.
Control socket is another way to control MGB. It is a TCP socket listening on port configured in web interface (System → Control port). Communication protocol is described here.
MGB maintains a configuration file, that is persistent across both power-cycle and firmware update. Generally the configuration can be viewed and modified in web interface. All items contained in Video, Photo, LAN, Interface, Triggers, NTP and System tabs are part of mentioned configuration file and so they are persistent.
It is possible to download the configuration file via HTTP server in two ways. Either click the appropriate button (Other → Configuration download) in web interface or directly get it at URL http://<mgb-ip>/configuration.xml.
It is possible to upload the configuration file via web interface (Other → Configuration upload) or Samba share. When using Samba, just copy the configuration file to shared folder at URL \\<mgb-ip>\confupload\. After the file is processed, it is deleted and only then you are allowed to upload another configuration file.
Remember, that some configuration options need reboot for changes to take effect, no matter how they are configured (via HTTP server or Samba share).
In some cases it may be required to reset the configuration to the default factory state. To reset the configuration, just follow these steps:
ATTENTION: Currently there is a known bug causing unexpected MGB shutdown about 1min after configuration reset.
There are two ways to update firmware, using SD card or Samba share.
To update firmware using SD card, just follow these steps:
To update firmware using Samba share, just copy the distributed firmware archive to shared folder at URL \\<mgb-ip>\fwupload\. After the file is copied, MGB performs some checks (cca 30s) and in case of some error the file is deleted and (only) then you are allowed to upload another file. In case of no error MGB reboots itself while LED gets red blinking, after a while LED gets orange blinking, final phase of update process starts and you have to wait until LED gets green. At this moment MGB is ready.
MGB has a socket for interchangeable video interface modules providing adaptation of external video interface to MGB's internal one. Interface modules may be installed only when MGB is shut down.
It consists of DS90UR916 deserializer. It is capable of grabbing all LVDS FPD Link 2 systems.
It consists of DS90UB948 deserializer. It is capable of grabbing all LVDS FPD Link 3 systems.
It consists of MAX96878 deserializer capable of GMSL2 and GMSL3 protocols. The module can capture one single video stream from the multistream input. The entire multistream is mirrored from input to Daisy Chain output. These GMSL dedicated options can be found in web interface:
FPD Link 3 protocol is much more complex than FPD Link 2. For this reason FPD Link 3 settings require more effort to fit in a given system. There are also special options in web interface allowing to set serializer and deserializer registers to custom values.
MGB contains internal synchronization generator, that generates internal VSYNC (Vertical Synchronization) pulses according to DE (Data Enable) signal. It must be enabled in systems, which lack these signals (e.g. MIB2+ Bottom Display). On the other hand this feature should be disabled if video already contains these signals. DE/Vsync length option sets the size of DE gap that generates the VSYNC pulse (e.g. if set to 1000 and DE is active high, low level on DE longer than 1000 pixels triggers the VSYNC pulse). This value should be set longer than DE gap at the end of the line and shorter than DE gap at the end of the frame.
A few known configurations are listed below. These values were found experimentally and could be changed occasionally in the future.
MIB2+ MGB between ZR and TOP display:
| LVDS input | : | DUAL |
| OpenLDI | : | DUAL |
| On lock falling edge reset | : | DES-SER |
| On lock rising edge reset | : | DES-SER |
| Internal Hsync/Vsync generator | : | disabled |
| Custom configuration | : | disabled |
MIB2+ MGB between TOP and BOT display:
| LVDS input | : | DUAL (one SW version of D5 used SINGLE) |
| OpenLDI | : | DUAL (one SW version of D5 used SINGLE) |
| On lock falling edge reset | : | DES-SER |
| On lock rising edge reset | : | DES-SER |
| Internal Hsync/Vsync generator | : | enabled (this can vary according to D5 SW version) |
| DE/Vsync length | : | 1000 |
| Custom configuration | : | disabled |
MIB2+ ICL:
| LVDS input | : | DUAL |
| OpenLDI | : | DUAL |
| On lock falling edge reset | : | DES-SER |
| On lock rising edge reset | : | NONE |
| Internal Hsync/Vsync generator | : | disabled |
| Custom configuration | : | disabled |
| Back channel | : | UART |
| Back channel sniffer | : | enabled |
MIB2 HIGH 9.2”:
| On lock falling edge reset | : | NONE |
| On lock rising edge reset | : | NONE |
| Internal Hsync/Vsync generator | : | disabled |
| Custom configuration | : | disabled |
MIB3 OI 9.2”:
| Internal Hsync/Vsync generator | : | disabled |
| Custom configuration | : | enabled |
| LVDS3DESCTRL0 | : | 0x049EB800 |
| LVDS3DESCTRL1 | : | 0x00003440 |
| LVDS3DESCTRL2 | : | 0x00000001 |
| LVDS3SERCTRL0 | : | 0x001E00D2 |
| LVDS3SERCTRL1 | : | 0x00802000 |
AUDI HCP3:
| OpenLDI | : | DUAL |
| GMSL protocol | : | GMSL3 (AR-HUD, FID), GMSL2 (CID) |
| GMSL rate | : | 12 Gbps (AR-HUD, FID), 6 Gbps (CID) |
| GMSL stream ID | : | 0 (AR-HUD), 1 (FID), 2 (CID) |
| GMSL FEC | : | enabled (it was disabled in some ZR softwares) |
PORSCHE HCP3:
| OpenLDI | : | DUAL |
| GMSL protocol | : | GMSL3 |
| GMSL rate | : | 12 Gbps |
| GMSL stream ID | : | 0 (AR-HUD), 1 (FID), 2 (CID), 3 (DID) |
| GMSL FEC | : | enabled (it was disabled in some ZR softwares) |
MGB is delivered without any connection cables because of a variety of video systems. However some usable connection cables including their documentation sheets are listed below.
Cables can be ordered from MD ELEKTRONIK GmbH, Neutraublinger Str. 4, D 84478 Waldkraiburg, Deutschland.