Running with cProfile shows that there are quite a lot calls:
469896 0.254 0.000 0.254 0.000 trx_list.py:37(__getitem__)
Let's better avoid using it in performance critical parts.
Change-Id: I2bbc0a2af8218af0b9a02d8e16d4216cf602892a
By default RSSI on the Rx side is computed based on transmitter's
tx power and then substracting the the Rx path loss.
If FAKE_RSSI is used, then the values in there are used instead.
A default hardcoded value of tx nominal power = 50 dBm is set to keep
old behavior of RSSI=-60dB after calculations.
Change-Id: I3ee1a32ca22c3272e66b3ca78e4f67d283844c80
Jenkins build #2516 has uncovered a problem in DATADumpFile.parse_msg():
======================================================================
FAIL: test_parse_empty (test_data_dump.DATADump_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/build/src/target/trx_toolkit/test_data_dump.py",
line 138, in test_parse_empty
self.assertEqual(msg, False)
AssertionError: None != False
I did a quick investigation, and figured out that this failure
happens when trying to call parse_msg() with idx == 0, because
DATADumpFile._seek2msg() basically does nothing in this case
and thus always returns True. The None itself comes from
DATADumpFile._parse_msg().
Let's ensure that DATADumpFile.parse_msg() always returns None,
even if DATADumpFile._seek2msg() fails. Also, update the unit
test, so we always test a wide range of 'idx' values.
Change-Id: Ifcfa9c5208636a0f9309f5ba8e47d282dc6a03f4
There are two ways to implement frequency hopping:
a) The Transceiver is configured with the hopping parameters, in
particular HSN, MAIO, and the list of ARFCNs (channels), so the
actual Rx/Tx frequencies are changed by the Transceiver itself
depending on the current TDMA frame number.
b) The L1 maintains several Transceivers (two or more), so each
instance is assigned one dedicated RF carrier frequency, and
hence the number of available hopping frequencies is equal to
the number of Transceivers. In this case, it's the task of
the L1 to commutate bursts between Transceivers (frequencies).
Variant a) is commonly known as "synthesizer frequency hopping"
whereas b) is known as "baseband frequency hopping".
For the MS side, a) is preferred, because a phone usually has only
one Transceiver (per RAT). On the other hand, b) is more suitable
for the BTS side, because it's relatively easy to implement and
there is no technical limitation on the amount of Transceivers.
FakeTRX obviously does support b) since multi-TRX feature has been
implemented, as well as a) by resolving UL/DL frequencies using a
preconfigured (by the L1) set of the hopping parameters. The later
can be enabled using the SETFH control command:
CMD SETFH <HSN> <MAIO> <RXF1> <TXF1> [... <RXFN> <TXFN>]
where <RXFN> and <TXFN> is a pair of Rx/Tx frequencies (in kHz)
corresponding to one ARFCN the Mobile Allocation. Note that the
channel list is expected to be sorted in ascending order.
NOTE: in the current implementation, mode a) applies to the whole
Transceiver and all its timeslots, so using in for the BTS side
does not make any sense (imagine BCCH hopping together with DCCH).
Change-Id: I587e4f5da67c7b7f28e010ed46b24622c31a3fdd
If the main thread crashes, the CLCKGen's thread would never stop.
It would also happen if the main thread terminates without calling
CLCKGen.stop(). Let's prevent this by creating a daemon thread.
Change-Id: I9d41c5baa25fa0a263758414a164c1bded25e04e
The previous approach was based on threading.Timer, so on each clock
iteration one thread spawned another new thread. So far it worked
well, but such frequent spawning involves an additional overhead.
After this change, CLCKGen.start() allocates and starts a new thread,
that periodically sends clock indications and sleep()s during the
indication intervals. The CLCKGen.stop() in its turn terminates
that thread and frees the memory.
Change-Id: Ibe477eb0a1ee2193c1ff16452a407be7e858b2ef
Since TRXD header version 1, we should send NOPE indications to the
L1 side in absence of TRX2L1 bursts, and IDLE indications during
IDLE TDMA frames (basically noise measurements).
This change is the first step towards the goal: if a given burst
is to be dropped due to the path loss simulation (see FAKE_DROP),
mark the carrier TRX2L1 message as NOPE.ind and send anyway.
Change-Id: Iabd0af665e3108d23a908638f943a5b689986e2c
Related: OS#3428, OS#2975
The burst transformation in BurstForwarder.forward_msg() used to be
done only once, so then the resulting message was distributed over
the list of connected (and active) transceivers.
This approach limits the path loss simulation capabilities, because
a reference to the same message is passed to FakeTRX.send_data_msg().
If one transceiver changes (or removes) the burst bits, the other
transceivers would not receive the original message.
Let's do the transformation individually for each transceiver,
so the original message will always remain unchanged.
Change-Id: Ia016a3a9bb6e9f17182a7168aa5a501ae9b9978b
Since version 3.8, Python warnins us that using the "is" and "is not"
operators with string and numerical literals is a bad idea. Let's
avoid this and use the classical '==' and '!=' operators instead.
Change-Id: Iaed86d630ac1e0b9b4f72bbf3c788e325783456d
Bug description: https://bugs.python.org/issue34850
Before using DATA_MSG.HDR_LEN, we need to make sure that a parsed
header version is known and supported. Otherwise we will get an
IndexError exception.
Change-Id: Ie1887aa8709da1a2a287aa58a7873e72c0b4ed33
Unlike DATA_MSG.HDR_LEN, the CHDR_LEN is a constant that defines
length of the common header, which is mandatory for every version.
DATA_MSG.HDR_LEN in its turn defines length of the whole header,
including the version specific fields. Thus we need to know the
header version before using it.
In DATA_MSG.parse_msg() we need to parse the common header first,
so then we know the version and length of the whole header. After
that we can safely use DATA_MSG.HDR_LEN.
Change-Id: I2809f5f96209eed64bdabf7a15575144313f7cc9
For sure, the following message is much more informative:
Ignoring an incorrect message: Unhandled version 12
than:
Failed to parse message, dropping...
NOTE: since the way of printing exceptions is different in both
Python versions, I had to drop Python 2 support.
Change-Id: I5fb02ce508c58ff94e47accc0ed655939eb53062
Raising exceptions is a Pythonic way to handle errors, which in this
particular case will help us to know *why* exactly a given message
is incorrect or incomplete.
Change-Id: Ia961f83c717066af61699c80536468392b8ce064
C/I (Carrier-to-Interference ratio) is a value in cB (centiBels),
computed from the training sequence of each received burst,
by comparing the "ideal" training sequence with the received one.
This change introduces a new command similar to FAKE_TOA and FAKE_RSSI,
so it can be used by TTCN-3 test case 'TC_pcu_data_ind_lqual_cb' to
verify that the link quality measurements are delivered to the PCU.
Change-Id: I7080effbbc1022d1884c6d6f0cb580eba8e514ff
Related: OS#1855
Messages on DATA interface may have different header formats, defined
by a version number, which can be negotiated on the control interface.
By default, the Transceiver will use the legacy header version (0).
The header format negotiation can be initiated by the L1 using the
'SETFORMAT' command. If the requested version is not supported by
the transceiver, status code of the response message should indicate
a preferred (basically, the latest) version. The format of this
message is the following:
L1 -> TRX: CMD SETFORMAT VER_REQ
L1 <- TRX: RSP SETFORMAT VER_RSP VER_REQ
where:
- VER_REQ is the requested version (suggested by the L1),
- VER_RSP is either the applied version if matches VER_REQ,
or a preferred version if VER_REQ is not supported.
If the transceiver indicates VER_RSP different than VER_REQ, the L1
is supposed to reinitiate the version negotiation using the suggested
VER_RSP. For example:
L1 -> TRX: CMD SETFORMAT 2
L1 <- TRX: RSP SETFORMAT 1 2
L1 -> TRX: CMD SETFORMAT 1
L1 <- TRX: RSP SETFORMAT 1 1
If no suitable VER_RSP is found, or the VER_REQ is incorrect,
the status code in the response shall be -1.
As soon as VER_RSP matches VER_REQ in the response, the process
of negotiation is complete. Changing the header version is
supposed to be done before POWERON, but can be also done after.
Change-Id: I8d441b2559863d2dbd680db371062e4f3a2f9ff9
Related: OS#4006
Since the new TRXD header format has been introduced, FakeTRX needs
to be able to fill it correctly. In particular, the following:
- Modulation, which can be determined from the burst length;
- Training Sequence Code (and set), which needs to be detected
by comparing the burst bits of L12TRX message against known
training sequences (only GMSK and the default TS set for now);
- C/I (Carrier-to-Interference ratio), which can be simulated
later on, as instructed on the TRXC interface ('FAKE_CI').
The actual TRXD header version is stored in the instance of class
DATAInterface. By default (at startup), legacy version 0 is used.
The version negotiation is supposed to be performed on the TRXC
interface, and to be implemented in a follow-up change.
Different Transceivers may use different header versions, thus in
FakeTRX.send_data_msg() we need to override the original version
of the L12TRX message, and generate the corresponding PDU.
Limitations:
- NOPE / IDLE indications are not (yet) supported;
- TSC detection: GMSK modulation only.
Change-Id: I164f5ae4ce7694d6e324aab927a04e96d489ebd8
Related: OS#4006
Training Sequences are defined in 3GPP TS 45.002, and used by the
transceiver for detecting bursts. This change introduces an enum
with training sequences for GMSK for Access and Normal bursts.
This enumeration is needed for the follow-up changes that implement
TRXD header version 1 support, and can now be used by RandBurstGen.
Change-Id: If3bf102019ef53d6ee9ad230ef98bb45845b5af5
Since version 0x01, the burst bits are encoded as L16V,
so appending two dummy octets doesn't make sense.
Change-Id: I4d6c0bf54649d636ea6cb3fa2f37486b6619d5b3
Vadim Yanitskiy
Pau Espin
Vadim Yanitskiy
Martin Hauke