This is an old revision of the document!
The ADuCM3029_demo_cn0537 project provides a solution to implement a smoke detector with the capability to pass UL-217 specification, using the EVAL-CN0537-ARDZ and the EVAL-ADICUP3029. The Arduino shield uses a ADPD188BI to control the LEDs and photo-diodes, a temperature sensor for compensation, heater resistors to correct condensation and an SD card adapter to log operation data when not attended by a user terminal. The program can be controlled using a UART CLI.
The ADuCM_demo_cn0537 project uses EVAL-CN0537-ARDZ and EVAL-ADICUP3029 to provide an UL-217 compliant solution to smoke detection. The application gives user access to the ADPD188BI registers and other software defined application parameters to get smoke data at the desired rate and use it to calculate the Power Transfer Ratio (PTR) that directly correlates to the amount of smoke in the chamber. The alarm algorithm then takes the PTR measurement and measures it against a calculated baseline to determine if the alarm should trigger or not. The application has two main stages:
In the initialization process the software modules and part drivers are instantiated and set to initial values. ADD PICTURE The application initializes the CLI process on top of the UART core and then sets up the ADPD188BI for smoke detection measurements. The program then reads calibration data from the part and uses them to set up the PTR measurements. After the PTR measurements are ready the application initializes the algorithm. This process may take a few seconds to complete. The application finishes initialization by setting up temperature compensation and real time clock counter. The main process is then started in idle mode.
The main process has two modes of operation: idle and streaming. In idle mode the serial CLI may be used to alter functionality parameters like ADPD188BI registers and output data rate. The CLI can also be used to set up SD card logging by creating a file on it. Note that for the log to be complete, the file opened on the card must also be closed for the data to be saved.
Using the 'stream' command the process switches to streaming mode where smoke data is taken out at the set sampling rate. After temperature compensation and PTR calculation, data is fed to the algorithm to determine the alarm state. If the alarm is triggered the buzzer is activated and the alarm can only be reset by pressing the button on the shield or calling the 'reset_alarm' command on the CLI. If working parameters need to be adjusted it is recommended to return to idle mode by calling the 'idle' command and adjusting as necessary and then return to the stream mode. In streaming mode, if the serial terminal is connected, the application will display temperature compensated code values or PTR values at users choice, timestamped. The timestamp is in seconds relative to the start of the application. The alarm state is also displayed on the terminal while streaming.
The following is a list of items needed in order to replicate this demo.
The configuration parameters can be found in the config.h file.
vref - Reference voltage of the ADC. If the internal reference is used this value must be 2.5V. If an external reference is used then this value must be the value of the external reference.
Referece | vref value |
---|---|
internal | 2.5 |
external | Actual reference voltage |
/* Reference voltage of the ADC */ float vref = 2.5;
A serial terminal is an application that runs on a PC or laptop that is used to display data and interact with a connected device (including many of the Circuits from the Lab reference designs). The device's UART peripheral is most often connected to a UART to USB interface IC, which appears as a traditional COM port on the host PC/ laptop. (Traditionally, the device's UART port would have been connected to an RS-232 line driver / receiver and connected to the PC via a 9-pin or 25-pin serial port.) There are many open-source applications, and while there are many choices, typically we use one of the following:
Before continuing, please make sure you download and install one of the above programs.
There are several parameters on all serial terminal programs that must be setup properly in order for the PC and the connected device to communicate. Below are the common settings that must match on both the PC side and the connected UART device.
In many instances there are other options that each of the different serial terminal applications provide, such as local line echo or local line editing, and features like this can be turned on or off depending on your preferences. This setup guide will not go over all the options of each tool, but just the minor features that will make it easier to read back data from the connected devices.
Example setup using Putty
Typing help or h after initial calibration sequence will display the list of commands and their short versions. Bellow is the short command list:
Function | Command | Description | Example |
---|---|---|---|
General commands | |||
h | Display available commands. | ||
stts | Display parameters of the application. | ||
Internal register commands | |||
r | Display voltage or current on the selected channel. <chan> = channel to be shown | ||
sur | Change channel update rate. <rate> = new channel update rate in Hz. If it is bigger than output data rate divided by 80 can cause unpredictable behaviour. | ||
HART commands | |||
he | Enable HART channel. | ||
hd | Disable HART channel. | ||
hcc | Select wanted channel. <chan> = Channel to be selected. | ||
ht | Transmit string through HART. <string> = string to be transmitted. | ||
hg | Send the received buffer through UART connection. | ||
hcz | Send command zero with the specified number of FFs in the preambule. <pbsize> = size of the preambule (no. of 0xFFs in the beginning). | ||
hpt | Send command zero with the specified number of FFs in the preambule. <byte> = byte to send in loop. | ||
ADC commands | |||
arr | Display value of ADC register of the given address. <reg> = address of the register. | ||
awr | Change value of the ADC register of the given address. <reg> = address of the register. <val> = new value of the register. | ||
ags | Get a specific number of samples from the given channel. <ch> = selected chanel. <nr> = number of channels; cannot exceed 2048. | ||
aso | Set sample rate. <sps> = selected sample rate option. If it is smaller than channel update rate multiplied by 80 can cause unpredictable behaviour. | ||
asf | Set filter option. <filter> = selected filter option. | ||
aep | Enable post filter. | ||
adp | Select postfilter. <opt> = selected postfilter option. | ||
asp | Reset controller, parameters and faults | ||
aowe | Enable open wire detection. | ||
aowd | Disable open wire detection. | ||
EEPROM commands | |||
de | Discover EEPROM I2C addresses if there are any. |
We recommend not opening the project directly, but rather import it into CrossCore Embedded Studios and make a local copy in your workspace.
The source code and include files of the ADuCM3029_demo_cn0414 can be found here:
The official tool we promote for use with the EVAL-ADICUP3029 is CrossCore Embedded Studio. For more information on downloading the tools and a quick start guide on how to use the tool basics, please check out the Tools Overview page.
For more detailed instructions on importing this application/demo example into the CrossCore Embedded Studios tools, please view our How to import existing projects into your workspace section.
For more detailed instructions on importing this application/demo example into the CrossCore Embedded Studios tools, please view our How to configure the debug session section.
The program is composed of two main parts:
Board setup initializes UART, SPI and I2C communication and verifies if there is an active EVAL-CN0414-ARDZ board connected by reading the AD4111 ID register. Here is also initialized the update timer for the internal channel registers.
The main process routine implements the CLI and calls the commands input by the user. This routine also checks the flags asserted in the asynchronous events (the update channel register flag, the HART received flag and the floating channel flags) and calls the appropriate handler methods. There is also a flag asserted by the channel register update rate and the ADC output data rate. If the update rate would be too close to the output data rate, the actual update rate might slow down to be possible for the program to maintain all functionality. The update rate may never be bigger or equal to the ADC output data rate divided by 8 (for 8 channels).
The flow chart below represents the way the channel registers are updated. Only one channel is active at any one time (the channel that must be read).
End of Document