RYB Design Document - Group 20 1

Team 20 / Year 2023-2024/ Project “Rock Your
Baby”
Complete Design Document
Version 3
18/01/2024
2
1.1 Architecture and Requirement at Product Level (System level) .......................... 8

1.1.1 Goal of the product ........................................................................................... 8
1.1.2 Set of Requirements at Product level (System Level) ....................................... 8
1.1.3 Description of the Inputs and Outputs at Product level (System Level) ............ 9
1.1.4 Specification of the Inputs and Outputs at Product level (System Level) ........ 11
1.2 Architecture and Requirement at Submodule Level (Sub-system level) .......... 12
1.2.1 Overview of the product with a high-level context diagram ............................. 12
1.3 Goal of each submodule ....................................................................................... 14
1.3.1.1 Goal of Submodule “Communication” ....................................................... 14
1.3.1.2 Goal of Submodule “Heartbeat” ................................................................ 14
1.3.1.3 Goal of Submodule “Crying” ..................................................................... 14
1.3.1.4 Goal of Submodule “Decision Making” ..................................................... 14
1.3.1.5 Goal of Submodule “Motors drivers” ......................................................... 14
1.3.2 Set of requirements for each submodule ........................................................ 14
1.3.2.1 for the Submodule “Communication” ........................................................ 14
1.3.2.2 Set of requirements for the Submodule “Heartbeat” ................................. 15
1.3.2.3 Set of requirements for the Submodule “Crying” ...................................... 15
1.3.2.4 Set of requirements for the Submodule “Decision Making” ....................... 15
1.3.2.5 Set of requirements for the Submodule “Motors drivers” .......................... 16
1.4 Signals description and specifications at submodule level (Sub-system level)
................................................................................................................................. 17
1.4.1 Internal signals: description, specifications, and alternatives .......................... 17
1.4.1.1 Internal Signal “crying volume” ................................................................. 17
1.4.1.2 Internal Signal “heartrate” ......................................................................... 17
1.4.1.3 Internal Signal “rocking amplitude............................................................. 18
1.4.1.4 Internal Signal “rocking frequency” ........................................................... 19
2.1 Goal(s) of the “Communication” submodule ...................................................... 20
2.2 Design choices of the “Communication” submodule ........................................ 20
2.3 Design alternatives of the “Communication” submodule .................................. 24
2.4 Tests of the “Communication” submodule ......................................................... 26
2.4.1 Tests “Heartrate” with respect to its specifications. ......................................... 26
2.4.2 Tests “Crying Volume” with respect to its specifications. ................................ 26
2.4.3 Tests “Rocking Amplitude” with respect to its specifications. .......................... 27
2.4.4 Tests “Rocking Frequency” with respect to its specifications. ......................... 27
3.1 Submodule “Heartbeat” ........................................................................................ 29
3.1.1 Goals and Guidelines for the Submodule “Heartbeat” .................................... 29
3.1.2 Design choices for the Submodule “Heartbeat” .............................................. 29
3.1.3 Design alternatives for the Submodule “Heartbeat” ........................................ 31
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
3
3.2 Submodule “Crying” ............................................................................................. 33

3.2.1 Goals and Guidelines for the Submodule “Crying” .......................................... 33
3.2.2 Design choices for the Submodule “Crying” .................................................... 33
3.2.3 Design alternatives for the Submodule “Crying” ............................................. 36
3.3 Submodule “Decision Making”............................................................................. 37
3.3.1 Goals and Guidelines for the Submodule “Decision Making” .......................... 37
3.3.2 Design choices for the Submodule “Decision Making” .................................... 37
3.3.3 Design alternatives for the Submodule “Decision Making” .............................. 40
3.4 Submodule “Motors drivers” ................................................................................ 41
3.4.1 Goals and Guidelines for the Submodule “Motor drivers” ............................... 41
3.4.2 Design choices for the Submodule “Motor drivers” ......................................... 42
3.4.3 Design alternatives for the Submodule “Motor drivers” ................................... 45
4.1 Test of Submodule “Heartbeat”............................................................................ 47
4.1.1 Functional Validation of the Submodule “Heartbeat”....................................... 47
4.1.1.1 Functional Validation of “The Heartbeat submodule must accurately detect
the baby's heart rate using a sensor that can capture the LED's intensity
pattern located under the baby's skin.” the Submodule “Heartbeat” ......... 47
4.1.1.2 Functional Validation of “The system must display the measurements and
continuously update the current heart rate in BPM, presenting this
information in a clear and user-friendly manner.” the Submodule
“Heartbeat” ............................................................................................... 47
4.1.1.3 Functional Validation of “The heartbeat submodule must be able to
measure the heartbeat no matter the way the heartbeat will be emulated.”
the Submodule “Heartbeat” ...................................................................... 48
4.1.2 Interface Validation of the Submodule “Heartbeat” ......................................... 48
4.1.2.1 Interface Validation of the Submodule “Heartbeat” “Any deviations in heart
rate should be promptly reported to the Decision-Making submodule.” .... 48
4.2 Test of Submodule “Crying” ................................................................................. 49
4.2.1 Functional Validation of the Submodule “Crying” ............................................ 49
4.2.1.1 Functional Validation of “Able to obtain measurements from the cradle
microphone” the Submodule “Crying” ....................................................... 49
4.2.1.2 Functional Validation of “Able to separate the crying sound from the
background noise picked up by the microphone” the Submodule Crying. 49
4.2.1.3 Functionality Validation of “Able to analyze the crying sound and calculate
a crying volume” the Submodule Crying. .................................................. 51
4.2.1.4 Functionality Validation of “Able to send the crying volume to the Decision-
Making submodule.” ................................................................................. 52
4.2.2 Interface Validation of the Submodule “Crying” .............................................. 52
4.2.2.1 Interface Validation of the Submodule “Crying” – “Heartbeat” .................. 52
4.2.2.2 Interface Validation of the Submodule “Crying” – “Crying Volume.” ......... 52
4.3 Test of Submodule “Decision Making” ................................................................ 52
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
4
4.3.1 Functional Validation of the Submodule “Decision Making” ............................ 52

4.3.1.1 Functional Validation of “Able to calculate the current stress level from the
given input (crying volume and heartrate).” the Submodule “Decision
Making” ..................................................................................................... 52
4.3.1.2 Functional Validation of “Able to decide how to most efficiently traverse
through the stress matrix. & Able to display the current progress of calming
down the baby. ” the Submodule “Decision Making”................................. 53
4.3.1.3 Functional Validation of “Able to communicate the desired frequency and
amplitude of the rocking motion to the Motors drivers Submodule.” the
Submodule “Decision Making.” ................................................................. 53
4.3.2 Interface Validation of the Submodule “Decision Making” ............................... 53
4.3.2.1 Interface Validation of the Submodule “Decision Making” – “crying volume”
.................................................................................................................. 53
4.3.2.2 Interface Validation of the Submodule “Decision Making” – “heartrate” .... 53
4.3.2.3 Interface Validation of the Submodule “Decision Making” – “rocking
amplitude” ................................................................................................. 54
frequency” ................................................................................................. 54
4.4 Test of Submodule “Motors drivers” ................................................................... 55
4.4.1 Functional Validation of the Submodule “Motors drivers” ................................ 55
4.4.1.1 Functional Validation of "Able to interpret the combined amplitude and
frequency data and convert it into useful information for motor drivers" the
Submodule “Motors drivers” ..................................................................... 55
4.4.1.2 Functional Validation of “Able to provide the required amount of power to
the motors in order to initiate movement in the cradle.” the Submodule
“Motor drivers.” ......................................................................................... 55
4.4.1.3 Functional Validation of “Able to start, stop or change the speed of the
cradle’s motion” the Submodule “Motor drivers.” ...................................... 56
4.4.1.4 Functional Validation of “Able to maintain high voltage input for initiating or
sustaining movement in the cradle” the Submodule “Motor drivers.” ........ 57
Functional Validation of "Able to display the duty cycle information of the PWM
signals sent to the motors.” the Submodule “Motor drivers.” .................... 57
4.4.2 Interface Validation of the Submodule “Motors drivers” .................................. 57
4.4.2.1 Interface Validation of the Submodule “Motors drivers” – “Rocking
Amplitude” ................................................................................................ 57
4.4.2.2 Interface Validation of the Submodule “Motor drivers” – “Rocking
Frequency” ............................................................................................... 57
5.1 Test of Input signals of the product after integration ......................................... 58
5.1.1 Functional Validation of the Input signal “Heartbeat” of the product after
integration ....................................................................................................... 58
5.1.2 Functional Validation of the Input signal “Crying” of the product after integration
58
5.2 Test of Output signals of the product after integration ...................................... 58
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
5
5.2.1 Functional Validation of the Output signal “Rocking Amplitude” of the product
after integration ............................................................................................... 58
5.2.2 Functional Validation of the Output signal “Rocking Frequency” of the product
after integration ............................................................................................... 58
5.3 Integration Validation ............................................................................................ 59
5.3.1 Integration test: communication ...................................................................... 59
5.3.2 Integration of the Submodules “Decision making” and “Motors drivers” .......... 59
5.3.3 Integration of the submodules “Heartbeat”, “Decision Making” and “Motors
Drivers” ........................................................................................................... 59
5.3.4 Integration of the submodules “Heartbeat”, “Crying”, “Decision Making” and
“Motors Drivers” .............................................................................................. 59
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
6
List of Figures
Figure 1(the frequency of heartbeat as a function of the stress percentage) .................. 9
Figure 2 the crying volume as a function of the stress percentage ............................... 10
Figure 3 High-level context diagram .............................................................................. 12
Figure 4 in depth context diagram ................................................................................. 13
Figure 4 Illustration of the design choice of the displays ............................................... 22
Figure 6 heartbeat circuit............................................................................................... 29
Figure 7 heartbeat circuit diagram ................................................................................. 30
Figure 8 heartbeat alternative 1 circuit diagram ............................................................ 31
Figure 9 heartbeat alternative 2 circuit diagram ............................................................ 32
Figure 10 The Crying Submodule ................................................................................. 34
Figure 11 bandpass amplifier circuit .............................................................................. 35
Figure 12 low pass filter with operational amplifier circuit.............................................. 36
Figure 13 crying submodule alternative circuit .............................................................. 37
Figure 15 decision making pynq display........................................................................ 39
Figure 16 explanation stress level ................................................................................. 39
Figure 17 stress matrix example ................................................................................... 40
Figure 18 decision making process ............................................................................... 40
Figure 19 the Motors-Drivers submodule setup ............................................................ 42
Figure 20 Circuit design built on LTspice ...................................................................... 43
Figure 21 Graph of initial and amplified signal .............................................................. 43
Figure 22 Circuit design built on the sub-module board ................................................ 43
Figure 23 Graph of the input and output signals obtained from an oscilloscope ........... 44
Figure 24 Alternative circuit design motor drivers ......................................................... 45
Figure 25 Alternative circuit design ............................................................................... 46
Figure 26 Oscilloscope view of bandpass amplifier ....................................................... 49
Figure 27 Oscilloscope view of the bandpass amplifier ................................................. 50
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
7
Figure 28 Oscilloscope view of the sound signal that is not filtered or amplified ........... 51
Figure 29 Multiple steps of the matrix displayed on the PYNQ LCD screen .................. 53
Figure 30 The baby setup’s lights turn on when the signals are received ..................... 55
Figure 31 The PWM-signal from the PYNQ-board ........................................................ 56
Figure 32 circuit with two transistors ............................................................................. 56
List of Tables
Table 1 range and rocking frequency ........................................................................... 10

