Gold Crest Award

1. GOLD CREST AWARD
2016-17
QINETIQ PROJECT
Saamiah Zaveri
BY

3. 1.1.1 Introduction
The problem presented was a potential scenario, in which there is an attack on a Forward Operation
Base (FOB) and the means of communication are damaged or destroyed. Therefore, an emergency
communication system would be required to communicate with all the people on the base to provide
instructions and updates on what is happening. The customer provided some requirements for the
solution namely: The solution must be portable, it must cost £300 or less for its development and
the information must reach an area of approximately 200 sq. m
1.1.2 Problem Research Questions
Before brainstorming ideas for our solution, we decided to make a few more inferences into the
scope of the problem. We posed the following questions to each other and to the customer:
• Where is the FOB located?
• There is no specific locations but if the product can function in a lot of environ ments
then it is much better
• We then inferred that the solution must be durable
• Does it have to be self sufficient?
• Yes, therefore battery powered
• Does it have to be hidden?
• Not too worried about this factor
1.1.3 Gantt Chart
After interpreting the problem, the team created a Gantt Chart in order to organise the project into
a sections and assigning time to each section. This would hopefully make the project more efficient
and more importantly keep the group on a schedule to produce a working prototype.

4. -
Project Gantt Chart:

5. 1.2 Idea Brainstorming
From the first requirement, the team then inferred that a wired connection would not be possible as
a wired portable device would not be very portable (and inefficient given that the solution is already
battery powered), and in the case where cables get damaged during the chaos the solution would
break down.
From this we came up with 2 plausible ideas for a solution:
• 1.2.1 Walkie Talkies
Advantages:
• Extremely portable and easy to carry
• Can have a long battery life if powerful batteries (e.g. Lithium-ion batteries) are used
• Fast interaction across long distances
Disadvantages:
• The powerful battery can overheat and explode if there is too much internal heat
• Only one person can talk on the same channel at a time
• Between only two walkie talkies, difficult to communicate with the entire base
• Easy to intercept
• Expensive to supply everyone on the base with a walkie talkie, and difficult to
account for visitors on the base
From evaluating the advantages and disadvantages, we decided that walkie talkies would not be the
best solution, primarily concerning the fact that it is not possible to communicate with the entire
base simultaneously.

6. • 1.2.2 App and Speakers
After turning down the walkie talkie solution, we still explored the idea of a portable device everyone
in the base could have, without the logistical hassle of supplying everyone with a walkie talkie. We
then asked the customer if we may assume that everyone on the base has a smartphone, bringing our
customer restrictions to:
• The solution must be portable
• The prototype must cost £300 or less for its development
• The information must reach a radius of approximately 200m
• Assume everyone on the base has a smartphone
The group decided to explore the possibility of an app that everyone on the base would have to talk to
each other via Bluetooth (as Bluetooth is much more secure than other wireless methods), but imme-
diately ran into the same obstacles as with the walkie talkie idea namely:
• Everyone can’t speak at the same time
• High interference as people will be trying to send as many messages as possible in
an emergency situation
• Limited number of devices a smartphone can connect to via Bluetooth
The group then came up with idea to write an app similar to JBL Connect (a phone application that
allows the user of JBL speakers to control different settings remotely), where we would create blue-
tooth speakers to put all around the base as well as an app for the smartphones to connect to. We
then considered how exactly messages would be transmitted i.e. would the messages be spoken live
and simply played out loud simultaneously by the speakers or would the app have pre-recorded mes-
sages built in? We compared the solutions shown below:
Live Messages Pre-recorded messages
Situation-specific messages may be transmitted in the event the emer-
gency may be unusual in nature, which is difficult to predict when using
pre-recorded messages
The members of the base will be able to identify the person speaking (i.e.
as an authoritative figure) thus making the instructions easier to follow
and obey
Does not require the transmitting
power that live messages require
Less likely to be subject to unclarity
due to bad signals (e.g. during a
storm)

