2012-07-18 13:40:05 +02:00
|
|
|
|
Scenarios
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
|
|
|
|
|
2012-07-19 09:37:31 +02:00
|
|
|
|
* File naming convention
|
|
|
|
|
|
2012-08-28 19:29:06 +02:00
|
|
|
|
: sS_jJ_dev_YYYY-MM-DD[+suffix][_similarity].extension
|
2012-07-19 09:37:31 +02:00
|
|
|
|
|
|
|
|
|
With:
|
|
|
|
|
- S :: scenario number.
|
|
|
|
|
- J :: test number.
|
|
|
|
|
- YYYY :: year.
|
|
|
|
|
- MM :: month.
|
|
|
|
|
- DD :: day.
|
2012-07-20 14:04:58 +02:00
|
|
|
|
- dev :: client device short name.
|
2012-08-28 19:29:06 +02:00
|
|
|
|
- suffix :: an optional suffix can be added, separated by a +; suffixes
|
|
|
|
|
have the following meanings:
|
|
|
|
|
+ coord :: the real coordinate were added in the file;
|
|
|
|
|
+ calib :: the file is a manual calibration file, containing
|
|
|
|
|
calibration requests (type 1) (+coord is implied, as
|
|
|
|
|
manual calibration requests always contain the mobile's
|
|
|
|
|
coordinates); it can be made from real calibration
|
|
|
|
|
requests, or from simple positioning requests with added
|
|
|
|
|
coordinates and adapted type.
|
2012-07-19 09:37:31 +02:00
|
|
|
|
- extension :: file extension:
|
|
|
|
|
+ agg :: OwlPS Aggregator output file;
|
|
|
|
|
+ txt :: experiment report;
|
|
|
|
|
+ log :: OwlPS Positioner log file (recorded at the input);
|
|
|
|
|
+ pos :: OwlPS Positioner results;
|
|
|
|
|
+ out :: OwlPS Positioner standard output;
|
|
|
|
|
+ err :: OwlPS Positioner standard error;
|
|
|
|
|
+ ods :: results formatted in a spreadsheet.
|
|
|
|
|
|
2012-08-28 19:29:06 +02:00
|
|
|
|
For the result files, the name of the similarity algorithm used to
|
|
|
|
|
compute the positions is added after the suffix. For now it can be one
|
|
|
|
|
of the following:
|
|
|
|
|
- mean,
|
|
|
|
|
- interval,
|
|
|
|
|
- interval2.
|
2012-07-19 09:37:31 +02:00
|
|
|
|
|
|
|
|
|
|
2012-07-20 14:04:58 +02:00
|
|
|
|
* Client devices
|
|
|
|
|
|
|
|
|
|
The following mobile terminals can be used:
|
|
|
|
|
- and :: Android smartphone (Samsung Nexus S);
|
|
|
|
|
- fon :: Fonera 2.0;
|
|
|
|
|
- iph :: iPhone;
|
|
|
|
|
- eee :: Asus EeePC 1001-PX (Atheros AR2427 Wi-Fi chipset, Linux
|
|
|
|
|
3.0.0).
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
|
|
|
|
|
* Testing area
|
|
|
|
|
|
|
|
|
|
** Area description
|
|
|
|
|
|
|
|
|
|
The deployment area is a room of 5.80 × 10.60 metres. The origin of the
|
|
|
|
|
plan is set to the South-West corner of the room.
|
2012-07-20 18:11:06 +02:00
|
|
|
|
|
|
|
|
|
The East wall is a weight-bearing wall made of concrete, whereas the
|
|
|
|
|
others are simple partitions, 9.5 cm thick. The West wall has two doors
|
|
|
|
|
and four windows made of Plexiglas. The doors and windows height is 2.5
|
|
|
|
|
m.
|
|
|
|
|
A West-East room divider built from metal, plastic and wood can be
|
|
|
|
|
folded or unfolded to separate the room in two areas of approximately
|
|
|
|
|
the same size.
|
|
|
|
|
|
|
|
|
|
The room is clear from any obstacle, except for the following elements:
|
|
|
|
|
- Two technical columns (electricity and network cables) whose diameter
|
|
|
|
|
is 12.5 cm, sitting at the coordinates (1.74;4.72) and (2.46;6.63).
|
|
|
|
|
- Another technical column (which is likely to contain water) of floor
|
|
|
|
|
dimensions 31 × 51.5 cm. It sits against the East wall, its centre
|
|
|
|
|
being approximately (2.3;5.65).
|
|
|
|
|
- The room divider. Folded its floor dimensions are 115 × 71 cm, and
|
|
|
|
|
its centre is around (5.4;5.7); when it is set up, it splits the room
|
|
|
|
|
at approximately 5.25 m in the Y axis.
|
|
|
|
|
- Four heaters (air conditioners) that measure each 150 × 23 cm,
|
|
|
|
|
sitting at each end of the East wall and between the two doors of the
|
|
|
|
|
West wall.
|
|
|
|
|
- Two light metal and wood tables and three plastic and metal chairs.
|
2012-07-19 11:54:15 +02:00
|
|
|
|
|
|
|
|
|
** Measurement points
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-19 09:44:19 +02:00
|
|
|
|
To simplify the scenario explanation, the following measurement points
|
2012-07-19 11:54:15 +02:00
|
|
|
|
are predefined:
|
2012-07-18 13:40:05 +02:00
|
|
|
|
1. (5;10)
|
|
|
|
|
2. (1;10)
|
|
|
|
|
3. (5;1)
|
|
|
|
|
4. (1;1)
|
|
|
|
|
5. (2.5;5.5)
|
|
|
|
|
6. (5;5)
|
|
|
|
|
7. (5;2)
|
|
|
|
|
8. (3;2)
|
|
|
|
|
9. (3;0)
|
|
|
|
|
10. (1;5)
|
2012-07-19 11:54:15 +02:00
|
|
|
|
11. (1;3)
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
|
|
|
|
|
2012-07-18 19:38:20 +02:00
|
|
|
|
* Common rules
|
|
|
|
|
|
2012-07-19 09:44:19 +02:00
|
|
|
|
Except if stated otherwise, all the scenarios follow these rules.
|
|
|
|
|
|
|
|
|
|
** Devices used
|
|
|
|
|
|
2012-07-20 14:04:58 +02:00
|
|
|
|
- Mobile terminal: cf. the file names. The OwlPS Client version is
|
|
|
|
|
v1.3.0-11-gc4e0352.
|
2012-07-19 09:44:19 +02:00
|
|
|
|
- Aggregation server: Asus EEE-PC 701 4G running Debian GNU/Linux
|
|
|
|
|
squeeze (Linux 2.6.32), with an Atheros AR 500 Wi-Fi interface. It
|
|
|
|
|
runs OwlPS Aggregator v1.3.1-14-ge278aab.
|
|
|
|
|
- Listeners: 4 Fonera 2.0, running OwlPS Listener v1.3.0-11-gc4e0352.
|
|
|
|
|
|
|
|
|
|
** Environmental parameters:
|
|
|
|
|
|
|
|
|
|
- The temperature is controlled around 22°C.
|
|
|
|
|
- The humidity varies from 38% to 55%.
|
|
|
|
|
|
2012-08-23 17:50:14 +02:00
|
|
|
|
** Aggregator
|
|
|
|
|
|
|
|
|
|
OwlPS Aggregator is run with the default parameters as of the version
|
|
|
|
|
used, with autocalibration enabled. These parameters can be found in the
|
|
|
|
|
configuration file [[./owlps-config/owlps-aggregator.conf]].
|
|
|
|
|
|
|
|
|
|
These parameters are not very important, except for the delay between
|
|
|
|
|
two autocalibration orders. The default value is 1000 ms.
|
|
|
|
|
|
2012-07-19 09:44:19 +02:00
|
|
|
|
** Listeners
|
|
|
|
|
|
|
|
|
|
The capture points are attached to the walls and all have their antennas
|
|
|
|
|
in vertical position, in the direction of the ceiling.
|
|
|
|
|
Their coordinates are given in the OwlPS Positioner's configuration file
|
|
|
|
|
([[./owlps-config/listeners-fonera.csv]]).
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
The OwlPS Listener program runs continuously, with the autocalibration
|
|
|
|
|
activated. It is launched with the following command:
|
2012-07-19 09:44:19 +02:00
|
|
|
|
: owlps-listenerd -A -v -i 192.168.11.254 -I 192.168.11.254 -r ath1 -w ath0
|
|
|
|
|
|
|
|
|
|
** Client
|
|
|
|
|
|
|
|
|
|
The mobile terminal continuously sends positioning requests with the
|
|
|
|
|
following parameters:
|
|
|
|
|
- 20 packets (-n20),
|
|
|
|
|
- 10 ms between two packets (-t10),
|
|
|
|
|
- 800 ms between two requests (-F800).
|
2012-07-19 12:43:43 +02:00
|
|
|
|
Therefore, one request is transmitted approximately each second.
|
2012-07-19 09:44:19 +02:00
|
|
|
|
The destination IP address is the Aggregator's one (i.e. 192.168.11.254
|
|
|
|
|
in our setup).
|
|
|
|
|
|
|
|
|
|
The complete command used to launch OwlPS Client is the following:
|
2012-07-20 14:04:58 +02:00
|
|
|
|
: owlps-client -i 192.168.11.254 -n20 -t10 -F800
|
2012-07-19 09:44:19 +02:00
|
|
|
|
|
|
|
|
|
The mobile terminal's antenna is vertical.
|
|
|
|
|
|
|
|
|
|
** Measurement-related rules
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
- Three mobile terminal's altitudes are defined:
|
|
|
|
|
+ floor (0 m),
|
|
|
|
|
+ hip (0.82 m),
|
|
|
|
|
+ ear (1.57 m).
|
|
|
|
|
- For the altitudes higher than “floor”, when the mobile terminal is not
|
|
|
|
|
carried by a human operator, it is put on a non-metallic object. In
|
|
|
|
|
our setup, the “hip” altitude is achieved by stacking a empty trash
|
|
|
|
|
(32 cm) on a cardboard box (50 cm); for the “ear” altitude, we add a
|
|
|
|
|
stack of small boxes (75 cm).
|
2012-07-18 19:38:20 +02:00
|
|
|
|
- When a human operator carries the mobile terminal, the altitude of the
|
2012-07-19 11:54:15 +02:00
|
|
|
|
terminal is 1 m (hips/belly).
|
2012-07-20 14:04:58 +02:00
|
|
|
|
- The antenna of the capture points and the mobile terminal are
|
|
|
|
|
vertical. When the mobile terminal is a laptop computer, the screen is
|
|
|
|
|
vertical, and the computer is set up so that the display side of the
|
|
|
|
|
screen is in direction of the wall opposite to the point where the
|
2012-07-20 18:11:06 +02:00
|
|
|
|
mobile is located (when applicable).
|
2012-07-20 14:04:58 +02:00
|
|
|
|
|
|
|
|
|
** Measurement procedure
|
|
|
|
|
|
|
|
|
|
- The infrastructure (Listeners and Aggregator) must be started first
|
|
|
|
|
and at least a round of autocalibration request done (i.e. each
|
|
|
|
|
capture point must have sent at least one autocalibration request)
|
|
|
|
|
before the mobile terminal is started.
|
|
|
|
|
- In the scenario in which a human has to move along a path, a metronome
|
|
|
|
|
is set up with the tempo at which the person has to walk. For example,
|
|
|
|
|
60 bpm if the pace is of one metre per second.
|
2012-07-18 19:38:20 +02:00
|
|
|
|
|
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
* Overview of the scenarios
|
|
|
|
|
|
|
|
|
|
** Scenario 1
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
The mobile terminal is still, without human operator, at hip altitude.
|
|
|
|
|
Measurements are taken at each corner and the centre of the room
|
|
|
|
|
(measurement points 1 to 5), during 1 minute at each position.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 2
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
Repeat the scenario 1, but the mobile terminal is on the floor.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 3
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
This scenario tests the antenna angles and measurement direction, with a
|
2012-07-20 18:11:06 +02:00
|
|
|
|
human operator. The measurement points 2 and 5 are tested.
|
|
|
|
|
|
|
|
|
|
For each point, measurements are taken in two directions, with a 45°
|
|
|
|
|
angle (clockwise) between the two directions.
|
|
|
|
|
For the measurement point 2, the directions are:
|
|
|
|
|
1. East,
|
|
|
|
|
2. South-East.
|
|
|
|
|
For the measurement point 5, the directions are:
|
|
|
|
|
1. North-West.
|
|
|
|
|
2. North,
|
|
|
|
|
|
|
|
|
|
For each direction, three antenna orientations are measured:
|
|
|
|
|
1. horizontal,
|
|
|
|
|
2. diagonal,
|
|
|
|
|
3. vertical.
|
|
|
|
|
|
|
|
|
|
Therefore, we have 6 measurements per point. Each measurement lasts one
|
|
|
|
|
minute.
|
2012-06-26 19:01:32 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 4
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 19:14:42 +02:00
|
|
|
|
Test with a human operator carrying the mobile terminal. The operator
|
2012-08-23 12:56:45 +02:00
|
|
|
|
moves along a path following the measurement points 1 to 5, and stands
|
|
|
|
|
at each point for 10 seconds. The pace of the operator is 1 m/s (one
|
|
|
|
|
second per step, with one-metre steps).
|
2012-07-18 19:14:42 +02:00
|
|
|
|
|
|
|
|
|
Timing:
|
|
|
|
|
- t-10 :: stand at MP#1 in the direction of MP#2, start the aggregation
|
|
|
|
|
server (with autocalibration activated).
|
|
|
|
|
- t0 :: start the client, stay at MP#1 until t10.
|
|
|
|
|
- t10 :: start walking to MP#2 (4 m distance).
|
|
|
|
|
- t14 :: arrived at MP#2, start rotating in the direction of MP#3.
|
|
|
|
|
- t15 :: rotation achieved, stay at MP#2 until t25.
|
|
|
|
|
- t25 :: start walking to MP#3 (about 9.85 m distance, so the walk pace
|
|
|
|
|
is around 1.1 m/s to achieve MP#3 in 9 seconds).
|
|
|
|
|
- t34 :: arrived at MP#3, start rotating in the direction of MP#4.
|
|
|
|
|
- t35 :: rotation achieved, stay at MP#3 until t45.
|
|
|
|
|
- t45 :: start walking to MP#4 (4 m distance).
|
|
|
|
|
- t49 :: arrived at MP#4, start rotating in the direction of MP#5.
|
|
|
|
|
- t50 :: rotation achieved, stay at MP#4 until t60.
|
|
|
|
|
- t60 :: start walking to MP#5 (about 4.74 m distance, so the walk pace
|
|
|
|
|
is around 1.2 m/s to achieve MP#5 in 4 seconds).
|
|
|
|
|
- t64 :: arrived at MP#5, start rotating to the right (in the direction
|
|
|
|
|
of the mobile wall).
|
|
|
|
|
- t65 :: rotation achieved, stay at MP#5 until t75.
|
|
|
|
|
- t75 :: stop the client.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 5
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-20 18:11:06 +02:00
|
|
|
|
This scenario aims to evaluate the impact of the delay between the
|
|
|
|
|
packets sent by the mobile terminal. There is no delay between two
|
|
|
|
|
requests (-F0), and each request is transmitted during approximately one
|
|
|
|
|
second (assuming that the transmission time of a packet is almost
|
|
|
|
|
negligible; since it is a false assumption, each request lasts slightly
|
|
|
|
|
more than one second). Please keep in mind that for requests as long as
|
|
|
|
|
one second, the aggregation timeout must be extended in the Aggregator's
|
|
|
|
|
configuration.
|
|
|
|
|
|
|
|
|
|
The following values are evaluated:
|
|
|
|
|
- 0 ms, 1000 packets;
|
|
|
|
|
- 5 ms, 200 packets;
|
|
|
|
|
- 10 ms, 100 packets;
|
|
|
|
|
- 20 ms, 50 packets;
|
|
|
|
|
- 40 ms, 25 packets;
|
|
|
|
|
- 500 ms, 2 packets.
|
|
|
|
|
|
|
|
|
|
The mobile is on the floor, at the centre of the room (2.5;5.5;0).
|
|
|
|
|
|
|
|
|
|
For each value, the following procedure is run:
|
|
|
|
|
1. The aggregation server is launched, and autocalibration requests are
|
|
|
|
|
received for 10 seconds.
|
|
|
|
|
2. The aggregation server is restarted without autocalibration.
|
|
|
|
|
3. The client is run for one minute.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 6
|
|
|
|
|
|
2012-07-20 14:04:58 +02:00
|
|
|
|
This scenario uses measurement points 1 and 5-10. For each measurement
|
|
|
|
|
point, three altitudes of the terminal are tested: floor, hip and ear.
|
2012-07-20 18:11:06 +02:00
|
|
|
|
The room divider is half-closed (from the East wall to the centre of the
|
2012-07-20 14:04:58 +02:00
|
|
|
|
room), and there is no human operator in the room.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-20 14:04:58 +02:00
|
|
|
|
For each point, each altitude is measured for one minute, in the
|
|
|
|
|
following order:
|
2012-07-19 11:54:15 +02:00
|
|
|
|
1. floor,
|
|
|
|
|
2. hip,
|
|
|
|
|
3. ear.
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
|
|
|
|
** Scenario 7
|
2012-07-05 13:53:24 +02:00
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
Repeat the scenario 6, but with a human operator standing 0.5 m at the
|
|
|
|
|
West of the terminal.
|
|
|
|
|
Only the hip altitude is studied.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 8
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
Repeat the scenario 7, but the human operator is always standing at the
|
|
|
|
|
measurement point 11.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 9
|
|
|
|
|
|
2012-07-20 18:11:06 +02:00
|
|
|
|
This scenario is similar to the scenario 5, but the parameter evaluated
|
|
|
|
|
is the size of the packets:
|
|
|
|
|
- 64 B,
|
|
|
|
|
- 128 B,
|
|
|
|
|
- 256 B,
|
|
|
|
|
- 512 B,
|
|
|
|
|
- 1024 B,
|
|
|
|
|
- 1450 B.
|
|
|
|
|
This size is the parameter given to OwlPS Client, and is less than the
|
|
|
|
|
size of the radio packet. The size of the packet received at the
|
|
|
|
|
listeners must be written, as it can vary.
|
|
|
|
|
|
|
|
|
|
Please refer to the scenario 5 for details and measurement procedure.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 10
|
|
|
|
|
|
2012-07-20 14:04:58 +02:00
|
|
|
|
Repeat the scenario 1 several time, varying the delay between two
|
|
|
|
|
packets of the autocalibration requests (option -t of owlps-listenerd):
|
|
|
|
|
- 5 ms,
|
|
|
|
|
- 10 ms,
|
|
|
|
|
- 15 ms,
|
|
|
|
|
- 20 ms,
|
|
|
|
|
- 25 ms.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 11
|
|
|
|
|
|
2012-07-19 12:43:43 +02:00
|
|
|
|
Repeat the scenario 4 several time with different autocalibration
|
2012-07-20 14:04:58 +02:00
|
|
|
|
frequencies on the Aggregator (delay between two autocalibration
|
|
|
|
|
orders). The autocalibration requests' settings (number of packets and
|
|
|
|
|
delay between two packets) will be adjusted on the Listeners, so that a
|
|
|
|
|
request emission lasts for around 20-25 ms less than the autocalibration
|
|
|
|
|
frequency.
|
2012-07-19 12:43:43 +02:00
|
|
|
|
|
2012-07-20 14:04:58 +02:00
|
|
|
|
The following frequencies are tested:
|
2012-07-19 12:43:43 +02:00
|
|
|
|
- 100 ms (Listeners: -n10 -t8 = 80 ms),
|
|
|
|
|
- 250 ms (Liseners: -n16 -t14 = 224 ms),
|
|
|
|
|
- 500 ms (Listeners: -n20 -t24 = 480 ms),
|
|
|
|
|
- 1000 ms (Listeners: -n39 -t25 = 975 ms).
|
2012-07-18 13:40:05 +02:00
|
|
|
|
*** TODO coord
|
|
|
|
|
|
|
|
|
|
** Scenario 12
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-20 14:04:58 +02:00
|
|
|
|
This scenario aims to evaluate the impact of horizontal capture points'
|
|
|
|
|
antennas. The scenario 1 is repeated partially (for the measurement
|
|
|
|
|
points 3, 4 and 5 only) two times:
|
|
|
|
|
1. Each capture point antenna is disposed horizontally, pointing in the
|
|
|
|
|
direction of the opposite wall.
|
2012-08-23 12:56:45 +02:00
|
|
|
|
2. The antennas are still horizontal, but placed so that each antenna
|
|
|
|
|
points in the direction of another capture point, in a circle: the
|
|
|
|
|
North-West and South-East listeners' antennas stay in the same
|
|
|
|
|
position as the previous test, but the North-East listener's antenna
|
|
|
|
|
points to the West, and the South-West listener's antenna points to
|
|
|
|
|
the East.
|
|
|
|
|
|
|
|
|
|
#+CAPTION: Scenario 12, test 1.
|
2012-07-20 14:04:58 +02:00
|
|
|
|
#+begin_src ditaa :cmdline -s 2 :file s12-1.png
|
2012-07-20 18:11:06 +02:00
|
|
|
|
+---+ +---+
|
|
|
|
|
| | | |
|
|
|
|
|
| | | |
|
|
|
|
|
+-+-+ +-+-+
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
+-+-+ +-+-+
|
|
|
|
|
| | | |
|
|
|
|
|
| | | |
|
|
|
|
|
+---+ +---+
|
2012-07-20 14:04:58 +02:00
|
|
|
|
#+end_src
|
|
|
|
|
|
2012-08-23 12:56:45 +02:00
|
|
|
|
#+CAPTION: Scenario 12, test 2.
|
2012-07-20 14:04:58 +02:00
|
|
|
|
#+begin_src ditaa :cmdline -s 2 :file s12-2.png
|
2012-07-20 18:11:06 +02:00
|
|
|
|
+---+ +---+
|
|
|
|
|
| | | |
|
|
|
|
|
| | | |
|
|
|
|
|
+-+-+ +-+-+
|
|
|
|
|
| |
|
|
|
|
|
| -----+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+----- |
|
|
|
|
|
| |
|
|
|
|
|
+-+-+ +-+-+
|
|
|
|
|
| | | |
|
|
|
|
|
| | | |
|
|
|
|
|
+---+ +---+
|
2012-07-20 14:04:58 +02:00
|
|
|
|
#+end_src
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 13
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
This scenario aims to evaluate the impact of the temperature. The
|
|
|
|
|
terminal is on the floor, at the measurement point 1. The temperature
|
|
|
|
|
starts from a maximum, and lowers to a minimum during the experiment.
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
|
|
|
|
** TODO Scenario 14
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
Repeat the scenario 13, but evaluate the impact of the humidity.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 15
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
Repeat the scenario 1, but without client. The terminal is instead
|
|
|
|
|
replaced by a human operator. This scenario aims to evaluate the
|
|
|
|
|
influence of the human body on the autocalibration requests.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 16
|
2012-07-05 18:02:46 +02:00
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
This scenario follows the same principles as the scenario 15, but this
|
|
|
|
|
time the scenario 4 is played instead of the scenario 1.
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
|
|
|
|
** Scenario 17
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
Repeat the scenario 16 (scenario 4 without mobile terminal), but with
|
|
|
|
|
two human operators, each starting from two opposite corners of the
|
|
|
|
|
room (measurement points 1 and 4). They move along the following
|
|
|
|
|
measurement points:
|
|
|
|
|
- Operator 1: 1, 2, 3, 4, 5 (same as scenario 16).
|
|
|
|
|
- Operator 2: 4, 3, 2, 1, 5.
|
2012-07-05 18:02:46 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** Scenario 18
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
The autocalibration is performed for 5 minutes, without mobile terminal
|
|
|
|
|
and without human operator.
|
2012-07-13 11:50:13 +02:00
|
|
|
|
|
2012-07-18 13:40:05 +02:00
|
|
|
|
** TODO Scenario 19
|
|
|
|
|
|
2012-07-19 11:54:15 +02:00
|
|
|
|
Repeat the scenario 17, but one of the operators carries the mobile
|
|
|
|
|
terminal.
|
2012-08-23 18:17:11 +02:00
|
|
|
|
|
|
|
|
|
** Scenario 20
|
|
|
|
|
|
|
|
|
|
Manual calibration, without autocalibration running. The mobile device
|
|
|
|
|
is carried by a human operator.
|