1 / 27

ACS at the Atacama Pathfinder Experiment (APEX)

Dirk Muders Max-Planck-Institut f ür Radioastronomie Bonn. ACS at the Atacama Pathfinder Experiment (APEX). The APEX Project. APEX is a 12m radio telescope located north of the ALMA site on Chajnantor at 5100m

melindasexton
Download Presentation

ACS at the Atacama Pathfinder Experiment (APEX)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dirk Muders Max-Planck-Institut für Radioastronomie Bonn ACS at the Atacama Pathfinder Experiment (APEX)

  2. The APEX Project • APEX is a 12m radio telescope located north of the ALMA site on Chajnantor at 5100m • APEX is a pathfinder mission aimed at exploring the southern sub-mm sky in preparation for ALMA • APEX is a collaboration between MPIfR, AIRUB, ESO and OSO

  3. The APEX Project (cont.) • APEX is a copy of the US ALMA prototype antenna built by VERTEX • Compared to the ALMA telescope APEX features two additional Nasmyth receiver cabins, an instrument container and a compressor platform

  4. APEX Interfaces • APEX uses the same vendor-supplied control computers (ACU & PTC) and the same CAN bus interface (ICD 9) like ALMA • It was thus decided to re-use the ALMA prototype telescope control software (TICS) and most of the corresponding control hardware setup

  5. APEX Instrumentation • The APEX instrumentation will consist of: • Bolometer cameras with several hundred pixels (e.g. LABOCA) at λ=1 mm to 350 μm • Heterodyne receivers (single-pixel and arrays) at ν=230 GHz to 1.5 THz (200 μm) • Continuum backends • Auto-Correlators

  6. APEX Status • APEX has been erected in early 2003 • In September 2003 the telescope control system hard- and software were installed • Preliminary acceptance tests took place in November 2003 • Currently the pointing is being checked with an optical telescope

  7. Difficulties at 5000m: Low pressure Low oxygen content Oxygenization Pressurized Hard DriveBox

  8. ACS / TICS at APEX • APEX is using TICS and thus ACS • The ACS version in use is determined by TICS (currently ACS 2.0.1) • We will probably upgrade to ACS 3.0.1 this year if a new (stable) TICS port will be available

  9. ACS / TICS at APEX (cont.) • TICS provides antenna control (astronomical coordinate tracking, patterns, CAN bus access, etc.) via 4 COBs • ALMA's timing setup is much more complicated than needed for APEX • APEX uses GPS & IRIG-B to slave the ABM to TAI and a hardware timing generator for the 48ms Timing Events

  10. APEX Instrument Interfaces • APEX instrumentation needs to be interfaced to the ACS -> make components • Many instruments are legacy devices that use a simple ASCII protocol over a socket rather than the CAN bus that ALMA employs • Thus a socket DevIO implementation is needed

  11. APEX Socket DevIO • The socket code needs to handle sending and parsing ASCII messages for component properties AND for methods • It must handle multiplexing and concurrent accesses to the component properties • The messages are standardized using the SCPI syntax

  12. Socket DevIO Class Diagram

  13. SCPI Syntax Component sends the device: [APEX:]<device name>:<property/method name>? The device replies: [APEX:]<device name>:<property/method name> <value> \ <ISO 8601 time stamp> Example: APEX:SIS345:LO2:MULTI1:backShort2? APEX:SIS345:LO2:MULTI1:backShort2 2.341 \ 2003-11-05T10:19:38.310+00.00

  14. APEX Instruments IDLs • The instrument IDLs are kept as generic as possible to be able to re-use them for new instruments of the same kind; only a new CDB entry is needed • Instruments are implemented via a hierarchical device tree to: • have one high-level interface for observing • have low-level interface(s) for engineering

  15. APEX Device Hierarchy APEX:SIS345 apexHFE.idl APEX:SIS345:CALUNIT apexHFE_HCal.idl APEX:SIS345:MIXER1 apexHFE_Mixer.idl APEX:SIS345:MIXER1:COLDAMP apexHFE_ColdAmp.idl APEX:SIS345:MIXER2 apexHFE_Mixer.idl APEX:SIS345:MIXER2:COLDAMP apexHFE_ColdAmp.idl APEX:SIS345:LO1 apexHFE_LO.idl APEX:SIS345:LO1:GUNN apexHFE_Gunn.idl APEX:SIS345:LO1:PLL apexHFE_PLL.idl APEX:SIS345:LO1:MULTI1 apexHFE_Multi.idl APEX:SIS345:LO1:MULTI2 apexHFE_Multi.idl APEX:SIS345:LO2 apexHFE_LO.idl APEX:SIS345:LO2:GUNN apexHFE_Gunn.idl APEX:SIS345:LO2:PLL apexHFE_PLL.idl APEX:SIS345:LO2:MULTI1 apexHFE_Multi.idl APEX:SIS345:LO2:MULTI2 apexHFE_Multi.idl

  16. Code generation • The C++ component code is automatically generated from the IDLs using a modified version of the “bdsGenerator” from AIRUB • C++, *.h, xml and xsd files are created • DevIOUDPSock socket communication code & SCPI commands are automatically added • Embedded system host name and port are stored in the CDB and read at startup

  17. Serial & GPIB Devices • Many commercial devices use RS232 or GPIB communication with given commands • General problem of non-concurrent access -> need to serialize commands • Demultiplexing is done in the standalone SCPI command parser (CID) which in turn talks to the hardware, i.e. CID is a “driver” • Socket DevIO is re-used here

  18. CID Setup

  19. Device Emulators • A simple Python script was developed to emulate socket devices • The emulator uses the IDLs and sets up all property types automatically • Simple funtionality such as setting actual to commanded values is included • Can be extended easily

  20. APEX Control System (APECS) • For real observations all those components need to be set up and coordinated to perform “scans”. This is done by the “APEX Observing Engine” • The APEX raw data format (MBFITS) was defined based on ALMA's TI-FITS • The raw data writer collects telescope and backend data to write MBFITS files

  21. APECS (cont.) • APECS uses ACS to provide the necessary infrastructure to observe with APEX: • Observer CLI & GUI to set up scans for a number of standard observing modes • Telescope control (via TICS) & device setup • Raw data (MBFITS) writing • Online calibration (TA*) and data reduction for pointing, focus and skydip

  22. APECS Class Diagram

  23. APECS DeploymentDiagram

  24. ACS Pros • Hides many CORBA details • Allows for flexible distributed systems • Simple deployment reconfiguration • Component property model is very useful for hardware device implementations • Remote monitoring and remote observing is easily implemented

  25. ACS Cons • Steep learning curve; lab staff typically does not want to deal with it directly • ACS is pretty large; this conflicts with using it in embedded systems • TCP connections get stuck when parts of the software need to be restarted • Missing connection to existing lab tools such as LabView

  26. APEX's ACS Wishlist • Auto-reconnection does not always work but is essential for operations • Rather get a stable and debugged ACS than new features since ACS is the infrastructure for everything else • Share IDL and naming structure with other projects to facilitate re-using code

More Related