7. We also evaluated the feasibility of the two methods, as the team was limited to £300. Making a high
quality transmitter/receiver would have been a strain on the funds we had for the solution. The
team’s programming experience was also a limiting factor, decreasing the likelihood of a fully
functioning live message prototype as it would be difficult to program.
On the speaker development part of this solution, we went back to the customer to enquire the
exact location of the FOB in question. He replied that he would like the solution to be adaptable as
possible, therefore requiring the speaker to be extremely durable and resistant to water, dust,
extreme heat, and shock.
We also explored the idea of adding a solar panel to the speaker in the event the carrier has no
access to electricity for extended periods of time, however it would be a waste of resources if the
FOB was not in an extremely sunny place to recharge the undoubtedly large battery we were plan-
ning to use.
The problems with this solution, however, include:
• Speakers will need to be on all the time, therefore will require a lot of energy
• Everyone cannot transmit messages (even if pre-recorded) at the same time
• Need a way to connect the speakers
• When the speakers communicate you have can't more than one message as there will be
interference
Despite the disadvantages, we decided to pursue the idea for more research into its feasibility and
potential solutions to overcome the disadvantages.

8. 1.3 Final Idea Specification
After a bit of research, we introduced a Raspberry Pi 3 into the solution, as a PC would be beneficial
to communicate between the speaker and the app. For further research, we divided the solution into
5 aspects:
• Connectivity
• Environment and Usage
• Power
• Performance Requirements
• Software Requirements
• 1.3.1 Connectivity
As aforementioned, we researched heavily into alternatives to Bluetooth as the transmission method
for the solution. We narrowed the solutions down to four plausible methods and compared them as
shown below:
System of
communication
Advantages Disadvantages
Bluetooth Rate of transmission: 25 Mbits/s.
Handles both data and voice
transmissions simultaneously.
Range of radius 100 m (can be larger but depends
on the manufacturer’s implementations).
Can connect few devices (maximum 7).
Cannot penetrate walls.
Local Area Network
(LAN)
Range of radius 1 km.
Can connect numerous devices (no
definite limit).
Penetrates such physical objects as
walls and floors.
Maximum rate of transmission: 100
Mbits/s.
Average is 16 Mbits/s.
Wi-Fi Multiple overlapping access points offer
coverage several km in radius.
Can connect numerous devices (no
definite limit).
Rate of transmission: 54 Mbits/s.
Range of radius 90 m (single hotspot).
Does not penetrate physical objects very well.
Free space optical Range of radius up to 3 km.
Immune to electromagnetic
interference.
Rate of transmission: 10 Gbits/s.
Low penetration of such weather conditions as
rain, fog, snow, smog.
Vulnerable to atmospheric absorption.
No direct communication with mobile devices.

9. The table shows that the most advantageous form of communication is Bluetooth due to it having the
largest number of advantages that are necessary for this purpose. At this point, we decided to use a
Bluetooth LAN transmission to communicate between the speakers and the app would also connect
via Bluetooth to the Raspberry Pi. However, later during the development stage, we encountered
issues with coding in Java for a bluetooth connection, as there was little to no online guidance. As the
Java team was completely new to coding Java, we decided to switch to a Wireless LAN connection
rather than Bluetooth as we could access a lot of online resources to aid us during the development
process.
• 1.3.2 Environment and Usage
The speakers would be placed in different bases that are located in different environments. To with-
stand the different meteorological conditions of that environment and regular usage, the speakers
will have to be made of materials packing as many useful properties as possible.
Firstly the speaker may include rubber padding along the outside edges and corners to decrease
chances of breaking due to shocks and impacts. These rubber paddings are useful as speaker that
may be placed in a relatively high location and may fall down.
Secondly the speaker may need to include dust protection covers. This is to avoid any components
getting ruined (especially the speaker cone or magnets) from sand and small dust particles in desert
environments. Furthermore, water protection should be incorporated to protect the system from
rain or moisture in the air. We compared three potential materials for the speaker outer casing in the
table below:
Example of rubber shock protection that keeps it waterproof as well

