Category: Solutions

The Creek: Collect Data (Part 1)

In The Creek: Server Architecture I described a program called “runI2C” which is a shell script that is run once per minute by the crontab on the Raspberry PI (RPi). This shell script does a “sudo” and runs the java program “i2cdb”.

“i2cdb” is a Java program that uses the open source pi4j library to access the RPi I2C bus, reads the data out of the PSoC4 and then inserts it into the “creek data” database. In order for all of this to work you first need to get the pi4j jar files. To do that, on the Raspberry Pi, run “curl -s get.pi4j.com | sudo bash” which will install everything you need:

Pi4J is a Java library that will give you complete access to the GPIOs on the Raspberry Pi, you can read and write the GPIOs as well as use the UART, SPI and I2C communication devices. Once you install the libraries you will have 4 jar files in “/opt/pi4j/lib” as well as a bunch of examples in “/opt/pi4j/examples”.

Because I wanted to edit the files on my Mac, I copied the libraries into my “lib” directory in the project so that Netbeans would know about them.

The next library that you need is the mysql-connector which is a jar supplied by the MySql team. You can get it from their website. I put this jar file in my “lib” folder as well.

In order to access the database, there needs to be a user in the MySql database. To do this, log in as root in the MySqlWorkbench tool and add a new user. I call this user “creek” and give it a password of “creek”, then restrict it to only being able to connect from the RPi IP address.

Then assign “creek”s privileges

The next step is to create a MySql script to create the database. Originally, I stored the ADC raw counts in the database because I wasn’t sure about calibration and I was interested in the raw data. The problem with this method is that I had to encode the conversion from raw counts to depth on the server side. I have come to believe that is a bad idea and that the acquisition hardware should be responsible for that conversion.

The easiest thing to do is to make a script to make the table. I called it “table.sql” and I run it by doing “mysql -u creek -p < table.sql”

This program has been written and re-written about a dozen times (including as I prepared this post) as I searched around for what was the “best” solution. Originally it started as a hard coded program. After some iteration I decided to create a configuration file. That file, called “config.properties” is read in when the program starts. It specifies:

The mysql url, user and password
Which database and table to store the data into
If it should store timestamps, and the name of the timestamp column
The number of “variables” to read
For each variable
- The BUS # (0 or 1) on RPi (on my model only bus 1 works)
- The I2C slave address
- little or big endian
- The name of the column to store the data in
- What type of data (uint8, int8, uint16, int16, float, double)

Here is the file “config.properties.test”:

I was going crazy trying to get all of the pieces to fit together (the endian-ness, the sign) and trying to sort out the fact that Java doesnt like unsigned. So I created firmware for the PSoC that just had one of each test case. The project is called “debugJavaPi” and is available on the iotexpert github site. This program just creates an I2C buffer with one of each type of data, then initializes them with known data, then services I2C requests.

In the next post I will explain in detail the I2CDB Java Program.

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: Install MySQL

As I described in the Creek Software Architecture, I am using MySql as the database to hold all of the creek temperature and depth information. That means I need to get MySql going on the Raspberry Pi. The process is well documented on the MySql installation website. To do the installation you need to run:

sudo apt-get update
sudo apt-get install mysql-server
type password for root when it asks

After a bunch of gyrations and pages of information barf onto the screen, you will have MySql going on your Raspberry Pi. You can verify that by running

sudo service mysql status

It turns out that the command “service” has a number of useful options including:

sudo service mysql stop [which will turn off mysql]
sudo service mysql start [which will start it]
sudo service mysql restart [which will restart it]

As you guys might have noticed I like to run stuff on my Mac. In order to get mysql to talk on the network you need to change the networking configuration. To do this edit the file “/etc/mysql/my.cnf”

sudo vi /etc/mysql/my.cnf

Then add a “#” to comment out this bind-address statement

#bind-address = 127.0.0.1

Then you can restart mysql with the updated options using:

sudo service mysql restart

Once that is working you can add the ability for the root user to access the mysql service remotely on the network. To do this run the command line version of mysql

mysql -u root -p [it will ask you the mysql root password]
grant all privileges on *.* to ‘root’@’192.168.%.%’ with grant option;
quit

The “192.168.%.%” will restrict the access to this server/user to only the private IP addresses in my network.

Then you can startup MySqlWorkBench from your Mac (or whatever). The first thing that I do in MySqlWorkbench is to create a connection to the RPi. Remember in the previous post I added the IP address of the RPi to my “/etc/hosts” file and called it “iotexpertpi” this lets me refer to the RPi by name.

After I make the connection and click on the “Users and Privileges” button things look like this:

Then I create a database for storing the creekdata.

And a user called “creek” who is allowed to connect only from the Raspberry Pi.

And give that user insert/select privileges on the creekdata database:

That is it for MySql. In the next posts I will add Tomcat- a JSP Server- to the RPi.

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: Install the Raspberry PI Software

Years ago, when I did the first install of a Raspberry Pi (RPi), this whole thing was quite painful, however at this point the installation process is well documented. In addition adafruit.com has a nice tutorial about making the I2C work here.

To start the process download the Raspbian image from it from here.

Because I talked so much about security in this post, I thought that I had better check the cryptographic hash. So, I run

openssl sha1 2016-03-18-raspbian-jessie.img

And I get:

SHA1(2016-03-18-raspbian-jessie.img)= 824f4daf805eb0ff49bc3fa515d97f447d382d37

which definitely didn’t match the signature, so now what? Is this a hack? It turns out that my Mac “helps” you by unzipping the file. The cryptographic hash of a file and a zip of that file are different. If you download the zip and run the hash you will get:

SHA1(2016-03-18-raspbian-jessie.zip)= db41f2a8c6236c0ca9150fe4db2017c09e7871fb

OK. They match. Good. The next step is to write the image to the flash card. To do this

