- 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.
- 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.
- Adaptive Secondary Control System This CAN document from Micrograte defines the UDP/IP command interface among other things (from 2003-12-18).
- Requirements_for_the_ARGOS_BCU_version_1.3.pdf This document created by Gilles on 2010-09-08
- LBT672 Design Report Electronics This document contains sections describing the UDP communication. Marco Xompero (Arcetri) gave me this document on 2011-03-22.
- Draft SC BCU user manual Version from May 5th, 2011
- 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)
- The GUI visualizes the CM pixel map
- The GUI visualizes the subapPixelWeight
- 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:
| APD counters
| 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:
- x and y slopes
- frame counter
- status byte
- four APD counters
sends prepared frames. The diagnostic records must contain the values of the BonnUnit
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 (
) and the BonnUnit
frame counter (
). The difference between
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?
- It was often necessary to reset the BCU when running simple test programs.
- The byte order of the MGP packet is undefined. It is assumed that little-endian byte order is used.
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.
The referenced tables can be find in the document LBT-MIC-TRE-00910-0001 from 2011-02-05.
- Configure the HVC completely
- Table 6
- All values from Mario's MATLAB script
- Table 54, 55, 56, 57
- Access to the diagnostics from NIOS memory, i.e. table 14 and 15
- Access to the HVC Diagnostic records from the master diagnostics (table 43 and 44)
- Access to the HVC local actuator control loop diagonstics, i.e. table 58
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:
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.
- number of Shack-Hartmann filters
- number of slopes if eacg Shack-Hartmann sensor
- number of dowloaded pixels
- size of the LUT
- slopes normalization mode
DSP Parameters (slope computation)
Slope pixels are part of the SH active area. The following parameters are useful:
- the number of pixels per subaperture is configurable (Where???)
- pixel gain for each SH subaperture
- pixel offset for each SH subaperture
- time history coefficient
- slope offset
- global tip-tilt
- 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:
- pixel gain
- pixel offset
Average Flux Parameters
These parameters refer to slope pixels and contour pixels.
- gain of contour pixels sum
- gain of actual slope pixels sum
- 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
is necessary to upload the LUT.
Each diagnostics records contains the following entries:
- slope pixels
- contour pixels
- calculated average flux
- calculated slopes
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