Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-02-07T03:11:09ZOpen Source Mobile Communications
Redmine OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</p> gr-osmosdr - Bug #5144 (New): Support multiple Airspy deviceshttps://osmocom.org/issues/51442021-05-08T18:58:56ZAsciiWolf
<p>Please, consider supporting multiple Airspy devices in gr-osmosdr. Currently, this is not possible and only one of my connected Airspy R2 devices is available in GNU Radio companion and Gqrx.</p>
<p>There was a patch adding this support (by being able to specify the device serial number as a value for the "airspy" argument in Airspy Source) already posted in 2016: <a class="external" href="https://lists.osmocom.org/pipermail/osmocom-sdr/2016-April/001446.html">https://lists.osmocom.org/pipermail/osmocom-sdr/2016-April/001446.html</a></p>
<p>The patch still seems to work fine on latest gr-osmosdr and adds exactly the functionality needed to make multiple Airspy devices available. Please, consider adding this patch to upstream gr-osmosdr or implementing a different approach to support multiple Airspy devices in gr-osmosdr. Thanks!</p> gr-osmosdr - Bug #4098 (New): [BladeRF micro] Arguments set in osmocom Sink and Source are not pa...https://osmocom.org/issues/40982019-07-11T14:04:23Zlukeekul
<p>For Gnuradio, Device Arguments that are set in osmocom Sink or Source are not executed. As far as I understand the code, these arguments are ignored in sink_impl.cc and source_impl.cc.<br />A patch, the only addresses the bladeRF micro, can be found here:<br /><a class="external" href="https://github.com/Lukeekul/gr-osmosdr/commit/20d1a3618b9e81975d55b05e6f98d969db755aaf">https://github.com/Lukeekul/gr-osmosdr/commit/20d1a3618b9e81975d55b05e6f98d969db755aaf</a><br />Regards,<br />lukeekul</p> gr-osmosdr - Bug #3882 (New): Cannot compile gr-osmosdr!https://osmocom.org/issues/38822019-04-01T19:06:19Zmasterplayer31
<p>This is where I am having the problem at while compiling:</p>
<p>[ 30%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/soapy/soapy_common.cc.o<br />In file included from /usr/include/c++/5/type_traits:35:0,<br /> from /usr/local/include/SoapySDR/Types.hpp:14,<br /> from /home/bobby/gr-osmosdr/lib/soapy/soapy_common.h:25,<br /> from /home/bobby/gr-osmosdr/lib/soapy/soapy_common.cc:21:<br />/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.<br /> #error This file requires compiler and library support \<br /> ^<br />In file included from /home/bobby/gr-osmosdr/lib/soapy/soapy_common.h:25:0,<br /> from /home/bobby/gr-osmosdr/lib/soapy/soapy_common.cc:21:<br />/usr/local/include/SoapySDR/Types.hpp:174:15: error: ‘enable_if’ in namespace ‘std’ does not name a template type<br /> typename std::enable_if<std::is_same<Type, bool>::value, Type>::type StringToSe<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp:174:24: error: expected unqualified-id before ‘<’ token<br /> typename std::enable_if<std::is_same<Type, bool>::value, Type>::type StringToSe<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp:189:15: error: ‘enable_if’ in namespace ‘std’ does not name a template type<br /> typename std::enable_if<not std::is_same<Type, bool>::value and std::is_integra<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp:189:24: error: expected unqualified-id before ‘<’ token<br /> typename std::enable_if<not std::is_same<Type, bool>::value and std::is_integra<br /> ^<br />In file included from /home/bobby/gr-osmosdr/lib/soapy/soapy_common.h:25:0,<br /> from /home/bobby/gr-osmosdr/lib/soapy/soapy_common.cc:21:<br />/usr/local/include/SoapySDR/Types.hpp:195:15: error: ‘enable_if’ in namespace ‘std’ does not name a template type<br /> typename std::enable_if<not std::is_same<Type, bool>::value and std::is_integra<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp:195:24: error: expected unqualified-id before ‘<’ token<br /> typename std::enable_if<not std::is_same<Type, bool>::value and std::is_integra<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp:201:15: error: ‘enable_if’ in namespace ‘std’ does not name a template type<br /> typename std::enable_if<std::is_floating_point<Type>::value, Type>::type String<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp:201:24: error: expected unqualified-id before ‘<’ token<br /> typename std::enable_if<std::is_floating_point<Type>::value, Type>::type String<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp:207:15: error: ‘enable_if’ in namespace ‘std’ does not name a template type<br /> typename std::enable_if<std::is_same<typename std::decay<Type>::type, std::stri<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp:207:24: error: expected unqualified-id before ‘<’ token<br /> typename std::enable_if<std::is_same<typename std::decay<Type>::type, std::stri<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp: In function ‘std::__cxx11::string SoapySDR::Detail::SettingToString(const Type&)’:<br />/usr/local/include/SoapySDR/Types.hpp:230:12: error: ‘to_string’ is not a member of ‘std’<br /> return std::to_string(s);<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp: In function ‘Type SoapySDR::StringToSetting(const string&)’:<br />/usr/local/include/SoapySDR/Types.hpp:238:12: error: ‘StringToSetting’ is not a member of ‘SoapySDR::Detail’<br /> return SoapySDR::Detail::StringToSetting<Type>(s);<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp:238:12: note: suggested alternative:<br />/usr/local/include/SoapySDR/Types.hpp:236:6: note: ‘SoapySDR::StringToSetting’<br /> Type SoapySDR::StringToSetting(const std::string &s)<br /> ^<br />/usr/local/include/SoapySDR/Types.hpp:238:50: error: expected primary-expression before ‘>’ token<br /> return SoapySDR::Detail::StringToSetting<Type>(s);<br /> ^<br />lib/CMakeFiles/gnuradio-osmosdr.dir/build.make:350: recipe for target 'lib/CMakeFiles/gnuradio-osmosdr.dir/soapy/soapy_common.cc.o' failed<br />make<sup><a href="#fn2">2</a></sup>: <b>* [lib/CMakeFiles/gnuradio-osmosdr.dir/soapy/soapy_common.cc.o] Error 1<br />CMakeFiles/Makefile2:135: recipe for target 'lib/CMakeFiles/gnuradio-osmosdr.dir/all' failed<br />make<sup><a href="#fn1">1</a></sup>: <strong></b> [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2<br />Makefile:138: recipe for target 'all' failed<br />make: *</strong>* [all] Error 2</p>
<p>Can this be fixed?</p>
<p>Bobby Burgess</p> gr-osmosdr - Bug #3855 (New): Cannot build gr-osmosdr with Gnuradio 3.8https://osmocom.org/issues/38552019-03-22T17:53:51Zmartymac
<p>Hi,</p>
<p>Gnuradio has updated their CMake build files for the upcoming version 3.8 :</p>
<p><a class="external" href="https://github.com/gnuradio/gnuradio/commit/ab2fb35677e38a384df3f9503d1f45f64bbc0374">https://github.com/gnuradio/gnuradio/commit/ab2fb35677e38a384df3f9503d1f45f64bbc0374</a></p>
<p>Unfortunately, gr-osmosdr does not build anymore with those changes. Can you update build files to fix build against Gnuradio 3.8 ?</p>
<p>An example seems to be provided in the following commit :</p>
<p><a class="external" href="https://github.com/gnuradio/gnuradio/commit/c04188d7f4e7c7673e6ecc839a6455a6f6b20453">https://github.com/gnuradio/gnuradio/commit/c04188d7f4e7c7673e6ecc839a6455a6f6b20453</a></p>
<p>Thanks,</p>
<p>Ganael.</p> gr-osmosdr - Feature #3802 (New): New releasehttps://osmocom.org/issues/38022019-02-14T15:50:35ZFFY00
<p>Hello,</p>
<p>Is it possible to make a new release as the current one doesn't compile with the latest bladerf?</p>
<p>Thanks,<br />Filipe</p> gr-osmosdr - Feature #3597 (New): rtl: send final samples when device is losthttps://osmocom.org/issues/35972018-09-25T16:23:26Zxloem0xloem@gmail.com
<p>Current behavior of rtl source is to immediately stop work function when device is lost.</p>
<p>It would be nice to include the final samples received prior to the failure.</p>
<p>Patch at <a class="external" href="http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001834.html">http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001834.html</a></p> gr-osmosdr - Bug #3593 (New): rtl: 'len' argument ignored in librtlsdr callbackhttps://osmocom.org/issues/35932018-09-25T15:57:09Zxloem0xloem@gmail.com
<p>The libusb documentation specifies that the callback may be provided a length shorter than the buffersize, but the gr-osmosdr implementation ignores the length and assumes it is the buffersize.</p>
<p>Patch at <a class="external" href="http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001833.html">http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001833.html</a> to store and use these lengths.</p> gr-osmosdr - Bug #3592 (New): rtl: Race Conditionshttps://osmocom.org/issues/35922018-09-25T15:51:45Zxloem0xloem@gmail.com
<p>There appear to be a handful of race conditions in the rtl library.</p>
<p>1. _running is set false without a lock right before _buf_cond is notified; see <a class="external" href="http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n326">http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n326</a> <br /> _buf_cond is never notified again, so on this line <a class="external" href="http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n343">http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n343</a><br /> there could be an infinite hang. _running is checked inside a lock, and then _buf_cond waited on. If _running is set false in between those statements, the wait will never return.</p>
<p>I've attempted to fix this in <a class="external" href="http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001835.html">http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001835.html</a> . The patch also locks around _buf_used, which is recommended in the face of unknown compiler optimizations and target platforms by <a class="external" href="https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf">https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf</a> .</p>
<p>2. There is no lock shared between the write to the sample buffer at <a class="external" href="http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n304">http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n304</a> and the read from it at <a class="external" href="http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n352">http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n352</a> . When the overflow condition is hit, the buffer pointers will wrap, and corrupt data will be produced.</p>
<p>My approach to fixing this was to change how overflows are handled entirely in <a class="external" href="http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001832.html">http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001832.html</a></p> gr-osmosdr - Support #3512 (New): Bug #3462 on Arch Linux; gr-osmosdr install failshttps://osmocom.org/issues/35122018-08-31T14:58:01Z0pcom
<p>My application uses an SDRplay reciever, the errors in the build seem to be related to support for hardware I don't even have.</p>
<p>A suggestion of a workaround would be appreciated</p>
<p>The version listed in the AUR repositories is:<br />gr-osmosdr-nonfree-git-0.1.4.91</p>
<p>Fails the same way as with the instructions on github:</p>
<p>[user@host build]$ make<br />Scanning dependencies of target gnuradio-osmosdr<br />[ 1%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o<br />In file included from /home/user/gr-osmosdr/lib/bladerf/bladerf_source_c.h:26,<br /> from /home/user/gr-osmosdr/lib/source_impl.cc:72:<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:57:18: error: ‘bladerf_channel’ was not declared in this scope<br /> typedef std::map<bladerf_channel, bool> bladerf_channel_enable_map;<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:57:18: note: suggested alternative: ‘bladerf_image’<br /> typedef std::map<bladerf_channel, bool> bladerf_channel_enable_map;<br /> ^<sub>~~</sub>~~~~~~~~~~<br /> bladerf_image<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:57:39: error: template argument 1 is invalid<br /> typedef std::map<bladerf_channel, bool> bladerf_channel_enable_map;<br /> ^<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:57:39: error: template argument 3 is invalid<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:57:39: error: template argument 4 is invalid<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:60:18: error: ‘bladerf_channel’ was not declared in this scope<br /> typedef std::map<bladerf_channel, int> bladerf_channel_map;<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:60:18: note: suggested alternative: ‘bladerf_image’<br /> typedef std::map<bladerf_channel, int> bladerf_channel_map;<br /> ^<sub>~~</sub>~~~~~~~~~~<br /> bladerf_image<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:60:38: error: template argument 1 is invalid<br /> typedef std::map<bladerf_channel, int> bladerf_channel_map;<br /> ^<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:60:38: error: template argument 3 is invalid<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:60:38: error: template argument 4 is invalid<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:99:20: error: ‘bladerf_channel_layout’ was not declared in this scope<br /> size_t num_streams(bladerf_channel_layout layout);<br /> ^<sub>~~</sub>~~~~~~~~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:99:20: note: suggested alternative: ‘bladerf_channel_map’<br /> size_t num_streams(bladerf_channel_layout layout);<br /> ^<sub>~~</sub>~~~~~~~~~~~~~~~~~<br /> bladerf_channel_map<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:154:33: error: ‘bladerf_direction’ has not been declared<br /> void init(dict_t const &dict, bladerf_direction direction);<br /> ^<sub>~~</sub>~~~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:161:27: error: ‘bladerf_direction’ has not been declared<br /> size_t get_max_channels(bladerf_direction direction);<br /> ^<sub>~~</sub>~~~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:163:27: error: ‘bladerf_channel’ has not been declared<br /> void set_channel_enable(bladerf_channel ch, bool enable);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:164:27: error: ‘bladerf_channel’ has not been declared<br /> bool get_channel_enable(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:170:3: error: ‘bladerf_channel’ does not name a type; did you mean ‘bladerf_channel_map’?<br /> bladerf_channel str2channel(std::string const &ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br /> bladerf_channel_map<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:172:27: error: ‘bladerf_channel’ has not been declared<br /> std::string channel2str(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:174:22: error: ‘bladerf_channel’ has not been declared<br /> int channel2rfport(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:177:3: error: ‘bladerf_channel’ does not name a type; did you mean ‘bladerf_channel_map’?<br /> bladerf_channel chan2channel(bladerf_direction direction, size_t chan = 0);<br /> ^<sub>~~</sub>~~~~~~~~~~<br /> bladerf_channel_map<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:180:38: error: ‘bladerf_channel’ has not been declared<br /> osmosdr::meta_range_t sample_rates(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:182:39: error: ‘bladerf_channel’ has not been declared<br /> double set_sample_rate(double rate, bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:184:26: error: ‘bladerf_channel’ has not been declared<br /> double get_sample_rate(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:187:36: error: ‘bladerf_channel’ has not been declared<br /> osmosdr::freq_range_t freq_range(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:189:39: error: ‘bladerf_channel’ has not been declared<br /> double set_center_freq(double freq, bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:191:26: error: ‘bladerf_channel’ has not been declared<br /> double get_center_freq(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:194:43: error: ‘bladerf_channel’ has not been declared<br /> osmosdr::freq_range_t filter_bandwidths(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:196:42: error: ‘bladerf_channel’ has not been declared<br /> double set_bandwidth(double bandwidth, bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:198:24: error: ‘bladerf_channel’ has not been declared<br /> double get_bandwidth(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:201:43: error: ‘bladerf_channel’ has not been declared<br /> std::vector<std::string> get_gain_names(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:203:40: error: ‘bladerf_channel’ has not been declared<br /> osmosdr::gain_range_t get_gain_range(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:206:40: error: ‘bladerf_channel’ has not been declared<br /> bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:209:38: error: ‘bladerf_channel’ has not been declared<br /> bool set_gain_mode(bool automatic, bladerf_channel ch,<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:212:22: error: ‘bladerf_channel’ has not been declared<br /> bool get_gain_mode(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:215:32: error: ‘bladerf_channel’ has not been declared<br /> double set_gain(double gain, bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:217:57: error: ‘bladerf_channel’ has not been declared<br /> double set_gain(double gain, std::string const &name, bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:219:19: error: ‘bladerf_channel’ has not been declared<br /> double get_gain(bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:221:44: error: ‘bladerf_channel’ has not been declared<br /> double get_gain(std::string const &name, bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:224:41: error: ‘bladerf_direction’ has not been declared<br /> std::vector<std::string> get_antennas(bladerf_direction dir);<br /> ^<sub>~~</sub>~~~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:225:20: error: ‘bladerf_direction’ has not been declared<br /> bool set_antenna(bladerf_direction dir, size_t chan, const std::string &antenna);<br /> ^<sub>~~</sub>~~~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:228:57: error: ‘bladerf_channel’ has not been declared<br /> int set_dc_offset(std::complex<double> const &offset, bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:230:59: error: ‘bladerf_channel’ has not been declared<br /> int set_iq_balance(std::complex<double> const &balance, bladerf_channel ch);<br /> ^<sub>~~</sub>~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:285:25: error: ‘bladerf_direction’ has not been declared<br /> bool is_antenna_valid(bladerf_direction dir, const std::string &antenna);<br /> ^<sub>~~</sub>~~~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:210:51: error: ‘BLADERF_GAIN_DEFAULT’ was not declared in this scope<br /> bladerf_gain_mode agc_mode = BLADERF_GAIN_DEFAULT);<br /> ^<sub>~~</sub>~~~~~~~~~~~~~~~<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_common.h:210:51: note: suggested alternative: ‘BLADERF_GAIN_MANUAL’<br /> bladerf_gain_mode agc_mode = BLADERF_GAIN_DEFAULT);<br /> ^<sub>~~</sub>~~~~~~~~~~~~~~~<br /> BLADERF_GAIN_MANUAL<br />In file included from /home/user/gr-osmosdr/lib/source_impl.cc:72:<br />/home/user/gr-osmosdr/lib/bladerf/bladerf_source_c.h:135:3: error: ‘bladerf_channel_layout’ does not name a type; did you mean ‘bladerf_channel_map’?<br /> bladerf_channel_layout _layout; /**< channel layout <strong>/<br /> ^<sub>~~</sub>~~~~~~~~~~~~~~~~~<br /> bladerf_channel_map<br />make<sup><a href="#fn2">2</a></sup>: <b></strong> [lib/CMakeFiles/gnuradio-osmosdr.dir/build.make:63: lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o] Error 1<br />make<sup><a href="#fn1">1</a></sup>: <strong></b> [CMakeFiles/Makefile2:141: lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2<br />make: *</strong>* [Makefile:141: all] Error 2</p> gr-osmosdr - Bug #3462 (New): gr-osmosdr installation bladerf conversion errorshttps://osmocom.org/issues/34622018-08-10T17:51:15Zrytse
<p>Building gr-osmosdr from source fails with several bladerf conversion errors. I am on Ubuntu 16.04 with GNURadio installed through PyBOMBS. Failed `make -j12` output [here](<a class="external" href="https://gist.github.com/rytse/48550fcb29344d461a385aafeeeab8fb">https://gist.github.com/rytse/48550fcb29344d461a385aafeeeab8fb</a>), list of installed packages [here](<a class="external" href="https://gist.github.com/rytse/9624d95413aac4d32deb34b1f8e8352b">https://gist.github.com/rytse/9624d95413aac4d32deb34b1f8e8352b</a>).</p> gr-osmosdr - Feature #3414 (New): Include Airspy serial number in connection string.https://osmocom.org/issues/34142018-07-24T02:59:03Zdreinhold
<p>I was not sure where to post the updated code, so I pushed it to my github<br /><a class="external" href="https://github.com/ScanOC/gr-osmosdr/commit/f2e8386cdf3d8cdbe72b7a0ecc4ed4310a5fbca2">https://github.com/ScanOC/gr-osmosdr/commit/f2e8386cdf3d8cdbe72b7a0ecc4ed4310a5fbca2</a></p> Cellular Network Infrastructure - Feature #3142 (New): Further simplification of "NITB like" setupshttps://osmocom.org/issues/31422018-04-05T20:09:38Zlaforge
<p>Running the post-NITB network is quite a lot more complex than the old code.</p>
<p>There are some ideas on how to make it simpler to run small, self-contained networks while removing some complexity</p>
<ul>
<li>I was also wondering if we should spend time on "MGW-less operation". In theory, you only need OsmoMGW if you have no IP-level routing between your Abis / A / core network [like any decent network operator for security reasons]. But then, if you run everything on one machine, and don't need/want transcoding, and have transparent routing between all components, we could do without the MGW.</li>
</ul>
<ul>
<li>stp-less operation should also be possible (but make configuration actually more complicated), as both the "ASP" (client) and "SG" (server) role are inside libosmo-sigtran, and hence the server could run inside the MSC without the need of an external stp (osmo-stp is just a thin wrapper with vty around libosmo-sigtran)</li>
</ul>
<p>Let's keep this as a reminder and create sub-tasks as ideas materialize more</p> OsmoMSC - Feature #1974 (New): VLR: high water mark on subscriber storagehttps://osmocom.org/issues/19742017-03-08T14:54:50Zneelsnhofmeyr@sysmocom.de
<p>In libvlr, we (will) keep every subscriber in RAM as long as it still has valid auth tuples (3GPP TS 33.102 Annex C.2.3).<br />Most subscribers will still have auth tuples left upon detaching, so we would store <strong>all</strong> subscribers.</p>
<p>Implement a configurable way of limiting the number of subscribers kept in RAM, e.g. a fixed max size.<br />If this is reached, discard those subscribers that have been inactive for the longest time first.</p> OsmoMSC - Feature #1973 (New): VLR: efficient subscriber lookuphttps://osmocom.org/issues/19732017-03-08T14:52:10Zneelsnhofmeyr@sysmocom.de
<p>In libvlr, we (will) keep every subscriber in RAM as long as it still has valid auth tuples (3GPP TS 33.102 Annex C.2.3).<br />Most subscribers will still have auth tuples left upon detaching, so we would store <strong>all</strong> subscribers.<br />Storing numerous subscribers in a linear list is inefficient, implement a hash table for faster access times.</p> OsmoBTS - Feature #1755 (New): osmo-bts-sysmo L1: unify hLayer3 handlinghttps://osmocom.org/issues/17552016-06-16T11:27:40Zneelsnhofmeyr@sysmocom.de
<p>In <a class="external" href="https://gerrit.osmocom.org/264">https://gerrit.osmocom.org/264</a> , some hLayer3 use was added.<br />However, some of the messages were already using hLayer3.</p>
<p>After the patch, the prim_init() sets a hLayer3 which is overwritten<br />shortly after that, so the other functionality is not affected by this patch.</p>
<p>Some functions to generate hLayer3 for a timeslot and similar already existed,<br />and also to retrieve a timeslot and similar back from a hLayer3 handle.</p>
<p>And also, the other hLayer3 functions use a "magic" byte<br />(like the most significant byte always set to 0xbb).</p>
<p>So in fact, we should have rejected this patch, and we should follow up with<br />a merger of my hLayer3 to the existing hLayer3 infrastructure.<br />The priority is low though, since no harm is done.</p>
<p>See:</p>
<ul>
<li>osmo-bts/src/osmo-bts-sysmo/oml.c
<ul>
<li>mph_send_activate_req()</li>
<li>mph_send_config_logchpar()</li>
<li>mph_send_config_ciphering()</li>
<li>mph_send_deactivate_req()</li>
</ul></li>
</ul> OsmoBTS - Feature #1576 (New): consider using hLayer2 as a pointer storagehttps://osmocom.org/issues/15762016-02-23T15:38:30Zlaforge
<p>This would speed up the l1if_hLayer_to_lchan lookup. Not sure if it's worth the extra risk.</p>