Insert the card (into your Mac)
See what disks are mounted
Unmount the volume (if you already had something on the card)
Write the image onto the flash card. In the instructions on the Raspberry Pi site there is some confusion about if you should use /dev/rdiskx or /dev/diskx. Thats simple, you should use the “r” version. “r” stands for raw and is unbuffered and as such is much faster to write. Even with the raw device it still takes a few minutes. While it is writing you can press “ctrl-t” and it will give you a status (which I did twice during the write process)
Unmount the disk

Now that you have a bootable flash disk your next step is to insert the card into your RPi, attach a keyboard, the network cable and a screen. Then boot it. After a few minutes you should see:

The first thing that needs to be done is to change the password and expand the filesystem. To do this run “sudo rapsi-config” then select

[Option 1] Expand Filesystem
[Option 2] Change User Password

I prefer to interact with the RPi using secure shell from my Mac. To do this I need to know what IP address was assigned by my DHCP server. So, start a terminal on the Pi and type:

ifconfig (find the ip address and the ethernet mac address)

Once I know the ethernet mac address I can configure my DHCP to always give this Raspberry Pi the same IP address. You can read more about this in the “Creek Network” post. For now I will assign the RPi the address 192.168.15.82 and I will add that address to the /etc/hosts file on my Mac so I can refer to it by the name “iotexpertrpi”

Now that all of the networking is setup, reboot. As I have configured the IP address I can now log in using secure shell and start the configuration process.

[from the Mac] ssh pi@iotexpertpi (you will need to type the password which is “raspberry”)
[on the pi] mkdir .ssh
[on the pi] chmod 700 .ssh
[on the pi] exit
[from the Mac] cd ~/.ssh
[from the Mac] scp id_rsa.pub pi@iotexpertpi:.ssh/authorized_keys (you will need to type the password)

Then, to test SSH I will exit and log back in. After the secure shell is going I need turn on the stuff in the configuration that enables I2C.

[on the pi] sudo apt-get install i2c-tools

In order for the I2C work you also need to enable the kernel drivers for I2C. To do this run “[on the pi] sudo raspi-config”

After I2C is setup I will change the RPi to not start X-Windows.

After all of that, reboot the RPi and see if things are working.

[on the Mac] ssh pi@iotexpertpi
[on the pi] i2cdetect -y 1 (the 1 means bus 1. On the Broadcom chip there are 2 IC Masters which they have labeled 0 and 1. Apparently they did not connect Master 0 to anything)

This is good. I can “search” all of the addresses. Basically the RPi tries to write each address. If it gets an “ack” then it will indicate that on the chart with a number. In the picture below you can see that there are no I2C devices attached to the bus.

Everything looks good. Halt the RPi then attach the CYPI board and reboot.

Now, when I log back in and run “i2cdetect -y 1” lookey there, the CYPI “ACKs” on address 08.

If you remember in this post I talked about the I2C register structure of my Creek Firmware. In the two bytes starting at location 2, is a 16-bit integer of the temperature times 100 (I just noticed the error in my comment, bad Alan). Here is the register structure:

In I2C tools, the command “i2cget” can read bytes or words from an I2C Slave. Are things working? Run “i2cget -y 1 8 2 b” and “i2cget -y 1 8 2 b” and I get 0x10 and 0x09 or 0x0910 (remember that the data is stored little endian) which is 2310 in decimal or 23.1 degrees C. That makes sense. What is a bit confusing is when I read a whole word by changing the “b” to “w” it gives it to me correctly because it ASSUMES little endian, so be careful if your slave device doesnt store thing little endian.

Everything seems like it is working. In the next posts I will discuss the installation of the MySql, Tomcat and the rest of the server software.

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: Server Software Architecture

In the previous Elkhorn Creek posts I discussed the overall system architecture, the design of the Creek Board, and the design of CYPI. In this post I will focus on the software that is running on the Raspberry PI. The software is divided into two main pieces.

The Backend Server
The Java Server Pages GUI

For this application, most of the software on the Raspberry Pi is written in Java. In someways this was a strange choice, but I work with a group of guys who are Java programmers and build lots of web based Java applications, so Java it is.

Backend Server

The Backend Server performs the following jobs

Collects data from the PSoC4 via an I2C Master that resides in the Raspberry Pi and stores it into a MySQL Database
Once every 5 minutes creates a chart of the last 8 hours and stores it into a PNG which can be served by the Tomcat GUI
Bootload new firmware into the PSoC4

The first two jobs are run by “Cron” which is a unix utility to trigger jobs automatically. The cron table on the RPi looks like this:

# m h dom mon dow command

* * * * * /home/pi/getCreek/runi2c

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /home/pi/getCreek/makePNG

The BootloaderHost is triggered via the command line only after new firmware is sent to the RPi.

In future posts I will discuss

The BootloaderHost and the BCM2835 library
runI2C, the JDBC driver and the PI4J library
makePNG including JFreeChart

Java Server Pages (JSP) GUI

The user GUI for this system is a webpage that is served by the RPi. I use the Tomcat Java Server Pages Server. The JSP page “basic.jsp” creates the table of numbers and loads the graph. The JSP page “excel.jsp” create a CSV dump of all of the data in the database. The JSP programs are connected to MySQL a JDBC driver provided by Oracle. In future posts I will discuss:

The Tomcat installation and configuration
The MySQL installation and configuration
basic.jsp and excel.jsp

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: Testing the Bootloader

In the previous posts I described the main application firmware and the bootloader firmware. In this post I will take you through the process of verifying that it all works. In order to do this I need to:

Test the bootloader (verify that I can bootload)
Test the main application firmware (the subject of the next post)
- Verify the pressure sensor
- Verify the temperature sensor
- Verify the I2C communication

Testing Bootloader

Cypress makes a cool programming tool called the MiniProg-3 which we also call CY8CKIT-002. The MP3 is a multi purpose tool that can be use to:

