javascript代写: MCD4290 Assignment 1: Morse Code receiver app

Aim

Assignment 1: Morse Code receiver app

MCD4290, Trimester 3, 2016

Due: Sunday November 20th, 11:59PM (local time) Worth: 10% of final mark

In some situations it is not practical or desirable to transmit information using radio communication such as WiFi or Bluetooth. It is still possible to communicate between devices using other techniques. In this assignment you will demonstrate receiving a message on your phone from another device using only the camera. This will be done by decoding Morse code signals generated from changing the colour of the screen on the transmitting device. This approach of sending message using light and Morse code is still in use today by the US Coast Guard and Navy. In fact, you will be creating this app for the special forces of the (fictional) nation of Qabros, a small island nation with a proud military tradition.

You will work with your team to write a mobile web app that decodes the phone’s camera image into a series of Morse code signals, and then decodes and displays these on the screen of the device. We will provide you with a web site that acts as the transmitter.

Close to the completion of this your team will also begin work on Presentation 1, which is designed to be worked on in parallel to Assignment 1.

Background

Morse code is a method of nonverbal communication that was developed in the early 1800s to send messages across the telegraph system. It encodes letters and symbols as sets of on-off sounds, clicks or pulses of light. This encoding makes Morse code more reliable than voice in situations like a storm or gust where verbal noises would be hard to make out, as well as allowing efficient long distance communication.

The key benefit of Morse code is that it can be encoded using nearly anything and doesn’t require any specific equipment, meaning that it could function during a blackout or in a serious network failure.

Morse code characters are encoded as either a short “on” signal (dot . ), a long “on” signal (dash _ ), or a series of these dots and dashes; the more commonly used letters were designed to have shorter encodings (such as the letter “e” which is a single dot).

Some examples are the letters O ( _ _ _ ) and S ( . . . ) which together form the well-known SOS distress call ( . . . _ _ _ . . . ). Due to the nature of the limited options and the need to

keep common letters as short as possible, there can be some ambiguity of letters, for example, we mentioned that an e is a single dot and an s is three dots, so how do we tell the difference between three e’s and a single s ?

In order to handle this issue, Morse code includes gaps between individual dots and dashes. It includes longer gaps between letters and even longer gaps still between words. The time taken for all of these is dependant on the time for one dot (which is called the d ot duration and is also referred to as the ‘ time unit’ for the whole system).

● ● ●

● ●

a dot or short-on takes one time unit (the dot duration itself)
a dash or long-on takes three time units (three dot durations)
gap between elements (ex. between two dots, a dot and a dash or two dashes) is one time unit
gap betw een letters (ex. to distinguish between one s or three e’s) is three time units
gap between words is seven time units long

While there are many standards for Morse Code, the most commonly recognised is the ITU (International Telecommunication Union) standard which we will be following as much as possible. The standard can be found here: http://www.itu.int/dms_pubrec/itu-r/rec/m/R-REC-M.1677-1-200910-I!!PDF-E.pdf

A Morse code reference table is given below.

What you are provided with

You are given a skeleton code which can be found in the resources folder on the MCD4290 moodle site, in the assignment 1 area.

This skeleton code initialises the camera, displays the live camera image on the screen and calls your code with image data during every time unit. This web app has a single view with the camera image, a button labelled “Restart” (ID: r estartButton ) and message field (ID: messageField ) for you to display the decoded message in.

Every time the skeleton code takes a picture, it will trigger one of y our functions and pass through the image data. It will trigger a function called d ecodeCameraImage() which is where you will write most of your code. This function will decide the colour of the image and act upon the result. The app will also display a red/blue circle next to the camera image which denotes whether an image was recognised as red or blue.

The app skeleton contains a file MorseCodeReceiver.js with the empty decodeCameraImage() function. This file is where you should write your solution. You don’t need to understand the other files in the app skeleton, but if you wish to you will find they are documented.

You will also be provided with a transmitter web app which will provide appropriate blue and red flashes of light to represent “on” and “off” signals respectively. (Ex. Blue = On, Red = Off) We suggest that the easiest way to use this is from a desktop computer.

What you need to do

We suggest you work together to implement the following functionality. This will be easiest if you complete one before moving onto the next.

1. Write code in the decodeCameraImage() function to look at the pixels comprising the image data and determine if the image is mostly blue (“on”) or red (“off”), see below for more information. This function should return the value t rue if the image is mostly blue and false if the image is mostly red. You can test this code by running the app and seeing if the displayed circle matches the predominant colour in the image.
2. Create a lookup table (a JavaScript object) that maps a series of Morse code dots and dashes (a string) into a character (another string). The purpose of this is that any sequence of dots and dashes can be immediately converted to the corresponding character. You should include all the characters in Morse Code reference table below.
3. Keep track of the number of immediately matching on-off states for prior images, so that when the state changes you can tell how many time units (calls to your function) that state lasted for, and hence which of the following states it was:

1. On for 1–2 time units
2. On for ≥ 3 time units
3. Off for 1–2 time units
4. Off for 3–6 time units
5. Off for ≥ 7 time units