10. Material Properties Advantages Disadvantages
Carbon fibre High stiffness
High tensile
strength
High temperature
tolerance
Low thermal
expansion
Higher strength to weight ratio than
steel or aluminium.
Can be customized to a large extent
in the manufacturing process
Very high price(10-12$ per pound)
Not elastic- snaps instead of
bending
Conductive (relatively high
resistivity)
Urea-
Formaldehyde
High tensile
strength
Low water
absorption
High surface
hardness
One of the
toughest plastics
High operating temperatures
Non heat conductive
High dimensional stability
Relatively light
Relatively low price (300$ per tonne)
Relatively brittle
Lower HDT than carbon fibre
Carbon steel Brittle
Hard
Carbon content can be altered based
on preference and requirements
Can be heat treated to increase
toughness
Compared to other metals one of the
least heat conductive
Brittle
Mid price range (500$ per tonne)
Conducts more heat than carbon
fibre or urea-formaldehyde
From our comparison, the speakers will be made out of urea-formaldehyde as it satisfies most of
the required points and furthermore it has the lowest price which is something to consider when
the solution incorporates more than one unit.
1.3.3 Power
Power supply is one of the most important bit of our project. A device needs constant and reliable
power source to keep it work well and stable. A direct charger to the device is needed and also a
battery is very necessary as well. We considered a few things as the battery has a large impact on
the speaker’s portability (in terms of size and mass), as well as its lifespan. The criteria were as
follows:
• The battery itself needs to be light enough for a single person to carry
• It needs to maintain its battery life when it is not in use i.e. must be rechargeable
• Have the ability to work in extreme temperatures
• Provide enough power the speaker and communication apparatus for long periods of time
We compared four types of batteries that are common on the market: Nickel-Cadmium Batteries,
Nickel-Metal Hydride Batteries, Lead-acid Batteries and Lithium-Ion Batteries. From our overall
comparison the Lithium-Ion Battery was a much better choice.

11. Power
supply
Environment
al suitability
Chargin
g
speed
Cost Environment
al Protection
Service
life
Power
to size
ratio
Unique
defects
Nickel-
Cadmiu
m
Batteries Very
strong
Extremely
well
extremel
y quick
Pretty
cheap
Very toxic.
Average
life is 500
times of
recharging
. Pretty
short.
Pretty
low.
Can’t
store
much
electricit
y
Charge when
there’s still
power left
inside will
decrease the
battery life
Nickel–
Metal
Hydride
Batteries
Nice
but not
very
strong
Pretty bad
The
speed is
good.
But not
very
quick
Bit
expensiv
e
Fully
environmental
friendly
5000
times of
recharging
. Very
good
Decent
ratio.
30%
more
than
Nickel-
Cadmiu
m
battery
It will
naturally lose
some power
installed if
you don’t use
it or charge it
for some time
Lead-
acid
Batteries
Very
powerfu
l
Very well
Normal.
Slower
than the
other
three
Very
cheap
Decent. It’s a
bit toxic
Soso. Two
to three
years of
service lif
e
Low
Requires
frequent
maintainabilit
y
Lithium
Batteries
Very
powerfu
l and
stable
Very good Decent
speed
Cheap Very clean
Over six
years. The
longest
Very
high.
The device’s
internal
design needs
to be good.
Or there will
be risk of
explosion. i
Advantages:
• Produces a very powerful and stable power supply
• Functions between -20 and 60 degrees celsius
• High charging speed and capacity
• Reasonably priced
• Small and light
Disadvantages:
• Must be protected well by the outer case. The battery is very fragile. Any collision could lead
to a change in shape will make it very dangerous to use
• Even though it works under -20~60 degrees the temperature will affect its output slightly.
However, the Lithium-Ion Battery could supply over 60W of voltage and more than 5A of current to
the speaker, which is why we chose it for our power supply.

12. 1.3.4 Performance Requirements
In order to produce the best quality speaker we could whilst reducing the unit cost of the speakers for
the customer, we created some performance requirements that match the customer requirements to
choose the driver for the speaker.
• Make each speaker as loud as possible (up to our funds cap)
o To maximise the number of people receiving the information per unit speaker.
• We also wanted to reduce interference and white noise as much as possible
• A light driver that fulfills the other two requirements
We compared two drivers from recommended brands (from the DT department technician) in the
table below
Product Image Brand Cost Maximal
Output (Watts)
Frequency
Range
Weight
Sovereign 6-
100
Fane £32.78 100 60HZ -
10kHZ
1.65kg
Celestion 8
Inch Driver
Celestion £29.99 100 70HZ-6kHZ 2.3kg
We chose the top driver, the Sovereign 6-100 as the better option between the two drivers because
despite it being more expensive, it has more advantages over the Celestion 8 Inch as follows:
• Firstly, the end product has to be portable and therefore the weight of the components play an
important role as the lighter the end product the easier it is in terms of portability
• Secondly, we wanted a driver which was mid range for frequency, as this was the most effi-
cient because no energy is wasted with bass or higher frequency sounds which may not be heard by
the human ear.