Program and debug Cypress PSoC chips
Bridge USB <-> I2C (which I will use to test the firmware)
Bridge USB <-> JTAG
Bridge USB <-> ISSP

First, I will program the bootloader firmware using PSoC Creator connected via USB to a MP3. In the photograph below you can see:

Mini Prog 3
The CYPI Bridge Board with the PSoC 4
The 10-pin ARM programming header (which is attached to the grey cable from the MP3)
The blue blinking LED. (after I programmed the board the LED started blinking. In this picture I caught it on)

At this point it appears that the bootloader is programmed into PSoC4 as the LED is blinking. In this case I only programmed the bootloader, so there is no application firmware to jump to, so the chip will just keep running the bootloader until the power goes off.

Next, I need to attach another MP3 acting in the role of a USB <–> I2C bridge. The MP3 will emulate the Raspberry Pi which will be used in the production system, but for now it is easier to test without the added complexity of the RPi. I am using one MP3 just as a power source for the CYPI board (I could have just plugged in a wall wart). You can see that I have two wires, one for SDA and one for SCL connected to the correct RPi/CYPI pin. The other side of the wires are sticking into the correct female connectors on the header of the MP3 (right next to each other at the bottom).

Then I start the bootloader host which is a program that can read CYACD files (which is just a format of a hex file) and send it out over I2C (or UART) using the bootloading protocol. First, I select the correct CYACD file from the directory where PSoC Creator put it. Then I click the download button.

A few seconds after the boot loading is finished, the blinking blue led turns off and a blinking red led starts. This indicates that the main application firmware is running. To verify that the bootloader still works I press the reset switch on the board and the blue led starts blinking for 10 seconds before jumping back into the application firmware. Good. The bootloader and application firmware work together correctly.

In the next post I will show you how to use the Bridge Control Panel to verify that the firmware is working correctly.

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: Testing the Firmware

In the previous post I discussed the process that I used to test the bootloader firmware. In this post I will walk you through testing the actual application firmware. As I started working on this post I decided to remind myself of the format of the EZI2C buffer. Here it is:

The first thing that I immediately noticed was that I did something really dumb. Specifically I named one of the fields “float pressure” when it is really “float inches”. Oh well. The DataPacket structure is composed of 4 variables, two of them are 2-byte unsigned integers and two of them are 4-byte float. As this PSoC is an ARM chip, all of the variables are stored in little endian format-meaning that the Most Significant Byte (MSB) is last.

To help test the firmware, I will use a program called the Bridge Control Panel (BCP). The BCP is delivered as part of the PSoC Creator installation and is available under the Start->All Programs->Cypress menu. The BCP can talk to a Miniprog 3 (or any of the Cypress programmers) via the USB port and then bridge to the I2C bus. It can then act as an I2C master- in my case it will be emulating the Raspberry Pi I2C Master.

After starting the BCP, I first configure the “chart->variable settings”. This allows me to setup names and sizes of the EZI2C registers that I want to read from the PSoC. You can see that I added one variable to correspond to each variable in the DataPacket structure. In the BCP, an “int” is the same as an ARM int16 aka a two byte integer. I also select “sign” to indicate that the tempCenti is int16 (not uint16).

After setting up the variables, I first make sure that the BCP is talking to the PSoC4 by pressing “list” button on the BCP. When I click that button, the BCP tries to read from all of the 127 valid I2C addresses. If it gets an “ACK”, then it reports that it can talk to that device. On the screen below you can see that it sees “address: 10 08” which is the I2C address of my PSoC4.

The next step is to tell the BCP how to read the EZI2C registers. First I write a 0 to address 8 with the “w 8 0;” command. This sets the “data pointer” t0 0, meaning the start of the register space. I then issue command to read 12 bytes, each byte has a name that corresponds to a byte in the “variables” configured in the previous step. An example is “@0presscount” which corresponds to the least significant byte of the presscount variable and “@1presscount” which corresponds to the most significant byte of the presscount variable.

After setting up the variables, I press “return” to issue the command. The BCP returns “r 08+ 00+ 00+ AC+ 08+ 8A+ E4+ D0+ C2+ 9A+ 99+ B1+ 41+”. What does that mean? The R means that it did a read. The 08+ is the address of the I2C and the + means and “ACK”. Each of the other bytes+ are the other 12 bytes read in the command. I use this website to covert the 4-byte hex float(s) to decimal and I get:

pressCount = 0x0000 : There is 0 volts attached to the input which is true
tempCenti = 0x08AC = 2200 (that makes sense 22.2 degrees c * 100 ~= 2200)
pressure = 0xC2D0E48A = -104.44636535644531 … that makes sense rememberdp.pressure = (((float)dp.pressureCounts)-408)/3.906311:
temp = 0x41b1999A = 22.200000762939453 c = 71.9f [ok that makes sense]

The next step is to attach a bench power supply to the pressure input (I bought this one from eBay). I will use the variable voltage to simulate different pressures. Recall from the schematic that the pressure sensor acts as a current source that is then driven into a 51.1 ohm resistor. Here is the schematic:

With this setup if I put in 0.51V on the “high side” I should get [V=IR] 0.51V = I * 51.1Ohm so I= 0.01 A. You can see from the picture that is what I get (or pretty damn close). When I press return on the bridge control panel (see it in the screen shot above) I get “r 08+ E4+ 03+ C0+ 08+ 91+ 86+ 16+ 43+ 33+ 33+ B3+ 41+” which means

pressCount = 0x03E4 = 996 counts. The range of the ADC is 4096 counts (in single ended mode) and 0 –> 2.048V so 996 counts is 0.498v
tempCenti = 0x08C0 = 2200 (that makes sense 22.2 degrees c * 100 ~= 2200)
pressure = 0x43168691 = 150.52565002441406 [that works… remember the equation]dp.pressure = (((float)dp.pressureCounts)-408)/3.906311
temp = 0x41B33333 = 22.399999618530273 c = 72.3f [ok that makes sense]