Table 2 ragion and rocking amplitude ........................................................................... 10
Table 3 specifications of the input signal “crying intensity input” of the product ........... 11
Table 4 specifications of the input signal “hearbeat input” of the product ...................... 11
Table 5 specifications of the input signal “rocking amplitude output” of the product...... 11
Table 6 specifications of the input signal “rocking frequency output” of the product ..... 11
Table 7 Summary of Communication Details ................................................................ 23
Table 8 feature and specification of design alternative1 of the “communication” .......... 24
Table 9 feature and specification of design alternative2 of the “communication” .......... 25
Table - Acronyms ......................................................................................................... 61
Table - Referenced Documents ................................................................................... 62
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Architecture and Requirement at Product Level (System level)
1 Requirements and Architecture

1.1 Architecture and Requirement at Product Level (System level)
1.1.1Goal of the product

The goal of this product is to help nurseries by creating a smart baby cradle that can
automatically calm a crying baby, to free supervisors' time they would otherwise spend rocking
babies manually. It achieves this by listening to the baby's cries and monitoring their heart rate.
Then, it adjusts the way it rocks the baby to calm them down quickly.
1.1.2Set of Requirements at Product level (System Level)

Requirement 1: The cradle and monitoring devices must do no harm to the baby.
Requirement 2: The product must be able to detect and accurately measure the baby's crying
noise.
Requirement 3: The product must be able to detect and accurately measure the baby's heart
rate.
Requirement 4: The product must be able to process the information measured by sensors, to
calculate the baby's stress level and to determine appropriate rocking frequency and amplitude.
Requirement 5: The product must be able to control the motors attached to the cradle.
Requirement 6: The product's submodules must establish reliable communication with one
another to facilitate data exchange.
Requirement 7: The product must be able to combine the previous requirements to gradually
reduce the baby's stress level.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
1.1.3Description of the Inputs and Outputs at Product level

(System Level)
Input signals:
1. Heart Rate: The baby simulates a heartrate using an LED located under the baby's skin that
can emulate the heartbeat in 4 ways: heartbeat with 50% duty cycle, heartbeat with glitches,
with heartbeat deviations and ECG-pattern. The frequency derived from the LED's intensity
represents the baby's heart rate in BPM. It changes in response to the baby's stress level. This
signal is measured using a light sensor.
In the context of the system's operation, the stress level of the baby is primarily related to the
heart rate. When the heart rate frequency exceeds 60 BPM, the corresponding stress
percentage can be determined, as outlined in the provided table (see Figure 1.1.3.1).
Figure 1.1.3.1:
The frequency of the heartbeat as a function of the stress percentage
300
240
250
frequency in BPM
200
150
100
60 60
50
0
0 20 40 stress in % 60 80 100 120
Figure 1(the frequency of heartbeat as a function of the stress percentage)
It is important to note that a certain delay is inherent in the heart rate’s response to a change in
the baby’s stress level. Because of this delay, the 'Decision Making' submodule may choose to
rely on stress percentage data from the 'Crying Detection' submodule, which provides more up-
to-date information, but only works when the stress level is under 50%.
2. Crying Intensity: This signal is captured by a microphone mounted on the cradle. The signal
may contain noise, which will need to be filtered in order to isolate the crying noise. The crying
sound is then analyzed to calculate the baby's crying intensity in decibels (dB).
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
As seen in figure 1.1.3.2, when the stress level is under 50%, the crying volume is strongly
correlated to the stress level. In this scenario, the ‘Decision Making’ submodule can use this
signal to accurately determine the baby’s stress level.
Figure 1.1.3.2:
The Crying volume as a function of the stress percentage
100%
Crying Volume (%)
80%
60%
40%
20%
0%
0% 20% 40% 60% 80% 100%
Stress (%)
Figure 2 the crying volume as a function of the stress percentage
Output signals:
1. Rocking Frequency: The cradle adjusts its rocking motion frequency based on the
input signals. This means that the cradle can change how quickly it rocks the baby. There
are 5 different available rocking speeds.
The specific rocking speed for each range are as follows:
Table 1(ranges and rocking frequency)

1 2 3 4 5
Range
0.2Hz 0.35Hz 0.5Hz 0.65Hz 0.70Hz
Rocking
frequency
2. Rocking Amplitude: This signal controls the cradle's rocking amplitude, varying
within defined regions. It determines the intensity or strength of the cradle's rocking
motion. The amplitude control ensures that the cradle can rock gently or more vigorously
based on the baby's needs, which is especially important when aiming to reduce the
baby's stress level. The amplitude values for each of the 5 available regions are as
follows:
Table 2(ragions and rocking amplitudes)
1 2 3 4 5
Region
20% 40% 60% 80% 100%
Rocking
amplitude
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
1.1.4Specification of the Inputs and Outputs at Product level

(System Level)
Table 3(Specifications of the Input signal “crying intensity input” of the product)
Specifications of the Input signal “crying intensity input” of the product
Unit Decibel (dB)
Data type Analog signal
Range 0dB - maximum dB
Timing information Sampled at a rate sufficient to capture crying variations.
Table 4(Specifications of the Input signal “heartbeat input” of the product)

Specifications of the Input signal “heartbeat input” of the product
Unit Beats Per Minute (BPM)
Data type Analog
Range 60BPM - 240BPM
Timing information Sampled at a rate sufficiently large to accurately measure within the specified range.
Table 5(Specifications of the output signal “rocking amplitude output” of the product)5
Specifications of the output signal “rocking amplitude output” of the product
Unit Percentage (%)
Data type Digital (PWM signal)
Range 20% - 100%
PWM specification 1kHz 12V square wave. Duty cycle in Range 0% - 90%
Timing information Signal is continuous
Table 6(Specifications of the output signal “rocking frequency output” of the product)6
Specifications of the output signal “rocking frequency output” of the product
Unit Hertz (Hz)
Data type Digital (PWM signal)
Range 0.2Hz - 0.7Hz
PWM specification 1kHz 12V square wave. Duty cycle in Range 0% - 90%
Timing information Signal is continuous
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Architecture and Requirement at Submodule Level (Sub-system level)
Note that for signals “crying intensity input” and “heartrate input” the sample rate and
time to measure are not yet defined. These will need to be determined through testing.
1.2 Architecture and Requirement at Submodule Level (Sub-

system level)
1.2.1Overview of the product with a high-level context diagram

The product is divided into five submodules: communication, crying, heartrate, decision making
and motor drivers. A high-level overview of how these submodules operate with respect to one
another is given in Figure 4. The inner workings of these submodules are illustrated in Figure 4.
As shown in figures 3 and 4, the decision-making submodule is positioned at the heart of the
system. All other submodules are connected to this one submodule. The crying and heartrate
submodules are sending data, which they acquired from sensors and calculations to the
decision-making submodule, while the motor driver submodule receives data from it, and uses it
to control the cradle motor.
Figure 3 High-level context diagram
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Architecture and Requirement at Submodule Level (Sub-system level)
Figure 4 in depth context diagram
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Goal of each submodule
1.3 Goal of each submodule

1.3.1.1 Goal of Submodule “Communication”
The Communication submodule aims to establish and maintain reliable data exchange channels
between other submodules to ensure seamless coordination. It also allows for communication
between submodules.
1.3.1.2 Goal of Submodule “Heartbeat”

The Heartbeat submodule's goal is to accurately measure a light sensor and process the
measured data to determine the baby's heart rate. It can emulate the heartbeat in 4 ways:
heartbeat with 50% duty cycle, heartbeat with glitches, with deviations heartbeat-rate and ECG-
pattern. This heartrate is then sent to the decision-making submodule.
1.3.1.3 Goal of Submodule “Crying”

The goal of Submodule "Crying” is to measure the baby's crying sound and filter out any
background noise from the sound picked up by the microphone. Once the background noise is
filtered out, the crying noise is analyzed to calculate a crying volume. This volume will then be
sent to the decision-making submodule.
1.3.1.4 Goal of Submodule “Decision Making”

The “Decision Making” Submodule receives a crying volume and a heartbeat frequency as
input, which it converts to an accurate stress level. It uses an algorithm to determine a rocking
amplitude and frequency that most optimally traverses the stress matrix and calms down the
baby, based on the stress level. The rocking amplitude and frequency will be sent to the motors
drivers submodule.
1.3.1.5 Goal of Submodule “Motors drivers”

This submodule receives the rocking frequency and amplitude provided by the decision-making
submodule. The motors drivers should be able to control the cradle’s movements as in being in
charge of starting or stopping the movement or adjusting the speed of the cradle according to
the required frequency and amplitude predefined by the decision-making submodule to calm the
baby down.
1.3.2 Set of requirements for each submodule

1.3.2.1 for the Submodule “Communication”
- Requirement 1: “All submodules are able to send and receive any signal needed for
proper operation, without any obstacles.”
- Requirement 2: “The submodules must be able to communicate with the cradle sensors
and motor.”
- Requirement for the Graphical User Interface/ Display 1: “Each of the 4 other
submodules will display both data they receive and data they send from and to other
submodules. (Since this is mentioned here, this will not be separately mentioned for
each other submodule)”
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
- Requirement for the Graphical User Interface/ Display 2: “Displayed data must be
easy to comprehend without the need of additional clarification”
1.3.2.2 Set of requirements for the Submodule “Heartbeat”

Requirement 1: "The Heartbeat submodule must accurately detect the baby's heart rate using
a sensor that can capture the LED's intensity pattern located under the baby's skin."
Requirement 2: "Heart rate data should remain within the specified range of 60 BPM
(minimum) to 240 BPM (maximum), with a sensor capable of reliably measuring this range."
Requirement 3: "Any deviations in heart rate should be promptly reported to the Decision-
Making submodule."
Requirement 4: "The heartbeat sensor must operate without harming the baby, utilizing safe
and non-invasive technology."
Requirement 5: "The system must display the measurements and continuously update the
current heart rate in BPM, presenting this information in a clear and user-friendly manner."
Requirement 6: “The heartbeat submodule must be able to measure the heartbeat no matter
the way the heartbeat will be emulated.” (see 1.1.3 for specifications)
1.3.2.3 Set of requirements for the Submodule “Crying”

- Requirement 1: “Able to obtain measurements from the cradle microphone.”
- Requirement 2: “Able to separate the crying sound from the background noise picked
up by the microphone.”
- Requirement 3: “Able to analyze the crying sound and calculate a crying volume”
- Requirement 4: “Able to send the crying volume to the Decision-Making submodule.”
- Requirement for the Graphical User Interface/ Display: “Able to display both the
measured audio signal and the analyzed audio level.”
1.3.2.4 Set of requirements for the Submodule “Decision Making”

- Requirement 1: “Able to calculate the current stress level from the given input (crying
volume and heartrate).”
- Requirement 2: “Able to decide how to most efficiently traverse through the stress
matrix”
- Requirement 3: “Able to communicate the desired frequency and amplitude of the
rocking motion to the Motors drivers Submodule.”
- Requirement for the Graphical User Interface/ Display: “Able to display the current
progress of calming down the baby.”
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
1.3.2.5 Set of requirements for the Submodule “Motors drivers”

