Monthly Archives: December 2016

2016-12-06

Posted on by
Reply

Last week we figured out the map of the train tracks.  This involved finding the location of every point (train track switch) and section of track (area that could be individually powered).  The hardware that was being tested was a proto-board with components to allow for a PIC to be mobile.  To test it the board was programmed to send out valid packets and pulse a heartbeat LED.  The hardware that was tested can be seen on the schematic page.

Goals from previous week:

  • Figure out the bit mapping,
  • Test the hardware

Work Completed:

Greg:

  • Soldered 2 boards for the stations
  • Calculated addresses for sections of track
  • Calculated pins for points (how to control them)
  • Understood how to use the reed switches
  • Developed routing network (Eg North track to South track Eastbound)
  • Created schematics to interface with the points
  • Enhanced schematic to interface with the reed switches
  • Added interface to Bluetooth module
  • Moved to UART1 to keep UART2 open for bluetooth connection
  • Cleaned all tracks
  • Perform test runs on simple routing (N->N, Express->Express, S->S, E-bound)
  • Setup Input Capture to detect train on reed switch

Jack:

  • Got basic Bluetooth communication
  • Determined MAC addresses for all Bluetooth devices
  • Can now communicate with three Bluetooth slave
  • Determined that the BT modules can only connect to a maximum of three devices, unfortunately
  • Began on a workaround for the above problem
  • Began work on receiving information from the slave devices (we had discussed removing this from the project, I was determining how difficult it would be)

Challenges:

  • There are a lot of soldering connections which take a lot of time
  • Bluetooth master can only connect to two slaves

Upcoming Goals:

Greg:

  • Add safety cutout to the train tracks to prevent trains from crashing off the end.
  • Design external interface.

Jack:

  • Interface track control with Bluetooth.
  • Finish commands for individual stations.

Greg and Jack:

  • Build interface to control all of the train tracks.
  • Solder all boards

Status Update – Week 4

Posted on by
Reply

**Important Note for Clarification

            For this update and all future documentation, we will use consistent names to discuss which part of the project we are referring to. The “key” device refers to the hand-held device which includes the accelerometer. The “key” device is what will be moved around to enter passcodes to unlock the “lock” device. In initial designs, the “key” device was said to be a phone or Bluetooth key chain and the “lock” device was said to be a smart house lock.  

 

Goals for this past week:

  • Establish a Bluetooth connection in which the “key” device can tell the “lock” device the motion in which it was moved
  • Finalize details of UI, including improved screen transitions and corrected counters
  • Further improve accuracy of accelerometer
  • Begin to create a finalized design, integrating code for a “key” device and a “lock” device, and begin the process of making a final product to be used

 

Work Completed this week:

  • Craig
    • Developed a more reliable and accurate algorithm to correctly detect which direction the “key” device moves. The device now relies on current and past locations to create a variable bias point, based on when the user makes significant motion
    • Assisted in the debugging of now-outdated accelerometer code as well as small errors in the initial Bluetooth set-up
    • Separated the code for the “key” and “lock” devices

 

  • Rachel
    • Integrated the new accelerometer algorithm into the code for the “key” device
    • Successfully achieved a Bluetooth connection between two PIC32s, demonstrating a Bluetooth connection sending data from the master to the slave. Note: This Bluetooth connection was successful due to assistance and guidance from Jack Plumb.
    • Successfully sent values corresponding to the recorded horizontal and vertical movements as sent and collected from the “key” device to the “lock” device
    • Updated schematics and began to draft an initial design for the deliverable “key”device

 

Current Challenges:

Our biggest challenge is going to be making sure there is a smooth integration of parts while trying to complete the project, including all documentation and deliverables, by the fast-approaching deadline. While all major components are essentially built, some aspects have not been fully integrated with all parts of their respective devices (ie the key or the lock). The only potential setback we see would be if integration hits a snag, whether that be having pins being used for two different elements (something we have tried to consider and kept in mind while programming other elements) or having code conflict where one protothread blocks all others from continuing their respective functions. Overall, we believe that these small obstacles should not prevent us from completing this project by the demonstration on Friday.

 

Goals for upcoming week:

  • Craig
    • Connect the “key” device to a battery pack, thus making it mobile since it will no longer rely on the USB for power
    • Finalize all UI for the “lock” device LCD screen
    • Maximize accuracy of accelerometer readings, achieving accurate results with the minimal amount of movement
  • Rachel
    • Verify correct Bluetooth communication between the devices and accurate processing of received data
    • Finalize integration of devices
    • Update all schematics and diagrams of system elements as well as preparing documentation for the project demo and/or project report
  • Both partners
    • Create a deliverable / presentable “key” device, which currently is still on a breadboard, which is powered by a battery pack and able to be held while used
    • Commenting of all code

12/6/2016

Posted on by
Reply

Goals:

We would like to finalize the FSM we are developing now to determine how we are moving through the watering sequence. The largest contingency on this is how we are determining the optimal watering time based on temperature. We will come to a conclusion on this and Adam will continue to frame the FSM for our final design. Christer will finalize the comparator and be able to record the number of pulses output from the flow sensor that will directly translate to the amount of water being passed through the system. We will both be working on the I2C communication for the temperature sensor as we both will be executing this for the first time.

Work Completed:

Adam

  • Continued improvements to watering sequence.
  • Implemented a proportional control algorithm to alter the target water amount, based on the difference measured by the moisture sensor.
  • Cleaned up code, moved all configuration information to the top, to make it easier to switch from a test mode to real-time.
  • Implemented a manual water mode, allowing it to still interface with the automated system. Will only water the targeted amount (for defined moisture level). Allows for manual stoppage.
  • Temperature algorithm now uses a series of five data points, determining the temperature gain/loss between each, then makes a decision as to whether or not a cooling trend is located.
  • Recalibrated the LCD touchscreen, as well as debounced our button presses so they are accurate and (properly) responsive.
  • Further implemented two configurations, so that the system can switch between short timeframe testing and longer real-time use.

Christer

  • Changed flow sensor from working with the comparator to being a digital input pin. To accommodate this, an op-amp was added to create a more precise square wave. This input was used to control an interrupt that measures the amount of water dispersed by the tank.
  • The assembled flow system was attached to the water tank by screwing it into the valve on the bottom on the tank. To ensure the weight of the solenoid would not pull it from the valve, zip ties were used through holes put through the table to hold most of the weight.
  • The screen would display more water was dispersed than was actually let out of the tank due to the momentum of the water in the flow sensor. The logic for updating the flow value was changed to update only when in the state of watering and once we reached our target amount and the solenoid was closed, we would no longer update the water dispensed value.
  • Created the User Interface based on design proposal and elements we found useful during testing. The valve state is displayed at the bottom with an indicator if the tank needs water added to it.

Combined

  • Tested water flow sensor in test setup for accuracy. Reading was roughly 30ml over expected value.
  • Reviewed Design Proposal to ensure constraints were met. Added display information, as well as water moisture threshold.
  • Tested in soil. Soil used in testing proved to be difficult to use, due to extremely dry state it started in. Mixed with water, in hopes to produce moisture levels more conducive to further testing.
  • Fixed proportional control for water target amounts. We now normalize our error, and change our targeted amount by this percentage, rather than a fixed value.
  • Added failsafe to our solenoid valve. Will now only be allowed to stay open for a user-defined amount of time.
  • Tested system repeatedly to see how it traverses through the irrigation cycle. System seems fully implemented, however, more confirmation testing is still needed.

Current Challenges:

We are currently testing the system and attempting to identify any bugs. The largest challenge we are facing now is getting consistent dirt conditions for testing. The dirt was very dry when we added it to the containers and did not absorb water. We are letting the containers sit overnight with varying amounts of water to see how they settle. The other challenge we have is determining how we will display our findings in a way that conveys that our system meets the requirements.

Upcoming Goals:

If we find the soil has reached the testing condition that we expect (how saturated the dirt is) then we will test the system in each sample every day this week. Through these trials we hope to confirm the effectiveness of our target water dispensed algorithm, and its reactions to various soil moisture levels above and below desired thresholds. We also intend on running trending temperature trials to observe how the system reacts and ensure algorithm consistency.