For the last test of the pressure sensor input I put the variable supply to 1.0V which makes 0.019 mA. Once again V=IR 1V/51.1Ohm = 0.0196 A. Ok Ohms law still works. Then I press return and I get “r 08+ 98+ 07+ C0+ 08+ DD+ 9A+ C4+ 43+ 33+ 33+ B3+ 41+ p”. When I decode that I get

pressCount = 0x0798 = 1944 counts. The range of the ADC is 4096 counts (in single ended mode) and 0 –> 2.048V so 1944 counts is 0.972v (that is pretty damn close)
tempCenti = 0x08C0 = 2240 (that makes sense 22.4 degrees c * 100 ~= 2240)
pressure = 0x43C49ADD = 393.2098693847656 [that works… remember the equation]dp.pressure = (((float)dp.pressureCounts)-408)/3.906311:
temp = 0x41B33333 = 22.399999618530273 c = 72.3f [ok that makes sense]

In the next test I will go into graphing mode and use the “repeat” button to run I2C reads as fast as possible. I will then sweep the voltage on the bench power supply and plot the pressure and the counts to make sure that makes sense. It looks good, here is the plot:

In the next test I use a Fluke Thermocouple to verify that the TMP036 is reading the correct temperature. You can see that when I put the thermocouple right on the sensor it reads 23.4 degrees C. I then turned the camera towards the screen and took a picture of the plot. In that plot you can see the temperature bouncing around 22.5. The bounce is +- 1 count (literally noise) of the ADC . I am not sure what the cause of the 0.9 degree difference between the Fluke and the TMP036, it could be several things including the accuracy of the TMP036, the accuracy of the Fluke, the accuracy of the PSoC4 ADC, where I am measuring, etc. But less than a degree really doesn’t matter to me.

In the last test I make a graph of the temperature while I am grabbing the TMP036 which causes the temperature to rise. After a bit of time I let go of the sensor and you can see the temperature fall.

At this point it looks like the bootloader is working and that the PSoC 4 firmware is working. In the next post I will talk about the overall server software architecture.

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: PSoC 4 Bootloader Schematic + Firmware

A bootloader is a firmware program that can update the application firmware in an embedded system without using a programmer (like the Miniprog-3). This is a convienient way to fix bugs, release features, etc. without having to be physically at the system. As a developer you can update your design, then create a “hex” file image, then release that image (through email, the internet, etc) to be installed on all of your remote devices. Once your new hex file arrives at the host computer, the bootloader has the job of flashing the new firmware into your system. You can read more detail about bootloading in the excellent Cypress application note AN86526 PSoC4 I2C Bootloader.

In general, bootloaders are triggered by some external event (like a chip reset, a trigger from a GPIO, or a command from the application firmware). The bootloader then listens for communication from a host computer. The host computer could be lots of different things including a cell phone, a central application processor, or an external computer plugged into your system. Once the bootloader starts:

If there is no communication it will generally timeout after a set time, then jump into the application firmware to put the system into normal application mode.
If there is communication, it will copy a new application from the host computer and then write it into the flash in the correct place. There is a special case called a “dual application” boot loader. This provides safety by keeping and old image still in flash in case there is a problem bootloading the new firmware.

Here is a picture of the architecture:

In the Cypress language the bootloadable is an application image that can be bootloaded by the bootloader.

When I am making firmware like this I generally put two projects in the same workspace. One project is the bootloader and the other project is the bootloadable. This is exactly what you will find in in the PSoC Creator workspace called CreekFirmware on github. The first project is called p4arduino-creek which is the main application firmware that I discussed in detail in the previous post.

This bootloader, called p4bootloader, is a simple I2C bootloader. After the chip resets it:

Starts blinking the blue led to indicate that it is in bootloader mode
Waits 10 seconds to hear I2C communication
If there is none then it jumps into the main application (called the bootloadable)
It there is then it starts the boot loading process

The schematic is simply:

An I2C Slave
A bootloader component
A blinking LED (a clock tied directly to an output pin)

When you configure the bootloader component you need to select which communication interface to use. In this case it is the “I2C”. Then you configure how long you want to wait before timing out and jumping into the main application. In this case 10000ms a.k.a. 10s

The last step is to start the bootloader component in the firmware.

That is it. In the next post I will discuss the steps I took to test the firmware.

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: PSoC 4 Creator Schematic + Firmware

In this post I will describe the PSoC Creator schematic and firmware that I built to run the PSoC4. You can find the project on github. After you open the project in PSoC Creator you will find two projects in the workspace explorer:

p4ardino-creek: This project starts running 10 seconds after the chip powers up. It uses PSoC Analog to Digital Convertor to read the pressure sensor and the temperature sensor. It then convert the data to a readable form and stores it into the EZI2C buffer to be read by the Raspberry PI.
p4bootloader: This project runs for 10 seconds when the chip is rebooted. If it detects the Raspberry Pi host trying to load new firmware it will “bootload”. If after 10 seconds it doesn’t hear anything, it will run the p4arduino-creek application. I will describe how the bootloader works in the next post.

p4ardunio-creek

The schematic for this project contains four sections

The Analog to Digital convertor and the “external” schematic of the pressure current loop. The elements in blue are external to the PSoC and are there just for documentation.
The Red and Blue LED pins and the clock that drives the Red LED to blink
The EZI2C which serves as the I2C Slave for the Raspberry Pi to read
The Bootloadable component which allows this project to be boot loaded.

The configuration of each of elements is show below.

The ADC is configured to run as slowly as possible (1000 SPS). I have also enabled the averaging which automatically averages 256 samples. This effectively makes a low pass filter to remove noise. This is possible because the pressure and temperature move very slowly as compared to the speed at which they are sampled. The SAR ADC in the PSoC is inherently differential, I tell the ADC that I want the negative channel to be connected to a stable VREF. This allows me to measure between 0V and 2*vref = 2.048 volts.

On the ADC channels TAB I enable two channels, both single ended, both with averaging turned on. Channel 0 is connected to the pressure sensor (on Arduino pin A0 = PSoC Pin P2[0]) and channel 1 is connected to the TMP036 (on Arduino pin A1 = PSoC Pin P2[1])

For this design I setup the PSoC4 to act as an EZI2C slave. EZI2C means that the chip follows the EEPROM protocol which many many I2C masters understand. The only thing that I configure in this case is to use the slave address of 0X08.

For this project to be compatible with a bootloader it needs the bootloadble component instantiated. In this case I use all of the default configurations. When I make changes to the firmware in the future I will up-rev the version numbers. These settings are here to prevent you from accidentally overwriting and newer rev of the firmware or putting in the wrong application type.

In order for the bootloadable to work I need to tell it where its “bootloader” image resides. Remember from above that I put both projects in the same workspace. So, what I need to do is browse through the directory hierarchy into the bootloader project and selects its ELF and HEX files. If you want to read more about PSoC4 Bootloading you can read AN86526 entitled “PSoC 4 I2C Bootloader”

One of the unique features of a PSoC is its ability to do hardware based design. In this design I want a slowly blinking LED to indicate that the system is running. For this task I have to configure the pin to let one of the internal clocks drive it. To make this work you need to selected the output mode as “Clock”.

And you need to selected the “Out clock” as external.

Now, I want to turn off the Blue LED. As the LED is active Low, to turn it off you write a 1 to the pin. I do this as part of the setup of the pin by setting the initial drive state to high.

The last step in the device configuration is to select the proper pins on the Design Wide Resources (DWR) pins tab. Not setting the pins correctly is one of the most frequent errors that users make with PSoC Creator.

The firmware for the project is simple. In the first section (lines 3-8) I define a packed structure to serve as the I2C buffer. The __attribute__((packed)) tells the compiler to put all of the members of the structure in contiguous bytes. In the structure I defined below, if I had not marked it is packed, it is likely that the compiler would have put two bytes of padding after the pressureCounts and two bytes after the centiTemp. It would have done this to work align those datatypes to make the memory access more efficient.

The next section (lines 17-23) I initialize the system and start the components.

The the main body of the program (lines 27-43) I ask the ADC if it is done reading the voltages, if not go on, if so then calculate the different values and store them in the I2C buffer. The “CyEnterCriticalSection” prevents an I2C interrupt from reading the buffer before the data is completely written to prevent a partial read of the data.

In the next post I will explain boot loading and the p4bootloader project.

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: CYPI, a Raspberry Pi to Arduino Bridge

In the summer of 2013, I decided that I needed to design a printed circuit board. I had worked on sections of chips but no PCBs. I didnt really know which tool to use, but after looking around a bit it seemed like Eagle was a good simple choice as it had wide adoption in the Maker community. At that point in time the Elkhorn Creek Measuring System was being run off a Raspberry PI and a PSoC5LP but Cypress had just released a new family of chips called the PSoC4200. I thought that it would be a cool idea to have a PSoC to Raspberry PI bridge board. So this is what I did.

On the bottom of the board I wanted female pins that matched the Raspberry PI, and on the top I wanted an Arduino pins. Bottom line, I decided to build a board that was very similar to the CY8CKIT-042 except for having Raspberry PI GPIOs on the bottom of the board.

My board has:

Power System: Both 3.3v and 5.0v for the PSoC as well as 5.0v@1.0A for the Raspberry PI.
Reset System: A RPi connection to the PSoC and Arduino XRES.
An I2C connection between the RPi and the PSoC including the pullup resistors
A 3-Color LED
Arduino pins that match the pinout of the CY8CKIT-042

The overall schematic

I used the same RGB 3 Color LED (CLV1A-FKB- CJ1M1F1BB7R4S3) as exists on the CY8CKIT-042.

I wanted to be able to reset PSoC and Arduino from the Raspberry Pi so I attached the RPi GPIO 1_11 to a pulldown transistor that is connected to the XRES of the Arduino and PSoC. I also attached a small pushbutton to enable a user reset.

I copied the Arduino pin out of the CY8CKIT-042. This would allow me to easily use all of the projects that I had already developed that that development kit.

This section of the schematic has the required power supply decoupling capacitors. It also has the ARM standard 10 Pin programming header which allows me to program the PSoC using a MiniProg-3.

I provided pull up resistors on the PSoC P4[0] and P4[1] to easily enable the PSoC to serve as an I2C Master for the Arduino shield.

The connection to get data between the RPi and the PSoC is I2C. The PSoC is setup as an I2C slave and the RPi is the master. The connection on the RPi uses the RPI1_3 and RPI1_4 GPIOs. On the PSoC it is connected to P3[0] and P3[1].

The power supply turned out to be by far the most difficult part of the project. In the first version of the board I chose a regulator that was to small to supply the Raspberry PI. When the RPi was plugged in, the regulator immediately went into thermal shutdown. In general this sucked as the PSoC Applications Manager warned me to pick a big enough regulator. Oh well. In the final version of the board I used a 7805 to supply the RPi, this regulator has a giant tab which allows you to sink heat into the ground plane of the board. On the board I also provide a 5.0V supply and a 3.3V supply for the PSoC using a 1117 regulator.

Here is a picture of the final layout

And here is a picture of the first version of the board.

On thing that you might notice on this board is that the vias are exposed. What I didnt know is that you need to tell Eagle to “tent” the vias so that they are covered with solder mask.

There is a lot going on in the layout and it is probably easiest to review the layout using eagle. You can get the design from github at https://github.com/iotexpert/cypi

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: Creek Board 1.0 – RCCA

At my company Cypress, “RCCA” is an abbreviation for “Root Cause Corrective Action”. It is a formal process for changing the way that you work to prevent an error from happening again.

Unfortunately the title of this post is “Creek Board 1.0 – RCCA”. What that means is that the first time I sent the Creek Board to be manufactured I made an error, in fact a really stupid error. Specifically, the error that I made was a fundamental failure of not having an LVS (Layout versus Schematic) clean design. If you google “blue wire pcb” the first search result you will find is “Printed Circuit Board Repair and Rework Guides”, I had no idea why blue wires were used to fix printed circuit boards so I called my friend Dave Van Ness. He is an old grey beard type of guy. He told me that the blue wire was traditionally an “official fix” to a circuit board. It was used because other colors were already assigned (Red to power, Black to ground) etc. I guess that I thumbed my nose at tradition by fixing my PCB with a red wire.

After laying out a printed circuit board, the last step is to surround the board with a ground plane on the top and bottom of the board. Then you press the “ratsnest” button on Eagle. Then Eagle does a “pour” which fills in the empty space of the board with a ground plane. It then will update the bottom of the screen with the message “Ratsnet: Nothing to do!” which means all of the schematic and layout connections are complete. Or, if there are connections that still need to be made, it will update the layout with yellow “air wires” and it will give you a message like “Ratsnest: 1 airwires.” If you send the board to be made with an airwire, that is exactly what you will get. I will tell you that air doesn’t conduct electricity very well and you will end up needing your soldering iron.

In this case I missed seeing the tiny little airwire. See if you can see it:

It is hard to see, eh? In the next picture I turned off the ground layer and zoomed in so you can see that I am missing a power connection between the top and the bottom of the board. I highlighted this issue by clicking on the “Show Objects” at the top of the toolbar, then clicking on yellow wire. When I do that, Eagle tells me what the net is that is unconnected and it highlights every object that is attached to that net.

So now what?

What I ended up doing is the normal Cypress thing. I created a “tapeout checklist”. The checklist contains a list of all of the things that I double check before I send a PCB to be manufactured. Here is my current (and short) checklist:

No remaining airwires
Vias tented (or not)
Silkscreen on all connections
Test points on key nets
No DRC errors

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: Creek Board 1.1

In the previous post I described the entire system architecture. In this post, I am going to describe the Arduino shield that I unfortunately call “Elkhorn Creek Water Level 1.1”. It is unfortunate because in version 1.0 I made a really stupid error which ruined the first run of printed circuit boards. You can read more about how I made the error and what I am doing in the future in the post Creek Board 1.0 RCCA.

To make this system work I need to be able to interface the PSoC4200 with two sensors:

The US381-000005-015PG pressure sensor
A TMP036 temperature sensor

Both of these sensors are subject to environmental noise so they both have capacitive or RC filters connected to them. I originally built a prototype of this board using a proto board. However, it was a PITA because the wires would come loose and the system would stop working.

So I decided to make a real PCB. To do the design, I used the Eagle 7.2 PCB editor as it seemed like it had the most support from the maker community. The schematic for the system is fairly simple. It has

Pressure Sensor
- X1: A Molex Microfit 3.0 Connector to attach the two wires from the pressure sensor
- R1: A 51.1 Ohm resistor to group to convert the 4-20mA –> 0.204mV to 1.022V
- C1/R2: A low pass filter
- TVS1: A ESD diode to clamp any ESD event to ground to prevent it from blowing up the PSoC4A or the Sensor
Temperature Sensor
- TMP36: A sensor that turns temperature into a voltage. The equation for temperature is T=0.5V+10mV/degreeC. For 25 degrees C the Voltage = 750mV
- C2 + C3: Two decoupling capacitors to filter power supply noise
Arduino Interface
- A standard Arduino interface set of pins + the additional Cypress CY8CKIT-042 pins. I only used the A0 and A1 pins for signals and the Vin pin (which is 12v) to drive the current loop
Measurement Test Points
- Keystone 5000 test points. These test points are a little loop of wire that sticks up from the surface of the PCB to make it easy to probe a voltage with your DMM.

Here is the final Eagle Schematic for the board.

And the layout:

Once I completed the layout I sent the board to OSH Park to be manufactured. I have shared the project on their website. OSH Park is an excellent company that is easy to do business with. They charged me $22.55 for three of the boards. The fit and finish of the boards is very nice. Here is the board:

Here is the assembled board:

I have posted all of the project files at github. You can “git” them from https://github.com/iotexpert/TheCreek The Eagle project is in the CreekBoard directory.

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: Solution Architecture 1.0

In the previous post I introduced my IOT Project for the Elkhorn Creek. In this post I provide an overview of each of the building blocks in the system. Currently (because I have some ideas for improvements) there are four major blocks. Over the next few weeks I will write one or more detailed posts for each of the blocks.

1. Pressure Sensor

The Pressure Sensor is a Measurement Specialties US381-000005-015PG installed into the end of a long PVC pipe. Inside of the pipe there is a ~150 foot long telephone wire which is attached to the Creek Board.

All of the PVC came from Lowe’s and is glued together with PVC cement. At the end of the pipe you can see a ball valve. This valve will allow me to drain out any water that leaks or condenses into the system. This can absolutely happen and in fact killed an earlier revision of the system. The sensor itself is screwed into a 4″ clean-out cap. This will allow me to unscrew the cap and replace the sensor if it is ruined by something. Also, the cap is fairly thick and allowed for more threads on the sensor to grab into the PVC, which also improves my chances of not needing to replace this $142 sensor.

2. The “Creek Board”

The Creek Board is an Arduino Shield that I designed to replace my prototype bread-board. The shield contains:

The 51.1 Ohm Resistor which turns the current loop into a measurable voltage
A TMP36 Temperature Sensor which I was originally planning to use for temperature compensation.
Testpoint’s to measure the voltages with a DMM
Analog low-pass noise filters for the current loop
A Transient Voltage Supressor Diode to protect the CYPI board from an ESD event.