- Requirement 1: "Able to interpret the combined amplitude and frequency data and
convert it into useful information for motor drivers"
- Requirement 2: “Able to provide the required amount of power to the motors in order to
initiate movement in the cradle.”
- Requirement 3: “Able to start, stop or change the speed of the cradle’s motion”
- Requirement 4: “Able to maintain high voltage input for initiating or sustaining
movement in the cradle”
- Requirement for the Graphical User Interface/ Display: "Able to display the duty
cycle of the PWM signals sent to the motors.”
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Signals description and specifications at submodule level (Sub-system level)
1.4 Signals description and specifications at submodule level

(Sub-system level)
1.4.1Internal signals: description, specifications, and

alternatives
1.4.1.1 Internal Signal “crying volume”
1.4.1.1.1 Description of the signal “crying volume” with justification
The “Crying volume” signal contains the volume of the crying of the baby. This signal is
transmitted by the “Crying” submodule to the “Decision making” submodule. The “Decision
making” submodule then uses this signal to calculate the baby's stress level.
1.4.1.1.2 Specification of the signal “crying volume” with justification

The “crying volume” is a percentage (%) value between 0.0% and 100.0%. This signal will be
sent as soon as a new crying volume is measured and interpreted. For storing and transmitting
this signal, the “float” data type will be used, allowing for greater than integer precision.
1.4.1.1.3 Alternatives specifications of the signal “crying volume” with justification analyze
what
Instead of sending the “crying volume” signal as soon as a change is measured, the “crying”
submodule could wait for the new measurements to differ from the previous signal by at least
some predefined minimum value. (e.g., a 5% difference). This would reduce the amount of data
that needs to be transmitted.
By mapping the data from a 0.0%-100.0% value to an integer between 0 and 255, the data can
be compressed to just 1 byte. (Using the “unsigned char” type). This way, transmissions could
be reduced even more. (Since an “unsigned char” is only 1 byte, while a “float” is 4 bytes)
This specification could be useful if communication between submodules turns out to be slow or
costly.
1.4.1.2 Internal Signal “heartrate”

1.4.1.2.1 Description of the signal “heartrate” with justification
The "Heart Rate" signal carries data representing the baby's heart rate. The “heartrate”
submodule sends this signal to the “Decision Making” submodule, after it has translated
its measurements to a heartrate. The “Decision Making” submodule then uses this
signal to determine the baby's stress level.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
1.4.1.2.2 Specification of the signal “heartrate” with justification

The unit for the heartbeat is Beats Per Minute (PBM). The data type we are going to use is float.
This comes in handy, because it has large precision and everyone in our group will use it so it
will benefit ease of communication. The range of the heartrate is in between 60 BPM (minimum)
and 240 BPM (maximum). This signal will be sent as soon as a new heartrate is known.
1.4.1.2.3 Alternatives specifications of the signal “heartrate” with justification

In case data transmission turns out to be slow or costly, the following specifications can be
useful.
Instead of sending the “heartrate” signal every time a change is measured, the “heartrate”
submodule could wait for the new measurements to differ from the previous signal by at least a
set minimum value. (e.g., 5BPM). This would reduce the amount of data that needs to be
transmitted. In this case, the “heartrate” signal would still be a value between 60BPM and
240BPM.
By rounding the 60BPM – 240BPM value, the “heartrate” signal can be sent as an “unsigned
char”. This could further reduce the amount of data transmitted.
1.4.1.3 Internal Signal “rocking amplitude

1.4.1.3.1 Description of the signal “rocking amplitude” with justification
This signal is sent from the “Decision Making” Submodule to the “Motors Drivers” submodule. It
tells the “Motors Drivers” submodule what the desired rocking amplitude is. The receiving
submodule will then drive the motor at the instructed amplitude.
1.4.1.3.2 Specification of the signal “rocking amplitude” with justification

The “rocking amplitude” signal will be a percentage (%) value between 20.0% and 100.0%, as
given by the table below. To transmit this, the “float” data type will be used, allowing for
transmission of precise decimal values. This signal will be sent after the “Decision making”
submodule receives new information, and it has finished calculating the new desired rocking
amplitude. This way, the “Motors driver” submodule will receive the signal as soon as any new
information is available.
1.4.1.3.3 Alternatives specifications of the signal “rocking amplitude” with justification

If transmission of data is slow or costly, the desired rocking amplitude (ranging between 20.0%
and 100.0%) could be mapped to an integer value between 0 and 255. This could then be
transmitted with the “unsigned char” data type. Additionally, instead of sending a new signal
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
whenever the desired rocking amplitude changes, the signal could be sent every 5 seconds, to
save on data transmission even more.
1.4.1.4 Internal Signal “rocking frequency”

1.4.1.4.1 Description of the signal “rocking frequency” with justification.
This signal is sent from the “Decision Making” Submodule to the “Motors Drivers” submodule. It
tells the “Motors Drivers” submodule what the desired rocking frequency is. The receiving
submodule will then drive the motor at the instructed frequency.
1.4.1.4.2 Specification of the signal “rocking frequency” with justification.

The “rocking frequency” signal will be a value between 0.2Hz and 0.7Hz. (These limits are
derived from the table below). To transmit this with precision, the “float” data type will be used.
This signal will be sent after the “Decision making” submodule receives new information, and it
has finished calculating the new desired rocking frequency. This way, the “Motors driver”
submodule will receive the signal as soon as any new information is available.
1.4.1.4.3 Alternatives specifications of the signal “rocking frequency” with justification.

If transmission of data turns out to be slow or costly, the desired rocking frequency (ranging
between 0.2Hz and 0.7Hz) could be mapped to an integer value between 0 and 255. This could
then be transmitted with the “unsigned char” data type. Additionally, instead of sending a new
signal whenever the desired rocking frequency changes, the signal could be sent once every 5
seconds, to further reduce data transmissions.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Goal(s) of the “Communication” submodule
2 Design description of the “Communication”

submodule
2.1 Goal(s) of the “Communication” submodule

The primary objective of the "Communication" submodule is to ensure efficient and consistent
communication within the entire system. This module enables every other submodule to
simultaneously interact, exchange data, and operate in collaboration.
Goals and Requirements:
1. Intra-Board Communication: The submodule should facilitate fast and reliable
communication between various submodules. Every submodule relies on the exchange of data
to function correctly.
- Requirement: Each submodule in our system is designed for communicating its own data,
ensuring efficient and error-free communication. Data flows in one direction from heartbeat
submodule to crying submodule to decision-making submodule, and then to motor submodule.
2. External Interface Communication: Efficient and effective communication is not only

required among the different submodules of our system but also with external interfaces such as
sensors, motors, and the cradle itself. This encompasses the entire ecosystem of our product,
ensuring seamless interaction both internally (between submodules) and externally (with
hardware components and devices).
- Requirement: The submodules must be able to communicate with the cradle sensors and
motors drivers, supporting real-time responsiveness.
3. Data Display: The graphical user interface (GUI) plays a significant role. It visualizes the
data processed by the system which enables the user to see and interpret the information.
- Requirement: Each of the 4 other submodules will display both data they receive and data
they send from and to other submodules.
- Requirement: The displayed data should be easy to comprehend by the user ensuring
clarity, and simplicity for user interpretation. Include both incoming and outgoing data streams,
and ensure that the display updates in real-time.
2.2 Design choices of the “Communication” submodule

Protocol/Principles:
Error-Checking: Given the importance of correct data transfer, it is important for
communication to have a mechanism for error-checking. This ensures that the sent message is
the same as the received message. When an error is detected, the received message can be
discarded. Additionally, the recipient can reply to the sender to notify it of the received error. The
sender can then resend the message.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Design choices of the “Communication” submodule
2. Feedback Loop: Upon the receipt of any message, a feedback signal should be sent to the
sending entity. This "Acknowledgment" tells the sender the message was received and
processed. Upon receiving an error, an “Error” feedback signal should be sent.
In our current setup, we utilize UART for communication between submodules, which inherently
supports one-way communication on a single channel. This means the recipient cannot send
“Acknowledgment” or “Error” messages to the sender. To mitigate this limitation and enhance
communication reliability, we can implement robust error-checking mechanisms at the software
level. Additionally, we ensure thorough testing and validation of the data being transmitted
between submodules.
To further establish a feedback loop for acknowledgments, we propose utilizing General
Purpose Input/Output (GPIO) pins, allowing for acknowledgment signals to be sent over
separate channels. In our context, we could dedicate specific GPIO pins for sending
acknowledgment signals back to the sending submodule, thereby creating a reliable feedback
loop. This approach ensures that once a submodule receives a message via UART, it can
promptly send an acknowledgment signal through a GPIO pin, confirming the successful
reception of the message. This method enhances communication reliability while operating
within the constraints of our existing UART channels. Because of the high reliability of the UART
communication, this feedback loop will initially not be implemented, but will be noted as a
backup solution.
3. Data Encoding and Decoding: Efficient and accurate data transmission is paramount in our
system, necessitating the use of data encoding at the sender’s end and decoding at the
receiver’s end. This transformation process ensures that the data is in an optimal format for
transmission, allowing for seamless communication between different submodules. The
encoding process translates the data into a transmission-friendly format, while decoding
restores it to its original state for accurate interpretation and use.
Constraints:
1. No Delays: With a real-time system like this, latency should be minimal. Any delay in
communication can hinder the system's efficacy. (The communication should happen fast)
2. Space for Data: Ensure ample storage and bandwidth to accommodate all transmitted data
without bottlenecks.
3. Ease of use: The implementation of the communication must be easy to use. Both in
software (not needing too much code) and in hardware (not needing too many wires).
4. Timing: The timing requirements of the communication protocol must not be too strict. The
submodules must be able to focus on other tasks, while not having to constantly be checking for
incoming messages.
1. Communication Protocol:
We chose to proceed with the universal asynchronous receiver/transmitter (UART) protocol.
This choice supports quick and efficient communication between submodules, and it's reliable.
Inputs: Data received from other submodules (e.g., “Crying volume”, “Heartrate”).
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Outputs: Processed data to be sent to other submodules (e.g. “Crying volume and Heartrate”
and “motor driver”)
Unit: Depending on the signal (% for “Crying volume”, BPM for “Heartrate”, Hz for “Rocking
frequency” and % for “rocking amplitude”)
Data Type: Float. Allows for high precision.
Refresh Rate: As fast as new data becomes available. The system is engineered to be able to
uphold a high refresh rate, ensuring that data transmission between submodules occurs with
minimal delay. This rapid data exchange is crucial for maintaining the real-time responsiveness
of the system, allowing it to quickly adapt to changes in input data and execute necessary
adjustments promptly. The design strives for a seamless flow of information, minimizing latency
to enhance the system’s overall efficiency and effectiveness in real-time decision-making and
actions. This can be done by using compact encoding and effective buffer management,
reducing processing overheads and considering using a Real-Time Operating System if
necessary.
Type: Digital (ensuring precise data transfer).
Figure 4 Illustration of the design choice of the displays 5

