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/osmocom-net-gprs@lists.osmocom.org/.
Andreas Eversberg andreas at eversberg.euIvan Kluchnikov wrote: > Can you explain, what is the reason of using Time Indication message? > As I understand, we use only frame number from this message and call > gprs_rlcmac_poll_timeout() function. But when we receive Ready To Send > message, we also receive frame number, so why we couldn't use that FN > for our purpose and call gprs_rlcmac_poll_timeout() in function, which > handling ReadyToSend message? hi ivan, the reason is that i need to find out when an uplink control bock is not received. this is required to handle counters on dropped frames. the problem is, that i did not yet manage to get bad frame indications. in order to have a quick workarround, i use gsm time indications. these indications are sent in advance of about 10 frames. after 20 frames i can be sure that the frame has not been received. using rts message would be possible too, but since i cannot be sure how much earlier they are sent, i cannot define how many frames i have to wait until timeout. if openbts uses an exact definition of how much earlier the rts messages are sent. if you look at gprs_rlcmac_poll_timeout(), you will see that i wait 20 frames. if rts message would be sent 52 frames in advance, then you should use wait something like 60. (add 10 to avoid jitter). > Now I think, it makes sense to merge your branch with master, but we > should coordinate this process. When it is better to merge it? Do you > plan to make some more fixes, modifications and cleaning of the code > at this stage? > I believe, for better understanding of further development of the > project we should coordinate our efforts and discuss, what should be > implemented in the next steps. What plans of development do you have now? yes, i agree that we should coordinate it. my current plans are: - cleanup of debugging levels: (LOGL_DEBUG=full processing, LOGL_INFO=just infos about complete frames, LOGL_NOTICE=abnormal timeouts, invalid data and protocol errors, LOGL_ERROR=local errors, software errors. (i have already done this, but not yet committed.) - replace hand-hacked/wireshark transcoding of control blocks by generated code from encodix. (i will to try this tomorrow.) - changing from c++ back to c. (only possible after replacing the wireshark code.) - multislot support. i also agree with alexander's comment on splitting the commits. (especially the support of cell information from socket interface.) i can do that and provide seperate patches to this list tomorrow. sometimes it is hard to implement new features without doing cleanups at the same time, since i don't know what have to be cleaned in order to make the new feature work. instead i work on the feature and clean at the same time. (like replacing all hardcoded values by the cell information from the socket interface (or maybe from config file, one day).) regards, andreas