1. Betram's minutes of the topical meeting at Microgate in August 2010 Topic was the slope computing BCU. This is a good introduction into the programming interface of the slope BCU.
  2. Berwein's minutes to the meeting at Microgate in August 2010 This document is a short form of Betram's minutes but but with links to the appropriate sections to the user manual of Microgate.
  3. Adaptive Secondary Control System This CAN document from Micrograte defines the UDP/IP command interface among other things (from 2003-12-18).
  4. Requirements_for_the_ARGOS_BCU_version_1.3.pdf This document created by Gilles on 2010-09-08
  5. LBT672 Design Report Electronics This document contains sections describing the UDP communication. Marco Xompero (Arcetri) gave me this document on 2011-03-22.
  6. Draft SC BCU user manual Version from May 5th, 2011
  7. wiki: SC BCU Training Notes The first contact with the SC BCU.

Requirements for the Engineering GUI

Gilles suggested the following functionality (2012-02-09)
  1. The GUI visualizes the CM pixel map
  2. The GUI visualizes the subapPixelWeight
  3. The GUI can provide operations for shifting the pupils.


The Bonn Unit from MPIfR sends slopes and APD counts to the SC BCU over a serial interface. The BCU stores these data into DSP memory and puts them in diagnostic records. In the current configuration the data is going to the following DSP memory locations:
slopes sc_RotTTSlopeVect
APD counters sc_APDCounters
frame number sc_FCVector + 4
status byte sc_FCVector + 5

Communication Test Ideas

Here are some test ideas for checking the communication correctness and communication duration between the BCU and the BonnUnit:

MPIfR Frame Fields in Diagnostic Records

This test check the existence of the following MPIfR frame fields in the diagnostic record:
  1. x and y slopes
  2. frame counter
  3. status byte
  4. four APD counters
The BonnUnit sends prepared frames. The diagnostic records must contain the values of the BonnUnit frame.

Communication Failures

The goal of this test is checking absence of communication failures.

In the diagnostic records, the frame counter of the BonnUnit must always increment by one. This behaviour is required for a BonnUnit arrival frame rate up to 1 kHz.

The BCU generates a diagnostic record only if a frame from the pnCCD arrives. In order to check the absence of communication failures at a BonnUnit arrival frame rate of 1 kHz, either the pnCCD or a frame generator is required. When triggering the diagnostic record generation by software, only at a low frequency of ca. 5 Hz is achievable.


In this test, the the jitter is checked, i.e. the variation of the BCU frame counter and the BonnUnit frame counter. The jitter should be zero.

For this measurement, the captured diagnostic records contain the BCU frame counter (dsc_FramesCounter) and the BonnUnit frame counter (sc_FCVector+4). The difference between dsc_FramesCounter and the BonnUnit frame counter must be constant during the whole test run. This test requires that the BonnUnit frame arrival rate and the slope computation rate are the same. This test is feasible with a low slope computation frequency.


This test checks the "latency", i.e to check the processing time for the BonnUnit frames by the BCU.

In this test, both the APDs and the CCD are exposed to light simultaneously for a short period of time. Then, the diagnostic records tell the delay between the BonnUnit frame processing and the slope computation. We expect that the diagonstic record with the the illuminated pixels contains the high number of photons in the APD counters.

From the diagnostic records, the APD counters and the BonnUnit frame counter is necessary. For this test, the pnCCD is necessary. Therefore, only MPE can perform this test at the moment.

@MPIfR: Does MPIfR has any number for the processing time of the BonnUnit. I.e. the time between APD readout and frame output to the BCU?

Occurred Problems

  1. It was often necessary to reset the BCU when running simple test programs.
  2. The byte order of the MGP packet is undefined. It is assumed that little-endian byte order is used.

BCU Limitations

traffic: whenever BCU based electronic devices are connected to a general purpose network, the usual broadcast traffic (e.g.: ARP requests) is likely to fill up the input data buffers of the Ethernet port and block the communication. After that, only a complete reset of the board can bring the Ethernet communication back to work.

Source: CAN document 485f004b

When operating BCUs, it is recommend to put them into separated networks. In this way, each BCU only received the destined Ethernet traffic (source: Alfio Puglisi during Argos consortium meeting in March 2011).

The BCU ignores the source UDP port of requests. The BCU always send responses with a destination UDP port 10000.

Glossary for Diagnostics Data

There are some terms concerning the diagnostics data from the BCUs and FLAO:
Mirror diagnostic data
The diagnostic data from the AdSec
Fast diagnostic
One process of the AO Supervisor receiving the mirror diagnostic data
MasterBCU mechanism
One operation mode of the BCU where the BCU streams diagnostic frames out to a specified network host (LN slope computer user manual, 2009-02-27)
Master diagnostics
The LN slope computer user manual has the variable enable_master_diag to enable/disable the MasterBCU mechanism. Perhaps, this is the reason for the term master diagnostics.

HVC Boards

The referenced tables can be find in the document LBT-MIC-TRE-00910-0001 from 2011-02-05.
  1. Configure the HVC completely
    1. Table 6
    2. All values from Mario's MATLAB script
    3. Table 54, 55, 56, 57
  2. Access to the diagnostics from NIOS memory, i.e. table 14 and 15
  3. Access to the HVC Diagnostic records from the master diagnostics (table 43 and 44)
  4. Access to the HVC local actuator control loop diagonstics, i.e. table 58

BCU Programs



Claus sent us a cable for testing the communication between BonnUnit and BCU. Our software setup failed to detect the MPIfR values like counts and framecounters in the diagnostic records which come from the BCU. We (jlb, mk) connected to Garching and tested the software setup with the BonnUnit and BCU there. In Garching, the MPIfR specific values were in the diagnostic records. The problem can be located in these components:
  1. BCU
  2. cable
  3. BonnUnit


The BCU39 is similar to the Argos SC BCU. That is why it is worth to use it in order to gain some experience with BCUs in general.

DSP code

  1. number of Shack-Hartmann filters
  2. number of slopes if eacg Shack-Hartmann sensor
  3. number of dowloaded pixels
  4. size of the LUT
  5. slopes normalization mode

DSP Parameters (slope computation)

Slope pixels are part of the SH active area. The following parameters are useful:
  1. the number of pixels per subaperture is configurable (Where???)
  2. pixel gain for each SH subaperture
  3. pixel offset for each SH subaperture
  4. time history coefficient
  5. slope offset
  6. global tip-tilt
  7. LUT selector

Contour Pixel Parameters

Contour pixels belong the the SH contour and are useful for background estimation including compensation gains and offsets. The following parameters are useful:
  1. pixel gain
  2. pixel offset

Average Flux Parameters

These parameters refer to slope pixels and contour pixels.
  1. gain of contour pixels sum
  2. gain of actual slope pixels sum
  3. gain of previous pixels sum

Subaperture Pixel Weights

The weights of each pixel in x and y axes in the subaperture are configurable. The user manual shows typical values.


The Look-Up-Table (LUT) tells the BCU the order of the arriving pixel values. The command MGP_OP_WR_SCIMEASURE_RAM is necessary to upload the LUT.

Diagnostics Interface

Each diagnostics records contains the following entries:
  1. slope pixels
  2. contour pixels
  3. calculated average flux
  4. calculated slopes

CCD Emulator

Besides using an attached CCD as source for images, the BCU can compute slopes from an uploaded image or from randomly generated images. The operating mode has to be set by using MGP_OP_WRITE_CCDI operations.
Topic revision: r4 - 07 Aug 2018, AndrewColson
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback