Software Designs

System Firmware

Written in C utilizing the Particle Web IDE for the Particle Photon. Versions made available here are given as .txt for viewing compatibility.

Firmware changelog

1.0 Initial upload. Some artifacts from testing exist in comments. Feeding and watering timeouts are not yet calibrated.

1.1 Corrected erroneous behaviour if user stopped system whilst feeding/watering.

1.2 Added missing ISRs should the device be awake when the feed/water timing occurs. Added memory to sleep code to detect falling edge of counter bit 12 (comparison before/after sleep) to fix failure to feed.

1.3 Calibrated PWM values and timeout periods added for food mill and water pump under load.

Firmware Description

The system will sit idle until the user presses the start button; this button also handles stopping the system and returning it to idle. The user can set the feed level to one of LOW, MEDIUM, or HIGH via a set button, and view status of supplies using a status button.

Optionally, the user can manage the device remotely using an app powered by Blynk. The settings and displays within the app are seamlessly synced between their hardware counterparts as long as there is an internet connection for both devices.

Once the start button has been pressed. the system autonomously behaves as described below:

  1. Every 1.5 hours, cat will be given water

  2. Every 12 hours, cat will be fed up to the user-selected feed level

  3. Enters power-save after 30 seconds of inactivity.

    1. Will wake on any button, or the falling edge of the clock-counter every 1.5 hours

    2. If a button is used to wake the device from sleep, the button action will be carried out after the device wakes up without the user having to press it again

    3. App functionality will not immediately respond, however the device will respond to any changes made in the app on the next wakeup from any source

  4. If the user supplies a backup CR2032 battery, on power loss, the scheduled feed time and settings will be saved, and when power is returned, the device will resume normal function once the scheduled time has been met (see startButtonHandler state 9).

    1. In the absence of a backup battery, the device will simply reset when power is returned with all states in their default states

  5. If the user enables notifications on the Blynk app, they will be notified for the following:

    1. Any time the device power is returned without a backup battery in place (or a dead battery is present) stating that the device has been initially set up, or reset in the case of power loss.

    2. On low food or water supply

Firmware Components

Main loop

The functionality of the device is based on a superlooped state machine design, however there is a few conditional statements and discontinuous actions in the system as described below.

The startButtonHandler state machine functions as an enable for the system overall, and prohibits the system from feeding, watering, or entering power save.

The statusButtonHandler state machine prevents the setButtonHandler from running to prevent LED conflicts from occurring, as the devices share the same LEDs for indication.

In the event of power loss, where the battery backup is utilized, there is some discontinuous behavior used to get the system back to the user setpoints, including presetting state machines to a previous state directly, or in the case of startButtonHandler, a special recovery state.

Power Save (Sleep)

After 30 seconds of inactivity, the device will enter a sleep state to minimize idle power usage. Currently this is measured at 2-3 mA, which is between 1-3% of the current drawn while the device is idle with all peripherals powered.

The sleep mode chosen from the Particle API is the STOP mode, as there was no measured benefit to the DEEP_SLEEP mode, and the HIBERNATE mode cannot detect the cause of wakeup.

The sleep mode is configured such that any button on the device can wake it, as well as a falling edge of the ninth counter bit. The API allows user code to determine and utilize the wakeup source, therefore I have used it to trigger either the function of the button once awoken (as opposed to the user having to press it again afterward) or trigger the appropriate feed or water function based on the ninth counter bit as well as the state of the twelth.

The device will not instantaneously respond to user modifications to settings from the Blynk app, however the device will respond to them during the next wakeup.

State Machines

Start Button Handler (FSM)

Set Button Handler (FSM)

Status Button Handler (FSM)

Water Function (FSM)

Feed Function (FSM)

Shift Register Usage and Pin Assignment

After assessing the pin count required for the project, I counted a total of 23 required IO pins, accounting for the shift register controlling the LEDs. The Photon has 18 GPIO pins, therefore I decided to cascade another shift register onto the first to eliminate a few output pins. By cascading these, they can both be controlled using the same three pins, with the only additional requirement that two bytes be sent back-to-back instead of one. This gives 18 pins, which the Photon can handle.

The shift register is updated on each cycle of the main loop, but to minimize wear on the hardware, the system will only update the outputs if there is a change from the previous cycle.

The pin assignments can be viewed in the report below

Companion Phone App

App powered by Blynk and custom-made to parallel the onboard controls and indicators of the hardware in a minimalistic and self-explanatory manner.

User Interface

The UI is designed in a minimalistic fashion without any external menus or settings with the following features:

  • Controls, which parallel their hardware counterparts and update accordingly when the hardware controls are used:

    • Start toggle, which is a direct parallel to the hardware start button

    • Feed volume slider, which allows the user to directly set the level without cycling through each like in hardware

  • Food and water supply indicators persistently show the previously measured value, negating the need for a status button.

  • Notification toggle, where notifications include

    • Low food

    • Low water

    • Device reset on power recovery when a backup battery isn't provided

Control and Indicator Parallel Behavior

An important note about the behavior of the parallel controls is that, when the device is stopped or the feed volume is changed, the hardware will not respond to this change until it next wakes up, but will respond when it does.

Because the food and water supply levels do not change between feeding and watering events, the measurement made following these events is sent to the app to be displayed, removing the need for a status button. If the user would like to see an immediate response in the app when the device is resupplied with food and/or water, they can use the hardware status button to do this.

The notification toggle has no functionality in hardware and simply allows notifications from the device to pass through to the owner. The commands to notify on low food or water will always send to the app; the toggle simply enables them to be seen. However, if there is no supplied backup battery, and the device is reset after a power loss, this will reset all settings in the app, including notifications to 'On', and notifying the user that the device has been reset in the process. This particular alert mentions that the user can include a battery to prevent future power-loss resets.