Some code in T tracers is used by both LTE and NR.
In LTE, we expect 10 subframes per frame, and the logging is done with
this assumption. We have one tick per subframe.
In NR, we deal with slots, not subframes. And we have n ticks per frame
(depending on mu). As of today, only n=20 is tested (corresponding to
mu=1).
A previous commit introduced 'subframes_per_frame' which had the correct
meaning for LTE but was truly 'slots per frame' for NR. This creates
confusion.
Let's replace 'subframe' by 'tick' to reduce confusion.
Think: NR with different number of slots per frame depending on mu.
The name 'subframes_per_frame' is a bit ambiguous. It is valid for LTE,
but for NR it should be 'slots_per_frame'.
For example, for sub-carrier spacing of 30KHz, we have 20 slots per
frame, so in this case subframes_per_frame = 20. In reality whatever
the numerology, there is always 10 subframes per frame in NR.
But how to name this variable which is used both for LTE and NR cases?
'subframes_or_slots_per_frame'? It's a bit long and also ambiguous.
Conclusion: no big deal I think. 'subframes_per_frame' and so be it.
- Add CMakeLists.txt to build all T tracer user tools
- Previous Makefiles are retained in common/utils/T: you can do
$ cd common/utils/T/tracer
$ make # all executables are there
or also
$ mkdir build && cd build
$ cmake .. -GNinja
$ ninja T_tools # all executables are in build/common/utils/T/tracer
XY_LOOP_MODE: replace old points with new ones, using the maximum size
of the view
XY_FORCE_MODE: append_forced sets those and only those points
and we crash if we pass too much points
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.
no deadlock should be possible as of the current state of
things. When the textlist's lock is set the GUI lock is
never on.
Let's cross fingers that things don't change crazily in
the future...
when too much data has been sent to the text list view, way too much
GUI processing is done, let's batch-process the changes and then tell
the GUI that something has changed
Cedric Roux