PSoC4000s & The SmartIO – Part 2

In the previous posts I introduced you to the Smart IO.  I also went through the instructions to create CapSense Buttons using the new Mutual-cap CSX mode of the PSoC4000S.  In this post I am going to use the three CapSense buttons on the CY8CKIT-145 as inputs to the Smart IO.  I want to create a simple logic function P25 = !XOR(P24,P26,P27).  This will cause the LED that is attached P25 to light up when there is an odd number of 1’s on P24,P26,P27.  The equation is slightly strange because the LED is wired as active low (it lights up when there is a 0 written to it)

To make this work I soldered an 8 pin female header to Port 2 of my development kit.  I then wired:

  • P20 <–> P24
  • P21 <–> P26
  • P22 <–> P27

You can see all of that in the picture below.

IMG_2744

The next step is to create the schematic for this design.  I started from the Mutual Capacitance project that I talked about in the previous post.  It has three LEDs and the Capsense Buttons.  I then add

  • Three digital output pins (P20,P21,P22) to drive the three inputs to the SmartIO
  • Three digital input pins (P24,P26, P27) to use as inputs to the SmartIO
  • One digital output pin (P25) to drive the LED
  • The Smart IO block

3xorschematic

The next step is to configure the SmartIO.  I setup P24,P26,P27 as “inputs” and setup P25 as an “output”

smartio-config

Then I configure the LUT to match the logic equation: P25 = !XOR(P24,P26,P27)

LUT5

Lastly I assign the pins to the correct physical pins on the chip.

dwr

Then I create the firmware by copying the main.c from the earlier CapSense example.  I then add the small amount of code to glue it all together:

  • Line 7: start the SmartIO
  • Lines 27-29: Write to P20,P21,P22 based on the state of the input buttons.

3xormainc

You can find this PSoC Creator workspace on github in the directory called “SmartIO”.  This project is called “3Xor”.

In the next post I will show you how to make a state machine using the Smart IO.

Index Description
PSoC4000s & The SmartIO – Part 1 An introduction to the SmartIO and first project
PSoC4000s & CSX Mutual CapSense Buttons Part 1 Using mutual capacitance
PSoC4000s & CSX Mutual CapSense Buttons Part 2 Using the CapSense tuner
PSoC4000s & The SmartIO – Part 2 A 3 input XOR logic gate
PSoC4000s & The SmartIO – Part 3 A 3 bit up counter state machine
PSoC4000s & The SmartIO – Part 4 Using an external clock with the Smart IO
PSoC4000s & The SmartIO – Part 5 Triggering an interrupt

PSoC4000s & CSX Mutual CapSense Buttons Part 2

In the previous post I gave you the instructions to get the new Mutual Capacitance buttons going on the CY8CKIT-142.  In this post I will talk about how to add the Capsense Tuner to your project.  The Capsense tuner can talk to your design while it is running, then report back to you the parametric of your design.

First you need to add the tuner to your project.  In order to do this, start with the last design, then add an EzI2C component.  Here is the new schematic:

Tuner-Schematic

Then you configure the EZ2IC to have 16 bit sub addresses.

Tuner-EzConfig

Then assign the EZI2C pins to the KitProg I2C bridge pins

Tuner-DWR

The last step is to write the firmware which is almost exactly what you had in the last project except

  • Lines 8-9 which start the capsense block and setup the Capsense memory buffer to be readable by the remote host
  • Line 21: which updates the Capsense memory buffer with the current state of the capsense parameters

tuner-firmware

Once all of this is done, build and program the device.  Then start the capsense tuner by right clicking the Capsense component in the schematic and saying “run Tuner”

launch-tuner

Then configure the tuner communication parameters from the “Tools->Tuner communication setup” menu.  These should match what you have setup in the EZI2C component.  Specifically you need set the I2C addresses to be the same, and you need to have the sub-address set to “2-bytes” which is the same as the 16-bit sub-address which you set in the component above.

tuner-comm-setup

The next step is to press “connect”  and the “start”.  First make sure that your three buttons are working.  In the picture below you can see that I am touching Buttons 1 and 2 as they are “active” (red color) which means that their signal is above the threshold.

2-buttons

The next step is to look at a “graph view” of button 0.  You can do this by pressing “graph view” and selecting Button0_Rx0.  Once I switch to this view I touch the button 9 times.  You can see that as there are 9 button touches in the Status window.  A status of 1 means that the button is active and a status of 0 is an inactive.

In the sensor data window you can see the “baseline” which is the noise on the sensor node without a touch.  The blue line is the “RawCounts” which the amount of signal on the node.

In the middle window you can see the “Sensor Signal” which is the Sensor Data minus the baseline.  Any time the Sensor Signal is above the touch threshold then the sensor status is active.

Tuner-graph

The last step is to use the SNR measurement tab to see how robust your design is.  First click on the “SNR Measurement” tab.  Then pick out which sensor you will measure.  In this case I have setup measurement on “Button_0”.  Then click on “Acquire noise” and wait.  It will make the graph shown below which says that my noise is about 3008-2995 or about 13 counts.

BaselineNoise

The next step is to see how much signal you get.  Start this process by pressing “Acquire Signal” and touching the correct button.  You can see orange line represents the amount of signal when you are touching the sensor.  The system will then calculate the SNR which in this case is 56.85 which is tons.

SNR

The last thing that you could do is change the Capsense parameters in the sensor parameter screen.  For instance you could change the threshold from 100 to a bigger number to give more reliable touches.

Parameters

OK.  Now I have my capsense buttons working.  In the next posts Ill be ready to talk more about the Smart IO.

You can find this PSoC Creator workspace on github in the directory called “145MutualCap”.  This project is called “TunerMutualCapButtons-145”.

PSoC4000s & CSX Mutual CapSense Buttons Part 1

In the previous post I talked about my original goal to learn about the SmartIO.  But, in order fully try out the SmartIO I needed an input source.  On this board I had only one easy input from the factory – specifically the mechanical button on P0[7]- but I wanted to have multiple switches.  Well, the obvious choice was to use the three Capsense Buttons on the user interface expansion board.   When I looked at that board closely I remembered that the buttons were put there to support the new Capsense functionality of the PSoC4000s family.  Inside of Cypress we call the new feature “CSX”, but its real name is “Mutual Capacitance”.  Mutual Capsense works by transmitting a signal on the “Tx” pin and then receiving that signal by capacitively coupling that signal through your finger into the “Rx” line.  Here is a picture of that part of the PCB schematic and a zoom in of the board.  You can see that there are three different size buttons.  Each of the buttons is composed of an even number of pie shaped segments.

mutual-cap-buttonsScreen Shot 2016-03-06 at 2.03.17 PM

The mutual capacitance technique has a much higher Signal-to-Noise Ratio (SnR) as compared to the Self Capacitance technique of previous chips and as a result is more immune to noise and can work through a thicker overlay.  I thought that I would try putting on overlay on my board, so I cut out a piece of 1.5mm acrylic and used double sided tape to attach it to my board.  You can see it in the photograph above.

To make this work I started by creating a new project called “MutualCapButtons”.  I then added the Capsense component and three digital output pins (one for each of the three LEDs on the expansion board).  Here is the schematic:

mutual-button-schematic

The next step was to configure the CapSense block by double clicking it.  I then added three buttons and set the sensing mode to CSX (Mutual-cap).

mtutual-cap-config

It is possible to have dedicated Tx/Rx pins or you can share the Txs.  To do this, select “Advanced” and “Widget details”.  Then select “Button1_Tx”  and choose its sensor to be the same as “Button0_Tx”.  On this design I shared the Tx between all three of the buttons.

Mutual-sharing

The next step is to assign the pins to the correct Port/Pin locations on the chip:

button-pin-assignments

The last step is to write the firmware

  • Lines 8-10 Start the capsense block and get the scanning going
  • Line 14: If the capsense block is done scanning then process the results
  • Line 16: Take all of the raw data from the scan and setup all of the status information
  • Lines 18-20: If the buttons are being pushed then turn on the corresponding LED
  • Lines 22-23 Start another scan

Mutual-firmware

That is all there is to making it work.

You can find this PSoC Creator workspace on github in the directory called “145MutualCap”.  This project is called “MutualCapButtons-145”.

In the next post Ill talk in detail about using the Capsense Tuner to understand the Capsense performance.

PSoC4000s & The SmartIO – Part 1

In the previous four posts I talked about building an IOT device using the new CY8CKIT145.  You might remember from the first post that my original objective in picking up the board was to try a new feature of PSoC Creator.  Well, over the last few days I have been trying out that feature. Actually, it isn’t a feature of the software, it is a feature of some of the new chips called the Smart IO.  The Smart IO is a programmable logic bock that sits between the High Speed IO Matrix (HSIOM) of the chip and the Input/Output Port.  The HSIOM has all of the peripherals (SCB, TCPWM etc) of the chips attached to it.  The Smart IO will allow you to take signals from inside or outside of the chip, perform logic functions on them, and then drive those signals into or out of the chip.  Some of examples of why you might want to do this include:

  • Combining several inputs (from the outside) to trigger an interrupt
  • Inverting a signal entering the chip
  • Inverting a signal exiting the chip
  • Remapping an input from one pin to a different input (e.g. flipping Tx, Rx pins)
  • Buffering one signal into multiple output pins (to increase the drive strength)

As usual with Cypress programmable logic, you can do a jaw dropping number of clever things.  This block includes sequential logic as well as combinational logic, so it is possible to make state machines in the fabric.  It also includes more surprises which have not been shown yet.

The Smart IO works the same as other peripheral blocks, you start by dragging the component onto the schematic and double clicking to start the customizer.

When you start the customizer you get the screen below.  The first thing to decide is which Port is going to use the Smart IO.  The Smart IO completely takes over an entire port.  On this chip there are two Smart IOs, one on Port 2 and one on Port 3.   When you look at the customizer there are some things to notice:

  • On the right side of the customizer you can see the 8 GPIO pins.  The dropdown menus that are currently labeled “Bypass” allow you to select the mode of the pin (Bypass, Input, Output, None).
  • On the bottom of the customizer you can see the 8 LUTs and select their inputs.
  • On the left side of the customizer you can see the the 8 connections to/from the HSIOM.  The drop down menu that is currently labeled “Bypass” allows you to select the mode of that connection to the HSIOM (Bypass, Input, Output, None).   I will talk about the “Undefined” menu in the with the next picture
  • In the middle of the customizer is the routing matrix.  Horizontally on the routing matrix there are 8 groups of three wires.  The top wire in each group is a wire that originates with the GPIO.  The middle wire originates from the corresponding LUT.  The bottom wire originates from the HSIOM.  For example the top three wires in the picture are
    • Line 1: from GPIO7
    • Line 2: from LUT 7
    • Line 3: from Data7
  • You can “make” the connection by either by clicking the solder dot or by choosing from the coresponding drop down menu (more on that below)

basicsmartio

The other menu on the HSIOM side of the customizer says “Undefined”.  This menu has a list of each fixed function device and the inputs/outputs of that device that can be connected to that input/output.  This menu doesn’t actually change anything in your design, it is only for information.  For example you can see in the screen shot below that  data4 can connect to:

  • TCPWM0: Line_Out
  • LCD0: COM[20]
  • LCD0: SEG[20]
  • SCB1: Spi Select[1]

smartio-dataselect

