FSC - facts about the board

D. Neise 07.02.2011

Contents

1 Basic Facts and Purpose 2

1.1 measurement modes . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Ethernet Interface 3

2.1 FSC registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 getting out results - the telegram . . . . . . . . . . . . . . . . . . 4

1 Basic Facts and Purpose

This document presents electronic facts and figures of FACTs FSC board, which stands for Fact Slow Control. The name is a bit misleading, since the boards sole purpose is to monitor slowly changing parameters, such as:

• up to 64 temperatures (RTD like sensors, e.g. Pt1000 or Pt100),

• up to 4 humidities (designed for Honeywell HIH-40xx family),

• the DC levels of all FACT low voltage supply channels(32 ??? channels),

• the current drawn from each of these channels (converted to a voltage inside LV-supply).

FSC therefor brings an 8MHz ATmega32L micro controller(MCU), used to readout the muxed 24bit sigma delta ADC (AD7719) which is connected to the RTDs. In addition the ATmegas internal 10bit ADC is used to monitor the humidity, LV-voltages and LV-currents. The muxers on FSC belong to analog devices ADG77xx family, and are controlled by the MCU according to the users needs. The User has access to FSC via Ethernet Interface, comprised(?) by wiznets W5100, the younger brother of W5300, which is used on FACTs FAD boards. AD7719 and W5100 communicate with the MCU via an SPI bus, which results in the fact, that User interaction might slow down temperature measurement or vice versa. Additionally the user should be aware, that sigma delta ADCs have a long settling, when muxed. Redout of all 64 temperature channels takes about 13s, while the one channel might be readout with >10Hz. In addition FSC runs a 32bit timer, counting seconds since timer init. The timer is initialized to zero, when FSC is powered. User may synchronize FSCs timer to Unix time. We do not talk here about the accelerometer on the FSC, since this piece it not part of the original proposal.

1.1 measurement modes

FSC knows two measurement modes. The first is on demand. When FSC measures on demand, user may send a command telling FSC, what to measure. FSC will measure it and return the result, only after the measurement was finished. It is possible to tell FSC to measure several sensors at a time. If the user asked for a temperature measurement and FSC had to change the muxer setting, this might take up to 300ms. During a measurement on demand, FSC is not checking for incoming commands. So new commands will pile up in W5100 input FIFO. So sending a lot of on demand commands can easily delay FSC reaction a lot.

The second mode is free running. In free running mode FSC measures all activated sensors and stores the value and time tuples. Once all sensors were measured, FSC returns a measurement telegram. The user can define which sensors should be measured and which should be left out. Additionally one can tell FSC how often it should start a measurement cycle.

2 Ethernet Interface

FSC runs as a TCP/IP server, this means after W5100 was initialized, FSC will listen on one Port, but will not attempt to connect to any other server. Since W5100 does not support DHCP, FSC has a fix IP^{1}. The Port is not yet defined, but since FADs use Ports 5000-5007, there is a high probability, that you can access FSC via Port 5000 as well. For simplicity of firmware coding, the UI is non human readable, commands from User to FCS may look like this.

address  mnemonic description
byte 0  command see reference to next subsection
byte 1  ticket no number of commands - upcounting
byte 2 length length of data section - if apropriate
byte 3..1k data  parameters for command - if apropriate

Table 1: composition of FSC commands

FSCs answers might be eigther a short acknowledgement, in case the user changed a just setting, or a measurement telegram. An acknowledgement contains the number of the command, which caused the FSC to answer and looks like this.

address  mnemonic description
byte 0  ticket no number of the command,

causing this answer: range: 0x01 .. 0xFF

byte 1 length length of data section
byte 2  command first byte in data section: repeated command
byte 3..1k data  parameters for command - repetition as well

Table 2: composition of FSCs answer - acknowledgement

If the user asked for a measurement on demand, the acknowledgement contains the measurement telegram inside the data section. For a detailed description of the telegram refer to the right subsection. In case the FSC returns data measured, because it was switched to free running mode, the message looks slightly different.

address  mnemonic  description
byte 0  free run code 0x00 - is defined not to

be a legal ticket number

byte 1 length length of data section
byte 2..1k telegram  see the right subsection

Table 3: composition of FSCs free running massage

1see FACT Elogbook / doc

2.1 FSC registers

FSC uses the following registers.

address name  description
0x00  status  stats register - TBR (e.g. mode; timer synched?; )
0x01  error  error register -

TBR (AD7719 found disconnected sensor, HUM or TEMP too high, V or I out of range)

0x02  timer3
0x03  timer2
0x04  timer1
0x05 timer0 current time
0x06  TempEn7
0x07  TempEn6
0x08  TempEn5
0x09  TempEn4
0x0A  TempEn3
0x0B  TempEn2
0x0C  TempEn1
0x0D  TempEn0
0x0E  HumiEn0
0x0F  AcceEn0
0x10  VoltEn4
0x11  VoltEn3
0x12  VoltEn2
0x13  VoltEn1
0x14  VoltEn0
0x15  CurrEn4
0x16  CurrEn3
0x17  CurrEn2
0x18  CurrEn1
0x19  CurrEn0
...  ...  to be complited

Table 4: FSC registers

2.2 getting out results - the telegram

Most probably not every input channel will be connected to a sensor. In order not to measure unconnected channels, the user may define, which sensor is active.