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
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;
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)
