Differences

This shows you the differences between two versions of the page.

--- milestone_1 [2022/01/06 11:31]
scott [Report]
+++ milestone_1 [2023/01/13 16:21] (current)
scott [Requirements]
@@ Line 1: / Line 1: @@
-===== Milestone 1 =====
+====== Milestone 1 ======
 ===== Overview =====
-This milestone requires you to complete three tasks: 1) find your team member, 2) <del>implement</del> test a queue, and 3) verify that you have a working receiver board.
-  * Pass off and report submission will be done as a team (not individually)
+Before starting this milestone, find your team member. Pass off and report submission will be done as a team (not individually).
-  * Verify that you have one good transmitter and one good receiver board
-  * <del>Implement</del> Test a queue software package on the ZYBO board
+This milestone requires you to complete three tasks:
+  - Verify that you have one good transmitter and one good receiver board
+  - Submit a report describing your analog board experiments
+  - Implement a queue library module
 ----
-==== Queue Task Overview ====
+==== Requirements ====
-You will need to <del>implement</del> test a queue data structure for your laser-tag system. You should remember the basics of the queue data structure from some of your CS classes. This web-page provides a quick review of queues. This web page explains the “circular buffer” implementation strategy for queues. You must implement your queue as a circular buffer.
+  - You must have one working transmitter board.
+  - You must have one working receiver board.
+  - You must submit the report as described below.
+  - Your queue code must implement all of the functions listed in the queue.h file. For those of you unfamiliar with how to allocate memory in 'C', the queue_init() and queue_garbageCollect() functions are provided through a link below.
+  - Write your own queue code. Don't download code from the internet, it may have bugs in it. Also, since this queue module has extra functions that are not typically included in a queue implementation, things will just go faster and easier if you write the code yourselves.
+  - Your queue code must pass the provided queue_runTest() test.
+  - You must follow the same [[http://byu-cpe.github.io/ecen330/other/coding-standard/|coding standards]] as was done for ECEN 330. **Exception: clang-format is not required. Ignore any clang-format rules.**
-//The queue that you must <del>implement</del> test will be just a little different than a typical queue. It must have the following properties://
+----
-  * //Using a special function, your queue must allow you to keep adding (pushing) new elements even after it is full.// If the queue is full when you add an additional element, it must remove the oldest element and add the new one, making sure to keep the correct order of things in the queue. For example, let's say that your queue can contain 200 elements. If you add 400 elements to the queue, the queue should contain the last 200 elements that were added, in the same order that they were added. In other words, the queue will contain elements 201 through 400. When you remove an element from the queue, the elements should be removed in arrival order, e.g., element 201, followed by element 202, etc. You write a special function to do this: queue_overwritePush().
-  * //You must be able to read the contents in the queue without removing them or disturbing them.// In other words, your queue must provide a function that can read elements in the queue by index. For example, let's assume that the name of the function is queue_readElementAt(&q, index) and that it takes two arguments (the address of the queue, and the index of the element to read). If index = 0, this will read the oldest element in the queue. Larger values of index will successively read data that arrived later. You must print out an error message if the index-value would access elements beyond what is currently stored in the queue.
+===== Resources =====
-==== Queue Pass-Off ====
+==== Videos ====
-  * <del>Ensure that the queue_print() function prints out the contents of the queue **in order, from oldest value to newest value.**</del>
+These videos provide guidance on the oscilloscope that you will use during the pass off of your receiver board.
-  * Ensure that the queue_runTest() function runs to its end and that all tests pass.
+  * [[https://youtu.be/M9ywmh9OWpY|Long Range Pass Off Procedure]]
-  * <del>Submit your code on learning-suite.</del>
+  * [[https://youtu.be/3vgLWtSc4pM|Short Range Pass Off Procedure]]
+==== Queue Coding Help ====
+  * [[malloc_and_queue|How to use malloc and pointers in 'C' with the queue]].
+  * [[queue_resources|Queue Code Sketch]].
+  * [[http://en.wikipedia.org/wiki/Circular_buffer|Circular Buffer]]
+==== Source Code ====
+Note that the following files are provided in your ecen390 project directory. The test code is used to check the correctness of your code.
+  * lasertag/main.c
+  * lasertag/queue.h
+  * lasertag/support/queueTest.h
+  * lasertag/support/queueTest.c
+You are expected to create and implement the following file. See the provided header file (.h) for a description of each function.
+  * lasertag/queue.c
 ----
-==== Receiver Board Task Overview ====
+===== Specifications =====
+==== Receiver Board ====
 For this task, you must verify that you can receive a 20 mV RMS FFT signal from a gun excited with a 0 - 3.3V square wave when the two guns are separated by 40 feet.
 {{ ::milestone1verifyanaloghardware.jpg?600 }}
-These videos provide guidance on the oscilloscope that you will use during the pass-off of your receiver board.
+You will be using the gun mounted on the column. Save the raw data from the oscilloscope on a USB flash drive. You can then process the captured data with MATLAB to produce FFT plots for the report. The raw data needs to be collected with a sample rate of 100 ksamples/second.
-  - [[https://youtu.be/M9ywmh9OWpY|Long Range Pass Off Procedure]]
-  - [[https://youtu.be/3vgLWtSc4pM|Short Range Pass Off Procedure]]
-You will be using the gun mounted on the column.  In addition to saving the FFT plot for your report you also need to save the raw data.  The raw data needs to be collected with a sample rate of 100 ksamples/second.
 ** Oscilloscope settings**
@@ Line 39: / Line 60: @@
   * Under the save menu select settings set the number of samples to 50,000
-You can verify the sample rate by reading the data into Matlab and subtracting the time sample. The Matlab code would be the following.
+You can verify the sample rate by reading the data into MATLAB and subtracting the time sample. The MATLAB code would be the following.
 <code>
 /max(diff(t))
 </code>
-The Matlab output should be 1E5.
+The MATLAB output should be 1E5.
-==== Receiver Board Pass-Off ====
-Show the following on the oscilloscope display:
-  * Frequency domain plot of received data with hit for player 1 (frequency 1),
-  * Frequency domain plot of received data with shooter blocked (without hit) for player 1 (frequency 1).
 ----
-==== Report ====
+==== Queue ====
-You will turn in one report for this Milestone, the report will describe your experiments with your receiver boards and contain the following:
+You will need to implement a queue library module for your laser-tag system. Create a new file named queue.c in the lasertag directory. You should remember the basics of the queue data structure from some of your CS classes. A link under “Queue Coding Help” provides a quick review of queues. A link also explains the “circular buffer” implementation strategy for queues. You must implement your queue as a circular buffer.
-  - Matlab plot (in frequency domain) of received data with hit for player 1 (frequency 1),
-  - Matlab plot (in frequency domain) of received data with shooter blocked (without hit) for player 1 (frequency 1).
-  - Proper titles, etc.
-Here is a sample {{::milestone1_report.pdf|report}} you can use as an example.
+//The queue that you must implement will be just a little different than a typical queue. It must have the following properties://
+  * //Using a special function, your queue must allow you to keep adding (pushing) new elements even after it is full.// If the queue is full when you add an additional element, it must remove the oldest element and add the new one, making sure to keep the correct order of things in the queue. For example, let's say that your queue can contain 200 elements. If you add 400 elements to the queue, the queue should contain the last 200 elements that were added, in the same order that they were added. In other words, the queue will contain elements 201 through 400. When you remove an element from the queue, the elements should be removed in arrival order, e.g., element 201, followed by element 202, etc. You write a special function to do this: queue_overwritePush().
+  * //You must be able to read the contents in the queue without removing them or disturbing them.// In other words, your queue must provide a function that can read elements in the queue by index. For example, let's assume that the name of the function is queue_readElementAt(&q, index) and that it takes two arguments (the address of the queue, and the index of the element to read). If index = 0, this will read the oldest element in the queue. Larger values of index will successively read data that arrived later. You must print out an error message if the index-value would access elements beyond what is currently stored in the queue.
 ----
-===== All Requirements for this Milestone =====
+===== Pass Off =====
-  - You must have one working transmitter board.
-  - You must have one working receiver board.
-  - You must submit the report as described directly above.
-  - Your queue code must implement all of the functions listed in the queue.h file shown below. For those of you unfamiliar with how to allocate memory in 'C', I provided the queue_init() and queue_garbageCollect() functions below.
-  - <del>Write your own queue code. Don't download code from the internet, it tends to have bugs in it anyway. Also, because I have added functions that are not typically included in a queue data structure, things will just go faster and easier if you write the code yourselves.</del>
-  - Your queue code must pass the provided queue_runTest() test.
-  - You must follow the same [[http://byu-cpe.github.io/ecen330/other/coding-standard/|coding standards]] as was done for ECEN 330.
-----
+==== Receiver Board ====
+Show the following on the oscilloscope display:
+  * Frequency domain plot of received data with hit for player 1 (frequency 1),
+  * Frequency domain plot of received data with shooter blocked (without hit) for player 1 (frequency 1).
-===== Implementing the Queue =====
+==== Queue ====
-All software is developed using the same setup as you used in ECEn 330. A [[http://github.com/byu-cpe/ecen330_student/blob/master/lasertag/main.c|main.c]] is provided in the lasertag directory that you can modify to call various test functions.
+  * Ensure that the queue_runTest() function runs to its end and that all tests pass. This can be done by uncommenting ''#define RUNNING_MODE_TESTS'' in main.c.
+  * Submit your queue code on Learning Suite. Run "./check_and_zip.py 390m1" from within the ecen390 directory to create a .zip file of your project. Submit only one .zip file per team. The TAs will give credit to both members of the team.
-  * [[malloc_and_queue|How to use malloc and pointers in 'C' with the queue]].
+==== Report ====
-  * [[queue_and_array|Using an array to implement a queue.]]
+You will turn in one report for this Milestone, the report will describe your experiments with your receiver boards and contain the following:
-  * [[queue_resources|Resources]].
+  - MATLAB plot (in frequency domain) of received data with hit for player 1 (frequency 1).
+  - MATLAB plot (in frequency domain) of received data with shooter blocked (without hit) for player 1 (frequency 1).
+  - Proper titles, etc.
-----
+Here is a sample {{::milestone1_report.pdf|report}} you can use as an example.

ECEN 390 - Laser Tag Project

User Tools

Site Tools

Differences

Page Tools