3. CYPI

I designed CYPI to be a “Cypress” to “Raspberry Pi” bridge. On the bottom of the board is a connector that is compatible with the Raspberry Pi GPIOs. On the top of the board are connectors that are compatible with Arduino. On the board is:

A Cypress PSoC4200 – CY8C4245AXI-483
A wall wart barrel power connection
Voltage regulators that allow the entire system to run off of one wall wart
A 10-pin ARM Program/Debug header
A reset switch
A user LED

4. Raspberry PI

The Raspberry PI is a single board linux computer.

This RPi serves the following tasks

An I2C Master to read temperature and pressure data from the PSoC4. This task is performed by a Java program that is triggered once per minute by the Linux crontab
A MySQL database server to hold the historical data
A Java program that uses a JDBC connection and JFreeChart to once per minute create a PNG chart of the last 8 hours of data.
Tomcat with a Java Server Page (JSP) which dynamically creates the website http://www.elkhorn-creek.org

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

The Creek: IOT for the Elkhorn Creek

In January of 2011, Dr. TJ Rodgers, the CEO of Cypress decided that I needed a career change, specifically running the software development team at Cypress. This was a great opportunity to get back into new product development, as I had spent the previous 8 years at Cypress running the IT group. Cypress is a very technical company, and even as a Vice President of Software Engineering running a big group, I was still expected to have in-depth technical knowledge of my area. I needed to learn PSoC Creator and our product PSoC. So, I needed a real project.

First, the backstory. I live on the Elkhorn Creek in Central Kentucky. Here is a picture of me canoeing with my kids:

Unfortunately, some days I live IN the Elkhorn Creek.

When things start getting crazy I always wanted something a little better than this to measure the water depth.

I decided that this would be a perfect PSoC project for me to learn the software and the chip.

I remembered from physics that fresh water is 0.43 psi/ft …well actually, I googled. In order to measure the depth of the creek I needed a pressure sensor. After looking around on Digikey I found that Measurement Specialties makes a really cool sensor, the U5300, that fit my needs perfectly. Here is a picture:

This is a 1/4″ NPT 15 PSI vented gauge pressure transducer that is “current loop” or “4-20ma current loop” or “analog, current”. There are several important pieces of information in its name.

1/4″ NPT means that the threaded end of the pressure sensor, that divides the “wet” and “dry” side is threaded as 1/4″ National Pipe Thread. NPT means that the threads are tapered in and will create a waterproof seal. Unfortunately it also means you can’t go down to your local Lowe’s to get a tap to make the threads in the end of the PVC. In order to do that you need an NPT tap, which I found on Amazon. When you screw in the sensor you also need to use pipe dope, NOT teflon tape. The pipe dope will push into the crevices of the threads under pressure to increase the water tightness of the seal. If you use tape it will break the threads and leak. For some reason they didn’t mention any of this when I was EE school.
Vented Gauge. This means that the sensor reads differential pressure. On the “wet” side and on the “dry” side. In my application one side, the “wet” side is at the end of a piece of PVC in the bottom of the creek. The “dry” side of the sensor is inside of the PVC which will go all the way to my barn and is exposed to the atmosphere. By having the sensor read on both sides, it will cancel out the atmospheric pressure. This is good, because the pressure where I am in KY can vary by as much as 2 inches of Hg a.k.a. 0.98PSI or 2.28 Ft. You can read about the other types of pressure sensors in the Wikipedia article.
15 PSI is the maximum pressure that the sensor can read. This will allow me to read from 0 ft of water up to 15 PSI / 0.43 PSI/ft = 34.8ft. If there is 35 ft of water, I will need to call Noah, as the entire first floor of my house will be underwater.
“4-20ma current loop”. This means that the sensor converts (aka transduces) pressure into current. The current loop sensor is a genius idea created at Bell Labs to communicate over long distances between telephone switching stations. Because it uses current, it is mostly insensitive to the length of the cable. 4-20ma means that when the sensor reads 0 PSI the output is 4ma and when the sensor read 15PSI the output is 20ma. If you route the loop through a 51.1ohm resistor, Ohm’s law tells you that you will get a value between 0.2044 volts and 1.022volts. This voltage is perfect to be read by the Analog to Digital convertor in the PSoC.

Here is a picture of the sensor sticking through the end of the PVC:

To make this system work I first needed to create a long ditch from the barn in my backyard all the way to the Elkhorn Creek. A big ditch: sounds like a job for a big dig witch, so I headed down to the ByPass Rentall. I asked if they would rent me a Ditch Witch, they said “Do you want the big one?”. This question only has one answer: “Hell Yes”.

This bad boy made short work of installing a PVC pipe from my barn to the ditch.

In the next posts I will:

Show the whole system architecture
Show the Printed Circuit Board
Talk about the PSoC firmware
Show how the Raspberry Pi and Java work

You can see the system working at http://www.elkhorn-creek.org

Alan

Index	Description
The Creek: IOT for the Elkhorn Creek	Introduction
The Creek: Solution Architecture 1.0	Overall architecture
The Creek: Creek Board 1.1	Eagle layout of the board
The Creek: Creek Board 1.0 – RCCA	A discussion of the errors in the 1.0 board
The Creek: CYPI, a Raspberry Pi to Arduino Bridge	PSoC4 <--> Raspberry Pi Bridge Board
The Creek: PSoC4 Creator Schematic and Firmware	Firmware to interface with the temperature and pressure sensors
The Creek: Testing the Firmware	Using tools to verify that the PSoC 4 Firmware is working correctly
The Creek: Testing the Bootloader	Make sure that you can load new firmware into the PSoC
The Creek: Software Architecture	All of the Raspberry Pi software connections
The Creek: Install MySql	Instruction to configure MySql
The Creek: Install Tomcat	Instruction to configure Tomcat JSP Server
The Creek: Data Collection Java (Part 1)	The Java program that reads the I2C and saves it in the database
The Creek: Data Collection Java (Part 2)	The Java program that reads the I2C and saves it in the database
The Creek: Create the Chart with JFreeChart	Using open source Java charting software to create plots of the Creek Depth
The Creek: Flood Event Data Processor	A batch program to create analyze the database and create a table of flood events
The Creek: Flood Event Web Page	A batch program to create the flood event web page
The Creek: Creek Server 1.1	Updates to all of the back off server programs to integrate charts
The Creek: JSP Web Page for www.elkhorn-creek.org	The JSP program to make the table and display the website
The Creek: Raspberry Pi Clock Stretching	Sorting out a bug in the system having to do with the Broadcomm Raspberry Pi Master not functioning well with clock stretching
The Creek: Creek Server 1.2	Caching the web pages to make them faster

