Relay Slave Board for the Mercury System

Mercury system peripheral board with two relays on screw terminals and a four-way dip switch for the bus address.

SKU 7305-SB110EAN 8219671102223Item type: Assembled, Shields & add-ons

Description

Slave Board for the Mercury System. It carries two relays, a LED for user applications, a four-position dip switch for setting the board’s bus address dynamically, a Mercury connector, a programmer connector and screw terminals for the relays.
Mercury System
Mercury System (MS for short) is a modular system for developing connectivity and IoT applications. The system uses several types of electronic board (logic unit, modem, slave board with sensors and actuators, power boards and so on) plus a complete SW structure that makes complex applications possible. Scalability, ease of use and modularity are the key factors, and they come from using a mixed set of components that let the system be assembled like a model built out of LEGO© bricks.

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

Base Board (BB): This is the “brain” of the whole Mercury System: it holds the main logic unit, several communication buses and the connectors for interfacing the slaves. It also has a simple power supply and a charger for a single LiPo cell (enough to cover the power needs of simpler systems). It comes in several variants, depending on the microcontroller unit used.

Modem Board (MB): this is the board that provides network connectivity. It comes in several variants, depending on the network interface (GSM / GPRS, Wi-Fi, BT, Radio and so on). It connects to the base board over a dedicated serial line.

Power Board (PB): this is the board that covers the system’s particular power requirements when they arise. These boards vary according to the power need to be met (high power, solar harvesting, piezoelectric harvesting and so on).

Slave Board (SB): these are the system’s peripherals and vary according to the particular sensor or actuator fitted. Typical examples are SBs with relays, temperature sensors, RGB LED controllers, servo drivers, accelerometers and so on. They talk to the BB over I2C or UART with a dedicated command set.

Expansion Board (EB): these are the boards that allow Mercury boards to be connected side by side. Some variants can carry a display, a battery holder and so on.

Brain-Less Board (BL): these are the boards with no controller. As a rule they carry really simple sensors or actuators that do not need the bus interface. They are an alternative to slave boards in cost-sensitive applications.

Slave Boards and Modem Boards come pre-programmed with firmware that implements a dedicated command set for high-level control, while Base Boards carry a software framework that provides all the low-level services (operating system, device drivers, system services and so on), leaving the user only the application-level logic to write.

Mercury System Framework
Mercury System Framework (MSF) is a layered software framework designed specifically to support application development with the Mercury System. It gives the user a complete set of basic functions for interfacing Slave Boards (SB) and Modem Boards (MB) easily, along with a number of software and infrastructure system services.
The framework is made up of the following components:

HAL (Hardware Abstraction Layer): the purpose of this layer is to hide the hardware dependencies 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 the Modem Board (WiFi, BT, GSM / GPRS). It also provides a set of system services such as System Power Management, RTCC, USB terminal and so on.
It is split into two main components:

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

The Slave Boards of the Mercury System
The layout of the Mercury Slave boards is standardised, to simplify interfacing with the Base Board and to guarantee a high level of modularity and scalability. Every slave board has an I2C (Inter Integrated Circuit) communication line and a four-position dip switch for setting the slave board’s bus address dynamically. Addresses 0x01 to 0x0F are available for the Slaves, while address 0x00 is reserved for broadcast communication. Up to 15 devices can therefore be connected to the Base Board using the dynamic addressing scheme. That number can be increased further by reprogramming the Slave with an address supplied by the software. Two open-collector digital lines connected to the base board’s external interrupts are also provided, for slave boards that need to raise asynchronous interrupts. Finally, slave boards that need more bandwidth and peer-to-peer communication can be interfaced over an additional UART channel.

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:

Sub-families Examples
Sensor Slave Board Ultrasound, infrared, temperature and humidity, PIR, gas sensor, air quality, thermocouple, humidity, analogue input, accelerometer
Actuator Slave Board Relay, High-Side Driver, Low-Side Driver, Servo, DC Motor, Stepper Motor, Neopixel
Communication Slave Board RS232, RS485, CAN, LIN, Ethernet, Bluetooth
Interface Slave Board OLED Display, Keypad, Mini-Joystick
Special Slave Boards SD Card, MP3 decoder

Documentation and useful links

Technical details

PML peripheral management layer
SSL system services layer

You may also like…

About us

Open-Electronics.org is the brainchild of a world leader in hobby electronics Futura Group srl. Open-Electronics.org is devoted to support development, hacking and playing with electronics: we share exciting open projects and create amazing products!

Open-Electronics.org is not just a container of ideas: it is also a web site lead by a team of engineers and geeks who will take part in the discussions and give support.

Our mission is to become a reference Open Source hacking site with ideas and feedback aimed to enrich the community.