Difference between revisions of "S14: Asset Management and Location System"

Revision as of 20:07, 20 May 2014

Grading Criteria

How well is Software & Hardware Design described?
How well can this report be used to reproduce this project?
Code Quality
Overall Report Quality:
- Software Block Diagrams
- Hardware Block Diagrams
  Schematic Quality
- Quality of technical challenges and solutions adopted.

S14: Asset Management and Location System

Abstract

The ultimate vision of this project is to develop an asset management and location system to compete with The Tile App. There are two major components to the Tile solution: the tracker and the application. The tracker is small low-power embedded system that can be attached to an object. The application is primarily a user interface that provides visual feedback to guide a user to a specified tag.

Objectives & Introduction

Objectives

To track a tile location within 100 meters
To add/register tiles to user
To remove tiles from user tiles database
Display a histogram of tile vicinity

Team Members & Responsibilities

Akash Ayare
Pardeep Badhan
Talha Ilyas

Schedule

Show a simple table or figures that show your scheduled as planned before you started working on the project. Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals. The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.

Week	Date	Planned	Actual
1	3/6	Create Wiki page and add the schedule of the project.	Wiki page was created and preliminary scheduling was added.
2	3/13	Research on Bluetooth and Zigbee radio technologies.	Compared Bluetooth and Zigbee range and power consumption. Although Zigbee has slightly better power consumption and better range, decision was made to use Bluetooth for the project to keep similarity with Tile project.
3	3/20	Order parts and research RSSI	Parts were not ordered mainly due to the number of options available; more research was still needed. Instead, the team registered with GitLab. Project "lpc1758_freertos" was checked in as the base project. Furthermore, the team trained on Git workflow and branching methodology.
4	3/27	Interface Bluetooth Modules.	Ordered Class 1 Bluetooth version 2 modules.
5	4/3	Achieve basic Bluetooth communication.	Basic connectivity achieved. Hercules Setup software was used to connect to the Bluetooth Serial port.
6	4/10	Fetch RSSI value from the Bluetooth module.	Discovered there are two ways to fetch the RSSI value. One mode worked better over the other, but it was slower. In a open room, with one of the modes, there wasn't significant change in RSSI value when proximity changed. The second mode provided better distance estimation, but it was slower to fetch RSSI value in this mode.
7	4/17	Experiment how this value changes with proximity.	Started interfacing with the Bluetooth module with SJ One Board instead of Hercules. Also, added a task to receive Bluetooth data and display it on console.
8	4/24	Implement visual indicator (histogram) corresponding to RSSI values.	Interfaced LCD screen with SJ One Board. Added tasks to control the user menu and monitor switches, and user menu infrastructure that: Displayed the menu list to the LCD and selection markers to indicate currently selected menu item Allowed the user to scroll up and down the menu list using the switches Allowed the user to select a menu option Allowed the user to go back to the previous menu
9	5/1	Packaging, battery installation, and testing. Expansion of feature-set	Enhanced features: Added CharDev pointers in LCD and Bluetooth class instead of using the Uart2 and Uart3 directly. This allowed us to switch Uart ports with minimum code changes Changed switch ID variable names so they are independent of the action associated with the switch Modified LCD::display to add an option whether to display the selection marker or not Added "Add Tile" option (not completed yet, "select" action is pending). When "Add Tile" option is selected, the code does Bluetooth inquiry and lists all the devices on the LCD Enhanced logic to get the Bluetooth into command mode. The function Bluetooth::goToCmdMode makes sure the Bluetooth is in command mode before returning. It does this by issuing "V" command and verifying the received data. After issuing the CMD string ($$$), the trick was to wait few milliseconds Added a function that enables us to retrive string from the user. The top row of the LCD has character which the user can use to form a string. The switches allow the user to go left/right to select a character. The other two switches serve as backspace+cancel and select. Also, added an option to not center align the text on LCD. Updated the LCD class to support a FTDI (USB) emulation mode when a LCD display is not available. To enter emulation mode P2.7 must be pulled high. Otherwise, normal LCD mode will be assumed. Previously, after Adding a Tile only the bluetooth MAC address was visible on the screen. Now, the MAC address is concatenated with the RSSI value. The RSSI value starts with a negative (-) sign, so it is easy to distinguish the two values without using a space character. Also, when a list of tiles would return it wasn't easy to determine if you reached the bottom or the top of the list of tiles. Now, when you reach the top (or bottom) of the tile list a message will be displayed. The user menu portion of the "Add Tile" menu has been completed. The user can now 1) query the Bluetooth devices, 2) select the device he/she wants to add, 3) select the name of the device or simply use the MAC address. TODO: The corresponding back end operation needs to be completed. We should be able to store the device information (MAC address, Bluetooth name, device name (selected by the user) to the on-board flash. Changed the switch names back to its original form as suggested by Akash. Some touch ups to the LCD::display function. This change implements the Track Tile menu and associated actions. Plus, it will display a histogram based on the RSSI value. There are a lot of TODOs that need to be addressed in this change. The major things that need to be done is refactoring, splitting Track (List, Track, Histogram), and continuously update histogram until back is pushed. This change improves the display and overall user experience by conforming to existing design patterns and API. This change also includes some minimal refactoring. Split Track Action into List and Track. Plus, the display will automatically update whenever new data is available when operating in tracking mode. Pushing the back button will exit tracking mode... but the response can be a little slow.
10	5/8	Demo	The demo was postponed to 05/22 Enhanced features: Finished backend support for "Add Tile", added support for "Remove Tile", and "List Tiles" menus. The "Add Tile" option now writes the tile information to the flash. At bootup, this file is read to determine the number registered tile devices, and the information of each device is read in memory. The file doesn't start a 0 to always make usage of Storage::append() API - if the offset is 0, it write to end of the file. Added "tileDevice" class that stores the information of a tile. The information includes 1) tile name, 2) Bluetooth name, 3) MAC address, 4) COD, 5) RSSI when the device was added. Moved the inquiry logic to a function. Also made it more robust. It is now able to handle a case where multiple inquiry attempts are made. The logic will finish the old query, and then it will start a new inquiry. Also moved the "Start of List" and "End of List" to LCD::display function to avoid the replication. Added new function called "inquirySingleBTDevice" that inquiries for a particular device. Also, started adding few comments to the code. Displayed more info in "List" menu - 1) Tile Name, 2) Bluetooth Name, and 3) MAC address Track feature has entry through list. Since list is redefined in devel, the track feature list is commented out - in turn, disabling the entire track feature. With the merge resolved, the next step is to evaluate if list can be modularized to satisfy requirements of both branches; otherwise logic changes need to be made. Re-enabled tracking feature. Changed entry into tracking feature from listTile... to selectTile. The selectTile... function makes use of registredTileDevice shared data structure. Additionally, it uses the new (simplified) logic for determining if the displayed list is at top or is at end; with updated re-initialization on back press/action. Minimal edits to trackTile... function to bring it into an operational state. However, this function needs to be updated to use latest APIs and data structures. trackTile... function has been refactored to maintain historical behavior, but now invokes inquirySingleBTDevice API. The inquiryAllBTDevices function signature was modified to include an optional argument to display the "Searching..." message. This message is not desirable when displaying a histogram in a loop. In any case, the inquiryAllBTDevices API remains backward compatible. Note: In testing, unexpected behavior was observed when a tile comes into or exits the field of vision while in trackingMode.