Physics Lab: The Rotary Encoder

When I started thinking about the G-Force machine I knew that I wanted to be able teach Newtons Laws using data collected from the machine. That meant that I needed position, velocity and acceleration. Since we all went to Physics class, we remember that you can calculate velocity from the change in position, and you can calculate acceleration from the change in velocity.

Given all of that, I decided to start with an E6A2-CW3C rotary quadrature encoder which I bought from Sparkfun. This device sends out two trains of pulses based on the direction and speed of the rotor. There is/will be a wheel attached to the rotor of this device that will run along the track. As the car moves, it will turn the rotor and send out the train of pulses which can then be connected the PSoC TCPWM which is a block inside of the PSoC. These pulses are encoded with a scheme known as “quadrature encoding”.

The next picture is a snapshot from the Cypress Quadrature Decoder Component Datasheet which explains quadrature.

The E6A2-CW3C quadrature decoder generates 200 pulses per rotation. Assuming that the diameter of the wheel that I attach to the device is 10″, I will be able to measure a change of 10″/200 pulses = 0.05 inch. More than enough. In fact the PSoC Quadrature component is capable of counting rising and falling edges which yields a multiplier up to 4x or 0.0126″ (which is beyond ridiculous). The one issue that is important with the design is that I would like the total number of pulses that the system generates as it moves down the track to be able to fit into a 16-bit number. Given that the track is 120′ long, that means with a 10″ wheel I will get 120 feet*12 inches/foot / 10inches/turn = 144 turns * 200 pulses/turn = 28,800 pulses for the entire length of the track. This is good as it is well less than 2^16=65536 which is the largest number that can fit into a 16-bit number.

In the next post Ill talk more about the Accelerometer(s).

Index	Description
Physics Lab: An Introduction to G-Force	Introduction
Physics Lab: The Rotary Encoder	Measuring position

Physics Lab

Physics Lab: An Introduction to G-Force

My friend Bill Cloyd runs a non-profit company in Lexington, Kentucky called Newtons Attic. The company focuses on Engineering and Physics education for kids. Billy runs day camps, week camps and after school camps for primary school kids. In these camps/classes the kids build robots, catapults, cross-bows, Rube Goldberg machines, fly drones etc. uising the tools in the machine shop at the Newtons Attic Campus. This is the perfect place for budding engineers and scientists. In addition to this he does road shows with his crazy machines.

One of the machines (called G-Force) is 120′ long track with a spring activated car. One end of the track curves up to the sky. This is an excellent platform for teaching kids about Newtons Laws. Here are a couple of pictures:

When high-school physics classes visit Newtons Attic they take “data” using stop watches etc and then try to match their observations to the predictions that result from Newtons Law. I always felt that this process would greatly benefit from some automation. I have launched into a project to build an electronic system that can attach to the car and collect and transmit the kinematic data from the car. For those of you who have forgotten kinematic data is position, velocity and acceleration.

To do this I am building a system around the new Cypress PSoC4-BLE chip. The system will have the following “sensors”

1. A Linear Encoder attached to a wheel running along the track

2. A 3-Axis Accelerometer

3. A 3-Axis Gyro

4. A 3-Axir Magnetometer

5. A Spansion (now Cypress) SPI Flash to record the data

6. An Air Pressure Sensor and a Relative Humidity Sensor (which I will use to calculate the Air Density)

The PSoC4-BLE will collect the data from these sensor and broadcast the data to any BLE Enabled device (iPhone, Android Phone).

The last part of the system will be a Swift App (running on iPhone) and a Java App (running on Android) to collect and display the data.

In the next bunch of posts you will be able to follow me through the Schematic Design, Board Design, Firmware Development, Board Manufacturing and App development process.

Alan

Index	Description
Physics Lab: An Introduction to G-Force	Introduction
Physics Lab: The Rotary Encoder	Measuring position

BLE Physics Lab

Category: Solutions

The Creek: Collect Data (Part 1)

The Creek: Install MySQL

The Creek: Install the Raspberry PI Software

The Creek: Server Software Architecture

Backend Server

Java Server Pages (JSP) GUI

The Creek: Testing the Bootloader

Testing Bootloader

The Creek: Testing the Firmware

The Creek: PSoC 4 Bootloader Schematic + Firmware

The Creek: PSoC 4 Creator Schematic + Firmware

p4ardunio-creek

The Creek: CYPI, a Raspberry Pi to Arduino Bridge

The Creek: Creek Board 1.0 – RCCA

The Creek: Creek Board 1.1

The Creek: Solution Architecture 1.0

1. Pressure Sensor

2. The “Creek Board”

3. CYPI

4. Raspberry PI

The Creek: IOT for the Elkhorn Creek

Physics Lab: The Rotary Encoder

Physics Lab: An Introduction to G-Force

Meta

© IoT Expert

Category: Solutions

Backend Server

Java Server Pages (JSP) GUI

Testing Bootloader

p4ardunio-creek

1. Pressure Sensor

2. The “Creek Board”

3. CYPI

4. Raspberry PI

Meta

Tags

© IoT Expert