gmr March 2022

gmr@lists.osmocom.org

3 participants
3 discussions

RACH scan
by Johann T. 06 Feb '23

06 Feb '23

Hi, I have made some captures on the L-band uplink channels and tried to decode the RACH messages. All four consecutive TCH channels (according to the spot beam) were recorded and a call was made during the recording. I am using the GRC block gmr_rach_scan.grc. I have removed the IQ swap from the graph, as suggested in the mailing list. The sampling rate and samples-per-symbol values have been set to 93.6k and 4, respectively. It ran fine without any errors, but I couldn't see any results either on the wireshark or under /tmp/rach.txt. Maybe I overlooked something here. Any ideas or remarks? Many thanks, Johann

3 8

Bug (+ patch) for sync_id retrieval code
by Bart Marinissen 16 Mar '22

16 Mar '22

Hi, Whilst working with this code, I came across some inconsistent sync-ids. Diving in deeper, I found a bug. It’s probably best explained by the patch itself, (see below) but I will also try and explain it in plain words. In short, when checking which sync_id has the highest correlation, the relevant bit of of the signal (with wiggle room) is correlated against the sync-id pattern into a buffer. This adds the output correlation to the buffer. Then, at the end, it was decided which sync_id was present by looking for the max correlation. In between sync-ids, the buffer was not reset. Hence when checking the last sync_id, the buffer does not hold the correlation between that sync_id and the signal, but the sum of correlations between the signal and all sync_id. Hence the results were very strongly biased towards the later sync_ids. The fix is easy. Clear the buffer before every correlation. See the patch below. The patch should apply to the master branch, I believe the bug exists in most branches though,. In my mind, the change is too trivial to be copyrighted. But for completeness sake, I give the osmocom-gmr project permission to use this patch. Kind regards, Bart Marinissen diff --git a/src/sdr/pi4cxpsk.c b/src/sdr/pi4cxpsk.c index 1ed40e01989bac05ff915ebd811835a60f95f61e..e8ab843a92d90622b64b5a59fcaff9ef4d01fea0 100644 --- a/src/sdr/pi4cxpsk.c +++ b/src/sdr/pi4cxpsk.c @@ -204,12 +204,12 @@ _gmr1_pi4cxpsk_sync_find(struct gmr1_pi4cxpsk_burst *burst_type, goto err; } - memset(corr->data, 0x00, sizeof(float complex) * corr->max_len); - corr->len = w; - /* Scan all possible training sequences */ for (i=0; (i < GMR1_MAX_SYNC) && (burst_type->sync[i] != NULL); i++) { + memset(corr->data, 0x00, sizeof(float complex) * corr->max_len); + corr->len = w; + struct gmr1_pi4cxpsk_sync *csync; float s_toa, s_pwr; float complex s_peak;

2 1

OsmoDevCon 2022 ?
by Harald Welte 11 Mar '22

11 Mar '22

Dear fellow Osmocom developers, as you all know, we've sadly had to skip OsmoDevCon 2020 and 2021, trying to compensate it at least to some extent with our OsmoDevCall every two weeks. The COVID-19 pandemic is far from over, and we don't know what the upcoming winter season will bring. Nevertheless, I think it would be a good idea to start a discussion of whether we should plan for an OsmoDevCon in 2022. I personally would say let's plan for the usual late April 2022 time frame, and if the pandemic situation deteriorates, we can still cancel it with something like one month lead time. I would also personally suggest to limit attendance to people who are fully vaccinated, and in addition do a self-test for all participants every morning. In terms of venue, we might also consider to move to a venue that allows better ventilation. Irrespective of the above we can also bring the air filters from the sysmocom office. So with that as an input statement, I would like to hear your opinion on the above proposals. Who would want to attend? Any complaints against the "vaccinated only plus daily self-tests in the morning" approach? Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

gmr March 2022