Parts List & Cost

Item	Part Name	Part Cost	Qty	Total Cost
1	LPC1758 SJSU One Board	$80	1	$80
2	SparkFun BlueSMiRF Gold]	$64.95	2	$209.90
3	SparkFun Bluetooh Mate Gold	$64.95	1	$274.85
4	Serial Enabled 16x2 LCD	$24.95	1	$299.80

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

Hardware Interface

SJSU One UART3 is interfaced with the Bluetooth module at 115200 bps with RX and TX queue depth of 1000 elements, respectively using the supplied UART3 driver. The following table depicts the connections:

SJSU One		Peripheral
Power	3.3V	VCC	Bluetooth
Ground	GND	GND
N/A	CTS-I	RTS
UART3	TX	RX - O
UART3	RX	TX - O
Power	3.3V	VCC	LCD
Ground	GND	GND
UART2	TX	RX

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

My Issue #1

Discuss the issue and resolution.

Conclusion

Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

Project Video

Upload a video of your project and post the link here.

Project Source Code

Send me your zipped source code and I will upload this to SourceForge and link it for you.

References

Acknowledgement

Any acknowledgement that you may wish to provide can be included here.

References Used

List any references used in project.

Appendix

You can list the references you used.

@@ Line 120: / Line 120: @@
 # Displayed more info in "List" menu - 1) Tile Name, 2) Bluetooth Name, and 3) MAC address
 # Track feature has entry through list. Since list is redefined in devel, the track feature list is commented out - in turn, disabling the entire track feature. With the merge resolved, the next step is to evaluate if list can be modularized to satisfy requirements of both branches; otherwise logic changes need to be made.
-# Re-enabled tracking feature. Changed entry into tracking feature from listTile... to selectTile. The selectTile... function makes use of registredTileDevice shared data structure. Additionally, it uses the new (simplified) logic for
+# Re-enabled tracking feature. Changed entry into tracking feature from listTile... to selectTile. The selectTile... function makes use of registredTileDevice shared data structure. Additionally, it uses the new (simplified) logic for determining if the displayed list is at top or is at end; with updated re-initialization on back press/action. Minimal edits to trackTile... function to bring it into an operational state. However, this function needs to be updated to use latest APIs and data structures.
-determining if the displayed list is at top or is at end; with updated re-initialization on back press/action. Minimal edits to trackTile... function to bring it into an operational state. However, this function needs to be updated to use latest APIs and data structures.
 # trackTile... function has been refactored to maintain historical behavior, but now invokes inquirySingleBTDevice API. The inquiryAllBTDevices function signature was modified to include an optional argument to display the "Searching..." message. This message is not desirable when displaying a histogram in a loop. In any case, the inquiryAllBTDevices API remains backward compatible. Note: In testing, unexpected behavior was observed when a tile comes into or exits the field of vision while in trackingMode.
 |}