RF POWER MONITORING 1
Low-Cost Arduino Based Radio Frequency
Power Monitoring with Machine Learning
Exposure Map
Testing & Analysis Report
Kristjan Bruno, Cody Davies, Michael Jacques, Kihyun Lee
Activity Report
1 V ERIFICATION T ESTING Requirement: Receive a wireless signal for
Requirement: Wireless Data Transmission processing
• Status: 100% Complete • Status: 100% Complete
• Explanation: Our system uses an Arduino • Explanation: We tested this by connecting
MKRWAN 1310 board with LoRa radio a low gain antenna to a signal generator
capabilities and a Raspberry Pi 3 board. and a matching antenna to our PCB. We
We verified our system by sending test then supplied a 600 MHz signal from the
messages from the Arduino which were signal generator and connected a multime-
successfully received by the Pi board and ter to our PCB’s output. We were able to
displayed on the LoRa module for the Pi. view the DC value change with respect to
Requirement: Convert RF Signal to DC Volt- the supplied signal strength so we knew it
age received the signal.
• Status: 100% Complete Requirement: Small Size
• Explanation: Our system requires us to be
• Status: 100% Complete
able to receive a high frequency electro- • Explanation: Our system needed to be
magnetic signal and convert it to a DC small enough to be placed almost any-
voltage value. We tested our system by where. We used custom PCBs which al-
feeding in a clean 600 MHz signal from lowed us to minimize the size of our de-
a signal generator through a hardwired sign.
connection. We then connected a benchtop
multimeter to the output of our PCB and Requirement: System Scalability
viewed the DC voltage it output. Our sys- • Status: 100% Complete
tem matched the expected values based on • Explanation: Our system requires it to be
component datasheets. highly scalable in order to create a “net”
which covers an area to be monitored. We
• Kristjan Bruno, have been able to connect two Arduinos
E-mail: kmbruno@[Link]
• Cody Davies,
concurrently and have both send data to
E-mail: cwdavies@[Link] a singular Raspberry Pi and have the data
• Michael Jacques, arrive successfully.
E-mail: mtjacques@[Link]
• Kihyun Lee, Requirement: Cloud Computing Connectivity
E-mail: klee23@[Link]
• Status: 40% Complete
PP-2017 V2.1
2 RF POWER MONITORING
Explanation: Our system makes use of Mi-
•
crosoft Azure for handling and processing
the data we collect. Currently we have suc-
cessfully created an Azure IoT hub which
allows us to connect our Raspberry Pi to
the cloud, and connected a digitally simu-
lated Pi which is able to successfully send
messages containing simulated data.
Requirement: System Accuracy
• Status: 0% Complete
• Explanation: We have not yet been able to
compare our board’s accuracy to a com-
mercially available software defined radio
(SDR). We plan to use an ADALM PLUTO
SDR and compare the output results from
that to the results from our board. Figure 1. Expected voltage output of commer-
cial RF detector (LTC5530).
Requirement: Machine Learning for Data Pro-
cessing
• Status: 0% Complete to view the output of our circuit with minimal
• Explanation: Our team has been focused interference from external noise. We started
on the hardware side of our project, which at a signal strength of -32 dBm because our
includes the data collection PCB and data RF detector operates in a range of -32dBm
transfer network. Once our data has been to 8dBm. We then slowly increased the signal
collected and sent to the cloud, we plan strength by a single dBm until we hit the upper
on using Azure to host a machine learning end of the operating range. Figure 2 shows the
model. This model will be used to process plot our data produced.
the data into a heatmap which varies based
on the time.
2 VALIDATION T ESTING
Our project is still in the early stages of devel-
opment. We are not yet at the point where we
would be able to deploy and get real-world,
user data from our system.
3 DATA A NALYSIS
Our team tested our first prototype board with
a hardwired connection to a benchtop signal
generator. We had that board tuned to capture
signals in the 600 MHz range, which corre-
sponds to the n71 band for 5G telecommuni- Figure 2. Generated DC voltage plot from PCB.
cations. Figure 1 shows the ideal output of the
commercial RF detector chip in our circuit from Our graph differs from the ideal due to a
the part’s datasheet. couple of factors. The first is that there could
We connected the output of our circuit to a be some internal noise in our circuit which we
benchtop multimeter to view the DC voltage have not yet been able to quantify through
generated from the input signal. We supplied testing. The datasheet graph is also supplied
a clean, 611 MHz signal to our board in order 3.6 volts, while due to the constraints of our
Activity Report
SURNAME et al. 3
Arduino microcontroller we are only able to
operate at a maximum of 3.3V. This test con-
firmed that our circuit was able to produce
a DC voltage from a high frequency signal
and our circuit operates very close to expected
values.
After this test we took a Keysight Field
Fox RF Signal Analyzer to multiple locations
around the UAlbany ETEC Building to mea-
sure the environmental RF signals for the
ranges we are interested in. We measured in
Mike Denmark’s office, next to the window on Figure 4. Single Arduino wireless testing setup.
the second floor, and on the roof observation
platform. Figure 3 shows the maximum signal
strength values we were able to capture using nected to the same Pi to prove our system is
the Keysight. scalable. We gave each Arduino a unique node
name and timed when messages are sent so
that messages are not dropped and lost. The
testing setup shown in Figure 5 includes a
second Arduino module. Figure 6 shows what
the incoming data looks like when receiving
messages from multiple nodes.
Figure 3. Maximum captured RF signals around
the ETEC building.
Using this data we were able to identify the
amount of amplification our new PCB required
to be able to capture environmental signals.
We redesigned our PCB test boards for each
band to include amplification. For the n66 band
we elected to add a 30dB amplifier to the Figure 5. Two Arduinos wireless testing setup.
circuit, and we designed the n71 test board
with circuitry to allow for both 30dB and 50dB
amplifiers, and we plan to test which is better
when our new PCBs arrive.
We have also been developing and testing
our system’s data transfer network. First, we
have been developing the half of the system
that sends data from the Arduino microcon-
troller to the Raspberry Pi central hub. First,
we connected a single Arduino module to the
Pi through LoRa and transmitted messages
containing random data. Figure 4 shows the
testing setup with one Arduino connected.
Development then shifted to scaling the sys- Figure 6. Data stream from multiple Arduino
tem to now include two Arduino boards con- nodes received by raspberry pi.
PP-2017 V2.1
4 RF POWER MONITORING
We have also started developing the second Currently the endpoints have not been con-
half of the network which sends from the figured in order to be able to view the messages
Pi to Microsoft Azure. We used a simulated but the dashboard shows the messages are
Raspberry Pi that is available on the web from being sent and received successfully. Once the
Microsoft to test this setup to minimize errors endpoints are configured, we will be able to
due to hardware. Figure 7 shows the simulation monitor the actual data being received. We will
we used. then shift to converting the system to using
a physical Raspberry Pi which we can then
merge with the code from the first half of the
system to create a single, final data network.
4 R ESULTS & D ISCUSSION
Our testing shows the feasibility of our design
and verifies our original requirements. Our
early stage testing here demonstrates we are
able to produce a DC voltage value from a
high frequency signal, and that our data net-
work is functional and scalable. This shows
our design is sound and should continue de-
velopment. Our testing regarding the signals
present around campus demonstrate that we
Figure 7. Data stream from multiple Arduino are focusing on relevant telecom bands, and
nodes received by raspberry pi. these signals are strong enough that they can
be measured. Due to the research nature of our
We then set up an IoT Hub on Microsoft project, the accuracy of our data is important
Azure to connect the Pi to the cloud. This and so the early signs based on the close match
receives the messages sent and displays the between our data and theoretical values from
time messages are received, the number of mes- component datasheets is promising.
sages, and other network analytics. Figure 8
shows the overview dashboard analytics for
the IoT hub. 5 F UTURE W ORK
Our work has focused on early development
and testing of core hardware and networking
systems. This opens up several options for
future work to continue to build on our project
and expand the scope. The first main option is
to develop a machine learning model to gener-
ate the heatmap. This is a core requirement of
our overall system and design. This is some-
thing we did not attempt this year due to time
constraints, as we chose to focus on the core
hardware of the system. Building off of that
requirement, the heatmap and ML model could
be made to be interactive. For example, they
could input their schedule and the heatmap
should be able to display what the exposure
they would experience would be. Another key
Figure 8. Data stream from multiple Arduino requirement to develop further is the scaling of
nodes received by raspberry pi. the system. Currently our system only has two
Activity Report
SURNAME et al. 5
nodes, however it can be scaled up significantly
larger. This will enable the project to begin
real-world testing with reading environmental
signals and generating data to be fed into the
machine learning model. For future work, we
suggest scaling down our system even further
by taking the core microchip from the Arduino
1310 board and integrating that into the PCB.
This would allow our design to be imple-
mented on a single PCB and distributed widely
for even greater area coverage. An ethernet
dongle could also be purchased a registered
to the UAlbany network to simplify adding
Raspberry Pi hubs to the internet on campus.
6 C ONCLUSIONS
Based on the testing data we have been able to
gather so far, our design is meeting our expec-
tations. We expect that by the end of the Spring
semester we will have the first iteration of the
entire core hardware system complete. Some of
our critical hardware-based subsystems, such
as the Arduino transmitting to the Raspberry
Pi and the first iteration of the PCB, are 100%
complete, while many of the others are very
near to completion. Once some more data has
been gathered from future testing, our focus
will shift to integrating these subsystems into
a single proof-of-concept network.
PP-2017 V2.1