Figure: Illustration of the design choice of the displays with example input/output data and
examples for information that can be shown in the middle
2. Data Encoding & Decoding:
In our data transmission protocol, each message needs to transmit a signal name and a
floating-point number. In order to do this these values must be converted to an array of bytes.
Once the message is received, it has to be converted back to a signal name and float value.
The exact structure of the message can be found in the next section.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
3. Message structure
UART uses serial communication. This means that the data is transferred one bit at a time over
a single communication channel. Each byte is sent according to libpynq 0.2.5's implementation
of UART.
To allow for larger data transfers, each message between submodules contains multiple bytes.
To maintain clarity and consistency in our communication protocol, each message follows a
specific structure:
• START_BYTE(1 byte) + SIGNAL_NAME(1 byte) + VALUE(4 bytes) + END_BYTE(1
byte)
Start_byte is a single byte that signals the beginning of a message, ensuring that the receiving
submodule is ready to interpret the incoming data. This must always have the value 255
(0b11111111)
Signal_name is a single byte that identifies which signal is being transmitted. It enables the
system to send multiple types of data over the same communication channel, assisting the
receiving submodule in correctly interpreting the incoming data.
Value is the main data payload of the message, consisting of a float value converted into 4
bytes. The use of a float ensures precision in the transmitted data.
End_byte is a single byte that indicates the end of the message, providing a clear marker to
help the receiving submodule understand when a complete message has been received. This
must always have the value 0 (0b00000000)
4. Error Detection and Correction:

The system incorporates basic error detection mechanisms to identify anomalies or errors in the
received data, such as nonsensical signal names or highly improbable values. While this
method does not correct the errors, it plays a vital role in maintaining system reliability by
signaling when a transmission error might have occurred.
Table 7 Summary of Communication Details
Feature Specification
Protocol . UART (Universal Asynchronous Receiver-

Transmitter)
Inputs Data from submodules (connected to the A1

pin)
Outputs Data to submodules(connected to the A0 pin)
Data Type Float
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Design alternatives of the “Communication” submodule
2.3 Design alternatives of the “Communication” submodule

Alternative 1:
An alternative communication protocol could be SPI (Serial Peripheral Interface). This protocol
implies the use of one “master” submodule, and 3 other “slave” submodules. When one
submodule wants to send a message to another submodule, it sends the message to the
master, which then sends then forwards the message to the correct submodule.
This protocol is especially useful when each submodule needs to be able to communicate with
every other submodule. However, in this application, this is not required. Signals only need to
go one way.
If we would use the SPI protocol the units would remain the same (% for “Crying volume”, BPM
for “Heartrate”, Hz for “Rocking frequency”, % for “Rocking Amplitude”). The table would look
like this:
Table 8 features and specifications of Design alternative 1 of the Communication
Protocol Serial Peripheral Interface (SPI)
Input Data from submodules
Outputs Data to submodules
Data Type Float for high precision
Comparison and Justification

The UART solution is simpler, as it requires less wiring and only allows for one way
communication. This simplicity makes it easier to use and more reliable than SPI. Using UART
also removes the need for having one “master” submodule, which allows for the implementation
of the communication to be almost identical between submodules. In addition to this
communication between for instance the crying-submodule and heartbeat-submodule is not
necessary so we don't have to use parallel communication and we can spare time this way by
using UART.
For these reasons ultimately UART was chosen over SPI.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Design alternatives of the “Communication” submodule
Alternative 2:
In addition to this we came up with an alternative design to use PWM communication without a
library. PWM is a square wave (turning on and off a GPIO pin), where the duty cycle (how long
the pin is on vs off) determines the value. In this case, a value of 0 would be fully off and 255
would be fully on. 128 would be on 50% of the time
This does cause major changes in terms of protocol and data types that we receive.
Table 9 features and specifications of Design alternative 2 of the Communication
Protocol PWM (Pulse Width Modulation), as implemented

by libpynq 0.2.5
Input Data from submodules, converted to a PWM

signal.
Outputs Data to submodules, converted to a PWM signal.
Data Type Unsigned char
An advantage of the simplicity of PWM is that there is no overhead with start bits, stop bits,
parity bits like in UART. we can continuously keep sending the signal.
However, there are also major disadvantages, because this is a "bit banging" communication
method, there is no hardware here to help us (e.g. there is no data buffer, which means we
have to be very precise with our timing). This timing precision means the program constantly
needs to be checking for any incoming data, hindering the submodule's ability to focus on other
tasks.
Only the sending of the PMW data is implemented in the pynq library. So the receiving part
would be a lot of extra work. In this case we would have to implement this ourselfs, which we
wouldnt have to do for the UART Protocol.
In addition to this, the data we send with UART can be a lot more precise, instead of just
sending a value between 0 and 255, with UART we can send very small and very large values
with multiple decimals of precision. This is why we chose for our alternative using UART.
The unit for both these alternatives remains the same as our chosen design it depends on the
signal (% for “Crying volume”, BPM for “Heartrate”, Hz for “Rocking frequency”, % for “Rocking
Amplitude”). In alternative 2 the signal sent by the bits can be between 0 and 255, for a
percentage we would just use the 0 to 100. The same goes for the heartrate and rocking
frequency (we can just send it as a whole number between 0 and 255).
Comparison and Justification
While the PWM-based approach does offer continuous signal refresh, this comes at the cost of
increased complexity in timing management. Our final design choice (UART), therefore, strikes
a good optimal balance between speed, simplicity, and development efficiency, ensuring
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Tests of the “Communication” submodule
reliable communication between the PYNQ boards while minimizing potential pitfalls and
complexities associated with the alternative designs.
2.4 Tests of the “Communication” submodule
2.4.1 Tests “Heartrate” with respect to its specifications.

Goal of the test: Observe whether the Heartrate signal (in BPM) will be communicated from
Heartrate submodule to the decision-making submodule. This value must also be shown in the
input and output sections on the corresponding submodules’ LCD screens.
Test set up: Three PYNQ boards are each connected to a computer with ethernet- and USB
cables. One will be the heartrate submodule, one will be the crying submodule, the other will be
the decision-making submodule. The signal will be sent from the heartrate submodule to the
crying submodule, which will then forward it to the decision-making submodule. The PYNQ
boards are connected to each other with wires as described in section 2.2. VS Code is used to
run the test and is open on each computer screen.
Next, the test is started. The heartrate submodule will create a simulated value for the heartrate,
that is constantly increasing.
The test will be considered a success when these conditions are met:
1. The heartrate is correctly displayed in the output section of the heartrate submodule's
display.
2. The heartrate is sent by the heartrate submodule.
3. The heartrate is correctly received by the crying submodule.
4. The heartrate is correctly displayed in the input section of the crying submodule's
display.
5. The heartrate is sent by the crying submodule.
6. The heartrate is correctly displayed in the output section of the crying submodule's
display.
7. The heartrate is correctly received by the decision-making submodule.
8. The heartrate is correctly displayed in the input section of the decision-making
submodule's display.
9. All values displayed on the displays are equal.
10. The displayed values are observed to be increasing correctly.
For condition 9 to be met, all other 8 conditions must be met. Thus, if condition 9 and 10 are
observed to be met, the test is considered a success.
Conclusion of the test: The Heartrate data is sent and received, and the correct value is
observed on each LCD screen. This means all given criteria are met. The test is considered a
success.
2.4.2 Tests “Crying Volume” with respect to its specifications.

This test is similar to the “Heartrate” signal test. However, instead of using 3 pynq boards, it only
uses 2.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Goal of the test: Observe whether the Crying volume signal (in %) will be communicated from
crying volume submodule to the decision-making submodule. This value must also be shown in
the input and output sections on the corresponding submodules’ LCD screens.
Test set up: Two PYNQ boards are each connected to a computer with ethernet- and USB
cables. One will be the sender, while the other will be the receiver. The PYNQ boards are
connected to each other with wires as described in section 2.2. VS Code is used to run the test
and is open on both the computer screens.
Next, the test started. The crying submodule will create a simulated value for the crying volume,
that is constantly increasing.
The test will be considered a success when these conditions are met:
1. The crying volume is correctly displayed in the output section of the crying volume
2. The crying volume is sent by the crying submodule.
3. The crying volume is correctly received by the decision-making submodule.
4. The crying volume is correctly displayed in the input section of the decision-making
5. Both values displayed on the displays are equal.
6. The displayed values are observed to be increasing correctly.
Conclusion of the test: The crying volume is sent and received, and the correct value is
observed on both LCD screens. When the value changes on the sending submodule, the value
changes on the receiving submodule shortly after. This meets all given criteria. The test is
considered a success.
2.4.3 Tests “Rocking Amplitude” with respect to its

specifications.
This test is similar to the “Crying Volume” test. The difference being the signal sent and the
submodules used. Instead of sending the signal from the Crying submodule to the decision-
making submodule, this signal is sent from the decision-making submodule to the motor's
drivers submodule.
Conclusion of the test: The rocking amplitude is sent and received, and the correct value is
observed on both LCD screens. This meets all given criteria (same criteria as “Crying Volume”
test). The test is considered a success.
2.4.4 Tests “Rocking Frequency” with respect to its

