Electrical/Telecommunications Design Proficiency
Session 1, 2017
- Week 13
Supplementary Task for the Electronics Topic
- Please review carefully the conditions under which you can do
this task and benefit from it, as outlined in the linked PDF.
- Week 13 Control Topic Continuation
- Unlike the Electronics supplementary task, this is a true
continuation of the Control Topic, as if it had lasted for 4 weeks.
- There will be no open Lab in Week 13.
- You may not borrow the Control Rig in Week 13. This is my
last opportunity to encourage you to design on paper, with
contingency plans to avert problems in the lab, rather than by
trial-and-error. I am more concerned about your approach than
your achievement of all the goals.
- Week 13
- Due to student request, bench posts have been re-arranged
relative to Weeks 6-9.
- All computers in EE113/114 now have Matlab 2012 as well as 2011.
We were unable to install the 2015 version due to incompatibility
with the equipment.
- If you have any difficulty using the dsp.AudioPlayer, you
might like to consult the slightly updated version found below,
which contains comments to help you make it work on older
versions of Matlab.
- If you have a very good reason to swap benches during Week 13,
this may be possible, but only with demonstrator permission.
- Detailed Guidelines for the Elective Topic Final Report
- Provides more explanation of the structure given in the Week 10 lecture
- Remember that the report is due on Friday of Week 13 by 5pm, not Thursday as indicated in early documents
- Submit your report as a single PDF document by email to firstname.lastname@example.org with the subject line: ELEC/TELE 4123 REPORT
- Cover Sheet for your Final Report
- Fill out the cover sheet by hand, scan it and include it at the front of your report.
- Before submitting your report you will need to return the E-cores (including former) either in the lab (Week 12 or Week 13) or directly to the EET Electronics Workshop staff in EE-G1.
- Assessment of Understanding for the Elective Topic
- Each team member must be prepared to be interviewed at any time during the laboratory session on Thursday of Week 12
- To prepare for the interview, you should consider that we are interested in two things:
- What is your understanding of the design problem that led to your team's approach (all aspects)?
- What are the detailed design decisions, calculations, analysis and behaviour of selected aspects of the design?
- this part may be ore focussed on your own contributions, but you should have an understanding of the overall design.
- Elective Topic Teams
- Full list is here
- There have been some changes to C03, E03, E20 and N07
- List includes assigned laboratory benches
- Network Topic Latest Announcements
- Multiple MAC address support has been enabled in EE101/102 now, so the Linux VM's in that lab can get their own externally visible IP addresses from Week 11, rather than relying upon VMware's NAT. This means that you will have no trouble running your own servers on the VM.
- We are installing aVM onto the lab PC's in EE101/102 with a more recent version of Linux (Fedora 25) -- you can choose either the older one that was available in Week 10 or the new one.
- You can disable the firewall on the Linux VM's on the lab PC's in EE101/102 by executing "service iptables stop" as root.
- We do not plan an open lab for Week 12, but because the network topic had some interruptions of services, the server platform will be made reachable from 5pm to 8pm on Wednesday of Week 12 -- i.e., during the slot when open labs have run for the other topics.
Copy of class email regarding Open Labs, Suggestions and Hints for Topic-1
- Cables in the labs (see above email for more details)
- Cables are for the equipment, not for your design.
- 3 BNC cables and 6 power cables are sufficient for each set of equipment
- Suggestions and Hints (more in the above email)
- Tasks may be completed out of order
- Bring a bigger breadboard -- small breadboards will really slow you down
Lectures, Labs and Tuts
- Lectures: Mondays 5-6, Weeks 1, 4, 7 and 10 only
- Tutorials: Mondays 5-6, Weeks 2-3, 5-6, 8-9 and 11-12
- While tutorials do not appear on your enrolment information for this course,
they take place within the same slot as the lecture which does appear.
- Participation in tutorials is MANDATORY and forms part of your assessment.
- Tutorial groups were assigned in the first laboratory or through subsequent email correspondence -- see below for the full list.
- Laboratories: Thursdays 9am to 1pm, Weeks 1-12 inclusive
Assigned Tutorial Groups: list
- If your name does not appear on the above list, you did not attend the laboratory in Week 1 -- you must contact the course convener, Prof. Taubman.
- The list contains the name of your demonstrator, as well as the tutorial location.
Course and Topic Descriptions
Electronics Design Tasks (core)
Signal Processing Design Tasks (core)
- Tasks 1, 2 and 3 -- Made available on Thursday of Week 3
- Tasks 4 and 5 -- Made available on Thursday of Week 4
- Sound Source for Signal Processing Task 5
- The web-page is here: sound_source
- You should be able to use this sound source from most mobile phones, which then become the "target" mentioned in the task description.
- NB: the implementation here has been tested on Firefox, Chrome and Safari. Internet Explorer has no support for Web Audio, though.
Control Design Tasks (core)
- Tasks 1, 2 and 3 -- Made available on Friday of Week 6 -- slight mods on Wednesday of Week 7, 11:10am
- Tasks 5, 5 and 6 -- Made available on Thursday of Week 7
- Photos of the control rig (with example inductive winding)
- Fan motor datasheet for the control rig
Example: how to continuously update audio in Matlab
- The example has been updated to indicate special precautions
required when running on older versions of Matlab -- if buffer
underrun is not supported by the dsp.AudioPlayer, you need
to be sure to call "step" without any return value
- You will find that the regular "audioplayer"
function in Matlab introduces a delay between successive
blocks of uploaded audio. Thanks to Max Fisher for pointing
- Multiple solutions to this problem can be found, but I suggest you
use "dsp.AudioPlayer" instead. This gives you a
convenient interface to the underlying audio queue. You push
blocks of audio onto the queue, with push calls blocking once
the queue is full. You can directly control the queue size and
the internal transfer block size so as to control latency. You
can then just run a tight loop which alternately pushes a
block of output audio and retrieves a block of input audio.
- These principles are demonstrated by the trivial example supplied
here, so as to speed you along.
Elective Design Topics (weeks 10-12)
- There are three elective design topics, as follows:
- Energy Systems;
- Physical Communications; and
- Networked Communications.
- Elective design is done in teams of size 3 or 4 (no exceptions)
- It will be much easier for you if your entire team has the same tutorial group, as explained in the general introduction to each of the design topics (see links above)
- Teams will be finalized during the Tutorial of Week 9:
- You can form a team ahead of time, in which case you must hand your tutor a list of all team members (including any from another tutorial group)
- use the form here to supply pre-formed team information to your tutor
- if you wish to form a team of 3, split across two tutorials, you will need to ask Prof. Taubman for permission
- email is fine, but first try to speak with him during the lab in Week 8 first;
- bear in mind that the tutor may assign an extra student to the group so as to create a 2+2 split
- Your tutor will organize any students in the tutorial who have not formed a team already into teams, so that the team members and topic are finalized on Monday of Week 9.
- Your tutor has the right to adjust pre-formed teams if necessary, in order to ensure that all students are in teams of 3 or 4 students each.
Supplementary Documentation for the Elective Topics
Energy Systems Elective:
- Ferrite Core Specifications
- Note that each team is only provided with one core. It is easy to break! If you break it, you will have to buy another one from the EE&T Electronics Workshop.
- Useful explanatory notes on the terms used to specify the ferrite core.
- Enameled winding wire available from the EE&T Electronics Workshop: SWG 21/22 (~0.8mm diameter); for other sizes, purchase your own outside.
- Transmission Line Model and Parameters
- There are two versions of the transmission line; the X parameter depends on the version your team receives.
- Version 1 -- X=1.0W; E=20%
- Version 2 -- X=0.95W; E=20%
Physical Communications Elective:
- Channel Schematic
- NB: the noise level depends upon the trimpot setting
- Lab staff will adjust the trimpot to get a noise level of ~0.2V RMS at the output -- measure it, but do not change it yourself!
- You MAY ASSUME that the message characters associated with this design task are ASCII values in the range 0 to 127 inclusive.
- You will receive a 4m length of shielded cable with 2 cores and a shield. You are to do the following:
- At one end (the source end), tie the shield to the black core, so the source has one GND and one ACTIVE line.
- At the other end (the receiver end), you are left with a shield (GND) and two ACTIVE lines, one of which (black) is close to GND, but allowed to float. These three leads go to the "Channel" PCB whose schematic appears above.
- We suggest you tie the black core to pin P2 and the red core to pin P1, corresponding to the non-inverting and inverting inputs of the differential amplifier at the "channel" front end. These are followed internally by another inverting amplifier, so the overall transfer function from the red (active) line to the output of the "channel" PCB will be non-inverting -- not that this is all that important.
- The performance target for this project is X=100 chars/s -- I have verified that it is possible to achieve significantly more than this.
- For testing purposes, the length of the messages will be on the order of 6000 characters in length.
- Bench and Computer Arrangements:
- Each Communications team has access to 4 lab computers and 4 signal generators.
- One team is assigned a long bench with 4 sets of lab equipment -- for this team, the shielded cable should be used to connect one long side of the bench (the transmitting side) to the other long side of the bench (the receiving side).
- Each of the other two teams are assigned one short bench plus half of a second short bench, all being against the window. Extra computers should have been installed at the second (half) bench, and the shielded cable should be used to connect the full bench (the transmitting side) to the half bench (the receiving side).
Networked Communications Elective:
- Protocol Description
- You MAY NOT ASSUME that the message is limited to ASCII characters. Each byte in the message may take any value from 0 to 255 inclusive
- Bench and Computer Arrangements:
- Each team is assigned half of a long bench and half of a short bench, in EE101 or EE102, all in-line across the room.
- This means that you will have access to 3 lab computers only. These three computers are all client computers for assessment purposes.
- The server itself does not require its own computer. Instead, each group will get a shell account on a separate Linux machine (located elsewhere) from which you run the server.
- Access details will be provided in the lab and access will generally be limited to laboratory hours.
- For maximum productivity, we suggest that at least one student in each team also brings laptop to the laboratory. While there are no spare network ports, the Uniwide wireless network will be sufficient for productive collaboration.
- The lab computers in EE101 and EE102 can only be booted into Windows, but a Fedora core Linux platform is provided via a virtual machine (VMware)
- You should find that you have admin access on the Linux virtual machine, so you can install additional applications, such as IDE's if you prefer.
- The lab computers also have Microsoft Visual Studio installed, so you can choose to develop your solution in Linux or Windows, or even a combination of both.
- Running the server
- As mentioned, the server is to be run on a separate machine, on which you will be given a shell account.
- The idea is that you should run the server yourself, which allows you to choose parameter settings that may help you in developing your solution.
- The server should appear in /usr/local/bin/4123_server. You can execute it, but you cannot copy the file.
- For the moment, at least, all of the server access accounts run on the same platform, with a single IP address, but each team should specify a different port number when running the server. You will be assigned a port number in the lab that does not collide with the port number of other teams.
- For usage statements, execute "4123_server -u" or "4123_client -u". The "-unordered" switch may be used during performance testing. You may find the "-multi_client_hosts" switch useful for your own testing and debugging.
- When the server is run with default settings, the performance target is X = 300 chars/s. However, we reserve the right to run the server with different settings and evaluate your performance with an appropriately mapped value for X.
"Standard" Electronic Components
The following electronic components will be available in the laboratories from Week 1.
- Analog IC's:
The following additional electronic components will be available in the Laboratories from Week 2
The following additional electronic components will be available in the Laboratories from Week 5
The following additional electronic components will be available in the Laboratories from Week 7
- You may find it helpful to print out copies of the relevant component data sheets and bring them to your laboratory sessions.
- New components must be obtained from the lab demonstrator who will mark down the components you have received on a class record.
- Used components are to be returned to the lab demonstrator who will keep them in separate containers from the new components.
- If the supply of new components runs out, you may need to work with previously used components.
- You may take your populated breadboard out of laboratories (at the end), together with components that you think you will need in the next laboratory.
- However, you must bring your breadboard UNPOPULATED to the next laboratory (unless instructed otherwise) and also bring back the components you have used.
Last Updated: 9 May 2017
Prof. D. S. Taubman