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-09-26 21:27:47 +02:00
|
|
|
|
: sS_tT_dev_YYYY-MM-DD[_info][+suffix][_similarity].extension
|
2012-07-19 09:37:31 +02:00
|
|
|
|
|
|
|
|
|
With:
|
|
|
|
|
- S :: scenario number.
|
2012-09-26 21:27:47 +02:00
|
|
|
|
- T :: test number; for a given scenario, the first test number is 01,
|
|
|
|
|
and each time the scenario is played the test number is
|
|
|
|
|
incremented.
|
2012-07-19 09:37:31 +02:00
|
|
|
|
- YYYY :: year.
|
|
|
|
|
- MM :: month.
|
|
|
|
|
- DD :: day.
|
2012-07-20 14:04:58 +02:00
|
|
|
|
- dev :: client device short name.
|
2012-08-29 15:44:16 +02:00
|
|
|
|
- info :: an optional informative string can be added, for example when
|
2012-09-26 21:27:47 +02:00
|
|
|
|
a scenario has to be run several times with different parameters; when
|
|
|
|
|
not obvious, the meaning of such suffixes should be documented in the
|
|
|
|
|
report files.
|
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-09-06 15:50:16 +02:00
|
|
|
|
When received by a Fonera 2.0, the default packet size is 103 bytes for
|
|
|
|
|
a positioning request, and 116 bytes for an (auto)calibration request.
|
|
|
|
|
|
2012-10-09 11:45:55 +02:00
|
|
|
|
Unless stated otherwise:
|
|
|
|
|
- the Fonera is equipped with a 1.8 dBi antenna and its transmission
|
|
|
|
|
power is 18 dBm;
|
|
|
|
|
- the transmission power of the EeePC is 14 dBm.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
|
|
|
|
|
2012-07-18 19:38:20 +02:00
|
|
|
|
* Common rules
|
|
|
|
|
|
2012-08-30 15:24:10 +02:00
|
|
|
|
Except if stated otherwise, all the scenarios follow these rules (or
|
|
|
|
|
should follow them for future tests). The description of the scenarios
|
|
|
|
|
has precedence over these common rules. Moreover, the report files
|
|
|
|
|
associated with each test should also warn about each noticed mistake,
|
|
|
|
|
and each exception made to these rules or to the scenario description.
|
2012-07-19 09:44:19 +02:00
|
|
|
|
|
|
|
|
|
** 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-09-14 20:27:11 +02:00
|
|
|
|
- Aggregation server: Asus EeePC 701 4G running Debian GNU/Linux
|
2012-07-19 09:44:19 +02:00
|
|
|
|
squeeze (Linux 2.6.32), with an Atheros AR 500 Wi-Fi interface. It
|
|
|
|
|
runs OwlPS Aggregator v1.3.1-14-ge278aab.
|
2012-09-14 20:27:11 +02:00
|
|
|
|
- Listeners: 4 Fonera 2.0 with 1.8 dBi antennas, running OpenWrt
|
2012-10-09 11:45:55 +02:00
|
|
|
|
Backfire. They run OwlPS Listener v1.3.0-11-gc4e0352, and their
|
|
|
|
|
transmission power is 18 dBm.
|
2012-09-14 20:27:11 +02:00
|
|
|
|
|
|
|
|
|
** Network
|
|
|
|
|
|
|
|
|
|
The aggregation server, the listeners and the terminal communicate
|
|
|
|
|
through an ad-hoc network. This limits the rate at which positioning and
|
|
|
|
|
autocalibration requests are transmitted, but allows for a quick
|
|
|
|
|
deployment.
|
2012-07-19 09:44:19 +02:00
|
|
|
|
|
|
|
|
|
** Environmental parameters:
|
|
|
|
|
|
2012-08-30 15:24:10 +02:00
|
|
|
|
Each test's report file should report the temperature and humidity when
|
2012-09-13 11:49:47 +02:00
|
|
|
|
the test was started. If the information is missing, one can assume
|
2012-09-14 20:27:11 +02:00
|
|
|
|
that the temperature is controlled around 22-24°C, and the humidity
|
2012-09-13 11:49:47 +02:00
|
|
|
|
varies from 38% to 55%.
|
2012-08-30 15:24:10 +02:00
|
|
|
|
|
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-08-30 15:24:10 +02:00
|
|
|
|
The default aggregation timeout should fit most test cases, but keep in
|
|
|
|
|
mind that for requests as long as one second (including manual
|
|
|
|
|
calibration request with the default parameters), it is too short and
|
|
|
|
|
must be extended in the Aggregator's configuration.
|
|
|
|
|
|
|
|
|
|
You should also be aware of the fact that for a capture point to
|
|
|
|
|
transmit autocalibration requests, it must be known by the
|
|
|
|
|
Aggregator. Therefore, it is not sufficient to wait for 10 seconds
|
|
|
|
|
(cf. Measurement procedure) after starting the Aggregator to guarantee
|
|
|
|
|
that each capture point transmits autocalibration requests for 10
|
2012-09-06 15:50:16 +02:00
|
|
|
|
seconds. The counter must be started after the Aggregator received a
|
2012-08-30 15:24:10 +02:00
|
|
|
|
Hello message from all the capture points.
|
|
|
|
|
|
2012-08-29 15:44:16 +02:00
|
|
|
|
At the end of a test, beware of not stopping the Aggregator too early,
|
|
|
|
|
e.g. if requests are sent with long delays, or simply if the aggregate
|
|
|
|
|
timeout is not reached for all the requests in memory (as of August
|
2012-08-30 15:24:10 +02:00
|
|
|
|
2012, OwlPS Aggregator does not flush the non-aggregated requests upon
|
2012-08-29 15:44:16 +02:00
|
|
|
|
exiting, but simply deletes them).
|
|
|
|
|
|
2012-07-19 09:44:19 +02:00
|
|
|
|
** Listeners
|
|
|
|
|
|
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
|
|
|
|
|
|
2012-09-27 17:42:24 +02:00
|
|
|
|
The default autocalibration parameters are used, i.e.:
|
|
|
|
|
- 20 packets (-n20),
|
|
|
|
|
- 25 ms between two packets (-t25).
|
|
|
|
|
|
2012-07-19 09:44:19 +02:00
|
|
|
|
** 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
|
|
|
|
|
2012-09-13 12:49:23 +02:00
|
|
|
|
When using a metronome, the command should be adjusted so that exactly
|
|
|
|
|
one request is transmitted for each beat of the metronome. For 60 bpm
|
|
|
|
|
(one request per second), the following parameters have been found to be
|
|
|
|
|
almost exact:
|
|
|
|
|
: owlps-client -i 192.168.11.254 -n20 -t10 -F761
|
|
|
|
|
|
|
|
|
|
When a precise number of requests have to be sent during the scenario,
|
|
|
|
|
one can use the -N parameter introduced in OwlPS v1.3.1-21-g5d94fe8.
|
|
|
|
|
|
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-09-06 15:50:16 +02:00
|
|
|
|
- The antenna of the mobile terminal is 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 mobile is
|
|
|
|
|
located (when applicable).
|
2012-07-20 14:04:58 +02:00
|
|
|
|
|
|
|
|
|
** Measurement procedure
|
|
|
|
|
|
|
|
|
|
- The infrastructure (Listeners and Aggregator) must be started first
|
2012-08-30 15:24:10 +02:00
|
|
|
|
and at least two rounds of autocalibration request done (i.e. each
|
|
|
|
|
capture point must have sent at least two autocalibration request)
|
|
|
|
|
before the mobile terminal is started. As a best practice, the
|
|
|
|
|
measurements should start at least 10 seconds after the Aggregator
|
|
|
|
|
knows all the Listeners (cf. Aggregator for more details).
|
2012-09-13 12:49:23 +02:00
|
|
|
|
- In the scenarios 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 step per second.
|
2012-07-18 19:38:20 +02:00
|
|
|
|
|
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
* One-room scenarios
|
|
|
|
|
|
|
|
|
|
This series of scenarios is schematised in the figure
|
|
|
|
|
[[./figures/room.svg]].
|
|
|
|
|
|
|
|
|
|
** 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.
|
|
|
|
|
|
|
|
|
|
This simple topology is described in the OwlPS Positioner's
|
|
|
|
|
configuration file [[./owlps-config/room/topology.csv]].
|
2012-09-13 15:23:36 +02:00
|
|
|
|
The file [[./figures/room_panorama_180.jpg]] is a panoramic (180°)
|
|
|
|
|
photograph of the room.
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
2012-09-13 11:49:47 +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.
|
2012-09-14 20:27:11 +02:00
|
|
|
|
A West-East room divider built from wood, metal, and plastic can be
|
2012-09-13 11:49:47 +02:00
|
|
|
|
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:
|
2012-09-14 20:27:11 +02:00
|
|
|
|
- Two technical columns made of aluminium containing electricity and
|
|
|
|
|
network cables, and whose diameter is 12.5 cm, sitting at the
|
|
|
|
|
coordinates (1.74;4.72) and (2.46;6.63).
|
2012-09-13 11:49:47 +02:00
|
|
|
|
- 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
|
2012-09-14 20:27:11 +02:00
|
|
|
|
its centre is around (5.4;5.7) (against the East wall); when it is set
|
|
|
|
|
up, it splits the room at approximately 5.25 m in the Y axis.
|
2012-09-27 17:42:24 +02:00
|
|
|
|
- Four heaters (air conditioners) that measure each 150 × 23 × 92 cm,
|
2012-09-13 11:49:47 +02:00
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
*** 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/room/listeners-fonera.csv]].
|
|
|
|
|
|
|
|
|
|
*** Measurement points
|
|
|
|
|
|
|
|
|
|
To simplify the scenario explanation, the following measurement points
|
|
|
|
|
are predefined:
|
|
|
|
|
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)
|
|
|
|
|
11. (1;3)
|
|
|
|
|
|
|
|
|
|
** Scenario 1 (static, hip)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
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-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 2 (static, floor)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
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-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 3 (antenna angle & direction)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
2012-09-06 15:50:16 +02:00
|
|
|
|
This scenario tests the antenna angle 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-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 4 (mobility)
|
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:
|
2012-09-27 17:42:24 +02:00
|
|
|
|
Before to start the timer, start the aggregation server (with
|
|
|
|
|
autocalibration activated) and wait for all the listeners to send a
|
|
|
|
|
Hello message.
|
|
|
|
|
- t-10 :: Stand at MP#1 in the direction of MP#2, while the listeners
|
2012-09-13 11:49:47 +02:00
|
|
|
|
send autocalibration requests.
|
2012-09-27 17:42:24 +02:00
|
|
|
|
- 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
|
2012-07-18 19:14:42 +02:00
|
|
|
|
is around 1.1 m/s to achieve MP#3 in 9 seconds).
|
2012-09-27 17:42:24 +02:00
|
|
|
|
- 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
|
2012-07-18 19:14:42 +02:00
|
|
|
|
is around 1.2 m/s to achieve MP#5 in 4 seconds).
|
2012-09-27 17:42:24 +02:00
|
|
|
|
- t64 :: Arrived at MP#5, start rotating to the right (in the direction
|
2012-07-18 19:14:42 +02:00
|
|
|
|
of the mobile wall).
|
2012-09-27 17:42:24 +02:00
|
|
|
|
- t65 :: Rotation achieved, stay at MP#5 until t75.
|
|
|
|
|
- t75 :: Stop the client.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 5 (inter-packet delay)
|
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
|
2012-08-29 11:31:22 +02:00
|
|
|
|
packets sent by the mobile terminal. The delay between two requests
|
|
|
|
|
(-F), must be the same as the delay between two packets (-t).
|
|
|
|
|
Each request lasts approximately for one second, and the total number of
|
|
|
|
|
packets transmitted during each test must be approximately the same, in
|
|
|
|
|
order to ease the statistical treatment.
|
|
|
|
|
|
|
|
|
|
The following parameters are evaluated:
|
|
|
|
|
- 10 ms, 100 packets, 60 requests (6000 packets);
|
|
|
|
|
- 20 ms, 50 packets, 120 requests (6000 packets);
|
|
|
|
|
- 30 ms, 33 packets, 182 requests (6006 packets);
|
|
|
|
|
- 40 ms, 25 packets, 240 requests (6000 packets);
|
|
|
|
|
- 50 ms, 20 packets, 300 requests (6000 packets).
|
2012-07-20 18:11:06 +02:00
|
|
|
|
|
|
|
|
|
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:
|
2012-08-29 11:31:22 +02:00
|
|
|
|
1. The aggregation server is launched, and autocalibration requests from
|
|
|
|
|
all the capture points are received for at least 10 seconds.
|
2012-07-20 18:11:06 +02:00
|
|
|
|
2. The aggregation server is restarted without autocalibration.
|
2012-08-29 11:31:22 +02:00
|
|
|
|
3. The client is run.
|
|
|
|
|
|
2012-08-29 15:44:16 +02:00
|
|
|
|
Alternatively, if the experiments are done during only one session, the
|
|
|
|
|
autocalibration process can be run only once, at the beginning, and the
|
|
|
|
|
autocalibration requests stored in a separate file.
|
|
|
|
|
|
2012-08-30 15:24:10 +02:00
|
|
|
|
Please keep in mind that for requests as long as one second, the
|
|
|
|
|
aggregation timeout must be extended in the Aggregator's configuration
|
|
|
|
|
(cf. Common rules for details).
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 6 (altitude)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
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
|
|
|
|
|
2012-10-09 11:45:55 +02:00
|
|
|
|
Alternative procedure (advised for easier use of the measurements): a
|
|
|
|
|
separate aggregation file is made for each point and each altitude.
|
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 7 (altitude & human presence)
|
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-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 8 (altitude & fixed human presence)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
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-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 9 (packet size)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
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
|
2012-10-09 11:45:55 +02:00
|
|
|
|
listeners must be written in the report files, as it can vary.
|
2012-07-20 18:11:06 +02:00
|
|
|
|
|
|
|
|
|
Please refer to the scenario 5 for details and measurement procedure.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 10 (autocalibration inter-packet delay)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
2012-08-29 15:44:16 +02:00
|
|
|
|
Repeat the scenario 1 several times, varying the delay between two
|
2012-07-20 14:04:58 +02:00
|
|
|
|
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-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 11 (autocalibration frequency, mobility)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
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),
|
2012-08-30 15:24:10 +02:00
|
|
|
|
- 250 ms (Listeners: -n16 -t14 = 224 ms),
|
2012-07-19 12:43:43 +02:00
|
|
|
|
- 500 ms (Listeners: -n20 -t24 = 480 ms),
|
|
|
|
|
- 1000 ms (Listeners: -n39 -t25 = 975 ms).
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 12 (horizontal antennas)
|
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.
|
|
|
|
|
|
2012-10-09 11:45:55 +02:00
|
|
|
|
#+CAPTION: Scenario 12, antennas in the direction of the opposite wall
|
|
|
|
|
#+begin_src ditaa :cmdline -s 2 :file s12-opposite.png
|
2012-07-20 18:11:06 +02:00
|
|
|
|
+---+ +---+
|
|
|
|
|
| | | |
|
|
|
|
|
| | | |
|
|
|
|
|
+-+-+ +-+-+
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
+-+-+ +-+-+
|
|
|
|
|
| | | |
|
|
|
|
|
| | | |
|
|
|
|
|
+---+ +---+
|
2012-07-20 14:04:58 +02:00
|
|
|
|
#+end_src
|
|
|
|
|
|
2012-10-09 11:45:55 +02:00
|
|
|
|
#+CAPTION: Scenario 12, antennas forming a “circle”
|
|
|
|
|
#+begin_src ditaa :cmdline -s 2 :file s12-circle.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-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 13 (temperature)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
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
|
|
|
|
|
2012-10-01 16:21:29 +02:00
|
|
|
|
** Scenario 14 (humidity)
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-10-01 16:21:29 +02:00
|
|
|
|
This scenario is similar to the scenario 13, but its goal is to evaluate
|
|
|
|
|
the impact of the humidity rather than of the temperature. Like in the
|
|
|
|
|
scenario 13, the terminal is at the measurement point 1, but it is
|
|
|
|
|
placed at hip altitude.
|
|
|
|
|
|
|
|
|
|
The humidity starts from a minimum, and is raised during the experiment.
|
|
|
|
|
For this purpose, boilers and hot water basins can be used. That is why
|
|
|
|
|
the client terminal should not be put on the floor, to avoid attenuation
|
|
|
|
|
of the signal due to the liquid water itself.
|
|
|
|
|
|
|
|
|
|
Nobody should enter the room during the measurements.
|
2012-06-20 11:40:11 +02:00
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 15 (autocalibration alone, static)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
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-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 16 (autocalibration alone, mobility)
|
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
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 17 (autocalibration alone, mobility, two humans)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
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-09-20 12:50:48 +02:00
|
|
|
|
Detailed procedure:
|
|
|
|
|
- Start the aggregation server; human operator #1 is standing at MP#1,
|
|
|
|
|
while operator #2 is standing at MP#4.
|
|
|
|
|
- After 10 seconds at these positions, the operators start moving to the
|
|
|
|
|
next measurement points: operator #1 goes to MP#2, while operator #2
|
|
|
|
|
goes to MP#3. The operators walk at a pace of one step per second, in
|
|
|
|
|
the direction of the next measurement point. It takes 4 seconds to
|
|
|
|
|
reach the next measurement point.
|
|
|
|
|
- Each time the next measurement point is reached, the operators turn in
|
|
|
|
|
the direction of the next measurement point and stand for 10 seconds
|
|
|
|
|
(so at the second position, operator #1 turns in the direction of the
|
|
|
|
|
MP#3, and operator #2 turns in the direction of MP#2). The time to
|
|
|
|
|
turn is one second (so the total movement time is 5s in this case).
|
|
|
|
|
- After 10 seconds at these positions, the operators start walking:
|
|
|
|
|
operator #1 to MP#3, and operator #2 to MP#2. The time needed to
|
|
|
|
|
complete this walk is 10 seconds.
|
|
|
|
|
- After 10 seconds at these positions, operator #1 starts walking to
|
|
|
|
|
MP#4 operator #2 starts walking to MP#1. The time needed to reach
|
|
|
|
|
these points is 5 seconds.
|
|
|
|
|
- After 10 seconds at these positions, both operators walk to MP#5.
|
|
|
|
|
- After 10 seconds at MP#5, the measurements are stopped.
|
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 18 (autocalibration alone, empty room)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
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-09-13 11:49:47 +02:00
|
|
|
|
** TODO Scenario 19 (mobility, two humans)
|
2012-07-18 13:40:05 +02:00
|
|
|
|
|
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
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 20 (manual calibration)
|
2012-08-23 18:17:11 +02:00
|
|
|
|
|
|
|
|
|
Manual calibration, without autocalibration running. The mobile device
|
|
|
|
|
is carried by a human operator.
|
2012-08-30 15:24:10 +02:00
|
|
|
|
|
|
|
|
|
Please keep in mind that the default aggregation time is not sufficient
|
|
|
|
|
to aggregate correctly manual calibration requests (cf. Common rules).
|
2012-09-06 15:50:45 +02:00
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 21 (obstacle)
|
2012-09-06 15:50:45 +02:00
|
|
|
|
|
|
|
|
|
This scenario aims to evaluate the impact of an obstacle on the
|
|
|
|
|
propagation. Only two equipments are used, one on each side of the
|
|
|
|
|
obstacle. To evaluate the attenuation in both directions, the easiest
|
|
|
|
|
way is to activate the autocalibration, but one can also use normal
|
|
|
|
|
positioning requests.
|
2012-09-13 11:49:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Office space scenarios
|
|
|
|
|
|
2012-09-13 12:49:46 +02:00
|
|
|
|
This series of scenarios is schematised in the figure
|
|
|
|
|
[[./figures/offices.svg]].
|
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Common rules exceptions & additions
|
|
|
|
|
|
|
|
|
|
*** Device used
|
|
|
|
|
|
|
|
|
|
The Fonera use 5 dBi antennas.
|
|
|
|
|
|
|
|
|
|
*** Measurement-related rules
|
|
|
|
|
|
|
|
|
|
Due to the fact that the antenna used on the client terminal in not
|
|
|
|
|
bendable, to have it vertical in a fixed position, a little stand was
|
|
|
|
|
used, which increases the terminal altitude by 13 cm. Therefore, the
|
|
|
|
|
standard altitudes become:
|
|
|
|
|
- floor (0.13 m),
|
|
|
|
|
- hip (0.95 m),
|
|
|
|
|
- ear (1.70 m).
|
|
|
|
|
|
|
|
|
|
** Testing area
|
|
|
|
|
|
|
|
|
|
*** TODO Area description
|
|
|
|
|
|
|
|
|
|
This space's topology is described in the OwlPS Positioner's
|
|
|
|
|
configuration files [[./owlps-config/offices/topology.csv]] and
|
|
|
|
|
[[./owlps-config/offices/waypoints.csv]].
|
|
|
|
|
|
|
|
|
|
*** Listeners
|
|
|
|
|
|
|
|
|
|
The capture points are put on pieces of furniture, at an altitude of
|
|
|
|
|
approximately one metre; for this experiment, it is considered that the
|
|
|
|
|
altitude is exactly one metre. All the capture points have their
|
|
|
|
|
antennas in vertical position, in the direction of the ceiling.
|
|
|
|
|
Their coordinates, as well as their real altitudes, are given in the
|
|
|
|
|
OwlPS Positioner's configuration file
|
|
|
|
|
[[./owlps-config/offices/listeners-fonera.csv]].
|
|
|
|
|
|
|
|
|
|
*** Calibration points
|
|
|
|
|
|
|
|
|
|
1. (3;5.48)
|
|
|
|
|
2. (3;9.09)
|
|
|
|
|
3. (3;12.67)
|
|
|
|
|
4. (3;16.30)
|
|
|
|
|
5. (3;19)
|
|
|
|
|
6. (3;24)
|
|
|
|
|
7. (7.50;5.48)
|
|
|
|
|
8. (7.50;9.09)
|
|
|
|
|
9. (7.50;12.67)
|
|
|
|
|
10. (7.50;16.30)
|
|
|
|
|
11. (7.50;19)
|
|
|
|
|
12. (7.50;24)
|
|
|
|
|
|
|
|
|
|
*** Measurement points
|
|
|
|
|
|
|
|
|
|
1. (3;5.48)
|
|
|
|
|
2. (6.85;7)
|
|
|
|
|
3. (1.66;8.49)
|
|
|
|
|
4. (2.95;11.79)
|
|
|
|
|
5. (6.31;13.80)
|
|
|
|
|
6. (4.90;15.10)
|
|
|
|
|
7. (2.75;16.63)
|
|
|
|
|
8. (8.41;13.15)
|
|
|
|
|
9. (9.59;16.20)
|
|
|
|
|
10. (7.50;18)
|
|
|
|
|
11. (5.15;21.07)
|
|
|
|
|
12. (3;19)
|
|
|
|
|
13. (1.77;23.30)
|
|
|
|
|
14. (3.55;23.80)
|
|
|
|
|
|
|
|
|
|
** Scenario 50 (manual calibration)
|
|
|
|
|
|
|
|
|
|
This scenario is similar to the scenario 20. The calibration points are
|
|
|
|
|
listed in the upper section “Calibration points”.
|
|
|
|
|
|
|
|
|
|
** Scenario 51 (static, hip)
|
|
|
|
|
|
|
|
|
|
This scenario is similar to the scenario 1. The measurement points used
|
|
|
|
|
are 1, 2, 5, 7, 10 and 11, and the terminal is at hip altitude, without
|
|
|
|
|
human operator carrying it.
|
|
|
|
|
|
|
|
|
|
** Scenario 52 (static, floor)
|
|
|
|
|
|
|
|
|
|
This scenario is similar to the scenario 2, i.e. a static measurement
|
|
|
|
|
with the terminal on the floor, but with the following differences:
|
|
|
|
|
- only the measurement point 8 is used;
|
|
|
|
|
- the test lasts for at least 30 minutes.
|
|
|
|
|
|
2012-09-13 12:59:00 +02:00
|
|
|
|
** Scenario 53 (autocalibration alone)
|
|
|
|
|
|
|
|
|
|
This scenario is similar to the scenarios 15 to 18, except the
|
|
|
|
|
environment is not controlled, i.e. people move in the corridor and
|
|
|
|
|
offices in a regular office activity.
|
|
|
|
|
|
2012-09-13 11:49:47 +02:00
|
|
|
|
** Scenario 54 (mobility)
|
|
|
|
|
|
|
|
|
|
This scenario is similar to the scenario 4: a path is defined, going
|
|
|
|
|
through all the 14 measurement points.
|
|
|
|
|
|
2012-09-19 13:02:23 +02:00
|
|
|
|
*** Procedure
|
|
|
|
|
|
2012-09-27 17:42:24 +02:00
|
|
|
|
Before to start the timer, start the aggregation server (with
|
|
|
|
|
autocalibration activated) and wait for all the listeners to send a
|
|
|
|
|
Hello message.
|
|
|
|
|
- t-10 :: Stand at MP#1, facing the North, while the listeners send
|
2012-09-13 11:49:47 +02:00
|
|
|
|
autocalibration requests.
|
2012-09-27 17:42:24 +02:00
|
|
|
|
- t1 :: Start the client, stay at MP#1 until t10.
|
|
|
|
|
- t11 :: Start walking to MP#2 (6 steps).
|
|
|
|
|
- t16 :: Arrived at MP#2, face the North and wait until t26.
|
|
|
|
|
- t27 :: Start walking to MP#3 (7 steps).
|
|
|
|
|
- t33 :: Arrived at MP#3, rotate clockwise in two steps (until t35), to
|
2012-09-13 11:49:47 +02:00
|
|
|
|
face the right side of the frame of the door between the two
|
|
|
|
|
offices; wait until t44.
|
2012-09-27 17:42:24 +02:00
|
|
|
|
- t45 :: Start walking to MP#4 (5 steps).
|
|
|
|
|
- t49 :: Arrived at MP#4, rotating clockwise in one step (until t50) to
|
2012-09-13 11:49:47 +02:00
|
|
|
|
face the office door (MP#5); wait until t60.
|
2012-09-27 17:42:24 +02:00
|
|
|
|
- t61 :: Start walking to MP#5 (4 steps).
|
|
|
|
|
- t64 :: Arrived at MP#5, face the stairway and wait until t74.
|
|
|
|
|
- t75 :: Start walking to MP#6 (4 steps).
|
|
|
|
|
- t78 :: Arrived at MP#6, face the West and wait until t88.
|
|
|
|
|
- t89 :: Start walking to MP#7 (5 steps).
|
|
|
|
|
- t93 :: Arrived at MP#7, rotate counter-clockwise in two steps (until
|
|
|
|
|
t95) to face the middle of the office wall (the wall separating
|
|
|
|
|
the office from the corridor); wait until t104.
|
|
|
|
|
- t105 :: Start walking to MP#8 (8 steps).
|
|
|
|
|
- t112 :: Arrived at MP#8, rotate counter-clockwise in one step (until
|
2012-09-13 11:49:47 +02:00
|
|
|
|
t113) to face MP#9; wait until t122.
|
2012-09-27 17:42:24 +02:00
|
|
|
|
- t123 :: Start walking to MP#9 (4 steps).
|
|
|
|
|
- t126 :: Arrived at MP#9, rotate counter-clockwise in one step (until
|
2012-09-13 11:49:47 +02:00
|
|
|
|
t127) to face the West; wait until t136.
|
2012-09-27 17:42:24 +02:00
|
|
|
|
- t137 :: Start walking to MP#10 (4 steps).
|
|
|
|
|
- t140 :: Arrived at MP#10, face the North and wait until t150.
|
|
|
|
|
- t151 :: Start walking to MP#11 (6 steps).
|
|
|
|
|
- t156 :: Arrived at MP#11, face the West and wait until t166.
|
|
|
|
|
- t167 :: Start walking to MP#12 (4 steps).
|
|
|
|
|
- t170 :: Arrived at MP#12, face the West and wait until t180.
|
|
|
|
|
- t181 :: Start walking to MP#13 (6 steps).
|
|
|
|
|
- t186 :: Arrived at MP#13, face the North and wait until t196.
|
|
|
|
|
- t197 :: Start walking to MP#14 (4 steps).
|
|
|
|
|
- t200 :: Arrived at MP#14, face the room door and wait until t210.
|
|
|
|
|
- t210 and a few milliseconds :: Stop the client.
|
2012-09-13 12:49:23 +02:00
|
|
|
|
|
|
|
|
|
One request should be transmitted each second, for a total of 210
|
|
|
|
|
requests. To help meeting this goal, the client can be launched with the
|
|
|
|
|
-N210 option.
|
2012-09-19 13:02:23 +02:00
|
|
|
|
|
|
|
|
|
*** Detailed timing
|
|
|
|
|
|
|
|
|
|
Note: this timing is based on test #7 (2012-09-11), with the slight time
|
|
|
|
|
shift induced by the client's parameters (i.e. -n20 -t10 -F761 -N210).
|
|
|
|
|
Due to this time shift, 210 requests are sent during 212 seconds, the
|
|
|
|
|
end of the test (labelled “end” below) is therefore t212. The two “lost”
|
|
|
|
|
seconds are rattrapées during the intervals indicated with a star (*).
|
|
|
|
|
|
|
|
|
|
- t1-t10 :: (3;5.48;1)
|
|
|
|
|
- t11 :: (3.60;6.30;1)
|
|
|
|
|
- t12 :: (4.24;6.30;1)
|
|
|
|
|
- t13 :: (4.88;6.30;1)
|
|
|
|
|
- t14 :: (5.52;6.30;1)
|
|
|
|
|
- t15 :: (6.15;6.30;1)
|
|
|
|
|
- t16-t26 :: (6.85;7;1)
|
|
|
|
|
- t27 :: (6.15;7.70;1)
|
|
|
|
|
- t28 :: (5.39;7.83;1)
|
|
|
|
|
- t29 :: (4.64;7.97;1)
|
|
|
|
|
- t30 :: (3.89;8.10;1)
|
|
|
|
|
- t31 :: (3.15;8.23;1)
|
|
|
|
|
- t32 :: (2.41;8.36;1)
|
|
|
|
|
- t33-t44 :: (1.66;8.49;1)
|
|
|
|
|
- t45 :: (2.14;8.92;1)
|
|
|
|
|
- t46 :: (2.62;9.36;1)
|
|
|
|
|
- t47 :: (3.10;9.79;1)
|
|
|
|
|
- t48 :: (3;10.79;1)
|
|
|
|
|
- t49-t60 :: (2.95;11.79;1)
|
|
|
|
|
- t61 :: (3.79;12.29;1)
|
|
|
|
|
- t62 :: (4.63;12.80;1)
|
|
|
|
|
- t63 :: (5.47;13.30;1)
|
|
|
|
|
- t64-t74* :: (6.31;13.80;1)
|
|
|
|
|
- t75 :: (6.50;14.30;1)
|
|
|
|
|
- t76 :: (5.90;14.50;1)
|
|
|
|
|
- t77 :: (5.40;14.50;1)
|
2012-09-27 16:28:14 +02:00
|
|
|
|
- t78-t88 :: (4.90;15.10;1)
|
|
|
|
|
- t89 :: (4.10;15.10;1)
|
|
|
|
|
- t90 :: (3.60;15.60;1)
|
|
|
|
|
- t91 :: (3.60;16.10;1)
|
|
|
|
|
- t92 :: (3.60;16.60;1)
|
2012-09-19 13:02:23 +02:00
|
|
|
|
- t93-t104 :: (2.75;16.63;1)
|
|
|
|
|
- t105 :: (3.70;16.54;1)
|
|
|
|
|
- t106 :: (4.65;16.44;1)
|
|
|
|
|
- t107 :: (5;15.80;1)
|
|
|
|
|
- t108 :: (5.30;15;1)
|
|
|
|
|
- t109 :: (6.08;14.54;1)
|
|
|
|
|
- t110 :: (6.85;14.08;1)
|
|
|
|
|
- t111 :: (7.63;13.61;1)
|
|
|
|
|
- t112-t122 :: (8.41;13.15;1)
|
|
|
|
|
- t123 :: (8.71;13.91;1)
|
|
|
|
|
- t124 :: (9;14.68;1)
|
|
|
|
|
- t125 :: (9.30;15.44;1)
|
|
|
|
|
- t126-t136 :: (9.59;16.20;1)
|
|
|
|
|
- t137 :: (8.80;16.20;1)
|
|
|
|
|
- t138 :: (8;16.20;1)
|
|
|
|
|
- t139 :: (7.50;17;1)
|
|
|
|
|
- t140-t150 :: (7.50;18;1)
|
|
|
|
|
- t151 :: (7.50;18.80;1)
|
|
|
|
|
- t152 :: (7.50;19.60;1)
|
|
|
|
|
- t153 :: (7.50;20.40;1)
|
|
|
|
|
- t154 :: (6.80;21.07;1)
|
|
|
|
|
- t155 :: (6;21.07;1)
|
|
|
|
|
- t156-t166* :: (5.15;21.07;1)
|
|
|
|
|
- t167 :: (4.63;20.58;1)
|
|
|
|
|
- t168 :: (4.12;20.09;1)
|
|
|
|
|
- t169 :: (3.60;19.60;1)
|
|
|
|
|
- t170-t180 :: (3;19;1)
|
|
|
|
|
- t181 :: (2.40;19.60;1)
|
|
|
|
|
- t182 :: (1.77;20.20;1)
|
|
|
|
|
- t183 :: (1.77;20.98;1)
|
|
|
|
|
- t184 :: (1.77;21.75;1)
|
|
|
|
|
- t185 :: (1.77;22.52;1)
|
|
|
|
|
- t186-t196 :: (1.77;23.30;1)
|
|
|
|
|
- t197 :: (2.20;23.80;1)
|
|
|
|
|
- t198 :: (2.70;24.50;1)
|
|
|
|
|
- t199 :: (3.20;24.20;1)
|
|
|
|
|
- t200-end :: (3.55;23.80;1)
|