Mini-Project 2: Weather station with CAN-Bus¶

To measure and analyze the temperature at different points of the environment, for example the indoor and outdoor temperature, a weather station can be used. Such a weatherstation, which consists of a master and one or more slave devices, can be simulated with your MCU kit. In a team of maximum three you will condense what you have learnt in the lectures and tutorials throughout the semester into an application. For the first part of the project, the requirements are clearly defined and must be fulfilled for a passing grade. In the second part, you will have the opportunity to implement additional features to achieve the maximum grade. A catalogue of ideas for additional features is provided at the end of the project description. Feel free to implement your own ideas.

Grading¶

The project will count towards your final grade. A project with no additional functionality can achieve a sufficient grade - up to a grade 5. To get the maximum grade (6), you need to show creativity and implement additional tasks or functionality.

Completeness of the project and project management (4.5%)

Design (2%)

Functionality (3.5%)

Documents to be Submitted¶

You must provide all the documents necessary for the use (user perspective) and development (developer perspective) of your application in the BFH Gitlab project repository provided.

Git Workflow¶

As in a real software project, you should now assign a version number to each version on the master branch. Remember the usual way of versioning, v<major>.<minor>.<patch>.

Description¶

Your temperature logger kit will be used as a simulated temperature measure device for a weather station to measure the device temperature and the ground temperature of a field. The operator of the field needs several measurements, collected to a station inside a room. All devices are connected to a CAN-Bus system for communication. A basic slave device consists of a CAN-Bus interface, a sensor for the device temperature as reference, an external thermocouple temperature interface for measuring the ground temperature and an UART service interface.

Device Overview

The master device does not need the external temperature interface as it will be used in the office. The UART interface is needed to send all collected information to a computer. You can write the master and slave code into two different CubeMX projecs in one Git repository, each with a separate README. As an additional feature, it is possible to implement both parts in a single project.

All slave devices need some configuration values for the communication and localisation, which can be read out with UART.

The master will collect all data from the connected slaves and sends them with UART to the computer with a frequency of 1 Hz. The message must have the following structure:

"<index>,<location1>,<ddd.ddd>,<ggg.ggg>,<location2>,<ddd.ddd>,<ggg.ggg>,...\n"

Where the ddd.ddd is the device temperature and ggg.ggg the ground temperature from the device of location X. If no device is connected, the index is not incremented and the following status message is sent:

"#No device connected\n"

It is up to you to define how to measure the temperatures and send them to the master device. Describe the idea in the README and explain it in the presentation.

To provide a better overview of the required interfaces, these are explained in more detail below:

Temperature Measurements¶

Device Temperature¶

The internal temperature is measured with the LM75 Digital Temperature Sensor on the mbed application shield. The needed communication protocol is I²C. The received temperature is a 11-bit binary (two’s complement) value. The calculation to get a human readable floating point value is a task of this project.

External Temperature¶

The external temperature is read with the LTC2360 Analog Digital Converter, as the digital variant of MAX 31855 Thermocouple Digital Converter is not available for channel II due to conflicts with the CAN-Bus adapter. Read for more information about the analog measurement flow in Analog option.

CAN Communication¶

CAN is used for the transmission of data between the nodes (MCUs). The protocol is not defined. The definition of a workable communication method (protocol) is another task for your group. Here are some example which data is needed from the slave device.

• Master to node(s):

  • Get temperatures (device and field)

  • Get location

• Outdoor devices (nodes) to master:

  • Registration request

  • Device temperature

  • External temperature

  • Current location

Depending on your implementation or your additional features, the communication differs from the above example.

UART Communication¶

In order to standardize the communication with all devices, the settings are defined:

The protocol is defined as a simple "<command>:<arg1>,<arg2>,...\n" structure. The command followed by the value or values is expected as the response, e.g "<command>:<value1>, <value2>,...\n". With the defined device data, the desired commands are:

Requirements¶

The basic requirements for this mini-project can be derived from the description.

• System

  • The system should work for at least 2 slaves and one master.

  • The system works also for just one device.

  • The needed configuration of the devices is described in the README.

• Device Temperature:

  • The device temperature can be read out with the full resolution according to the data sheet.

  • The temperature is formatted to an human readable format including correct negative values.

• External Temperature:

  • The external temperature can be read out in the full resolution according to the data sheet with the analog option.

  • Which channel is selected to read out is written in the README or can be as an additional feature selected with UART or CAN.

• CAN-Bus:

  • The communication runs without errors.

  • Registration works to add / remove devices during runtime as described in the section CAN Communication.

  • The commands and expected answers are described in the README.

• UART Communication:

  • UART is configured as desired in the table UART Configuration.

  • All commands from the UART Commands are integrated for the slave device.

  • All UART commands and answers are described in the README.

  • The master sends every second the current temperature from all connected devices.

Additional Features¶

The implementation of additional features is required to achieve the highest grade. Of course, you do not have to implement all of them. Feel free to implement other features as well. If you provide your own additional features, they will be graded based on the invested programming effort.

The features will depend on the solution you provide for a minimum implementation.

• Display (0.5 - 1%)

  • Use the LCD display to show the device settings and current temperatures (0.5%).

  • Add more information to the LCD with a menu and a description in the README (0.5%)

• Internal ADC Measuring (0.5%)

  • Add as additional external temperature reference the internal ADC temperature value from measuring the same channel.

  • Send both values or only one with a possible error detection from a measurement option.

• Channel Selection over UART/CAN (0.5%)

  • Select the channel to read out with CAN / UART instead of using a fixed channel

• One project for master and slave device (1.5%)

  • Combine code of controller and field node(s) in one project. Control the type and settings etc. based on a configuration either at compile-time (conditional compilation) or at run-time (configuration property). Describe how to configure the type in the README.

• Add additional sensor (0.5 - 1%)

  • Add additional measurement values like device orientation measured with MMA7660 Motion Sensor (0.5%).

  • Interpret and calculate to readable values from the sensor data (0.5%)

• Registration of CAN nodes (0.5 - 1%)

  • Add the possibility to add more than 2 devices to the master (0.5%)

  • Add an automatically registration with unknown device addresses from the master (0.5%)