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
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
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
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.
this may be removed at some point, it's very brutal. But when you
write some code, it may happen (it "may"!!) that *sometimes* the
code does not work and crashes. In thoses cases I prefer the
local tracer (or the tracee) to go away immediately without even
thinking about it maybe still running in the background.
In case of monitoring (as opposed to debugging) maybe it's preferable
to let the process live its life as it wants.
Time will tell.
Cedric Roux