Data format

[pointhi]

I used the board linked in the following issue to decode some board informations: OpenBoardView/OpenBoardView#126

In my case, I started with the lowest level of information (e.g. known tracks), thus I hardcoded "known" positions in the file to extract records as I think they might fit. I think for such binary-blobs that's the better approach, as it allows you to expand your knowlege step-wise. If you know how a record look like you can find the first one, and then the index to that record,..

This is just a dump of information I decoded some months ago, hope it helps 😃

Main Findings

• The file is little-endian
  • degrees are stored as 4 byte little endian integers in thousands of degrees (e.g. 180° = 180000)
  • coordinates are stored as 4 byte little endian integers, first comes x and then y. Sorry, I forgot in which unit they were (but you should find this out using the kaitai file and a board-viewer)
• I found some general "magic-byte" sequence which seemed to be the same on all files I looked on so far

Kaitai File

meta:
  id: allegro
  title: Allegro board file
  file-extension: brd
  endian: le
  encoding: UTF-8

# Findings (27.04.2021)
# Degree:
#  le 4 byte 180° = 180000
# Position x|y
#  le 4 byte | le 4 byte
# How found out: search for 180, 1800, 18000 until a high number of matches is found

# those numbers are the same on all allegro files I saw so far:
seq:
  - size: 3
  - id: magic
    contents: [0x00, 0x03, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x09, 0x00, 0x00, 0x00]
  - size: 44
  - id: zeroes1
    contents: [0x00, 0x00, 0x00, 0x00]
  - size: 60
  - id: zeroes2
    contents: [0x00, 0x00, 0x00, 0x00]
  - size: 36
  - id: zeroes3
    contents: [0x00, 0x00, 0x00, 0x00]
  - size: 28
  - id: zeroes4
    contents: [0x00, 0x00, 0x00, 0x00]
  - size: 28
  - id: zeroes5
    contents: [0x00, 0x00, 0x00, 0x00]
  - size: 12
  - id: string1
    type: str
    size: 60
  - size: 24
  - id: zeroes6
    contents: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]

instances:
  # file: 77G.MMW.automotive.radar-PCBF-V01-20180115-1520.brd
  # downloaded from https://github.com/OpenBoardView/OpenBoardView/issues/126
  
  # track_segment1: x=-18100 y=219000
  # pos: 0x25f284
  tracks_unknown:
    io: _root._io
    pos: 0x25f130  # hardcoded for now, only valid for this board
    type: tracks

  vias_unknown:
    io: _root._io
    pos: 0x2ea550  # hardcoded for now, only valid for this board
    type: vias

  # pad: 0x0032A990 - -233337 | 149000 | Pin2 | CAN_L

types:
  tracks:
    seq:
      - id: tracks
        type: track_seg
        repeat-expr: 20  # just show some vias to validate record
        repeat: expr

  vias:
    seq:
      - id: vias
        type: via_seg
        repeat-expr: 20  # just show some vias to validate record
        repeat: expr

  test:
    seq:
      - id: type_question_or_layer
        type: u4
      - id: data
        size: 32+4

  # TODO: offsets are wrong at some point
  track_seg:  # track_seg?
    seq:
      - id: type_question_or_layer  # no idea what this is, perhaps we can extract the record type -> size from it?
        type: u4
      - size: 4*4
      - id: width  # TODO: sometimes zero?
        type: s4
      - id: start
        type: point
      - id: end
        type: point


  # TODO: offsets are wrong at some point
  via_seg:
    seq:
      - id: position
        type: point
      - size: 4*5
      - id: rotation
        type: s4
      - size: 4*9

  point:
    seq:
      - id: x
        type: s4
      - id: y
        type: s4