13. 1.3.5 Software Requirements
The app needed to be easy to use and quick in its communication with the Raspberry Pi and the
speaker.
For the app development, we chose Java to program for Android as it is an easier language to learn
and practice with (due to high number of online tutorials) than Swift for iOS as our team is relatively
inexperienced in programming. Java also has strong cross-platform benefits.
Final Idea Diagram and Theory
How the solution worked as of this point in our development:
1)The user opens the application on the phone and selects the pre-recorded message that needs to
be sent
2)The signal from the message is sent through Wi-fi Lan to the antenna in the speaker
3)The antenna in the speaker receives the signal and transmits it electronically to the computer
4)The computer/amplifier processes the signal and turns it from digital to analogue audio so that it
can be played by the cone
5)The signal moves the cone in order to reproduce the requested message
6)The sound produced is then amplified to the rest of the base in order to transmit the message
7/8 )To power the phone and speaker, the batteries have to provide enough power. These will be
portable and can be connected to mains supply if they need to be charged but they have the option to
run independently.

14. 2 Research and Development
2.1 Research
2.1.1 Sound and hardware
The speaker system to be developed needed to have a wattage that would be enough in order to
produce a sound audible from a certain distance (This is helpful as it minimises the amount of units
that have to be placed around the FOB). In our research we decided that the system had to have a
total power of 60 watts.
The initial idea was to use two full range drivers and taking advantage of both the channels that are
offered and included in the amplifier (left channel and right channel). This could provide double the
sound with the same power as the amplifier can only consume a certain amount of power.
Through some research we also found out that we did not require the usage of the full spectrum of
sound as the human voice has a frequency of 300 to 3400 hertz. This would allow the cutting out of
frequencies ranging from 20 to 300/400 hertz. These frequencies require the most power to be pro-
duced as they are extremely low and by cutting them off, we could increase battery life.
The method required to cut out these specific frequencies is to install a device called a passive
crossover. This device splits the signal into two separate outputs; each output then cuts out differ-
ent frequencies of sounds so that high frequencies can be sent to the subwoofer and low frequen-
cies can be sent to the tweeters/ mid-range drivers. The crossover can be modified to filter out only
low frequencies.

15. -Diagram of individual crossover
-Diagram of speaker system

16. 2.1.2 Power
There are four types of batteries on the market and very approachable: Nickel-Cadmium Batteries,
Nickel-Metal Hydride Batteries, Lead-acid Batteries and Lithium Batteries. Due to my overall com-
parison the Lithium Battery is a much better choice. So I made a table to compare their performance.
Nickel-Cadmium Nickel–Metal Hydride Lead-acid Lithium
Power
√
Sustainability
×
Charging speed
√ √ × √
Environment
× √ × √
Cost
√ ×
Product service life and maintenance
Weight × √ ×
Weight
√ × √
Size to power ratio
× √ × √
From the comparison we could see the Lithium battery is the best one. It can produce very powerful
voltage and more than 5A current to the device. So we don’t need to concern the power consumption
of the device. .

17. Advantages:
· Produce a very powerful and stable power supply
· Function between -20~60 degrees
· Nice charging speed and capacity
· Reasonably priced
· Small and light
Disadvantages:
· Must be protected well by the outer case. The battery is very fragile. Any collision could lead
to a change in shape will make it very dangerous to use
· Even though it works under -20~60 degrees the temperature will affect its output slightly.
For a sensitive device, this is not a good news
· The way to increase total capacity and maintain low cost is to connect dozens of small
batteries. This takes no addition room but will increase the possibility of not functioning.
2.2 Development
One of the issues the group in general ran into was keeping up with our Gantt Chart, and as a result,
we were unable to produce a fully working prototype involving the app and playing test messages on
the speaker via the Pi. However, we were able to establish a connection between an Android phone
and a Raspberry Pi using PuTTy.
In order to make transmission of auditory information possible, the information should be transmit-
ted as digital signals first, to then be transformed into analogue signals to be broadcast around the
base.
In our prototype, we planned to send a pre-recorded message to the raspberry pi, which would then
send it to the speaker and make it broadcast the message.
First, an app had to be designed to serve the purpose of being a practical and functional tool to send
messages with the press of a button.
Next, a connection to the raspberry pi had to be established. For this, a code implementing a connec-
tion to Bluetooth (or Wi-Fi) had to be created, for which the theory is given below.

