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: might need to be more clear about how exactly a new blank model is created: could say "Hover over Blank Model and click 'Create Model' to create a new blank model"
  • also, "Blank Model" and "Create Model" (if the text is edited) should be bolded
• 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”
  • this would likely replace 3.1 #3
• 3.2 #1 There is no "right panel" anymore, might need to be updated for current UI
• 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…”
  • A potential option for reformatting is currently written out in lab02F24.tex 3.2 #1 (with the previous version commented out). In general, this style of bulletting is somewhat easier to read, and generally could be used as an example for other more wordy instructions (e.g. 3.2 #2)
• 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)
• 4 #6 sentence 1: in theory they've already run the simulation. do we want them to run it a second time, or should this read "if you haven't already, run the simulation now"
• 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?

Lab 3

v1->v2 recommendations

• Introduction: potentially replace the parentheses around “be they speech or music” with commas or em dashes
• Background eqn (2) (flanging) is the subscript on the last y supposed to be 1, not i?
• Instructions first paragraph: Appendix A is mentioned here - does that still exist? I can’t find it in the lab manual doc
• 5.1 #2: “in which” should be added before “you plan to save files”
• 5.1 #2: I also don’t necessarily think they need the full description here, and I think more is lost from the wordiness - could delete sentences 4 and 5
• 5.1 #3-5: these seem somewhat unnecessary to me, given students should already have completed lab 2
  • steps 4 and 5, especially, don’t contain actual instructions, so it might be helpful to either consolidate the content of these three steps into a side note or to delete them entirely
• 5.1 steps 6 and 7 should maybe be combined into one instruction, since there’s no actual prompt in #6 right now
• Figs 1 and 2 should be replaced with higher quality images
  • Also is there any way to reformat so that Fig 2 doesn’t take up the entire page and it’s more directly in-line, or is this an unavoidable LaTeX quirk?
• 5.1 #9: the “t” in “the” should be updated to match the rest of the word - it’s in kind of a strange font right now
• Could add a checkpoint after 5.1 #13
• 5.1 #14: it’s unclear whether they should be doing both 14a and 14b or if they should choose one or the other - maybe this should be specified in the first part of #14?
• 5.1 #14a: the cables that are needed to connect the function generator to the computer, as well as to the oscilloscope, should be included in the “Equipment Needed” section
• 5.1 #14b(iv): should be “via headphones” not “via headpones”
• I think we could also add a checkpoint after #14
• 5.2 #1: I remember the “NOTE”s being bolded in a previous lab - do we want to keep that convention? This applies to all of the notes in this section
• 5.2 #4: could add a checkpoint after #4 to explain to the TA how you created your model to implement the difference equation, then a deliverable to write up how the Simulink model is related to the difference equation
• 5.2 #5: same note here about the appendix (B) - I couldn’t find this in the lab manual or Canvas?
• 5.2 could add a checkpoint after #7, something along the lines of play the output for your TA, then a deliverable to answer the second question currently listed on pg. 11 (”What do you hear when a signal is processed using the single echo system?”). could also maybe add in question #5 (”Why does the output sound this way? (Relate your observations to the equation describing the system.)”)
• 5.2 also should probably add a deliverable after #8 to write up an explanation of how changes of a and D affect output
• 5.2 should add a deliverable at the end of the section that prompts the student to write up answers to questions 6-9 on pg. 11
• 5.3 #2: similar to 5.2 #4 I think we could add in a checkpoint followed by a deliverable after step 2 that addresses the first discussion prompt for the reverb exercise
• 5.3: should steps 2 and 3 be switched? I feel like it’s confusing to be creating a model which loads a signal from workspace that hasn’t been initialized yet
• 5.3 #4: “What do you hear?” should be turned into a deliverable that gets at the second discussion prompt
• 5.3 #5: I think it would be good to have a checkpoint here to discuss how modifying a and D affects the sound, and at the very least a deliverable for the third and fourth discussion prompts
• 5.3 #7: the section starting at “You will now compare” should be separated from the first part of the instruction - it should be indented differently, or there should be a skipped line before it, or both
• 5.3 I also think it would be good to have a checkpoint after #7 where we ask the students to play the real-time reverberator for their TA, as well as a deliverable asking them to compare reverb and echo (discussion prompt 5)
• 5.3 #8: don’t we usually provide the allpass reverberator on canvas? Should the instruction say to download the file and open it?
• Also I think we can add a deliverable after 5.3 #8 asking the students to compare the simple and allpass reverberators (prompt 6)
• 5.4 #2 I think this might be a good place to add a checkpoint, just something prompting them to show their TA the opened simulink file, so that TAs can make sure students are progressing okay
• 5.4 #4 “What do you hear?” should be turned into a deliverable, same as in 5.3
• 5.4 #5 I think it would be good to have both a checkpoint and a deliverable either here or after #6, checkpoint just asking them to discuss with the TA how modifying each parameter affects the sound, and then deliverable prompting them to write that up (discussion prompt 2)
• 5.4 a deliverable should be added at the end of the section asking students to write up answers to discussion prompts 3 and 4 (currently on pg. 16)
• section 6, wrap up: I think the wrap-up instructions might be better moved into their own subsection of instructions, maybe 5.5, so that the “lab report” section remains consistent between manuals
• 6.3: I’m fairly sure both of the first two bullets are included in the questions asked in the instructions - usually students are kind of confused (or at least ask me a lot of questions) about what exactly they should be answering, so it might be more straightforward to write something like “Answer all questions posed in deliverables (1-N)”, or to list each of the deliverables out, but I feel like that defeats the purpose of having them in the body of the lab manual to begin with
• 6.4: Same comment as with lab 2 about “Each group should turn in ONE report.”

Lab 4

v1->v2 recommendations

• section 1 sentence 3: insert “and the” before “Audio System Toolbox”
• section 2, first sentence after bullet points: I think the sentence might read a bit better if we delete the “the” ahead of “two major subsystems”
• section 2 last sentence: two parentheticals one after the other might be too much, I think either of them (or both) could be removed
• section 3: the NOTE should be bolded for consistency with other lab manuals
• 5.1 #1 doesn’t seem to give any specific instruction; the instruction itself seems to be #2, so the content in #1 might be better as another paragraph under the one that begins “The encoding process is relatively simple”, before the numbering of instructions for the exercise stars
• Also 5.1 #1 is there any way we can adjust the graphic so that the text from the code doesn’t go out of the box? We could have it wrap around maybe?
• 5.1 #2b: the note in parentheses should be bolded, taken out of parentheses, and slightly removed from the rest of the text to be consistent with notes in the other labs
• 5.1 #2c: the actual thing that should be implemented is a bit hidden here, it might help to insert a sentence saying something like “For each key input, you should find the corresponding row and column frequencies using the 4x3 matrices dtmf.colTones and dtmf.rowTones. For example, to translate the key ‘6’…” and then continue with the example code
• 5.1 #2 it’s also worth considering the fact that, especially if we remove #1 as a numbered instruction, #2 will be the only “step” in the exercise. in light of that, it might be helpful to break the subinstructions down and turn them into the main enumerated items in the exercise writeup in the manual
  • if this were the case, we would be committed to a more guided walkthrough of writing the encoder function. in that case, I think we probably wouldn’t need a checkpoint at the beginning. we could start with how to encode a single key and go through that in a few steps, and then cover how to string them together (probably one additional step)
  • I’m including a mockup of what the first couple steps of this could look like in the latex file lab04F24.tex
• 5.1 the bolded “HAVE YOUR TA/INSTRUCTOR…” statement at the end of this exercise should probably be turned into a checkpoint, and we should add a deliverable after the checkpoint that says that the completed dtmfdial.m file should be included in the final lab report
  • I tend to get a lot of questions from students when they’re coding their encoders, so it might be helpful if there was a checkpoint before they started that prompts them to kind of talk through their plans with the TA? Not necessary but something that might be helpful
• 5.2 #1: the parenthetical statement should maybe be turned into a “NOTE” so that the text of the instruction isn’t too long
• 5.2 #1: “Include a printout of these plots in your lab report” should be turned into a deliverable
• 5.2 #2: “For which tones do you expect a large correlation for each key (1, 5, and 9)? Are your results what you expect?” should be moved to the end of the instruction and turned into a checkpoint
• 5.2 #2: again, the instruction to include plots in the lab report should be turned into a deliverable
• 5.2 #3: again, there should be a checkpoint and a deliverable at the end of this instruction. the checkpoint can probably just address the questions “What do you observe? Why does this happen?”, and the deliverable can prompt them to include a zoomed-in plot in their lab report and also to write up a description of what they observed about the correlation plots in general (i.e. to answer the questions posed in the previous two checkpoints)
• There should also be a checkpoint and a deliverable after 5.2 #4 I think, replacing the bolded and/or italicized text
• 5.2 #5 reads like a paragraph intro to an exercise more so than an instruction, and the instructions following feel like a separate exercise from what the students were just doing - I think it might help the lab flow better if we ended exercise #2 after step 4 and began a third exercise afterward (of which the current #6 would be the first step)
• 5.2 #6: I think this step could be split up into two instructions: one that contains the first two sentences (load simple_corr.mdl) and another that asks them to build the intermediate steps
  • in this case, also, I think it would be helpful to move the current last sentence in #6 to the beginning of the second instruction and to move the text from sentence 3 till the second-to-last sentence after, potentially as a sub-bullet or a note
• I also think we could add a checkpoint after #6 to let TAs check in with students just using the SinWave input
• 5.2 #7: it’s not totally clear that the DSP Sine Wave block is replacing the From Workspace, maybe if “Use the” were changed to “Replace the Signal From Workspace block with a”
• The bolded text after 5.2 #8 should be turned into a checkpoint
• 5.2 #10: I think we can remove the parenthetical “(you will need to do this in your lab report)” and instead add a checkpoint afterward that has them discuss how the algorithm works with their TA and then a deliverable that prompts them to write it up
• I think we could also add a checkpoint and a deliverable at the end of the exercise 2 (after #12). the second-to-last bullet point in section 6.3 can be incorporated into those
• for section 6, I think the sequence of things to do before leaving should maybe be incorporated into the instructions, maybe as a separate subsection
• 6.3 same thought as with lab 3, since we’re transferring over to the checkpoint/deliverable format, it might be more straightforward to write something like “Answer all questions posed in deliverables (1-N)”
• And, again, same comment about “Each group should turn in ONE report.” I’ll stop noting this from now on, but it should apply in general I think