Big Relay Board for the Mercury System – 10 A

It has a 4-way dip switch that lets you set up to 15 different addresses (address 0x00 is reserved for the I2C Bus broadcast addressing scheme).

• Mercury Connector: to interface the board with the other boards in the Mercury family
• Address Dip Switch: Dip Switch for setting the board address within the Mercury system.
• Programmer Connector: PicKit 3 Microchip programmer / debugger connector. It plugs straight into the EB (Expansion Board) MCU debug port, to allow advanced debugging and programming features. 
• Relay: the SB111 board has a single relay output channel able to handle up to 10A.
• User LED: by default it is set up to work in heartbeat LED mode (periodic pulses)

• ADC: 12 ch, 10-bit
• Comparators: 2
• Temperature range: -40°C ~ 125°C
• Operating voltage: 1.8~5.5 V
• Pin Count: 20
• XLP: yes
• Cap Touch Channels: 12

The set of boards that makes up the Mercury System is built from the following “families”:

• Base Board (BB): It is the “brain” of the whole Mercury System and it holds the main logic unit, several communication buses and the connectors for interfacing the slaves. It also holds a simple power supply system and a charging unit for a single LiPo cell (able to meet the power requirements of simpler systems). It can exist in different variants, depending on the microcontroller unit used.

• Modem Board (MB): this is the board that provides network connectivity. It can exist in different variants, depending on the network interface (GSM / GPRS, Wi-Fi, BT, Radio …). It is interfaced to the base board over a dedicated serial line.

• Power Board (PB): this is the board that meets the particular power needs of the system, when required. They can vary according to the particular power need to be met (high power, solar harvesting, piezoelectric harvesting, etc.).

• Slave Board (SB): these are the peripherals of the system and they vary according to the specific sensor or actuator fitted. Typical examples are SBs with relays, temperature sensors, RGB LED controllers, servo controller, accelerometer, etc. They talk to the BB over I2C or UART with a dedicated command set.

• Expansion Board (EB): these are the boards that allow the Mercury boards to be connected planar. There are variants that can hold displays, a battery holder, etc.

• Brain-Less Board (BL): these are the boards with no controller. In general they hold really simple sensors or actuators that do not need the bus interface. They are an alternative to the slave boards for applications that call for low cost.

The Slave Boards and the Modem Boards come pre-programmed with firmware that implements a dedicated command set for high-level management, while the Base Boards come with a software framework that provides all the low-level services (operating system, peripheral drivers, system services, etc.), leaving the user only the application-level logic to develop. 

HAL (Hardware Abstraction Layer): the purpose of this layer is to abstract the hardware dependencies away from the layers above.
SML (System Management Layer): the purpose of this layer is to provide services for managing the communication buses (I2C, UART) and for managing the Modem Board (WiFi, BT, GSM / GPRS). It also provides a set of system services, such as System Power Management, RTCC, USB terminal, etc.
It is split into two main components:

• PML: peripheral management layer
• SSL: system services layer

OSL (Operative System Layer): this layer consists of a lightweight RTOS that provides basic services to the system, such as the scheduling tables for the various tasks, events, SW timers, alarms, etc.

There are several sub-families of Slave Board:

• Sensor Slave Board
• Actuator Slave Board
• Communication Slave Board
• Interface Slave Board
• Special Slave Boards

The table below gives some examples for each sub-family:

• Mercury System Getting Started Guide IoT and Connectivity Made Simple
• MS_SB111_Datasheet