18. 2.2.1 Theory
The speaker and the user would work similarly to a server and a client, with the user’s phone con-
necting to the raspberry pi as a client would a server as illustrated below:
The phone would connect to the Raspberry Pi via Secure Shell (SSH) through the app developed. The
Raspberry Pi would have all the pre-recorded messages saved to its SSD, and after the phone con-
nects to the Pi through the app, it would simply send specific requests that
have been pre-coded to correspond to accessing and playing specific messages through the drivers.

19. 2.2.2 App development
The first task was to create an app and design its interface so that it is easy to use and quick to trans-
mit messages through it.
To start with, we created an app with several buttons that display a message when clicked. The code
for the creation of buttons on an Android studio virtual device is pictured below:

20. After creating the XML layout for the main body of the app, we created the server-client system for
the phone to connect to the Pi (the server side comes under the Raspberry Pi section, whilst the
client code is shown below)
XML Layout:

22. The two boxes represent the server address and port respectively, where the app would attempt to
setup a socket through the selected address and port (which would be manually input for the proto-
type, but fixed for the final product if taken further).
Java for Socket:

23. In the onCreate method, we created the three buttons on the launch activity of the app (the Con-
nect, Clear, and Continue buttons). The user would connect to the Raspberry Pi using the Connect
button, then after connecting press the Continue button to proceed to the second activity of the
app

24. This establishes the socket between the Client and the Server.
The Continue button then takes the user to the MainActivity, where the buttons may be pressed to
communicate with the Raspberry Pi.
Ideally, the sample code above should cause the server program on the Raspberry Pi to print the
strings (in green), however, the team ran into problems when calling the ActionListener class and
actionPerformed method. We were also unable to understand the Hashmap class, which would have
enabled us to link specific buttons with integer values, which can then be passed on to the server.
Research into the issue took a substantial amount of time and hindered us from adapting completing
the Java app (partly due to our inexperience with Java as a whole). Given more time, we would have
done a lot more research and spent more time learning and doing example programs before attempt-
ing to complete the program.

25. 2.2.3 Raspberry Pi
The main aim was to establish connection between the Raspberry Pi and an Android phone which
allows to send the signals to the mobile app as well as to make the phone read the signal/message
from the Raspberry Pi and perform a certain task.
The chronology of the development is as follows:
The team performed research into what the device would be and the types of connection we should
use. Alex Girichev and Saamiah researched into how Python works, and attempted to perform some
algorithms, such as assigning meaning to some code words e.g. 5 would equal fire alarm.
The first step was to set up a SSH connection between the computer (before testing the Android
phone itself) and the raspberry Pi by creating a WI – FI hotspot out of the Raspberry Pi. The aim was
that the computer would be the client (emulate the Android) and it would connect to the Raspberry Pi
(the serve). The team used PuTTy to establish the SSH connection between the laptop and the Rasp-
berry Pi.
Alex then researched into the best software program to run the music file on the Raspberry Pi, and
found a program called “Pi Musicbox”, however its installation was limited by school’s firewall. As an
alternative, we tried installing runeaudio on the computer, however did not work either.
As a workaround, Alex came up with the idea to try to install the app on my phone then install on the
computer, then transfer it onto the raspberry Pi using a flash stick. However, as with most of the
other development sections, we only managed to get as far as establishing an SSH connection
between the laptop and the Raspberry Pi via WiFi, which can be easily adapted to fit the incoming
WiFi connection from the Java app.

26. 2.2.4 CAD development
To draw out all of the components that we had to fit in a cabinet, the development of a CAD model was
necessary. Furthermore, this would have also automatically built an orthographic drawing necessary
for the manufacturing stage of the process.
The CAD model featured all of the components necessary including the battery, raspberry pi, anten-
na, amplifier/computer and the speaker cones (tweeters, mid-range drivers)
The picture shows all the components:
1. Raspberry Pi with antenna
2. Battery pack
3. Amplifier
4. Speaker
The Diagram includes a large amount of empty space. Firstly, the crossovers are missing and these
occupy a large amount of space inside the speaker. Also, the speaker with a large interior, the speak-
er will be padded with a substantial amount of soundproofing material which will help

