This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gmr@lists.osmocom.org/.
Johann T. johann.tzt at gmail.comHi Sylvain, Thank you for getting back on this. I will look further into the block as you suggested. It is also possible that the uplink signal of my initial capture was too strong and somehow saturated the receiver. I plan to perform more tests in the coming weeks as the weather is getting better. Best regards, Johann On Tue, May 25, 2021 at 7:26 PM Sylvain Munaut <246tnt at gmail.com> wrote: > 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. > > Oops, looks like I complete missed this ... sorry. > > That graph was made to scan large bandwidth capture for RACH ... It's > very probable that a bunch of constants and thresholds value are just > not appropriate for a narrow band capture. > It kind of always required tweaking depending on the case. Basically > manually finding a RACH (in frequency and time), then look at all the > intermediate steps of the graphs (and possibly inside the block) to > see if it detects that particular one and tweak it until it does. And > then you can run it to find the other ones. > > I don't have any setup any more to capture C-band uplink so I have not > run that graph in years .... but that's all I remember about it. > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gmr/attachments/20210602/ab930add/attachment.htm>