RFD900x Test flight report
November 13, 2022 Flight Report
Table of Contents
Apparatus
Methods
Experimental Procedure
Results
Discussion
Further experiment
Apparatus
Laptop
RFD900X
Arduino Mega2560
A quadcopter named “Phoenix”
Methods
Establish a two-way communication between the RFD transmitters. The larger transmitter is connected to the laptop with Arduino software and serial monitor opened. The smaller transmitter is attached to the Phoenix.
The methodology of this test is basically the ground-side of transmitter will be sending data in package to the transmitter in the air side. The air-side of transmitter will send the data back as it received. Then, the ground-side can test the communication quality by verifying the corrption rate of the data. The downside of the test is that we cannot know exactly where the data is lost either during the uplink or the downlink.
Procedure
Off-drone testing
Before we attached the RFD to the Phoenix, we first did the corruption rate test within the campus by setting one transmitter at E7 building, and the other transmitter at DC building. The size of the data package is 4 byte, and the range of frequencies tested were varied from 10 - 200 Hz
The second off-drone test was a range test. We attached the larger transmitter to the antenna station to check how long the communication can go in the environment with interference. This time, the antenna station is set at E7 building, point towards the other transmitter. The other transmitter was held by a man, and that man would go as far as the connection was lost.
On-drone testing
We used the similar methodology here, except that we discuss the ground to ground communication is worse then ground to air communication and it is further discussed in the discussion section.
Result
Off-drone testing
A packet contains 4 byte of data, 100Hz. Thus, 400 bytes of data were transferred at every second.
No packet loss == 0-2 packet loss for every 100 packets.
Clear, sunny weather.
E7 6th floor to dc(150 m away):
100 - 50ms (10 - 20 Hz) no packet loss
30ms (33 Hz): normal 3-5 packet loss; max 6
10ms (100 Hz) : under 10 packet loss; max 15
E7 to MC (250 m away):
Tested frequency: 50 ms delay (20 Hz)
Normally antenna: loss connection
Improved antenna: can reach slc with loss rate average at 10 - 15
On-drone Testing:
Under other controller occupying the same frequency (10 ms)
Snowing weather below freezing point:
establish line of sight, behind the hill
(the following number represents the corruption rate which is the same as number of package lost)
no line of sight
median 3
highest 9
lowest 0 10+ sets of data loss rate at 0 every 100 packet
behind the hill
median 7
highest 16
lowest 0 5+ sets of data loss rate at 0 every 100 packet
establish line of sight, behind the hill even further
median 9
highest 34
lowest 5 1 sets of data loss rate at 0 every 100 packet
no line of sight, behind the hill even further
median 20
highest 72
lowest 10 no set of data loss rate at 0 every 100 packet
Discussion
As Adian has pointed out, the data is not being transferred as fast as we want. Therefore, we will put a test module into the los core and interface that can be called, so it could test the loss rate of the current setup. (For the test being implement, 2 seconds of data will be sent and there will be no verification occurred inbetween. The data will be read from the buffer and analyzed later.) Also, today’s test flight shows an importance in having a data recheck system when the data is being transmitted at a high speed. The trend being obsered is that, normally the packet is loss not corrupted.under a good setup the loss rate at 400 bytes per second will be controlled under 10%. And there are two significant connection lost being identified. And when arming the drone sometime the data transmission will be significantly improved meaning that the orientation will have an huge impact on the data transmission. This also shows us the importance of having a tracking antenna system for long range data transmission with omni-directional antenna. And in order to test weather the loss is more severe on the uplink or the downlink. A never powered off log system or the sd card driver is needed to help record that. Moreover, we think that it is important to have a system in the real test flight that can adjust the delay rate between each packet based on the loss rate of the current data.