27. This is the CAD model viewed from an angle
3 Conclusion and Reflection
In conclusion, even though the group was unable to complete a working prototype, we did make
valuable headway (in terms of research and development) into learning new programming languag-
es. From our tests with the Raspberry PI and PuTTy, our idea may well prove to work given more time
to fully pursue the project. We would use the time to further optimise the app (making it easier to
use, as speed is an important factor in emergency situations), as well as possibly build more than one
speaker and use more phones to fully test the limitations of the entire system if it were to be imple-
mented. Each and every one of the team members, however, gained valuable skills during the proj-
ect, some of which are outlined below:
Things I learned (Liza):
Throughout the project, I have had the chance to become more acquainted with the process of devel-
opment of an engineering project, namely a speaker for the military. Not only did I learn about the
main stages of it, but also how to work on it as a group and effectively contribute to the process. It
was not always easy to collaborate with people on this difficult task, but by abiding by deadlines and
meeting regularly, I believe that we were able to effectively carry out this process. Personally, I
learned a lot more than I knew before the project about the way a speaker is most effectively created
for various needs, and the way it should be programmed. I acquired a great deal of new programming
skills, especially in Java, which will help me in the future. Overall, this was a very interesting and
beneficial process for me, and I thoroughly enjoyed it.

28. Things I learned (James):
A never easy project for me and the team to design a military standard speaker with a reliable
encrypted communication system. First started in a different team and then switched to the only
team. I've learned how to work with lot of people in the group. This kind of quick switch made me
work better, since I’m always out of my comfort zone and help raise my efficiency. Providing possible
power supply solutions is my first mission. I learned a lot of electric powering knowledge from it.
After that I was assigned to the java developing group. Which is probably the hardest part of the
project. Even without significant results we managed to learn a lot of basic codings. Might be very
helpful in the future. I can also help the hardware side. Help with the development of raspberry pi. I
can use my hardware knowledge here to help. In short, this is a precious group corporate experience
for me.
Things I learned (Derrick):
It was quite the experience, working through the various stages of an engineering project as real
engineers would do. Aside from acquiring a variety new skills in programming (particularly in Java
and XML), I also gained leadership skills through my role as team leader. From coordinating the team
members to meet deadlines outlined in the group Gantt Chart to using new and efficient ways to
communicate and present ideas to each other and the Qinetiq team that helped us through the proj-
ect, the management skills gained through this project will undoubtedly help me in the future, partic-
ularly in the corporate world. All in all, it has been a pleasure working with Qinetiq as well as Mr
Stokes and most importantly the team on this project.
Things I learned (Valerio):
Throughout the entire project, I have had the chance to get an insight into the processes involved in
the development of a military product. By merging the two initial groups, I have had the chance to
interact and work with more people than expected. This has helped me take into consideration other
people’s opinions and ideas because during projects such as courseworks I usually prefer to restrict
myself and my ideas from others. It has boosted my confidence to work with people. In very few
occasions where Derrick was missing and I had to substitute in as project manager, I was unprepared
and had to act instantaneously. This helped me develop problem solving skills and gave me an idea of
what the role of leadership consists of.
From a technical point of view, I have familiarised myself with Solidworks (CAD software) by increas-
ing my skills and speed when drawing a model. Furthermore, I have strengthened and enhanced my
knowledge about speakers and technical/electrical hardware.
Unfortunately, I did not contribute to the coding aspect of the project, which is disappointing as I
would have liked to learn some basic knowledge about coding.

29. Things I learned (Alex G):
What I have learned from the project over course of the year:
The project made me rethink what a teamwork is, it gave me very useful experience in real world
problems and showed me how to overcome real world practical problems when working and search-
ing for the most effective solution. The project also showed me that often the reality differs from the
possible theory since the conditions in practice often differ from the real background. Furthermore
as I worked on the project I came to the realization that the whole team should have been more coop-
erative and our slow response and relatively slow execution of some tasks slowed the whole process
down a lot.
Things I learned (Saamiah):
From starting out as two different teams to becoming one large group, the most important thing I
learned from this project is teamwork. I learned that in order to produce the best possible result, it is
a group effort that is extremely important. This project also taught me the importance of organisation
as well as meeting deadlines. From making Gantt charts to recording the minutes of each meeting, I
saw our project develop into something I never thought possible. Furthermore, this experience
helped widen my knowledge of programming as well as simple things like wifi and bluetooth. This
has been an extremely valuable and interesting experience for me, one that I will never forget.
Things I learned (Jake):
Throughout this Qinetiq scheme I have learnt the roles in which engineers take on daily and the
sophistication that surrounds it. Firstly, when starting the project I had truly no idea of how a speaker
actually worked, which is why I took on the challenge of joining the club to interact and learn of the
professionals in their area. I learnt an array of different things from how a basic speaker works to
developing one on CAD to learning the importance of teamwork. On top of this, I improved my ability
to communicate within a group of people as well as improving my presentation skills. I would like to
thank the Qinetiq team once again for their huge shift in trying to help us build our knowledge in their
area and congratulate Derrick on being a very successful team leader.

