ECE 280/Summer 2024

This will be a page to keep track of updates to the ECE 280 lab manual during Summer 2024.

• June
  • All labs converted to single-file
  • Philosophy: convert sections to look like ECE 110
    • ECE 110:Abstract, Objectives, Background, Pre-Laboratory Exercises, Pre-Laboratory Assignment, Equipment, Experimental Exercises, Exploration, Assignment
    • Proposal: Purpose, Pre-lab Exercises, Pre-lab Assignment, Lab Exercises, Lab Report
  • Added code to counters to give n/N values with N being the total (I am more proud of this than I should be, really...)

Lab 0

v1->v2 recommendations

• In the Pratt Pundit section about MATLAB installation, it might be helpful to replace where it says that the installation will be 12 GB with a range, something like 8-12 GB, since when Adam and I installed we ended up with different sizes that were both less than 12GB.
  • Done
• We also thought it might be helpful to make installing MATLAB a part of the prelab deliverable—our idea was to have the prelab deliverable to be a Gradescope submission where students upload/submit something along the lines of: the selfie they took in front of the lab door, a screenshot of MATLAB booted up, and a textbox submission where they type in the toolboxes they installed (we often have an issue where students don't read the pundit closely enough, and so they end up having to reinstall MATLAB halfway through the semester to get a toolbox they forgot to install at the beginning).
  • Done - I kept the tutorial as part of the in-class but added the installation to the pre-lab. Also - people should certainly not need to reinstall MATLAB if they are missing a package - there's an easy way to add packages later. I have added that to the MATLAB page.
• In general, we thought it might be good to standardize formatting of lab manual sections similarly to how the ECE 110 lab manuals are, to have the sections: Purpose, Pre-lab Exercises, Pre-lab Assignment, Lab Exercises, and Lab Report, and to have those be uniform across all of the lab manuals for the class (with the potential addition of something like a Background section).
  • I am going to see if I can make Labs 0 and 1 fit into the full ECE 110 format; if not, once we decide on the sections, I will work to map things into those.
• Finally, we thought it might be good to add a portion to the lab that gets into LaTeX and basic functionality and guidelines for writing lab reports—I feel like 280 is kind of the class where you're meant to really learn how to write lab reports, but a lot of people find that overwhelming, so providing an intro and establishing some basic standards would be really helpful. In particular, we were thinking that this could be turned into a post-lab deliverable, maybe something where we have students upload a "lab report" written in LaTeX with all of the basic sections that are used in the subsequent weeks of lab, plus maybe they have to put in an equation or insert a photo (maybe the certificate of completion of the MATLAB onramp course?) in the Results and Discussion section, sort of the equivalent of a "hello world" for the skills they need to write relatively polished lab reports in LaTeX.
  • Now that EGR 105 is in place (and since students could have skipped EGR 103 for the last five years) we will have a good number of students who may have never seen LaTeX (AFAIK no other class before ECE 280 actually requires it). I don't know if students would need the full "EGR 103 Lab 1" treatment. I am going to leave this as a future deliverable for now once I get a better idea of how the section remapping works

Lab 1

v1->v2 recommendations

• We thought it might help to format the second paragraph of the Purpose section in bullet points—the paragraph format we thought makes it easy for students to skip over reading it and get confused about what they're meant to be doing each week.
• In the third sentence of section 2.1: the phrase "in using a number" is a bit confusing, maybe something like "The octave each note is in should be denoted by a number. Higher numbers indicate higher overall pitches." would be more clear.
• Figs 1 and 2 have somewhat poor image quality; it might be worth updating them.
  • Also for Fig 1 specifically, if updating it would be good to use an example that already has a treble clef in the photo. We could even use a software like Musescore or something similar to manufacture an example—it could still be Beethoven's Fifth, or it could be something else
• In sentence 2 of section 2.2: there's an extra "the" before the word "mainly."
• In the second-to-last sentence of 2.2, "Note that...": I don't think it's really necessary for them to know that the piece is written in C minor—all they need to know is that the key signature denotes which pitches are "automatically" sharp or flat, and I worry that the extraneous information without much explanation might overwhelm people who don't know much about music.
• Sentence 2 of paragraph 2 of 2.3: this sentence feels somewhat incomplete. An extra phrase would help, something like "a quarter note has twice the duration of an eighth note, which has twice that of a sixteenth note, and so on" or "a quarter note has twice the duration of an eighth note and half the duration of a half note and so on"
• Sentence 4 of paragraph 2 of 2.3: "scare" should be "score"
• 2.4 OVERALL: Would it make sense to design a Pratt Pundit page with a more in depth explanation of different effects and their implementations in MATLAB? We could also include links to different references that we normally include in the lab slideshow or the Canvas page.
• 2.4, overlapping tones, sentence 3: "advance" should be "advanced"
• 2.4, harmonics, paragraph 1 last sentence: this should be turned into a note, with the same formatting as the other notes have (i.e. bolded, "NOTE" in all caps)
  • Also somewhere in this section, it might be worth noting that different combinations of amplitudes for each harmonic can correspond to certain instruments students might be trying to synthesize, and maybe adding a link to this page (it's already linked on Canvas, but might be worth having everything in the lab manual).
  • And, similarly, a link to this page could be added to instrument synthesis in 2.4. If a Pratt Pundit page is created, then both links could be included there instead.
• 2.4, harmonics, paragraph 2 sentence 1: the second part of this sentence is kind of unclear, replacing it with something like "any signal can be expressed as a sum of sin and/or cos waves" might bring the point home a bit more efficiently for students
• 2.4, instrument synthesis, sentence 4: "where as" should be one word
• 2.4, reverb, sentence 2: "ceiling" should be plural to match the other words in the list
• 2.4, reverb, second-to-last sentence: the space in the parenthetical before "300" should be deleted
• 2.4, reverb, last sentence: "on the next page" should be changed to "in the next section."
• 2.5: The parentheticals "(loudness)" and "(post-echo)" seemed somewhat unnecessary to us.
• 2.5, sentence 4: there should be a "the" inserted before "echo's."
• 2.5: The formatting of the question about the causality of the system in parentheses disrupts the flow of reading—could this be reworded to be a statement? Something like "Consider what this indicates about the causality of the system."
• IN GENERAL: it might be worth considering separating the background into two sections: Week 1 Background and Week 2 Background.
  • The same applies for the instructions (in which case we should add in a note that if a student used "Mary Had a Little Lamb" or a different song that they don't want to submit as their final song, they should generate a note vector for their final song before proceeding with step 7.
• Instructions #1 sentence 1: The parenthetical should be adjusted and integrated more into the sentence, and "approximately" should be taken out, something like "Make sure that your score is a reasonable length—your final score should be 30-60 seconds—and have a source from which..."
  • The parenthetical in the first note can also be deleted (not all video game music is computer generated, and also I think people generally understand what it means for music to be computer generated)
  • Also, formatting between notes should be kept consistent, i.e. one shouldn't be italicized if the other isn't
• Questions in the instructions should be altered to be checkpoints followed by a deliverable, e.g. "Checkpoint (1): Explain to your TA why the endpoint in the example time vector above is 1 - 1/f_s, instead of 1" followed by "Deliverable: Write up your answer to the question above and include it in the Discussion section of your lab report," or have a deliverable at the end of the instructions that reads something like "Deliverable: Write up your answers to the questions addressed in Checkpoints N - M and include them in the Discussion section of your lab report."
  • Also, these checkpoints shouldn't be interrupt the text of the instruction. For example, in #2, rather than the checkpoint coming before the sentence beginning with "You may change...", it should go after the note.
• #4, sentence 1: saying "rests or silent portions" implies that there are silent portions in musical scores which aren't rests, might be better to use a parenthetical, something like "For the rests (silent portions) in your score..." or a similar expression.
• #4, HINT: worth noting that I don't think most students use this hint. Most of them just use whatever method they've already established for generating notes, but setting the amplitude value to 0, so I'm not sure how necessary including it is.
• #5, sentence 2: the parentheses can be replaced with a semicolon: "after repeated notes; otherwise, the three..."
• #5, last two sentences: It's worth considering shortening the interesting side note. I think the last sentence could be cut, and the overall meaning would be preserved. The phrase "Interesting side note" could also be deleted; we thought it would serve the same purpose if it starts with "Theoretically,...."
• A checkpoint could be added after #6 prompting the student to play what they have for the TA
• #s 7-9 cover a lot of ground, so it may be helpful to create a set of checkpoints that covers them to let students touch base with the TA and to let the TA get insight into how the students are doing
  • This could look like a checkpoint after 9 that prompts the student to play the TA their song before and after modification and explain how/why it was improved
  • Or could look like a checkpoint after each step (7, 8, and 9) and then a deliverable after 9 that prompts them to write up an explanation of how each effect affected (haha) the sound - this could get at the first item in the discussion section of their lab report
  • The question currently after 8 could be wrapped up into a deliverable (potentially as part of the one after 9), or it could be turned into a note, rather than a question
• #9: parentheses around "Watch your amplitudes!" are unnecessary - these could be removed
• section 4 (lab submission) generally: Each bullet point has a lot of sentences; I'm not sure that students will read through them as carefully as would be ideally as is. Would it be possible to break these down any further?
• section 4, sentence 2: should be a comma after "final array, y"
• sect. 4, sentence 3: potentially consider changing "Example" to "e.g." for consistency with the rest of the lab manual
  • Same thing for "For example, Huettel_Twinkle.wav” in sent. 6
• sect. 4, sentence 4: should be "between -1 and 1" (not "1 and -1") for consistency
• sect. 4, second bullet: this should also be broken up more. Much of it I think could be worked into a deliverable maybe at the end of the instructions
• IN GENERAL FOR SUBMISSION: I think it might be worth trying to figure out an alternative to Canvas or Box for file submissions
  • we could use the "online assignment" option on gradescope for more flexibility, or we could have two assignments on gradescope for this lab: one for the lab report and another for file drop (the same could apply for the image processing labs and in general for when we have them submit large chunks of code that are potentially awkward in-line in lab reports)

Lab 2

v1->v2 recommendations

• intro second paragraph sentence 2: comma before “such as a” should be deleted
• 3.1 #1 sentence 2: add “in which” before “you plan”
• 3.1 #2 sentence 3: “blocks” formatting somewhat confusing given the convention established for bolding, should it maybe be written just in italics?
• We could potentially add a checkpoint at the end of exercise 1, something along the lines of “show your TA your blank model and the open Simulink Library Browser window”
• 3.2 #1 sentences 3-4: the phrasing right now isn’t as straightforward as it could be, and I think it makes it easier for students to get lost. Could be condensed/reworked to read something like “Add the Signal Generator block to your model by clicking and holding it…”
• 3.2 #2: the actual instruction in this step is somewhat hidden in the middle of the block of text. I would maybe move sentences 3 and 4 to the beginning, and then maybe add a sub-indented bullet that’s something like “you can do so by…”
  • I also think it may be helpful to specify here that the frequency units should be rad/sec
• I think 3.2 #3 could be turned into a checkpoint, something like “save your model as ‘lab2demo.slx’ and show your TA the modified parameters of your signal generator block”
• 3.2 #4b: everything after “Notice” should be turned into a note on the side, and I think in doing so you could delete the last sentence
• 3.2 #5c should either be a note or a sub-bullet under 5b, since it doesn’t contain any specific instruction
• Should we add a figure between steps 5 and 6 that shows what the model should look like just with all the blocks dragged out as directed?
  • Also potentially a figure after 6 that shows a completed model?
• 3.2 #6c: the block of text is very long - is there any way it can be broken up at all?
• There should be a deliverable after step 6 prompting the student to take a screenshot of their completed model
  • potentially also a checkpoint, but if we have a figure after 5 or 6 then I don't think we necessarily need a checkpoint here
• Why is exercise #3 section 4 (not 3.3?) - I think it would be helpful for all of the lab exercises should be consolidated within the “instructions” section, potentially as subsections
• Section 4 #5 isn’t an instruction right now, it should probably either be rephrased to read as an instruction or it should be turned into a note
• Section 4 #6: this is a fairly large block of text. I think it might be easier for students if we pared down the instruction itself a bit and then added a checkpoint that’s something like discuss with your TA why the original output signal doesn’t look correct, and show them the two versions of your signal, followed by a deliverable that is a picture of the final signal (with timestep 0.01 s)
• Also 4 #6 second paragraph sentence 2: “details” in “Solver details” should be bolded
• The inclusion of sections 4.1-4.4 in the middle of the instructions is somewhat distracting, I think the actual content of the sections is good, but it might be helpful to move them either into a “background” section or into an appendix of sorts so that they don’t disrupt the workflow of the lab itself
• 4.5 #1 this instruction covers a lot of ground, and it’s not totally clear that the sub-indented numbers are meant to be subcomponents of this one. This could be helped by changing those bullets to be lettered (a-h) rather than numbered (1-8) and by adding a sentence after “for x and y in the MATLAB workspace” that says something like “The process for doing so is as follows: “ or “Perform the following steps for signals x and y:” or something like that
  • Another option is that that first section could be converted into a sort of summary: “In this exercise we will be…” and then starting the actual instructions with: 1. Start a new blank model and save it as lab2ex4.slx, 2. Move the Signal Editor block into the Simulink workspace, etc.
  • In this case, we should add a step after they’ve created one piecewise signal that says to repeat the steps above for y
• 4.5 indented #s 1 and 2: “Signal Editor” should be bolded for consistency when describing the block
• 4.5 indented #2: The quotation mark before “To create and edit…” should be reversed
  • same with “Plot/Edit” in #4
  • and both quotes in #7 and #8
• 4.5 indented #4: not sure if this is just my MATLAB, but I didn’t have the option to click “Plot/edit,” I had to right click on signal 1 and then select “edit signal." Worth looking into to see if it's a general inconsistency with 2024a or just a quirk of my setup
• 4.5 I think we could also add a checkpoint after #8 to have them show their piecewise signals to the TA
• 4.5 normal #2: It’s not immediately clear that they’re meant to be using the To Workspace blocks for this. I would maybe separate this into two instructions: one that prompts them to create z by taking the product of x and y (maybe even stating what block to use to do so), and a second on that says something like “use To Workspace blocks to save each of these signals, making sure that each block is set to create an array”
• 4.5 #3: add “and run your model” at the end of the sentence, it’s not totally intuitive that you have to actually run things for the to workspace blocks to work
• 4.5 #5 can be turned into a deliverable
• 4.6: I think yahoo has updated their interface, everything is pretty similar about downloading the data, but there’s no “Apply” button now, so references to that should probably be taken out
• 4.6 #1f: add “worth” after “days’” or remove the apostrophe
• 4.6 I think we can add a checkpoint after #1. Something like “show your TA your final 60 by 2 array and discuss your intuition for how to apply a 5-point moving average filter to the data.”
• 4.6 #2 this is a large block of text, and I think it might be easy for students to get lost trying to follow it. In particular, I think only the first two sentences are strictly necessary to be contained in the body of the instruction itself. “Note that” after could be turned into a note to the side of the instruction, or it could be a sub-bullet. Same thing applies to the italicized sentence at the end of the instruction, although I think that if possible, it should be reformatted to match the rest of the lab report (i.e. not italicized, perhaps in bold and/or expressed as a sub-bullet to #2)
• 4.6 I think we could also add a checkpoint after #2 where we ask students to show their TA their completed moving average filter—I normally have students come check that with me anyways. There should probably also be a deliverable here asking them to submit a pic of the simulink model
• 4.6 #3: insert “, select” before “Model Settings” and bold “Mo” in “Model”
  • Also either “type” in “Solver selection type” should be bolded, or “solver” in “Solver selection solver” should be un-bolded for consistency
• We should add a checkpoint after 4.6 #4 asking them to discuss the questions that are currently listed under #5 with the TA and to share their plot, followed by a deliverable asking them to submit the plot and to write up answers to the questions in their own words
  • This deliverable would replace #s 5 and 6
• 5.2: in the section with the questions from exercise #5, the formatting of the questions should match what’s listed in the body of the lab manual
• After 5.3 we should consider deleting the sentence “Each group should turn in one report.” since we usually require each individual to submit a report
• GENERAL THOUGHT: do we want this lab to have a prelab? And if so, would it be worth maybe turning exercises 1-3 into the prelab?