diff --git a/README.md b/README.md
index e1a747f0a98aa46e05d282e6db7433bdca348099..fc53d75dcb3285de1545563ac3d7aedfba859a8e 100644
--- a/README.md
+++ b/README.md
@@ -1,92 +1,65 @@
-# worksheet 3 IoT
+# worksheet 3 IoT - Ryan Morgan (20014885)
-User Datagram Protocol (UDP)
+Implementation in **udp.py**
-## Getting started
+## What's been completed:
+**Task 1** – Implemented a function that receives and decodes the welcome message from the UDP server. Data is picked out from the received packet and displayed in a specified format. Pieces of data is picked out using python slicing. Data such as: source port, destination port, data length, checksum, and payload.
-To make it easy for you to get started with GitLab, here's a list of recommended next steps.
+
+
+**Task 2** – Implemented a function that calculates the checksum for a UDP packet. The checksum is required to check if a packet is valid. This function starts by constructing a UDP packet to process and pre-processes the data if the length of the packet is uneven. It then loops through every two bytes in the packet and adds them together, which is then added onto the checksum for each loop iteration. Once all the bytes in the packet is processed, the checksum is bit shifted to the right by 16 and the one’s compliment of the checksum is calculated. The checksum is then returned for packet validation.
-Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
+
+
+**Task 3** – Implemented an infinite loop, which sends and a UDP packet with a payload of ‘1111’ and receives and the time back from the server. There’s a one second delay in each loop so a packet is sent/received every one second. The received packet is decoded and displayed.
-## Add your files
+
+
-- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
-- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
+## How to run code:
-```
-cd existing_repo
-git remote add origin https://gitlab.uwe.ac.uk/rj3-morgan/worksheet-3-iot.git
-git branch -M main
-git push -uf origin main
-```
+Make sure the python environment is activated (Example command: “source /home/ryan5.morgan/projects/iot_env/bin/activate”). Then just run the python file “udp.py” and it should work on its own (Example command: “python -u "/home/ryan5.morgan/projects/worksheet3/udp.py"”)
-## Integrate with your tools
+
-- [ ] [Set up project integrations](https://gitlab.uwe.ac.uk/rj3-morgan/worksheet-3-iot/-/settings/integrations)
+I did not have to make unit tests for my implementation for worksheet 3. This is because the server essentially already tests the implementation. For each loop, the server would send back the correct packet, and send the wrong packet in the loop after.
-## Collaborate with your team
+
-- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
-- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
-- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
-- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
-- [ ] [Automatically merge when pipeline succeeds](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
+
-## Test and Deploy
+### Functions in udp.py:
+#### udp()
+This the main part of functionality for udp.py. It begins by connecting to the server. Then it sends, receive, and display packets to/from the server. Sending, receiving, and displaying packets are mainly done by calling other implemented functions such as display_packet, send_packet and recv_and_decode_packet. There are no parameters for this function. All that is needed is that the function is run with asyncio.
-Use the built-in continuous integration in GitLab.
+> asyncio.run(udp())
-- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
-- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing(SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
-- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
-- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
-- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
+Asyncio.run creates an event loop, then waits for the function to finish running, then closes the event loop. This is used to asynchronous tasks.
-***
+#### display_packet()
+This function is for displaying the contents of a packet. The packet would be passed into the function as an argument.
-# Editing this README
+> E.g. display_packet(“\n\x00*\x00!\x00\xcb;Welcome to IoT UDP Server”)).
-When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thank you to [makeareadme.com](https://www.makeareadme.com/) for this template.
+Each part of the packet is sliced up (using python slices) and decoded to bytes for it to be printed/displayed.
-## Suggestions for a good README
-Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
+#### send_packet()
+This function constructs a UDP packet and sends it to the server. A UDP packet is made by getting all the parts of a packet in bytes and adding them together in a specific order (e.g. destination port + source port + length + checksum + message). The length is calculated from the length of a message. Once a packet is made, the bytes are encoded using the base64 library and sent off to the server using the websocket library. The websocket, destination port, source port, and message are passed into the function as parameters.
+> E.g. send_packet(websocket, dest_port, source_port, message))
-## Name
-Choose a self-explaining name for your project.
+#### recv_and_decode_packet()
+This function is for receiving a packet from the server,
+> packet = await websocket.recv()
-## Description
-Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
+displaying the encoded packet,
+> print(f"Base64: {packet}")
-## Badges
-On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
+and decoding it from base64 using the base64 library.
+> base64.b64decode(packet)
-## Visuals
-Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.
+The websocket is the only argument needed for this function.
+> recv_and_decode_packet(websocket)
-## Installation
-Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection.
-
-## Usage
-Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README.
-
-## Support
-Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc.
-
-## Roadmap
-If you have ideas for releases in the future, it is a good idea to list them in the README.
-
-## Contributing
-State if you are open to contributions and what your requirements are for accepting them.
-
-For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self.
-
-You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.
-
-## Authors and acknowledgment
-Show your appreciation to those who have contributed to the project.
-
-## License
-For open source projects, say how it is licensed.
-
-## Project status
-If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.
+#### compute_checksum()
+This function computes the checksum for a packet. It starts by constructing a packet (not with proper values because it’s not being sent to the server). the packet pre-processed in case the length of the packet is odd (uneven). If the length is odd, then add a 0 byte to the packet and increase the length by 1. The function then loops through each 2 bytes in the packet and adds them together. For each of the 2 bytes added, it is added onto the checksum. Finally, the final checksum is bit shifted by 16 bits and is converted to one’s compliment. Then the function can output the result The source port, destination port and payload are passed into this function as parameters.
+> E.g. compute_checksum(source, dest, payload)
diff --git a/README_images/howto_outputcorrect.png b/README_images/howto_outputcorrect.png
new file mode 100644
index 0000000000000000000000000000000000000000..f0c65aea8b7ec24551a1e3ea083522e4285232a5
Binary files /dev/null and b/README_images/howto_outputcorrect.png differ
diff --git a/README_images/howto_outputincorrect.png b/README_images/howto_outputincorrect.png
new file mode 100644
index 0000000000000000000000000000000000000000..37a762f8f0971980797816ebaf92da75c0f839c0
Binary files /dev/null and b/README_images/howto_outputincorrect.png differ
diff --git a/README_images/howto_packet.png b/README_images/howto_packet.png
new file mode 100644
index 0000000000000000000000000000000000000000..0e8284a614761462ee0192b5bb873c18eda7f26b
Binary files /dev/null and b/README_images/howto_packet.png differ
diff --git a/README_images/task1packet.png b/README_images/task1packet.png
new file mode 100644
index 0000000000000000000000000000000000000000..a2e75de3843fee8b04a75bef3202d54cbb162daa
Binary files /dev/null and b/README_images/task1packet.png differ
diff --git a/README_images/task2checksum.png b/README_images/task2checksum.png
new file mode 100644
index 0000000000000000000000000000000000000000..54cb57edcb2dcb1c0ae2685d1a2e42904978ab33
Binary files /dev/null and b/README_images/task2checksum.png differ
diff --git a/README_images/task3loop.png b/README_images/task3loop.png
new file mode 100644
index 0000000000000000000000000000000000000000..e6e5a479480e588594cab37bc5b3cc9e44126b97
Binary files /dev/null and b/README_images/task3loop.png differ
diff --git a/README_images/task3output.png b/README_images/task3output.png
new file mode 100644
index 0000000000000000000000000000000000000000..1da56f0d923064af28dba44fc4f2b13cc6ec0247
Binary files /dev/null and b/README_images/task3output.png differ