this is to avoid invalid configs that later on cause segfaults, etc.
e.g.:
0 0x7f397adf64a3 (/lib/x86_64-linux-gnu/libc.so.6+0xbb4a3)
1 0x7f397cc8c6ce (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x796ce)
2 0x55b921d61707 in srsran_vec_cf_copy /mnt/data/jenkins/workspace/srslte_ogt_trial_builder_x86-ubuntu1804-asan/srsLTE/lib/src/phy/utils/vector.c:226
3 0x55b921d3b1d4 in ssb_demodulate /mnt/data/jenkins/workspace/srslte_ogt_trial_builder_x86-ubuntu1804-asan/srsLTE/lib/src/phy/sync/ssb.c:632
4 0x55b921d3d8ce in srsran_ssb_csi_measure /mnt/data/jenkins/workspace/srslte_ogt_trial_builder_x86-ubuntu1804-asan/srsLTE/lib/src/phy/sync/ssb.c:905
5 0x55b9215dc20f in srsue::nr::cc_worker::measure_csi() /mnt/data/jenkins/workspace/srslte_ogt_trial_builder_x86-ubuntu1804-asan/srsLTE/srsue/src/phy/nr/cc_worker.cc:373
6 0x55b9215dd216 in srsue::nr::cc_worker::work_dl() /mnt/data/jenkins/workspace/srslte_ogt_trial_builder_x86-ubuntu1804-asan/srsLTE/srsue/src/phy/nr/cc_worker.cc:483
7 0x55b9215f9c69 in srsue::nr::sf_worker::work_imp() /mnt/data/jenkins/workspace/srslte_ogt_trial_builder_x86-ubuntu1804-asan/srsLTE/srsue/src/phy/nr/sf_worker.cc:78
8 0x55b921c47cc6 in srsran::thread_pool::worker::run_thread() /mnt/data/jenkins/workspace/srslte_ogt_trial_builder_x86-ubuntu1804-asan/srsLTE/lib/src/common/thread_pool.cc:48
9 0x55b92152ea0b in srsran:🧵:thread_function_entry(void*) /mnt/data/jenkins/workspace/srslte_ogt_trial_builder_x86-ubuntu1804-asan/srsLTE/lib/include/srsran/common/threads.h:103
10 0x7f397c9fb6da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)
11 0x7f397ae5c71e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x12171e)
* Improve reliability of timestamp to tti conversion
Difftime is not reliable as it might use 32 bit calculation, depending on the system. This leads to wrong frame numbers and subframe indices.
I encountered this Issue when testing the pssch_ue exampel on my system and the conversion from timestamp to frame number and sf idx was wrong.
* Improve GNSS Sync
Added loop to check for GNSS alignment while syncing.
If the received GNSS signal is weak, synchronization errors might occur while syncing.
we've had a few runs in the CI where opening the specified RF device
failed but the eNB/UE still continued to run, just picking the next available
run. This led to false-positive tests.
The policy should be that whenever the user specified a RF device to
be openend, and this device fails, the whole process should fail and
the application should exit.
The auto-detection mode is still available but only if no device name
is specified at all.