1. Smart Frisbee Blake Yerkes James Younce Ryan Moser Group #6: Dennis Yuan

2. Introduction  Frisbee tracks gameplay and wirelessly communicates with wristbands to improve game and state detection  Team scores  ID player holding Frisbee  Out-bounds & end zone detection

3. Objectives  Frisbee functionality  Knows where it is at on the field  Detects catches and ignores drops  Can differentiate between players  Keeps track of score

4. Hardware – Design Requirements  3.3 volt operating voltage for all components  Components must be able to interface with Cortex M0 over UART, SPI, or I2C  1.5 hour battery life for both Frisbee and wristbands  Minimal impact to Frisbee

5. Hardware – Original design

6. Hardware – Design Process  Frisbee and wristband PCBs were designed for smallest feasible size  Difficult to do with so many breakout boards  Needed ability to debug components  On wristband, all components were placed on one side of a two- layer PCB  This was done for protecting the player from the board and visa versa

7. Hardware – Final Design Frisbee PCB designWristband PCB design

8. Hardware – Requirements and Verification  Power supply outputs 3.3v  Power supply was installed, and the output probed  MPU communicates over I2C  Printed out accelerometer and gyroscope values  Transceiver communicates over SPI  Printed out transceiver register values  GPS communicates over UART  Printed out parsed GPS messages  Seven segment display drivers communicate over I2C  Had seven segments display the numbers zero through nine  Battery lasts for 1.5 hours  Ran it for 1.5 hours without charging

9. Hardware – Completed PCBs Finished Frisbee PCB Bare and covered, finished wristband PCBS

10. Hardware – Complete Assembly

11. Hardware - Challenges  Manufacturing defect in one of the Frisbee PCBs  Four processers had I2C failures  Switched Tx and Rx for GPS UART  MPU suffered reverse polarity, minor accuracy loss  One transceiver developed a short from IRQ to ground  One seven segment display had a bar burn out  Two power supplies burnt out  A third supply had the usb charging port pulled off

12. Wireless – Communication Scheme  Different Options available  Time division multiplexing  Faster  Harder to implement due to timing issues, sync issues  Different frequencies  No need for valid packets (backup plan)  Different background noises  Different wavelength dependence

13. Wireless – Current Design  Communication scheme uses query reply system  Frisbee hub sends out query code  Transceiver receives coded reply player id and incoming RSSI  Chose RFM22-Breakout module  Access to Pins  Reference Libraries  Multiple operating settings (GFSK, OOK, carrier frequencies, data rates)

14. Wireless - RFM22 RSSI

15. Wireless – RFM22 Operation  SPI 5 wire communication scheme  Currently 1.5 MHz determined by hardware side of project  Limited to 1 byte transfer to RFM22(early hardware mistake)  Internal registers determine operating parameters  Packet sending/receiving  Internal packet handling registers set up sync word, preamble, packet length  On board FIFO’s take data written to them and process/send/receive packet

16. Wireless - RFM22 Operation  Interrupt Line  Driven low upon interrupt event  Critical to operation of algorithm on software side  Configurable to include valid packet sent/received, RSSI thresholds  Current Iteration triggers on valid packet conditions

17. Wireless - RFM22 Settings  Low data rate requirement  Bandwidth management not an issue  Settings  F c =500Mhz  Data Rate ~ 5Kbps  Data sheet modem settings used for RF chain parameters

18. Wireless - Modified Requirements  Basis of project relies on relative powers received  Experimented with multiple channel  Background noise different  Wavelength dependence  Attempted calibration of factors  Absolute received power not necessary  Sufficient that received power is function of distance  Random noise now drives requirements

19. Wireless – RF Modified Requirements Friis EquationRelative power between 10 ->36 Inches dB RSSI module reports in increments of.5 dBm therefore Modules should safely be measured as no more than 22 RSSI increments away at same distance For safety require that both be about ½ of 22 measurement gap as 6 dB difference an therefore 12 RSSI increment levels

20. Wireless - RFM22 Verifying and Scaling  Verifying  Valid Packets transmitted and received  Same distance/same angle measurements showed RSSI variation below 12  Scaling  TDM on one channel becomes harder with more Wristbands  If multiple channels need to calibrate background, antenna, wavelength  Possible Solution: Use RSSI interrupt as reply condition  Antenna design  Timing access to micro-controller  Data driven reply-metrics

21. Software – Design Requirements  Collect and analyze data  Determine the current zone on the field  Control 7-Segment Displays  Process gyroscope and accelerometer data  Transceiver control } Game Parameters & State Detection

22. Software – Planning  Cortex M0 Processor  Small footprint  Low power consumption  I 2 C, UART, SPI  Past experience Processor next to pencil tip

23. Software – Original Design  Rely on accelerometer and gyroscope to determine state of Frisbee  Map 4 corners of field with GPS and determine location relative to the field boundaries  Use transceivers to detect closest player when Frisbee is caught  Chirp when out of bounds  Display team scores on Frisbee Original Gameplay Flow Diagram

24. Software – Challenges  Programming bugs  Issues printing out float variables  Shared hardware and software issues  Differentiating between a missed catch and valid catch  Running averages and arrays (lengthy data collection)  Multiple revisions of state detection algorithm

25. Software – Modified Design  Final method for state detection  Gyro is consistently decelerating (air)  Gyro is consistently near zero (ground)  Conditional remaining states (held)  Accelerometer not used

26. Software – Testing and Verification  Fine Tuning  Optimal array sizes  Accurate threshold values  Verification  Walked around to test field zones and accuracy  Validate the state detection accuracy  Correctly determine the closest player when caught in endzone  All verifications were successful

27. Conclusion  End Result: Success  Future Work:  Smart Frisbee serves as a proof-of-concept  Modify the Frisbee as little as possible to maintain trueness of game  Redesign as consumer product  Optimize for mass production  Redo GPS as antenna array