30. Meeting Minutes (from 9/11/16 to 18/11/16):
9th November 2016
-Potential scenario: during an attack, the means of communication in a FOB get destroyed and a
message needs to be spread to the people in the base giving instructions and information on what is
happening.
-The product has to be wireless in case that cables underground or on the ground get damaged.
-the product should be simple and intuitive
-One potential idea would be to place communication units that are independent (they get the energy
from differen sages via the communication units.
- Bluetooth could be used as it does not require any phone service or wi-fi connection.
-Wi-fi could also be used as a mean of communication by placing multiple routers in various points.
Questions:
1-What is the budget? £300 for the prototype
2-How big is the FOB? 200m
3-Where is the FOB located? there is no specific locations but if the product can function in a lot of
environments then it is much better
4-Does it have to be moved? yes, it has to be relatively portable
5-does it have to be self sufficient? yes
6-does it have to be hidden? not too worried about this factor
By next week we should have an idea of what we are going to be designing o each person has to
present a detailed idea (possibly with diagrams) of the product.
Ali G- wireless
Saamiah-bluetooth
Jake/Valerio-walkie talkie + another idea
The google drive account is
email: malcolqinetiq@gmail.com
password: Qinetiq16
remember to meet on Sunday at 2pm in the DT lab.
Saamiah bring your laptop next Wednesday so you can work with Derrick on gantt charts

31. Deadlines are:
14th of December for the PDR
8th of February for the report draft/outlines
22nd March for the final deliverables
13th November 2016
First idea: Walkie Talkies with lithium iron batteries
• It must be portable
• It has to have very fast interaction
Problems:
1. The battery can overheat and explode if there is too much heat (can use a carbon fibre case)
2. Only one person can talk. You can’t have a conversation (no channels)
3. need a lot of data transmission if everyone in the base is going to communicate at the
same time
4. New troops coming in won’t have a walkie talkie
Conclusion: Walkie Talkies won’t be possible
Second idea: Develop an app for the phone
• It must override everything else on the phone
• Connects via bluetooth to speakers
• Need an app for Android and iOS
• The app should open as soon as someone starts speaking
• Speakers need to be heat proof, shock proof, water proof
• Speakers will need to be solar powered and a back up battery in case there is no sun
Problems:
1. Everyone needs an iPhone which can be expensive
2. Bluetooth is slow compared to wifi.There could be a delay with too many devices
connected (need speakers because bluetooth will take too long)
3. Speakers will need to be on all the time- will require a lot of energy
4. Everyone can’t speak at the same time
5. Need a way to connect the speakers
6. When the speakers communicate you have can't more than one message there will
be interference

32. For Wednesday 16th November:
1. Look for a way to connect the speakers together
2. Deadline for bid submission is Friday 18th November. It must include:
• The suppliers understanding of the problem
• The delivery approach to be employed
• A Gantt Chart (or else a suitable Project Plan)
16th November 2016
Problem: if the person connected to the speaker can’t access their phone, no one else will be able to
use it. Some override is needed
Solution: if nothing is said for 10-15 seconds, the app resets and someone else can use it
• Increase the range of the speaker so you don't need too many speakers which reduces the cost
• Connect the speakers using the power cables
• Speakers switches to battery power when someone uses the app
• Can’t use solar power because the size of the speaker the speaker will have to be
increased and it would increase the cost
• Could add written messages between apps
Instead of leaving the speaker on at all times, turn on the speaker using the app
• Infrared can be used to turn in on. However, a phone can’t produce IR
• Bluetooth can be used to turn on all the speakers. Since all the speakers will be connected
to each other, a phone needs to connect to only one speaker
Valerio and Jake: working on brief for Friday
Saamiah and Derrick: working on Gantt chart
Need for friday
1. Gantt chart- 1 page
2. Formal write up- 1 page
3. Understanding of what we’re doing
• Derrick and Alex: computer programming research and DSSS technology/software options
• Valerio and Jake: research hardware- bluetooth, materials, casing, prices of general c
omponents, list of components we might need and price of it, find advantages and
disadvantages of the materials
• Saamiah: Complete Gantt chart

33. Initial Brief: