January 2022 - tetra - lists.osmocom.org

OsmoDevCon 2022 ?
by Harald Welte 10 Mar '22

10 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 4

lists.osmocom.org migrated to mailman3
by Harald Welte 03 Jan '22

03 Jan '22

Dear Osmocom community, today our mailing list server lists.osmocom.org has finally been migrated from mailman2-on-freebsd to mailman3-on-linux. This also included a variety of changes to DNS. I'll spare you the details, but everything _should_ be up and running now. * The List-Id headers should not have changed. * all list subscriptions + user accounts have been converted. * old 'static html' archives are still available (read only) at URLs like https://lists.osmocom.org/pipermail/baseband-devel/ * old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel are redirected to their respective modern counterparts In case you notice any mailing list related problem, please don't hesitate to contact me. Happy hacking, 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)

1 0

None
by None 03 Jan '22

03 Jan '22

would permit try transmitting. So if you either find a legal way to = include the ETSI code at build time, or preferable write a GPL compatibl= e audio decoder, I think we would be happy to include it in the git repo= sitory. cheers     holger Hello Pepijn, On Sat, 24 Sep 2011 15:49:37 +0200, "Pepijn van den Berkhof= " <<a ymailto=3D"mailto:vandenberkhof.pepijn@gmail.com" href=3D"mailto:v= andenberkhof.pepijn(a)gmail.com">vandenberkhof.pepijn(a)gmail.com</a>> wrote= : > > But do you actually hear output from a real life network= ? Because I > tried the examples attached to the ETSI document regard= ing the testing > of the codec. They work very nicely, but no luck on= real life networks > so far. (yes, no encryption) I know that= others have used the current code to decode speech, maybe someone can c= onfirm it. I haven't worked with the code for a while and so can't c= onfirm it, but it has worked for me in the past. Maybe I find the= time to try it within the next few weeks, if possible I will also try t= o provide a sample capture from a test TETRA network so everyone can try= the sample. "Test TETRA Network" means from a network under our control run in a faraday cage so that there are no legal issues providi= ng the capture. Best regards,   Dieter -- Dieter Spaa= r, Germany                  &n= bsp;       <a ymailto=3D"mailto:spaar@mirider.augusta.de" h= ref=3D"mailto:spaar@mirider.augusta.de">spaar(a)mirider.augusta.de</a> <br= > <div id=3D"yiv1108789824">is that could help us for voice decoding : ?= <a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.joys99.com= /d-4784.html">http://www.joys99.com/d-4784.html</a> --= =0A</div> _______________________________________________ te= tra mailing list <a ymailto=3D"mailto:tetra@lists.osmocom.org" href=3D"m= ailto:tetra@lists.osmocom.org">tetra(a)lists.osmocom.org</a> <a href=3D"ht= tps://lists.osmocom.org/mailman/listinfo/tetra" target=3D"_blank">https://l= ists.osmocom.org/mailman/listinfo/tetra</a> </div></div></div></= body></html> --1668814050-976982791-1316890565=:17022--

1 0

None
by None 03 Jan '22

03 Jan '22

========= The BCCH is used for two types of broadcast control channel: * BSCH (broadcast sync channel) * Broadcast Network Chanenl (BNCH) These channels, whcih are present only on the downlink, transmit information about the serving base station. The BSCH transmits the SYNC message. This provides physical layer synchronization information, including an extended training sequence for synchronisation and slot alignment, frequency correction bits to set the carrier frequency, along with MAC layer information on frame timing (i.e. the number of the current slot, frame and multiframe) as well as network layer information. Due to the physical layer synchronisation, the BSCH is transmitted on a synchronisation burst rather than a normal downlink burst. The BNCH either carries the ACCESS-DEFINE message or the SYSINFO message. The SYSINFO message fives the main carrier frequency so that mobiles can tune to it after picking up any SYSINFO message infromation on any secondary control channels, power information and network layer information. The broadcast control channels are normally transmitted in frame 18. Each takes up to one block of 216 bits, leaving the other block withing the burst for the corresponding assigned channel or for the base station to send signalling to other mobiles. O each slot, the sequence shon win figure 7.45 is used, and the sequence is offset b yone for each slot in the frame, so that every frame 18 has one BSCH and one BNCH. However, transmitting the network information takes several half-slot BNCH instances, and it will take some time therefore for a mobile to acquire all the information it needs. This is not normally a concern since mobiles will be switched on before they are used and an initial delay can be tolerated. The standards allow the option of transmitting the BNCH in other physical control channels (indicated by the AACH) as neccessary. Mobiles continue to monitor the BCCH after they are switched on and also during transmissions so as to ensure that they receive network information and remain synchronised. Multiframe number 1 2 3 4 DL Frame 18, first half slot BSCH* DL Frame 18, second half slot * BNCH * = Transmitted on a Synchronisation Burst Figure 7.45 BSCH and BNCH transmission sequence. ============== -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0