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/OpenBSC@lists.osmocom.org/.
Vadim Yanitskiy axilirator at gmail.comThanks to Sylvain, He pointed me out to the src/conv.c//osmo_conv_get_output_length(). I just implemented this function in Python, and finished related commit. With best regards, Vadim Yanitskiy. 2017-01-12 18:30 GMT+07:00 Vadim Yanitskiy <axilirator at gmail.com>: > Hi Tom and all, > > After a quick look at the 4th patch, related to your optimized > Viterbi decoder, I have noticed that currently the convolutional > code definitions from the 'src/gsm/gsm0503_conv.c' are out of > the 'tests/conv' test coverage... > > So, I would like to extend the test coverage. All I need are > the test vectors, which I'll add to existing ones. Some of them > I already found in your 4th patch, but some pending I need to > write myself. > > Right now I have a simple question... > Let's look at one example: > > { > .name = "GSM RACH (non-recursive, flushed, not punctured)", > .code = &gsm_conv_rach, > .in_len = 14, > .out_len = 36, // ??? > .has_vec = 0, > .vec_in = { }, > .vec_out = { }, > } > > As I noticed, the 'in_len' may be taken from the code definition: > > const struct osmo_conv_code gsm0503_rach = { > .N = 2, > .K = 5, > .len = 14, // The 'in_len' is here! > .next_output = xcch_output, > .next_state = xcch_state, > }; > > But I don't know how to calculate the 'out_len'... > Could you please give me some hint? > > I already started to work on your 4th patch: > https://gerrit.osmocom.org/1542 > https://gerrit.osmocom.org/1543 > > With best regards, > Vadim Yanitskiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170116/95cf8e83/attachment.htm>