- 20 Jun, 2016 2 commits
-
-
Cedric Roux authored
-
Cedric Roux authored
-
- 17 Jun, 2016 4 commits
-
-
Cedric Roux authored
-
Cedric Roux authored
to be used in conjunction with another tracer so conceptually it's more a tracee than a tracer
-
Cedric Roux authored
-
Cedric Roux authored
-
- 16 Jun, 2016 5 commits
-
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
- 15 Jun, 2016 1 commit
-
-
Cedric Roux authored
The distinction common space/user space still requires some careful examination.
-
- 13 Jun, 2016 2 commits
-
-
Rohit Gupta authored
T I did some compilation tests using `./build_oai -s --run-group "0101*"`, all was fine. I ran `lte-softmodem` with the sequans and let it run for a while with both uplink and downlink UDP low throughput traffic, all was fine. I ran some TCP tests, downlink 14 Mb/s (because the sequans does not report a CQI of 15 but 14 maximum, so we don't go to maximum MCS, so 14 Mb/s instead of 16) with a very clean radio (almost no error in the HARQ processes). For uplink things are not so clean, it starts at 6 Mb/s and after a while goes down to 2/3 Mbit/s. Lot's of errors in the HARQ processes, mostly uplink but also downlink. This is a both with and without T activated. So to me it's fine. The T tracer is a debugging tool. When it's not enabled, it has zero impact on the processing. I think we need to do very little tests before merging. I'll let you decide but to me it's okay! See merge request !36
-
Raymond Knopp authored
-
- 10 Jun, 2016 10 commits
-
-
Cedric Roux authored
if you compile *without* T it fails because the T macro is interpreted as a function call
-
Cedric Roux authored
-
Cedric Roux authored
Conflicts: cmake_targets/CMakeLists.txt cmake_targets/build_oai openair1/PHY/LTE_TRANSPORT/pucch.c openair1/SCHED/phy_procedures_lte_eNb.c openair2/LAYER2/MAC/eNB_scheduler_ulsch.c targets/RT/USER/lte-softmodem.c
-
Rohit Gupta authored
-
Dominique Nussbaum authored
-
Cedric Roux authored
very basic, to be refined, find a nice way to display (plot? text?) protocol data movement
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
to be refined, it's rough
-
- 09 Jun, 2016 8 commits
-
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
3 pixels wide look better than 1
-
Cedric Roux authored
- update T_messages.txt - update call sites of the T for thoses traces
-
Cedric Roux authored
more readable, still not satisfying though
-
Cedric Roux authored
-
- 08 Jun, 2016 7 commits
-
-
Cedric Roux authored
-
Cedric Roux authored
events are accepted by the logger if the filter accepts them the filter is optional (no filter means to accept all events)
-
Cedric Roux authored
improve the use of the variable "frame" in oaisim The modifications are only in oaisim.c. It is thus needless to run soft-modem tests. Only oaisim tests are required. See merge request !34
-
Cedric Roux authored
this is like timeview but the plotting is done at frame/subframe resolution of a given reference clock signal, let's say. The realtime information of the events is not used. It's all logical. It will be used to log harq processes for the moment.
-
Cedric Roux authored
-
Rohit Gupta authored
-
-
- 07 Jun, 2016 1 commit
-
-
Rohit Gupta authored
-