specifications.
This test is similar to the "Rocking amplitude” test, the only difference being that this is a
different signal than the Amplitude signal. Both signals are sent through the same wire.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Conclusion of the test: The rocking frequency data is sent and received, and the correct value
is observed on both LCD screens. This meets all given criteria (Same criteria as “Rocking
Amplitude”. The test is considered a success.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Submodule “Heartbeat”
3 Design Descriptions
3.1 Submodule “Heartbeat”
3.1.1Goals and Guidelines for the Submodule “Heartbeat”
Aligned with Sections 1 and 2, our primary objective for the "Heartbeat" submodule is to safely
attach a measuring device to the baby. We plan to use an elastic for this purpose, ensuring
comfort. Additionally, our goal is to accurately interpret all four types of heartbeat patterns
generated by the LED and convert these into BPM values, which will then inform the stress level
calculations.
3.1.2Design choices for the Submodule “Heartbeat”
Figure 6 heartbeat circuit

For the heartbeat detection design, we have selected a myDAQ kit paired with a breadboard for
the prototype circuit. This circuit incorporates an NSL 19M51 Light Dependent Resistor (LDR),
chosen for its suitable resistance characteristics. An LDR is made from a high-resistance
semiconductor material that absorbs photons and, depending on the light intensity, releases
electrons into the material. In the dark, an LDR has a high resistance, which can be in the order
of megaohms (MΩ). When exposed to light, the resistance drops; the brighter the light, the
lower the resistance, going down to a few hundred ohms in strong light. They are cheaper
compared to other light-sensing devices like photodiodes or phototransistors.
Our decision to use this particular LDR was further informed by direct experimentation using a
multimeter, where we determined its resistance to be around 70 Ohms under standard lighting
conditions.
The circuit also includes an LED (2V, 0.02A) and a resistor. The LED is used to check whether
LDR is working. We calculated the resistor value using Kirchhoff’s voltage law: Given our input
voltage of 5V and the LED voltage of 2V, we calculated a required resistance of 150 Ohms.
Subtracting the LDR’s resistance, we determined the ideal resistor value to be 80 Ohms.
5 (our input voltage) – 2 (the voltage of the light) = 3 volt left.
3V/0.02A = 150 Ohm
150 – 70 = 80 Ohm
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
V out
Figure 7 heartbeat circuit diagram
This setup allows us to detect the light variations from the LED beneath the baby's skin and
convert these signals into BPM values. The myDAQ kit interfaces with our computer. This way
we can see if the LDR receives light on the computer. If it receives light in periods we can
calculate the frequency of this in Hz. To calculate the BPM we will have to multiply the
frequency in Hz by 60.
When we have the bpm we are able to calculate the percentage stress. The formula we derived
from the given graph in the documentation is:
Equation 1
𝑠𝑡𝑎𝑟𝑡 𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑎𝑔𝑒
(𝑏𝑝𝑚 − 𝑏𝑝𝑚 𝑎𝑡 𝑠𝑡𝑎𝑟𝑡 𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑎𝑔𝑒) ∗ (𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑎𝑔𝑒 ℎ𝑖𝑔ℎ𝑒𝑠𝑡 − 𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑎𝑔𝑒 𝑙𝑜𝑤𝑒𝑠𝑡)
+
𝑏𝑝𝑚 ℎ𝑖𝑔ℎ𝑒𝑠𝑡 − 𝑏𝑝𝑚 𝑙𝑜𝑤𝑒𝑠𝑡
Equation 2
(𝑏𝑝𝑚−60)∗(100−10)
Percentage stress = 10 +
240−60
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
3.1.3 Design alternatives for the Submodule “Heartbeat”

Alternative 1: using a phototransistor
Phototransistors offer higher responsiveness and accuracy compared to LDRs, particularly in
environments with variable lighting.
v out
Figure 8 heartbeat alternative 1 circuit diagram
A phototransistor is a light-sensitive transistor. A phototransistor, light hitting the base-collector junction

generates a photocurrent that allows a larger current to flow from the collector to the emitter. When light
photons with enough energy strike the phototransistor, they generate electron-hole pairs in the base
region. The base-collector junction is designed to be sensitive to light so that the generated photocurrent
can be amplified.
The circuit includes a phototransistor with Mfr. No of LPT 80A, a Led with Mfr. No: C5SMF-RJE-
CU14QBB2, a resistor and a voltage source of 5 V. The phototransistor and LED are in series with the
resistor and powered by the 5V source. The LED has a voltage of 2V for the LED and a desired current of
20mA, we can calculate the resistor value using Ohm's Law:
R=(Vsupply-Vled)/I led
Where Vsupply is the supply voltage 5V, Vled is the LED's forward voltage 2V, and I_led is 20mA or
0.02A.
To calculate the resistor value:
R=(5V-2V)/0.02A
The calculated value for the resistor to achieve a current of 20mA with a 5V supply and a voltage of 2V
for the LED is 150 ohms.
Phototransistors are more sensitive to light than LDRs and faster in response to changes in light intensity.
They are sensitive to light from a particular direction, and they are usually more expensive than LDRs.
LDRs can detect light from all directions, however, they have a slower response time to changes in light
intensity compared to phototransistors. Their resistance is also affected by temperature, which can be a
disadvantage in some applications. The characteristics of LDRs can change over time with exposure to
light. LDRs are simple, easy-to-understand components. They are generally cheaper than
phototransistors. And they are smaller which is more comfortable for the baby.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
In conclusion, while phototransistors have their merits, the simplicity, cost-effectiveness, and
omnidirectional light sensing capabilities of LDRs make them a more suitable choice for our
needs. Their ease of integration into a variety of circuits without requiring complex support
components is particularly beneficial and LDR are more comfortable to wear for baby. All in all,
these factors are why we chose an LDR for our application.
Alternative 2: Light-to-Frequency Converter

A light-to-frequency converter is a device that converts light intensity into a corresponding
frequency of electrical pulses. Comparatively, an LDR (Light-Dependent Resistor) changes its
electrical resistance in response to changes in light intensity.
Light-to-Frequency Converter: Converts light intensity directly into a digital square wave signal
with a frequency proportional to light intensity. Provides a digital output that can interface
directly with microcontrollers or digital circuits.
Light-to-frequency converter offers a more precise measurement of light intensity than an LDR
and typically has a faster response to light intensity changes.
However Light-to-frequency converter is more complex to implement in a circuit, often requiring
additional electronic components and it’s generally more expensive than LDRs.
v out
Figure 9 heartbeat alternative 2 circuit diagram

The circuit includes a Light to Frequency converter the TSL230, a Led with Mfr. No: C5SMF-RJE-
CU14QBB2 , a photodiode (often this is built in the Light to Frequency converter) , a resistor and a
voltage source of 5 V.
The LED has a voltage of 2V and Iled is 20mA, the LED is connected in series with the photodiode input
of the LTF converter. When light falls on the photodiode it generates a signal that influences the LTF.
R=(Vsupply-Vled)/I led
To calculate the resistor value:
R=(5V-2V)/0.02A
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Submodule “Crying”
The calculated value for the resistor to achieve a current of 20mA with a 5V supply and a voltage of 2V
for the LED is 150 ohms.
Considering these points, for this application requiring simple light, where simplicity, cost-
effectiveness, and lower power consumption are prioritized over the high precision and quick
response provided by light-to-frequency converters, we have chosen to use an LDR. Despite its
slower response and non-linear output, the LDR's passive nature and ease of use make it well-
suited for our application.
3.2 Submodule “Crying”

3.2.1 Goals and Guidelines for the Submodule “Crying”
The goals for this submodule are still the same as in section 1 and 2. The main goal is to filter
out the background noise from the crying sound, so that we can accurately determine the
volume of the crying sound and send this signal to the decision-making submodule.
Another goal is to send the received signal from the heartbeat submodule to the decision-
making submodule.
3.2.2 Design choices for the Submodule “Crying”

First, the microphone picks up the crying sound from the baby. This crying sound still contains
background noise which needs to be filtered out before determining the crying volume. The high
frequency noises produced by the microphone also need to be filtered out.
To do this, we first use the myDAQ to determine the frequency ranges of the background noise,
the crying sound, and the high frequency noise produced by the audio, using the audio files in
Oncourse. By doing this we found that the frequency of the background noise is much lower
than the frequency of the crying sound: The frequency range of the background noise is [6-120]
Hz, and the frequency range for the crying sound is [420-1159] Hz. The frequency of the noise
produced by the microphone has a frequency of over 10kHz, which would be filtered out. Using
this information, we decided to build a band-pass amplifier.
We are going to build this band-pass amplifier on the breadboard.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Figure 10 The Crying Submodule
First, we need to pick a cut-off frequency, so that we can calculate what values we need to
choose for the capacitor and the resistor for the high pass filter. This cutoff frequency should be
higher than the maximum frequency of the background noise, but lower than the minimum
frequency of the crying sound, to make sure no crying sound is filtered out and no background
noise is still left in. We also need to find the cut-off frequency for the low pass filter.
The cutoff frequency we chose for the high pass filter is 400 Hz. We chose this value because
the minimum frequency of the crying sound is 420 HZ, and the maximum frequency of the
background noise is 120 Hz. We picked a value close to the minimum frequency of the crying
sound, to ensure that all unwanted background noise is filtered out. For the capacitor value we
chose 1uF, and for the resistor value we chose 390 Ohms. As we used the cut-off frequency
formula that stated:
F(c)=1/(2*π*R*C)
Since we chose 400 Hz as our cutoff frequency, we can fill this in in the formula.
400=1/(2*π*R*C)
This leaves us with 2 unknown variables R and C. From this formula you can calculate R*C.
After doing this we found out that R*C was equal to 1/800*π, which led to us picking 1uF for the
capacitor value and 390 Ohms for the resistor value, because multiplying these values gives
you approximately1/800*π:
The cutoff frequency we chose for the low pass filter is 2kHz. We chose this value because the
maximum frequency for the crying volume is 1159 Hz, and the minimum value for the noise
produced by the microphone is 10kHz. We chose this value close to the maximum frequency of
the crying volume, to ensure that all unwanted noise from the microphone is filtered out. For the
capacitor value we chose 1uF, and for the resistor value we chose 81 Ohms.
F(c)=1/(2*π*R*C)
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Again, filling in the 2kHz in the formula leaves us with the unknown variables R and C. After
calculating that R*C in this case is equal to 1/800*π, we picked the values 1uF and 81 Ohms for
our capacitor and resistor.
We also used a UA741 op-amp for the band pass amplifier.
Figure 11 bandpass amplifier circuit

This is a schematic diagram of the circuit we built. For the R1 and R2 resistor values, we
calculated that the ratio R2/R1 should be 39, so we picked 39k for R2 and 1k for R1.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
3.2.3 Design alternatives for the Submodule “Crying”

Alternative 1: Instead of building a bandpass amplifier we could build a high-pass filter that
would filter out the background noise from the actual crying sound. Then we would build an
amplifier as the microphone would output a low-value signal, in order to properly be able to
analyze the values. For the high pass filter, we would use the same values as we did for
building our final circuit.
We already did this type of circuit before we knew that the best option would be a bandpass
amplifier, but during tests we saw that there are also unwanted frequencies past the crying
ones, so we opted for the option of building a bandpass amplifier.
Figure 12 low pass filter with operational amplifier circuit
The downside here would be that all unwanted frequencies past our crying frequency would
also pass through, which would not happen when building a bandpass amplifier.
Alternative 2: As an alternative we could just build firstly a high-pass filter and a low-pass filter,
and then build an amplifier. Again, when building that we would use the same values for both
the high-pass R and C and the low-pass R and C.
The downside of choosing this alternative would be that building the same circuit but with
another order of the components might not be as effective for a band-pass amplifier since
amplifying the signal before filtering might amplify unwanted frequencies or noise. In our case,
we would first filter and then amplify which would not lead to this happening.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Submodule “Decision Making”
Figure 13 crying submodule alternative circuit
3.3 Submodule “Decision Making”

3.3.1Goals and Guidelines for the Submodule “Decision
Making”
Our goals and guidelines are aligned with our old goals. We should be able to calculate stress
level using the heartrate and crying volume. Based on this value and the current state of the
matrix we must be able to decide how to proceed. Finally, we will send frequency and amplitude
to the motor's drivers.
3.3.2Design choices for the Submodule “Decision Making”

First our algorithm starts with sending the maximum amplitude and frequency (0.70 Hz, 100%).
Then it starts with lowering the amplitude, if the baby does not get calmer the algorithm starts
with changing the amplitude. The algorithm responds as soon as it can respond to a certain
change in the crying volume or heart rate. We think it does not matter if we change the
amplitude first and then the frequency, since when we do it the other way around our algorithm
will not take a longer or shorter time.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Figure 14 decision-making algorithm logic

In this picture you see the logic of our algorithm, first it tries to go left(change the amplitude), if
the baby does not get calmer, it goes back and then changes the frequency (that is in this case
up) and if it notices again that the baby does not get calmer then it starts to change the
amplitude again.
Timing
After taking a step in the matrix, the submodule waits for the stress level to change (based on
the incoming heartrate and crying volume). Once this has changed and has stabilized, the
algorithm can proceed.
If the stress level has not changed after some amount of time (for example: 10 seconds), the
submodule will assume it has made a wrong turn (because stress level should decrease on
every step) and will take a step back. Then, the algorithm can continue.
Note that both the time to wait for the stabilization of the stress level and the time to wait for the
signal to change remains undefined. These values will be determined by testing with the cradle
setup and will mostly be determined by the heartrate's delay to a change in stress level.
Testing:
The way we know if our algorithm works is by simulating. First, we made an algorithm that
makes a matrix with random numbers in it. It is important to note that this random matrix does
not pick up any input from the other submodules, it simulates so the values in this matrix are
completely random. Through that matrix we set a path from 1 to 9 those numbers represent the
stress levels of the baby. Then we use our algorithm to look if it will find the correct path through
that matrix. On the display we can see the answer in the right picture.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Figure 14 decision making pynq display

Figure
The yellow blocks have the same or a higher value than the stress level our algorithm is
currently on, so they get marked yellow and our algorithm will ignore that tile next time. And the
blue block is the place where the algorithm is currently checking the stress level.
To test the full system, the submodule will need to be able to use the signals from the sensors
and send a signal to the motors drivers, rather than working in a simulated matrix.
Inverse Model:
If the rocking amplitude and frequency are at a maximum, then we know for certain that the
baby is at the maximum stress level. The rocking amplitude and frequency are always known,
and the stress level can be calculated (with the heartrate and crying volume). However even if
all these values are known, there will not be a set relation between these values, because every
baby is different. That is why we need to explore the behavior of our baby to see how it
responds to different rocking amplitudes and frequencies.
Figure 15 explanation stress level

Figure explanation stress level
In the picture above S optimal is the suitable stress level for this column. If the current stress
level is S optimal and the motion remains unchanged, it will not change. S panic means a way
to high amplitude or frequency is being used, for the current stress level of the baby.
When the stress level increases, the algorithm can decide to take a step back in the matrix.
If the baby starts panicking, the frequency or amplitude should be reduced to initial conditions.
The algorithm can then traverse through its original path, until the last step. There it will take a
different step than it previously did.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
The stress matrix will be explained down below:
Figure 16 stress matrix example

In the picture above, there is an example of how a certain baby responds to different amplitude
or frequency values. A baby can have the maximum stress level (K9) for multiple values, but
since the amplitude and frequency are determined by our submodule. We can always trace our
steps back if the baby goes on rampage.
3.3.3 Design alternatives for the Submodule “Decision

Making”
Alternative 1:
This algorithm will first try out our current algorithm. when it notices that the baby is not getting
calmer. It goes all the way back to the maximum frequency and amplitude values. Eventually,
the algorithm remembers what values it already tried, so it will try all the same values until the
point it went wrong and then it will go in the other direction.
Figure 17 decision making process

In this figure you see the algorithm trying to make the baby calm and when the baby does not
get calmer, it goes back to the maximum amplitude and frequency.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Submodule “Motors drivers”
In comparison with our normal algorithm, alternative 1 is inefficient, since it will check a lot more
stress levels than our normal algorithm. We cannot compare this alternative to alternative 2,
since this alternative changes the way our algorithm takes decisions, and the second alternative
does not touch the way our algorithm thinks.
Alternative 2:
As the second alternative we chose to wait for a constant delay after every step before our
algorithm chooses the amplitude and frequency. (for example: 10 seconds). (Instead of
continuing when a change in stress level is observed). This way the decisions might be more
reliable, at the cost of some speed otherwise gained by skipping the wait.
Again, the exact amount of time to wait must be determined through testing. In general, a longer
delay will make the data more reliable, while a shorter delay will allow the system to calm the
baby more quickly.
Because of the (possible quite significant) reduction in speed this alternative was not chosen.
By tuning the selected algorithm well, we are confident we can get fast, reliable decisions.
3.4 Submodule “Motors drivers”

3.4.1Goals and Guidelines for the Submodule “Motor drivers”
Our goals and guidelines are aligned with section 1 and 2. The goal of the Motors
Drivers submodule is to send two PWM signals to the motors. One signal contains
information of the amplitude and the other of the frequency of the cradle. The
information is received from the Decision-Making submodule. According to the
requirement of the motors to be working; both signals should have a constant amplitude
of 12V, a constant frequency of 1k Hz and should be able to supply at least 0.8A of
current.
Constraints:
• Not having ideal components: This might cause an unstable output of signals.
Therefore, the rocking amplitude and frequency might not be able to calm the
baby down
• Not being able to cooperate with the decision-making submodule: If the
data, being the frequency and amplitude, are not received simultaneously as the
baby’s stress level changes, the output from the motors-drivers submodule will
not reflect the correct signals.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
3.4.2 Design choices for the Submodule “Motor drivers”

Initially two digital UART signals are received with amplitudes of 5V (usually less), from
the decision-making submodule (the PYNQ-board). These signals contain information
about the duty cycle for the frequency and the amplitude of the working motors of the
cradle.
To deliver sufficient power to the motors, the signals need to be tuned to have a
constant amplitude of 12V and should be able to supply at least 0.8A of current. To
achieve this, we have decided to design a circuit that can amplify both signals. The
signals will have an amplitude of 5V at maximum and they are being sent from the
PYNQ-board. The aim is to have them amplified into signals with amplitudes of 12V
while keeping the original information of the duty cycle intact.
Figure 18 the Motors-Drivers submodule setup

According to this diagram, an outer power supply is connected to the backbone of the
submodule-board. Therefore, the purpose of the circuit design is to allow the current to
flow to the cradle so that the 12V power will reach the motors. The term ‘amplify’ is used
to indicate the allowance of the current flow. Thus, the transistor will be utilized as a
switch which controls the transmission of the power from the power supply that will be
set to 12V and at least 0.8A.
The fundamental purpose of the transistor is to allow the flow of current from the power
supply when it receives the signal containing the information from the PYNQ-board.
When no signal is received the circuit will remain as an open circuit and no current will
flow.
In order to test the circuit design, we first used the LTspice software in the aim of
targeting the weaknesses and strengths of the design on a conceptual level.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Figure 19 Circuit design built on LTspice
Figure 20 Graph of initial and amplified signal
In this graph the green signal demonstrates the input signal received from the PYNQ
and the blue signal demonstrates the output signal sent to the motors. The blue signal is
measured over the transistor thus it is clear that the circuit works according to the
requirements.
Later, we proceeded to test the circuit design on the actual sub-module board.
In this design, a program

specifically written for this sub-
module sends PWM signals
from the PYNQ-board imitating
the frequency and amplitude
signals received from the
decision-making submodule.
The ports AR3 and AR4 are
used as the output of the
PYNQ. As seen in the figure,
one end of the cable is
connected to a port and the
Figure 21 Circuit design built on the sub-module board
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
other is connected to the 10K ohm resistor and an NPN transistor (TIP132 Darlington
Transistor). The 10K ohm resistor here (which one end is grounded) acts as a protective
element by limiting the current entering the transistor to prevent any damage to it. In
addition, this specific transistor was chosen since this is a low-voltage application. Also,
BJTs have a lower voltage drop between the collector and emitter compared to
MOSFETS. This property will ensure a stable output as much as possible.
The Collector of the transistor is connected to ground, the Emitter is connected to the
motors (Motor F for frequency and Motor A for amplitude) and the Base is connected to
the AR3 and AR4 ports. The power source is set to supply a constant power of 12V and
a minimum of 0.8A of current. When a signal is received the switch closes, enabling the
12V power to be supplied to the motors. Therefore, the duty cycle from the square wave
with an amplitude of 5V (or less) will be mirrored as the signal with an amplitude of 12V
containing the same information. So, the data received from the decision-making
submodule will be transferred to the motors who will work according to the duty cycle of
these signals.
The circuit was tested using an oscilloscope to

measure the PWM signals received from the
Figure 22 Graph of the input and output signals PYNQ-board and the output signals from the
obtained from an oscilloscope circuit. The green signal demonstrates the
input signal received from the PYNQ and the
yellow signal demonstrates the output signal which is sent to the motors. This
demonstration clearly shows that the circuit design allows the current to flow in and out
of the circuit by utilizing the transistor as a switch. Therefore, the 12V power from an
outer power supply can be supplied to the cradle motors as a signal with the same duty
cycle as the first received signals, which satisfies the requirements. This circuit design
also allows the signals to supply 0.8A of current.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
3.4.3Design alternatives for the Submodule “Motor drivers”

As an alternative we have considered
building an amplifier circuit to directly
amplify our output signal from the PYNQ-
board. We designed a circuit which uses
an op-amp to amplify the signal to the
desired amplitude, while retaining the
desired frequency(1KHz). This way we
could use the original signal from the
PYNQ-board and send it directly to the
motors after amplifying it.
Figure 23
19 Alternative circuit design motor drivers
However, this design alternative does not
serve the purpose of the requirements for the motors to work. The argument is that there is a
12V power supply connected to the cradle and the aim is to transfer that power to it. Therefore,
the most efficient way is for the transistor to be used as a switch that allows the current to flow
to the cradle. Here, the transistor is used as an amplifier. Although the duty cycles are correct
and the initial signal is amplified, this approach to the problem does not propose an efficient or
correct solution. Thus, this design fails to coordinate with the system as a whole.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Alternative 2:
A sinewave generator is used to supply a square

wave signal to the transistor. The signal first goes
through the 1K ohm resistor which limits the flow of
current.
A 12V DC power supply is then connected to the
transistor so when the switch is closed, and the
current can flow through the 100K resistor
(representing the cradle). Therefore, the duty cycle
from the square wave with an amplitude of 5V
would be mirrored to the signal with an amplitude
of 12V.
An NPN transistor (2N4401) is chosen to be used
in this circuit since a low voltage DC is present.
The circuit was later tested on an actual Figure 24

6. Figure
20 Alternative
7. Alternative
circuit design
circuit design
breadboard. The green signal is the frequency signal coming from the PYNQ-board and
the yellow signal is the output signal. Here you can see the amplified signal, now with
an amplitude of 12V. However this is not a proper PWM signal.
Although this design achieves to actually ‘amplify’ the signals, it fails to meet some of
the requirements. One reason for this is that the excess current flow caused damage in
the transistor. To prevent this, the transistor was later changed to a MOSFET (IRF540)
in the same circuit. That did not work as well since the threshold voltage for any
MOSFET available was higher than the voltage of signals received from the PYNQ.
Also, in either of these circuit designs with different transistors the signals were not able
to supply 0.8A of current.
Another reason this alternative failed is that the program written to imitate the original
signals could not send proper PWM signals.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Test of Submodule “Heartbeat”
4 Tests at Submodule level (Sub-system level)

4.1 Test of Submodule “Heartbeat”
4.1.1Functional Validation of the Submodule “Heartbeat”
4.1.1.1 Functional Validation of “The Heartbeat submodule must accurately detect

the baby's heart rate using a sensor that can capture the LED's intensity
pattern located under the baby's skin.” the Submodule “Heartbeat”
In this functional validation, we employed a practical approach to simulate real-world conditions.
An LDR (Light Dependent Resistor) was placed on the baby's hand to capture the LED's
intensity pattern under the skin. This emulates the envisioned setup where the submodule is
designed to detect the baby's heart rate through the skin. The tests were conducted with
different heart rates. Clear square heartrate and heartrate with glitches.
Clear heartbeats were simulated, and the LDR successfully captured the LED's intensity
pattern. The recorded stress levels closely matched those displayed on the monitor.
To account for potential variations or glitches in the heart rate signal, intentional irregularities
were introduced. The submodule effectively managed to discern stress levels even in the
presence of these glitches, demonstrating its robustness.
The system was tested under variable heart rates, ensuring that the submodule accurately
adjusted to different intensities. The LDR consistently captured the LED's intensity patterns, and
stress levels were appropriately reflected.
The success of these tests affirms the submodule's capability to accurately detect the baby's
heart rate under realistic conditions. The utilization of an LDR on the baby's hand proved
effective in capturing LED intensity patterns, highlighting the robustness of the submodule in
handling different heart rate scenarios. This validation builds confidence in the submodule's
reliability and performance in a real-world application, laying a solid foundation for its integration
into the overall product.
4.1.1.2 Functional Validation of “The system must display the measurements and
continuously update the current heart rate in BPM, presenting this
information in a clear and user-friendly manner.” the Submodule “Heartbeat”
To ensure the user-friendly presentation of the baby's heart rate information, the system was
designed to continuously update and display stress percentages on the LCD placed on the
PYNQ board. The Heartbeat submodule was programmed to update and display the baby's
stress percentage on the LCD every 5 seconds. The displayed information included the current
heart rate in BPM along with corresponding stress levels. The information presented on the LCD
was designed in a clear and user-friendly manner, allowing caregivers to easily interpret the
baby's physiological status.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Test of Submodule “Heartbeat”
The BPM readings presented on the LCD were cross verified with the actual heart rate
measurements obtained from the LED's intensity pattern captured by the LDR.
4.1.1.3 Functional Validation of “The heartbeat submodule must be able to measure

the heartbeat no matter the way the heartbeat will be emulated.” the
Submodule “Heartbeat”
The Heartbeat submodule has been rigorously tested to ensure its capability to measure the
heartbeat accurately. Several scenarios were considered to evaluate the submodule's
performance in diverse conditions: Clear Square Heartbeat and Heartbeat with Glitches.
Emulating a clear square waveform, the Heartbeat submodule consistently and precisely
measured the heart rate. The submodule successfully captured the LED's intensity pattern,
providing reliable heart rate information.
In scenarios where the heartbeat signals included glitches or irregularities, the Heartbeat
submodule demonstrated resilience and accuracy in measuring the heart rate.
Glitches in the LED's intensity pattern was effectively accounted for, ensuring dependable
measurement.
For verification, the measured heart rate information from the Heartbeat submodule was
compared with the BPM values displayed on the monitoring system. The observed information
consistently matched the values shown on the monitor, confirming the accuracy and reliability of
the Heartbeat submodule.
This successful functional validation underscores the submodule's effectiveness in handling
different heartbeat patterns and variations. Whether it's a clear square waveform or a heartbeat
with glitches, the Heartbeat submodule ensures that the measured heart rate aligns with the
expected values, contributing to the overall precision and trustworthiness of the product.
4.1.2Interface Validation of the Submodule “Heartbeat”

4.1.2.1 Interface Validation of the Submodule “Heartbeat” “Any deviations in heart
rate should be promptly reported to the Decision-Making submodule.”
This crucial functional validation ensures that the Heartbeat submodule promptly detects any
deviations in the baby's heart rate and effectively communicates this information to the Decision-
Making submodule. The seamless integration between these two submodules is vital for timely
decision-making and appropriate responses to variations in the baby's condition.
The LDR captured these variations in the LED's intensity pattern under the baby's skin. The
captured heart rate peaks were promptly communicated to the Decision-Making submodule for
stress level calculation. The Decision-Making submodule accurately received the heart rate
information and calculated stress percentages based on the provided algorithm. The calculated
stress percentages, derived from the reported deviations in heart rate, consistently matched the
BPM values displayed on the monitor. This synchronization between the reported deviations and
the expected BPM values confirms the effectiveness of the communication between the
Heartbeat and Decision-Making submodules. The success of these tests underscores the robust
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Test of Submodule “Crying”
communication and interaction between the Heartbeat and Decision-Making submodules. Any
deviations in heart rate were accurately detected, reported, and processed to determine the
corresponding stress levels.
4.2 Test of Submodule “Crying”

4.2.1Functional Validation of the Submodule “Crying”
4.2.1.1 Functional Validation of “Able to obtain measurements from the cradle

microphone” the Submodule “Crying”
In order to achieve this we connected the microphone to the breadboard and we checked its
functionality by speaking into it.
Using the myDAQ from the HomeLab kit, we analyzed the received signals through its
oscilloscope function to verify it was working properly.
Figure 25 Oscilloscope view of bandpass amplifier
4.2.1.2 Functional Validation of “Able to separate the crying sound from the
background noise picked up by the microphone” the Submodule Crying.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
We were able to fulfill that requirement by building on the breadboard a bandpass amplifier and
just at its beginning we connected the microphone so the picked-up crying noises are being
filtered out from background noises that might have both low and high frequencies
We can easily see a difference between the unfiltered signal and the filtered one, as the
unfiltered ones is far more random, meaning that it fluctuates much more than the final one, that
displays only the frequencies between [420, 1159] Hz.
Figure 26 Oscilloscope view of the bandpass amplifier

Above there is the signal from the microphone, in green, when the band-pass amplifier works,
which is in blue.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Figure 27 Oscilloscope view of the sound signal that is not filtered or amplified
In the case above the band-pass amplifier is not connected to what the microphone receives,
therefore the signal is not filtered and amplified.
4.2.1.3 Functionality Validation of “Able to analyze the crying sound and calculate a
crying volume” the Submodule Crying.
We first tested the ability to analyze the crying sound by connecting the microphone to the
circuit and the circuit to the mydaq. This way we knew that the microphone and the circuit were
working properly. As can be seen in the pictures from section 4.2.1.2, the signal is correctly
amplified, and the low and high frequencies are filtered out correctly. After that, we connected
the circuit to the pynq board, and we used the ADC library, (analog to digital conversion), to
make sure the signal output from our circuit could be displayed on the pynq board, and the
crying volume could be calculated from the output signal. We did this by measuring the
loudness of the crying sound throughout the first 5 seconds, since the crying volume is the
highest at this point. The maximum volume measured within these 5 seconds is taken as 100%
crying volume. Afterwards, the volume is projected as a percentage of the maximum volume.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Test of Submodule “Decision Making”
4.2.1.4 Functionality Validation of “Able to send the crying volume to the Decision-
Making submodule.”
The crying volume is projected on the crying submodule PYNQ, and is sent to the decision-
making submodule. On the display from the decision-making submodule, there can be seen that
the crying volume signal has been received. This signal gets sent using the UART library.
4.2.2Interface Validation of the Submodule “Crying”

4.2.2.1 Interface Validation of the Submodule “Crying” – “Heartbeat”
The heartbeat signal is correctly received and directly forwarded to the decision-making
submodule.
4.2.2.2 Interface Validation of the Submodule “Crying” – “Crying Volume.”

The Crying volume signal is correctly received from the microphone connected to the circuit.
The background noise is filtered out of the noise so the only thing that is left is the crying sound.
The output signal in mV and the crying volume percentage are correctly received and projected
on the PYNQ.
4.3 Test of Submodule “Decision Making”
4.3.1Functional Validation of the Submodule “Decision

Making”
4.3.1.1 Functional Validation of “Able to calculate the current stress level from the
given input (crying volume and heartrate).” the Submodule “Decision
Making”
To test whether the decision making submodule is able to achieve this, we manually entered
several different combinations of crying volume and heartrate into the submodule. We then let it
calculate the corresponding stress level and compared these to our own calculations.
For every set of values we entered, the submodule was able to produce the correct stress level
from the given inputs.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
4.3.1.2 Functional Validation of “Able to decide how to most efficiently traverse

through the stress matrix. & Able to display the current progress of calming
down the baby. ” the Submodule “Decision Making”
We used an algorithm that produced a random matrix, this matrix represented the stress level of
the baby. We then used that matrix to see if our algorithm can traverse through a matrix without
getting stuck.
Figure 28 Multiple steps of the matrix displayed on the PYNQ LCD screen
We also made a graphical interface that shows where our algorithm currently is in the stress
matrix. The blue block shows where the algorithm is, the yellow block shows where it has been,
and the green block shows the current path. The test was successful if the algorithm could
reach the opposite corner of where it started, in the picture you can see that the test was
successful.
4.3.1.3 Functional Validation of “Able to communicate the desired frequency and

amplitude of the rocking motion to the Motors drivers Submodule.” the
Submodule “Decision Making.”
The decision making submodule is able to communicate to the motors drivers submodule. See
sections 4.3.2.3 and 4.3.2.4 for more details.
4.3.2 Interface Validation of the Submodule “Decision Making”

4.3.2.1 Interface Validation of the Submodule “Decision Making” – “crying volume”
The crying volume signal is correctly received from the crying submodule. (The crying
submodule's output is equal to the decision-making submodule's input). The decision-making
submodule is then able to use this value to calculate the stress level and traverse the matrix.
4.3.2.2 Interface Validation of the Submodule “Decision Making” – “heartrate”

The heartrate is correctly received from the heartrate submodule. The decision-making
submodule is then able to use this value to calculate the stress level and traverse the matrix.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>

amplitude”
The right rocking amplitude is correctly sent from the decision-making submodule to the motors
drivers submodule. The motors drivers submodule then correctly displays it has received this
signal.

frequency”
The right rocking frequency is correctly sent from the decision-making submodule to the motors
drivers submodule. The motors drivers submodule then correctly displays it has received this
value.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Test of Submodule “Motors drivers”
4.4 Test of Submodule “Motors drivers”

4.4.1Functional Validation of the Submodule “Motors drivers”
4.4.1.1 Functional Validation of "Able to interpret the combined amplitude and
frequency data and convert it into useful information for motor drivers" the
Submodule “Motors drivers”
We first tested our ability to send out two separate signals to the motors containing information
of the required amplitude and frequency duty cycles. In order to actually being able to send any
signal to the motors we built a simple transistor circuit which the power requirements will be
evaluated in the next subheading.
We checked if the circuit was successful of transferring the signal received from the PYNQ
board using an oscilloscope by measuring both input and output signals. After making sure that
the signals are individually amplified we tested the submodule by connecting it to the RYB setup
and generated manual PWM signals to see if the system actually received our amplified signal.
This was validated by observing the working of light bulbs on the RYB setup. The lights were on
if the signal was received and off if not.
Figure 29 The baby setup’s lights turn on when the signals are received
And finally, we connected our submodule to the decision making-submodule to find out if we
can interpret the combined amplitude and frequency and send that to the motors. For that
purpose, the decision-making submodule sent out arbitrary amplitude and frequency signals.
Then, it was observed that the two submodules were successfully working together as the
values sent from decision making were displayed both on PYNQ and RYB setup screen. At the
end we were able to calm the baby down by correctly interpreting the signals and sending them
to the motors without any obstacles.
4.4.1.2 Functional Validation of “Able to provide the required amount of power to the
motors in order to initiate movement in the cradle.” the Submodule “Motor
drivers.”
For the motors to initiate movement in the cradle our circuit needed to supply at least a current
of 0.8A and a voltage of 12V. To do this, we needed to amplify both signals from <5V to 12V. In
order to do that we had built a circuit that mainly uses a transistor that will behave as a switch.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
The output signal from the PYNQ-board, that contains the duty cycle information, controls that
switch. That is possible as the duty cycle is actually just the timeframe of the power delivered
and thus the switch stays closed as long as the duty cycle is present otherwise it stays opened.
Figure 25
Voltage of 12V supplied from an outer power source. Also a

demonstration that the signals can supply at least 0.8A of
current.
The switch is then connected to a power supply that can provide us the 12V and >0.8A. The
switch will then allow the power to go from the power supply to the motors when it’s closed with
the according duty cycle from the PYNQ-board. Therefore, the motors will receive the same
duty cycle information that was received from the decision-making submodule but this time with
12V instead of <5V and around 0.8A.
Figure 30
26 The PWM-signal from the PYNQ-
Figure 31
27 circuit with two transistors
board
Figure 27
The PWM-signal from the PYNQ-board (green

one) and the amplified output signal (yellow one) Circuit that was built with two transistors. One
on an oscilloscope. transistor is for the amplitude signal and the other
is for the frequency signal.
4.4.1.3 Functional Validation of “Able to start, stop or change the speed of the
cradle’s motion” the Submodule “Motor drivers.”
Our submodule can start, stop or change the speed of the cradle’s motion by interpreting the
command from the decision-making submodule. When we send out a duty cycle of zero, the
cradle doesn’t rock and when we send out a duty cycle of 0-90% the cradle will rock. The speed
of the cradle’s motion is controlled by the varying values of the amplitude and the frequency
duty cycle. This is validated by directly observing the movement of the cradle.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
4.4.1.4 Functional Validation of “Able to maintain high voltage input for initiating or
sustaining movement in the cradle” the Submodule “Motor drivers.”
Our circuit should be able to handle a high voltage that we send manually from an outer power
supply because the high voltage doesn’t go through the part of the circuit that regulates the
switch. The 12V only travels through the transistor and that can handle more than 12V. If not the
transistor will heat up and eventually get burnt.
This is validated by observing the movement in the cradle for a certain amount of time. This
means the circuit works consistently and seamlessly, so the transistors can maintain a high
voltage.
Functional Validation of "Able to display the duty cycle information of the PWM
signals sent to the motors.” the Submodule “Motor drivers.”
The duty cycle information of the PWM signals are displayed both on the PYNQ and RYB setup
screens. The software of motors drivers was composed accordingly. This will be validated in
detail in section 4.4.2.
4.4.2 Interface Validation of the Submodule “Motors drivers”

4.4.2.1 Interface Validation of the Submodule “Motors drivers” – “Rocking
Amplitude”
The signal of rocking amplitude with the correct duty cycle is received from the decision-making
submodule. The amplitude percentage and the duty cycle values are displayed on the PYNQ
LCD screen. The duty cycle is also visible on the RYB setup screen. As the baby keeps crying
its stress level and heart rate changes, thus the rocking amplitude changes accordingly. Each
different value of rocking amplitude, thus duty cycle value, is simultaneously displayed on both
screens. The change is also observed on a bar graph on the RYB setup. The input amplitude
from decision-making submodule appears on the top of the screen and the output amplitude
that is sent to the motors appears in the middle.
4.4.2.2 Interface Validation of the Submodule “Motor drivers” – “Rocking

Frequency”
The process of receiving and sending the rocking frequency is the same as the process of the
rocking amplitude signal. The information of the frequency and its required duty cycle is first
received from the decision-making submodule. These values are simultaneously displayed on
the LCD screen of the PYNQ. Then the rocking frequency signal is sent to the motors through
the transistor circuit and can be interpreted by the motors in the setup. This can be validated as
the duty cycle value for the rocking frequency that is also displayed on the LCD screen of the
RYB setup. The input frequency from decision-making submodule appears on the top of the
screen and the output frequency that is sent to the motors appears in the middle.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Test of Input signals of the product after integration
5 Tests at Product level (System level)

5.1 Test of Input signals of the product after integration
5.1.1Functional Validation of the Input signal “Heartbeat” of
the product after integration
We can see with the led on the heartrate circuit that pulses are being measured. On the display
of the decision making pynq board we can see that the heartrate signal has been received. With
the display of the baby setup, we can see that the conversion from pulses to bpm is right,
therefore we can say that the pulses are being measured accurately.
5.1.2Functional Validation of the Input signal “Crying” of the

product after integration
The microphone can measure the difference between different frequencies, as seen on the
display. However, the measurements were not accurate enough to be able to integrate the
crying submodule.
5.2 Test of Output signals of the product after integration
5.2.1 Functional Validation of the Output signal “Rocking

Amplitude” of the product after integration
To test if the baby setup can correctly interpret the output provided by the motor's drivers,
arbitrary rocking amplitude values were sent to first motors then the setup. Consequently, the
baby setup was able to read the signals accurately. The values for rocking amplitude in % were
displayed on the provided screen.
5.2.2 Functional Validation of the Output signal “Rocking

Frequency” of the product after integration
The same steps were followed for rocking frequency signal. Arbitrary rocking frequency values
were sent to first motors then the setup. It was observed on the setup screen that the correct
values of frequency in Hz were displayed.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
Complete V-Design Document RYB Integration Validation
5.3 Integration Validation

5.3.1Integration test: communication
The goal for this test was to ensure that each submodule can communicate with each other
seamlessly thus operate in collaboration by utilizing the UART communication protocol which is
explained in detail in section 2.
To test the integration of each subsystem, first the different submodule boards were connected
to the backbone. Then the exchanging of data between the submodules was tested. See
section 2.4 for more details on how these tests were conducted.
These tests all resulted in success. Each submodule is able to send and receive the signals
they need. These values are also shown on the display. Thus, efficient and error-free
communication was maintained.
5.3.2 Integration of the Submodules “Decision making”

and “Motors drivers”
In order to be able to test the integration of the Decision making and motors drivers
submodules, we added a “manual mode” to the decision-making submodule. This mode allows
for manually entering the heartrate and crying volume.
For this test, we ran the decision making and motors drivers submodules together. Every time
the heartrate or crying volume would change (which we could see on the baby monitor), we
manually entered these values into the decision-making submodule.
This configuration was able to calm down the baby, using our manual input. Which means the
test was passed successfully. We can conclude that the decision-making and motors drivers
submodules have been integrated successfully.
5.3.3 Integration of the submodules “Heartbeat”, “Decision

Making” and “Motors Drivers”
To test these 3 submodules, we used a similar setup to the previous test. However, instead of
using “manual mode”, we connected the heartrate submodule to the decision-making
submodule. The decision-making submodule would then wait for the heartbeat submodule’s
signal. For this test, the crying signal will be ignored.
This configuration was successfully able to calm down the baby, without needing manual input,
in under 10 minutes. This is considered a success.
5.3.4 Integration of the submodules “Heartbeat”, “Crying”,

“Decision Making” and “Motors Drivers”
To test this, we connected all 4 submodules to each other and to the baby. For this test, the
decision-making submodule will try to use both the heartrate signal and the crying signal.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
During the test, the system was able to partially calm down the baby. However, once the crying
submodule got involved, the test failed. The crying submodule’s measurements were not
reliable enough to be able to traverse the stress matrix.
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
6 Appendix A: Acronyms
Table 10 - Acronyms
Acronym Literal Translation
A Ampere
A Amplitude
BJT Bipolar junction transistor
BPM Beats per minute
C Capacitance (Farad)
Db Decibel
ECG-pattern Electrocardiography-pattern
E.g. Exempli gratia
F Farad
GPIO General Purpose Input/Output
GUI Graphical user interface
Hz Hertz
LCD Liquid crystal display
LDR Light dependent resistor
LED Light emitting diode
NPN transistor Negative-positive-negative transistor
Ω Ohm
PWM signal Pulse width modulation signal
Q1 Quartile 1
R Resistance (Ohm)
RYB Rock Your Baby
SPI Serial peripheral interface
UART Universal asynchronous receiver / transmitter
USB Universal serial bus
V Voltage
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>
7 Appendix B: Referenced Documents

Table 11 - Referenced Documents
Document
Document Location and/or URL Issue Date
Name
TIP132 TIP132 Datasheet(PDF) - Power Innovations Ltd <March1997>
Datasheet (alldatasheet.com)
RYB Course: Programming and engineering challenge <9/4/2023>
information (5EWC0), Topic: Rock Your Baby (tue.nl)
Date:
18/01/2024 Version 3 <RYB, 23/24, #20>

RYB Design Document - Group 20 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RYB Design Document - Group 20 1

Uploaded by

Copyright:

Available Formats

Team 20 / Year 2023-2024/ Project “Rock Your

1.1 Architecture and Requirement at Product Level (System level) .......................... 8

3.2 Submodule “Crying” ............................................................................................. 33

4.3.1 Functional Validation of the Submodule “Decision Making” ............................ 52

Table 1 range and rocking frequency ........................................................................... 10

1 Requirements and Architecture

1.1.1Goal of the product

1.1.2Set of Requirements at Product level (System Level)

1.1.3Description of the Inputs and Outputs at Product level

Figure 1(the frequency of heartbeat as a function of the stress percentage)

Figure 2 the crying volume as a function of the stress percentage

Table 1(ranges and rocking frequency)

1.1.4Specification of the Inputs and Outputs at Product level

Data type Analog signal

Range 0dB - maximum dB

Timing information Sampled at a rate sufficient to capture crying variations.

Table 4(Specifications of the Input signal “heartbeat input” of the product)

Data type Analog

Range 60BPM - 240BPM

Data type Digital (PWM signal)

Range 20% - 100%

Timing information Signal is continuous

Data type Digital (PWM signal)

Range 0.2Hz - 0.7Hz

Timing information Signal is continuous

1.2 Architecture and Requirement at Submodule Level (Sub-

1.2.1Overview of the product with a high-level context diagram

Figure 3 High-level context diagram

Figure 4 in depth context diagram

1.3 Goal of each submodule

1.3.1.2 Goal of Submodule “Heartbeat”

1.3.1.3 Goal of Submodule “Crying”

1.3.1.4 Goal of Submodule “Decision Making”

1.3.1.5 Goal of Submodule “Motors drivers”

1.3.2 Set of requirements for each submodule

1.3.2.2 Set of requirements for the Submodule “Heartbeat”

1.3.2.3 Set of requirements for the Submodule “Crying”

1.3.2.4 Set of requirements for the Submodule “Decision Making”

1.3.2.5 Set of requirements for the Submodule “Motors drivers”

1.4 Signals description and specifications at submodule level

1.4.1Internal signals: description, specifications, and

1.4.1.1.2 Specification of the signal “crying volume” with justification

1.4.1.2 Internal Signal “heartrate”

1.4.1.2.2 Specification of the signal “heartrate” with justification

1.4.1.2.3 Alternatives specifications of the signal “heartrate” with justification

1.4.1.3 Internal Signal “rocking amplitude

1.4.1.3.2 Specification of the signal “rocking amplitude” with justification

1.4.1.3.3 Alternatives specifications of the signal “rocking amplitude” with justification

1.4.1.4 Internal Signal “rocking frequency”

1.4.1.4.2 Specification of the signal “rocking frequency” with justification.

1.4.1.4.3 Alternatives specifications of the signal “rocking frequency” with justification.

2 Design description of the “Communication”

2.1 Goal(s) of the “Communication” submodule

2. External Interface Communication: Efficient and effective communication is not only

2.2 Design choices of the “Communication” submodule

Figure 4 Illustration of the design choice of the displays 5

4. Error Detection and Correction:

Table 7 Summary of Communication Details

Protocol . UART (Universal Asynchronous Receiver-

Inputs Data from submodules (connected to the A1

Outputs Data to submodules(connected to the A0 pin)

Data Type Float

2.3 Design alternatives of the “Communication” submodule