The best way to show you how all this works is with an example.  One of the frustrating things for me in the PSoC 4 Family has always been that the fixed function blocks (TCPWM, SCB) are only allowed to connect to a few pins on the chip.  This can be a bit of a pain if you have a board that is already wired and you need to remap a pin.  Take for example, on the Cy8CKIT-145 the user LED on the main board is connected to P2[5].  If I want to drive that LED with the Line out (instead of the Line_Out_N) I would create a schematic like this:

BlueLEDSchematic

When I go to the DWR to assign the pins I would see that the BlueLED cannot be attached to P2[5].  You can see all of the legal placements of that pin because they are highlighted in green.

blueledpinassignment

If I try to do it anyway, I will get the following error when I build.

pwm_error

This error says that I cannot connect the “line” output of the TCPWM to P2[5] (the pin with the LED).  That sucks.  But, with the Smart IO, I can “remap” the TCPWM Line output to P2[5].  To do this, I will start with a by adding a SmartIO to my schematic and configuring it.

  1. Select Port 2
  2. Configure GPIO 5 to “Output”.  This can be done by either clicking on the “solder dot” or by selecting output from the drop down menu
  3. Select data 4 as “Input”
  4. Select data 4 as “TCPWM[0].line.  Remember that this is ONLY for your information and doesn’t actually change anything in the project.
  5. Select the 3 inputs to LUT5 to be the data4 line which can be done from the three drop down menus or by clicking the three corresponding solder dots.

Screen Shot 2016-03-06 at 9.53.10 AMNext, I configure the LUT to “passthrough” by setting up 000 = 0 and 111=1 (which are the only two possible combinations as the three inputs are tied together).  You change the “Out”s from 0->1 and 1->0 by clicking on it.

LUT5

Then I will re-wire up the schematic to look like this:

blue-led-schematic-smartio

The firmware is trivial,  just start the PWM and the SmartIO

blue-led-firmware

When I program the kit the blue LED starts blinking.  Cool.

In the next posts I will teach you how to use some other configurations of the Smart IO and how to use the CapSense block to create inputs for the Smart IO.

You can find this PSoC Creator workspace on github in the directory called “SmartIO”.  This project is called “SimpleSmartIO”.

Index Description
PSoC4000s & The SmartIO – Part 1 An introduction to the SmartIO and first project
PSoC4000s & CSX Mutual CapSense Buttons Part 1 Using mutual capacitance
PSoC4000s & CSX Mutual CapSense Buttons Part 2 Using the CapSense tuner
PSoC4000s & The SmartIO – Part 2 A 3 input XOR logic gate
PSoC4000s & The SmartIO – Part 3 A 3 bit up counter state machine
PSoC4000s & The SmartIO – Part 4 Using an external clock with the Smart IO
PSoC4000s & The SmartIO – Part 5 Triggering an interrupt

PSoC4000s and the CY8CKIT145 Stamp Board – Part 4

OK.  We’re ready for the big moment: the user test.  I was feeling pretty cool.  I had spent the week talking to 100s of people and putting on a pretty good show.  I was the master of all things PSoC, a geek rockstar.  So I programmed the firmware.  The slider worked.  I was able to connect to the PRoC BLE from my app.  But for some stupid reason the the PSoC and PRoC just were not talking and I had no idea why.  And to make matters worse, I didn’t have anything I could (easily) use to debug the problem.   So much for being the king of PSoC.  I assumed that I had firmware bugs. I tried a bunch of different things, single stepping code, trying different pins, etc.  But nothing worked.  I couldn’t figure it out.  It was intensely frustrating to be stuck on the airplane with a broken design.

As soon as I landed in Detroit, I logged in to get my email.  I looked for messages from Rajesh (the PSoC Kit Manager) and sure enough, he had emailed me the missing schematic.  After digging through the schematic, I found the error.

schematic-resistors

The connection between the PRoC and PSoC had a 0 Ohm resistor that was “No Load,” meaning the footprint was there, but the board manufacturer had not put on the resistor.  This was done so that the pin could be used as a GPIO for something else.

Here is a zoomed-in picture of the PCB:

missing-resistors

The good news was, I was only one plane ride and an hour drive from my soldering iron.  As soon as I walked in the door, I went straight to my lab.

fixed-resistors

Now everything works.

There are two morals to this story:

  1. Don’t go to immediately to your lab after being gone for a week, as it really irritates your wife.
  2. Look closely at the schematic.

You can find the PSoC Creator workspace on github in the directory called “capsenseble-145.”

PSoC4000s and the CY8CKIT145 Stamp Board – Part 3

In this post, I will take you through the PRoC BLE schematic and firmware.  I describe a very similar version to this in great detail in the video you can find on the Cypress Video Training website.

First, I create a new project in my workspace called “145capsenseled-ble.”  Then, I add the UART component (the SCB version) and the BLE component.

schematic

Next, I configure the component to be a GATT server with a custom profile and a GAP client.

overall-profile

Then I create a custom service with two characteristics:

  • The “led” characteristic, which is set up as a uint8 that is writeable and readable.
  • The “capsense” characteristic, which is set up as uint16 that is readable and has a “notify.”

Next, I configure the UUIDs of the service and characteristics to match what is hard-coded in the iOS app.  Then, I add “Client User Descriptions” that describe the characteristics in plain text.

gatt-settings

Next I configure the GAP settings, specifically the advertising packet.

advertising-packet

I make the pin I assignments, which is just the UART Rx and Tx lines.

dwr-pin-assignment

Finally, I write the firmware.  I started with main.  In the infinite loop (line 116), if I have received a byte from other side, then I assign it to the global variable “fingerPos” (line 118). Next, call updateCapsense() (line 119), to update the GATT database with the new value of the slider.

main

The updateCapsense function:

Lines 31/32 If there is no connection, then don’t update the GATT database.

Lines 33-39 Update the GATT database with the current fingerPosition.

Lines 42-43 If the iPhone side has asked for notification and the position has changed, then send a notification.

Line 44 Save the last position.

update-capsense

The BleCallBack is the most complicated section of firmware.  It uses a “switch” statement to handle the different event “cases.” The cases are:

  • CYBLE_EVT_STACK_ON & CYBLE_EVT_GAP_DEVICE_DISCONNECTED:  In either of these cases you want to start the advertising function.
  • CYBLE_EVT_GATT_CONNECT_IND: When there is a connection made, update the GATT database with the current state of the CapSense and the LED.  This allows the iOS side to read the correct values.
  • CYBLE_EVT_WRITE_REQ: There are two kinds of write requests that are valid.
    • CYBLE_LED_CAPSENSE_LED_CHAR_HANDLE:  If the remote side writes into the LED value, then send that data to the PSoC4000S via the UART.
    • CYBLE_LEDCAPSENSE_CAPSENSE_CAPSENSECCCD: If the remote side has been asked to notify (or un-notify), then save that in the global variable capsenseNotify.

ble-callback

That is all of the firmware.

In the next post, I’ll take you through the debugging I had to do.

You can find the PSoC Creator workspace on github in the directory called “capsenseble-145.”

PSoC4000s and the CY8CKIT145 Stamp Board – Part 2

In the previous post, I unboxed the CY8CKIT145 and showed you the schematics.   In this post, I will show you how to build the CapSense firmware that runs on the PSoC4000S.  The first decision I needed to make was how to connect the PSoC and the PRoC chips.  So I looked at the back of the kit and there was a handy-dandy picture of the schematic in the silkscreen.  Here is a zoomed in view:

zoom-145

I didn’t have the schematic on the airplane, but here is a more “schematic” view of the chips on the board.

systemschematic-c

 

 

I knew that the UART source code would be slightly easier, so I picked that as the mechanism to connect the chips.  On my computer I had the “capsenseled” workspace from the videos.  So, I created a new PSoC4000S project in that workspace called “145capsenseled.”  I started with the schematic:

  1. Add the new CapSense component.  I am currently running a “nightly build” of PSoC Creator 3.3 that supports the new chip.  You can see in the PSoC Creator release I’m using there is a prototype version of the CapSense component.
  2. Add 5 Digital Output Pins under software control to drive the LEDs that are next to the slider
  3. Add 1 Digital Output pin to drive the blue LED
  4. Add a Serial Communication Block (SCB) configured as a UART

capsenseled-schematic

Here is a screenshot of the new CapSense component configuration wizard.  You can see I added a linear slider and set up the component to use SmartSense full-auto tuning.

capsense-configuration

After configuring the CapSense, I set up the pin assignments using the DWR:

capsenseled-pinassignment

Then I wrote the firmware, which was pretty straight forward.

  • 10-11 start the CapSense
  • 12 start the UART
  • 16: If the CapSense block is done scanning and is idle, then read the CapSense and do something with it (lines 17 -> 41).
  • 18: figure out where the person is touching
  • 19: if they have actually touched the block
  • 22-26 light up the LEDs
  • 30-35 If there is no touch, then turn off the LEDs.
  • 36-37 start the next scan
  • 38-39: If the UART is not busy… then send the position (0-100) or (0xFF if there is no touch).
  • 41-42: If there is a byte in the UART receive buffer, then light up or turn off the Blue LED. (Notice that the LED is active low so I use the “!” operation to flip the state of the signal.

capsense-firmware

After that, I programmed the kit and tested it.  It seemed like everything was good.  In the next post, I’ll show you the schematic and firmware that runs on the PRoC BLE.

You can find the PSoC Creator workspace on github in the directory called “capsenseble-145.”

PSoC4000s and the CY8CKIT145 Stamp Board – Part 1

One of the cool things about my job is I get to try out lots of new development kits before they are released to the general public.  In the previous post I talked about the demonstration I gave at the Embedded World conference using the CY8CKIT-042 BLE.  You can find a complete video tutorial for that project on the cypress.com video tutorial website.  While I was at the conference, I picked up an engineering sample of a new development kit and put it into my backpack because I wanted to try a new feature of PSoC Creator on the way home.  But, when I got on the airplane, I thought I would build the same project I had demonstrated at the conference using this kit.  So, in the next few posts, I am going to show you the new CY8CKIT145 Stamp Board and how to build an IOT solution with it.

It is called a “stamp board” because it comes in a flat postage stamp-like postcard mailer.  Here is a picture of the front and the back (you can see that it has already lived a hard life riding around in my backpack).

IMG_2720

Here is the back of the mailer:

IMG_2722

In the picture you can see the yellow label proclaiming this to be an engineering sample.  It doesn’t seem like much, but when you pull back the front of the package you get to see the surprise:

IMG_2721-1

The kit can literally be broken into four separate pieces:

  1. The main board:
    • The PSoC4000S
    • A reset switch
    • A user LED
    • A user push button
    • A programming selector (to pick either the PSoC4000s or the PRoC BLE (that is on the back of the kit)) as the target of the programmer
    • All of the PSoC4000S pins are available on the 100mil center headers
    • A PCB footprint for a 10-pin ARM programming header
  2. A programmer board:
    • A PSoC5LP programmed with KitProg2 Firmware
    • A programmer mode button
    • 100mil center header with some of the PSoC5LP pins
  3. A Capsense slider user interface board with a 5 Segment Slider and 5 LEDs
  4. A Capsense button user interface board with 3 mutual capacitance buttons and 3 LEDs

145front-e

And the back, with the tiny 10mm X 10mm PRoC BLE module:

IMG_2706

Here is the schematic for the board:

CY8CKIT-145_PSOC_4A-S1-page1

CY8CKIT-145_PSOC_4A-S1 page 2

CY8CKIT-145_PSOC_4A-S1-page3

I wanted to build a project that would have two-way communication between my iPhone and the board, and would be compatible with the Swift App I had written.  The user of the board would have a capsense slider (and LEDs) of which the iPhone App could read the position.  In addition, it would have an LED that the iOS app could turn on and off.  Here is a demonstration that I filmed with my iPhone on the airplane:

In the next post I will describe the overall system and show you the firmware.

Embedded World 2016

I spent the past week in Nuremberg, Germany at the Embedded World conference doing my day job.  At the show, I spent some of my time teaching people how to program PSoCs.  For some crazy reason they thought that it would be a good idea to give me a microphone and find out what comes out of my mouth- generally that is something semi-crazy and it is always loud.    Here is a picture of me talking to the crowd (I am the one in the blue shirt facing the crowd)

IMG_5570

So what did I talk about?  Well, at this show, IOT was the big buzz.  So I decided to teach people how to make an IOT device using the Cypress PSoC 4 BLE.  This was similar to a recent video tutorial that I had made.  I started with a blank schematic in PSoC Creator and a CY8CKIT-042BLE,  I then added a capsense slider, an LED, a PWM, and the BLE component.  Then I showed people how to write the firmware.  I did all of this live, which can make things interesting at times.  At one point on Thursday, my wife called from KY and it seemed like a good idea to answer the phone.  She was a good sport when I put the microphone next to my cell phone and talked to her live during while I was presenting.

You can get the step by step instructions for this project on the cypress.com video tutorials website.  While I talked, the Cypress people handed out free development kits which was a big hit with the crowd.

The morning of the last day I reflected back on the last several years and realized that this show was a coming of age for the Cypress PSoC 4 platform.  We finally had a very robust family of parts from the tiny PSoC 4000 all the way to the large PSoC4200L.  The family had an ARM Cortex M0, Capsense, BlueTooth Smart, CAN, LIN, USB, ADCs, SPI, UART, OP Amps, Analog Mux and Programmable Digital Blocks.  In addition to the chips, we had a big library of well written application notes,  a bunch of cool development kits and best of all we had PSoC Creator which is an amazing, magical, free IDE for building your projects.

On Monday, we had just announced the new PSoC4000S (S stands for small) with a new low power capsense block that included mutual capacitance sensing.  During the show we were using a new “stamp” board to show off the chip.  In the next post Ill show you what I did on the airplane ride home from Germany.

IMG_2703

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

Overall CYPI Schematic

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

Screen Shot 2016-01-30 at 8.29.32 PM

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.

Screen Shot 2016-01-30 at 8.29.19 PM

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.

Screen Shot 2016-01-30 at 8.29.03 PM

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.

Screen Shot 2016-01-30 at 8.28.46 PM

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.

Screen Shot 2016-01-30 at 8.28.18 PM

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].

Screen Shot 2016-01-30 at 8.28.01 PM

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.

Screen Shot 2016-01-30 at 8.27.34 PM

Here is a picture of the final layout

Overall Layout

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

IMG_1176 (1)

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.

IMG_2024

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:creek1.0board

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.

zoom-of-error

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:

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.

IMG_2655

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.  5000_sml

Here is the final Eagle Schematic for the board.

CreekBoardSchematic

And the layout:CreekBoard2.0Layout

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:

creekboard1.1

Here is the assembled board:

 

IMG_2652

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.

architecture

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.

MFG_U5354-000005-015PG_sml

IMG_2230All 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.

creekboard1.1

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

IMG_1173

4. Raspberry PI

The Raspberry PI is a single board linux computer.

Raspberry_Pi_B+_top

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:

DSC_0059.JPGUnfortunately, some days I live IN the Elkhorn Creek.

Img22

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

IMG_2007I 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:

MFG_U5354-000005-015PG_sml

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. 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.
  2. 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.
  3. 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. “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:

IMG_2230

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”.

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

In the next posts I will:

  1. Show the whole system architecture
  2. Show the Printed Circuit Board
  3. Talk about the PSoC firmware
  4. 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”.

10790-07

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

2015-04-27_13-00-00

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