= Dot
= Dash
= Inter-element space = Inter-character space = Inter-word space

We use these time unit ranges rather than exact values since we can’t (and shouldn’t need to) depend on the transmitter to show a coloured screen for an exact period of time. This is similar to Morse Code sent by humans — a dot or a dash will not always be the exact same length, but this is not a problem so long as they are consistently distinguishable from each other.

4. Keep track of dots and dashes until a inter-character or inter-word space is detected. When one is, consult your lookup table to convert the series of dots and dashes to a character. Append that character to the existing message string and show it in the message field.
5. Create an ‘onclick’ function which is called when the Restart button is clicked. This function should
   1. Clears the message field
   2. Clear any temporary variables that represent state, i.e., get the app ready to

      begin reading a completely new message.

6. When you detect an end-of-transmission symbol, instead of adding anything to the

   message you should call the m essageFinished() function to let the app know the whole message has been received. The displayed circle will change to green.

The following example demonstrates the signals that would be sent for the beginning of a short message “A BA…”. You can assume that your decodeCameraImage() function will be

called once during each time unit period.

Morse Code reference table

This table lists the symbols (and their corresponding Morse Code representation) that you should include for your app; this list follows the ITU standard.

* Note: these four symbols are not part of the official ITU standard but should be included in your app regardless

Image data format

The image data passed from the skeleton code to your function is an array of numbers. Every element in the array is a number representing a colour for a given pixel in the order red, green, blue, alpha. Pixel value range between 0 and 255; for the colours the number represents how much of that colour is in that pixel (255 being the most, 0 being none at all) for instance violet would be 127(red), 0(green), 255(blue) which we would treat as blue. Alpha represents the opacity of the pixel, so 0 means completely transparent and 255 would be completely opaque.

Every set of four consecutive elements is a particular pixel (the red, green, blue and alpha components)

For example the array value for the first four pixels of an image are shown below:

So accessing Image[0] would give the amount of red in the first pixel, Image[2] would give the amount of blue in the first pixel (in this case 255) and Image[4] would give the amount of red in the second pixel.

You are using this to determine the overall colour of the image, so you only need to tell if the image is mostly ON (blue) or mostly OFF (red), this way your app will be able to handle when the image is not a single solid colour.

Note: in the image data your code receives, the alpha of every pixel will be 255. Hence you can ignore the value, although you must still account for the space it occupies in the image data array.

Testing the app

Upload your code to the MCD4290 server using the assignment upload page. It will open the uploaded app, the address of which you can then visit on our team phone. The uploader can be found here:

      https://mcd4290.mcgroup.monash.edu/uploader/

You will test your app by pointing the camera at a screen running the transmitter web page, available here:

https://mcd4290.mcgroup.monash.edu/apps/morsetransmitter

On this webpage you can either enter some text or use the default test message and the web-page will convert this to a series of blue and red flashes. You should test your app using several different sentences until you are convinced that it works correctly.

Submission

Your team should submit their final version of the application online via Moodle; You must submit the following:

● Group Assignment cover sheet (http://moodle.vle.monash.edu/mod/resource/view.php?id=2885791)

● MorseCodeReceiver.js
These should be zipped up with the team name as the filename, e.g., “ Team014.zip ”. The submission should be uploaded by the team leader and must be finalised by Sunday November 20th, 11:59PM (local time)

You also need to individually complete the ● CATME peer assessment survey

as described below.

Your assignment will be assessed based on the version of “M orseCodeReceiver.js ” file you submit via Moodle. Before submission check your code still works with the original app skeleton, in case you may have modified your copy of any of those other files. We will run it with the original app skeleton and test it on your team smartphone. We will use the same phones when marking your assignments.

Late submissions

We do not accept late submissions without special consideration. Such special consideration applications should be made to the unit email address with a completed form and supporting documentation within two business days of the assignment deadline.

http://www.infotech.monash.edu.au/resources/student/equity/special-consideration.html

Peer Assessment

You are expected to work together as a team on this assignment and contribute roughly equal amounts of work. Peer assessment will be conducted via the CATME online system. You will receive email reminders at the appropriate time.

Not completing the CATME peer assessment component may result in a score of zero for the assignment.

Do:

• ●  Give your teammates accurate and honest feedback for improvement
• ●  Leave a short comment at the end of the survey to justify your rating
• ●  If there are issues/problems, raise them with your team early
• ●  Contact your demonstrators if the problems cannot be solved amongst yourselves

  Do NOT:

• ●  Opt out of this process or give each person the same rating
• ●  Make an agreement amongst your team to give the same range of mark

  Marking criteria

  Assessment criteria:

• ●  Whether the app functionality satisfies the assignment specification
• ●  Quality of app source code, including structure and documentation

  You will be marked as a group, however your individual marks will be subject to peer review moderation based on CATME feedback and scaling factors.

  Where to get help

  You can ask questions about the assignment on the General Discussion Forum on the unit’s Moodle page. This is the preferred venue for assignment clarification-type questions. You should check this forum (and the News forum) regularly, as the responses of the teaching staff are “official” and can constitute amendments or additions to the assignment specification. Before asking for a clarification, please look at the forum.