Part I EL/EEE Laboratory Whiteboard chat for the Raspberry Pi P20- 1

Whiteboard chat for the Raspberry Pi
This project accounts for 30% of your final mark.

By the end of this project you should have developed an interactive whiteboard
client/server that users can use to view pictures, shapes, etc., on two windows
when running on the same machine. This will involve implementing a suitable
GUI for the send and receive windows, devising a protocol to communicate
drawings between the two windows.

When you complete the project, you are expected to write a report which
explains your design, implementation and screenshots of your results as
detailed in Section 2 and Section 3 below and include clear/meaningful
comments in your code, and upload these by 4pm on 7 May 2021 here:

See a video of a potential solution
Part I EL/EEE Laboratory Whiteboard chat for the Raspberry Pi P20- 2


Preparation time : 45 hours

Items provided

Tools : None
Components : Raspberry Pi 3 Model B+ and 16GB Micro-SD card (from P6)
Equipment : HDMI capable monitor
Software : Same Raspbian image file as P6
Items to bring

• Essentials: A full list is available on the Laboratory website at
• Raspberry Pi
• Raspberry Pi SD card (kept from P6)
• Raspberry Pi power supply
• Raspberry Pi HDMI cable
• Raspberry Pi keyboard
• Raspberry Pi mouse
This project accounts for 30% of your final mark. You should spend up to 45 hours working on it.
Academic Integrity – If you undertake the project jointly with other students, it
is important that you acknowledge this fact in your report. Similarly, you may
want to use sources from the internet or books to help answer some of the
questions. Again, record any sources in your report.
Revision History
February 2021 Mohammed El-Hajjar Update the assessment
© Electronics and Computer Science, University of Southampton
Part I EL/EEE Laboratory Whiteboard chat for the Raspberry Pi P20- 3

1 Aims, Learning Outcomes and Outline
This project aims to:
• Develop confidence designing larger C++ applications which use multiple libraries.
• Develop an understanding of communication protocols and how the various layers of
network applications work.
• Get the opportunity to use advanced C++ features like abstract and template classes.
Having successfully completed the project, you will be able to:
• Design your own communication protocols/network-based applications.
• Use threads in C++ and use mutexes to make thread-safe collections.
The objective of this project is to design and develop an interactive whiteboard chat client/server
application, where users can use their Raspberry Pi to make two windows: one send window
that the user draws diagrams on and another receive window that displays the diagram coming
from the send window. You will do this by designing, developing and testing the application one
layer at a time, as detailed below.
The Qt5 tutorial at http://zetcode.com/gui/qt5/ and documentation at http://doc.qt.io/ will
again be useful. Documentation for the STL classes and collections can be viewed at
http://www.cplusplus.com/reference/. A good tutorial for the pthreads library (which you can
use to create threads that send and receive) can be found at
https://computing.llnl.gov/tutorials/pthreads/. You can also use Qthreads.

2 Background and design
2.1 Read up on threads and mutexes
You will need to use multiple threads in your client/server to respond to window events (the
main thread) as well as handling sending and receiving data. You should therefore:
• Read up on threads and the pthreads/qthreads library.
• Read about race conditions and how to use locks/mutexes to make a collection “thread-
2.2 Design your application
Your application will have a “send” window that allows the user to draw on it (by catching mouse
and/or keyboard events) and a “receive” window that will display drawings coming from the
other user as they are being drawn. This drawing must at least involve drawing line diagrams and
clearing the screen. To implement this functionality you must design several aspects (or layers)
of your application, and therefore must answer the following questions:

How will the send-window allow users to draw diagrams? How will it display
diagrams as they are being drawn, and how will it retain these diagrams so
that they don’t disappear when the window is repainted?
 How will you represent the drawing commands so that they can be sent to the other user whilst they are being drawn?
Part I EL/EEE Laboratory Whiteboard chat for the Raspberry Pi P20- 4

 How will you serialize these commands into packets to be sent from the send window?

How will you use threads to send and receive these packets, while the rest of
the application keeps running? How will you use mutexes to make any relevant
collections “thread-safe”?

How will you convert binary packets into a stream of 1’s and 0’s? How will you
transmit this stream in a reliable way? For example, you may need to signal
when a bit is ready to be read, and when the receive window has finished
reading the current bit.

How will you receive and buffer packets at the other end? How will you
deserialize them? How will you draw them on the receive window? How will
you retain the currently received diagram so that when the window is
repainted the diagram isn’t lost?
You are expected to write your answers to these questions in your reports. Hence, it is
suggested that your start your report by answering these questions clearly and based on your
own design.

3 Implementation
To start this project, connect up your Raspberry Pi (you can use your laptop/PC as described for
P6/P7), start Qt creator and open the “lab20” project”, which you can find on the Pi in
‘/home/pi/Documents/ELEC1204/P20’. In your application you will simply display in the receive-
window what is being drawn in the send-window. This will allow you to test your application one
layer at a time, until when all the layers are working. It is recommended to start with the
GUI/application layer and then move down to the physical layer, rather than the other way
around. This can be done using the following steps.
In your report, you can have similar sections titles as below, where you explain how you
implemented these and include screenshots for your implementation.
3.1 The GUI send and receive windows – 8 marks
Make a Qt application with two windows (or two parts of the same window), one send/local
window that the user draws on, and another receive/remote window that displays the diagram
coming from the other user. Implement various “drawing command” classes for the different
drawing actions you support (at least line drawing and screen clearing). Make your send window
respond to mouse/keyboard events, create these commands, and display them locally so that
they don’t disappear when the window is repainted. Pass these commands to the receive
window when they are created, and make the receive window display them, so that they don’t
disappear when it is repainted.
3.2 Serialize and deserialize drawing-commands – 5 marks
Write code that serializes (i.e., transforms into binary form like arrays of chars) these commands,
and deserializes them. Change the send and receive windows so that commands are serialized
and deserialized when passed from send to receive.
Part I EL/EEE Laboratory Whiteboard chat for the Raspberry Pi P20- 5

3.3 Implement send- and receive-threads – 7 marks
Implement send and receive threads, where the send thread takes serialized commands and will
send these, while the receive thread will read data and pass them to the receive window.
For now, just test this by passing serialized commands using a queue. You may want to
implement a thread-safe queue template class to do this.
3.4 Implement your communication protocol using booleans – 10 marks
Implement and test your bit-stream communication protocol, by toggling shared Boolean
variables, which are emulating the role of GPIO pins if you are communicating between two
different Raspberry Pis. Remember you need to think about how to signal when a bit is ready to
read, and when it has been read. You may need to use mutexes to avoid race conditions.
In your report, you are expected to explain how your communication protocol works, for
example detailing what signalling you are implementing between the send and receive
windows and how data is exchanged. In the report, you should illustrate your code using
pseudocodes or flowcharts.