Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-20T21:47:23ZOpen Source Mobile Communications
Redmine E1/T1 Hardware Interface (including icE1usb) - Support #6412 (New): No alignmenthttps://osmocom.org/issues/64122024-03-20T21:47:23Zpfassberg
<p>I'm testing icE1usb to connect a ISDN PBX to a switch partly over SDH.<br /><pre>
SS7/ISDN Switch - (STM-1) - ADM - (E1) - icE1usb - (IP) - icE1usb - (E1) - PABX
</pre></p>
<p>In the PABX side I have no problems, but between the ADM and the icE1usb I have problem to get the icE1usb aligned.</p>
<p>If I use a loopback cable I can get the ADM and the icE1usb aligned. But when I connect them only the ADM get aligned, never the icE1usb. The icE1usb don't act at all. The green LED keeps flashing and nothing in the logs or stat.</p>
<p>If I connect a Cisco modem pool to the same ADM port it immediately get aligned. I have MGWs and other stuff connected to the same ADM with no problems.</p>
<p>I've measured the voltage and find roughly 4 V Vp-p from icE1usb and 5 V Vp-p from the ADM.</p>
<p>I do not use CRC4 but I can't find any CRC4 settings in osmo-e1d config.</p>
<p>Any clues about what is going on and how to debug this?</p>
<p>// Peter</p> SIMtrace 2 - Bug #6181 (Feedback): Unexpected INS code with simtrace2-sniff: 0x7fhttps://osmocom.org/issues/61812023-09-15T15:44:53Zv.marinos
<p>Hello,</p>
<p>I used `simtrace2-sniff` to sniff the messages between my sysmocom SIM cards and a Google Pixel 5, during 5G SA registration. I captured the traffic with tcpdump over port 4729 (pcap file attached).</p>
<p>I am using Open5GS and srsRAN (5G) for the core and RAN respectively. The phone connects to the core successfully and has internet access.</p>
<p>When I replay the captured messages with pySim-trace I get the following error: "ValueError: Unknown CLA=A4 INS=7F". Wireshark also shows the same INS code, as Unknown (0x7f).</p>
<p>I looked at ETSI TS 102 221 V17.1.0 (2022-02), Table 10.5, and couldn't find any reference of APDU with INS code 0x7f.</p>
<p>Do you have any insights on why this APDU is showing up?</p>
<p>Thanks,<br />Marinos</p> OCTOI - Osmocom Community TDM over IP - Bug #5883 (New): GPS sync sometimes goes to hold overhttps://osmocom.org/issues/58832023-01-30T00:06:12Ztnt
<p>Last occurrences :</p>
<p>Sun Nov 27th 01:00<br />Thu Dec 6th 21:46 <br />Sun Dec 18th 01:00 <br />Wed Dec 28th 13:36<br />Sun Jan 29th 01:00</p>
<p>So at least 3 of them happened on Sundays, at 1 am local time (so 00:00 UTC), which also seems to correspond to the moment the GPS resets its 'ppr` messages counter to 0 ...</p> E1/T1 Hardware Interface (including icE1usb) - Feature #5710 (New): rs422: Merge as much of the g...https://osmocom.org/issues/57102022-10-13T18:53:21Ztnt
<p>Currently the gateware for the RS422 mode is another branch. It's just too big to have dual channel + hw support for it in the same build.</p>
<p>Either try to make it a build option, or reduce size of the gateware to make it fit.<br />ATM we create a whole different UART but technically we could just use the GPS uart and re-route the IO since the on-board GPS isn't used when rs422 mode is used.</p>
<p>This wouldn't support a possible future GPS 02/03 emulation mode but that's a problem for the future. (Although thinking about it, it could actually since after init we never TX to the onboard GPS and we never RX anything on the rs422 ... so we could have the same uart split: rx from onboard gps and tx to the RBS ... we just need to keep the onboard gps at 9600 or support different tx/rx baudrates)</p> E1/T1 Hardware Interface (including icE1usb) - Feature #5709 (New): rs422: Merge as much of the f...https://osmocom.org/issues/57092022-10-13T18:49:19Ztnt
<p>"Pluggable" GPS implementation should be possible.</p>
<p>The extensions boards have an EEPROM to allow run-time discovery and the firmware code size is not an issue, we have 64k and we're using 20.5k ATM so having the GPS03 code in there isn't going to make much of a difference.</p> E1/T1 Hardware Interface (including icE1usb) - Bug #5708 (New): rs422: Support runtime re-init of...https://osmocom.org/issues/57082022-10-13T18:46:17Ztnt
<p>Currently if the GPS receiver side doesn't have power, init will fail and never recover without a reboot.</p>
<p>This is because without power on that side, we can't talk to the I2C IO expander on the isolated side to initialize it and set up the RS422 transceiver ...</p>
<p>Solution is that if we haven't seen NMEA messages in a few seconds, try to re-init the I2C IO expander (default state on reset/power loss is everything disabled to be safe).</p>
<p>One thing to pay attention to is that I2C is slow. And the current I2C driver code is blocking, so we'd need to check the init sequence isn't too long and doesn't block the main loop processing for too long which would cause USB over/underflows ...</p> E1/T1 Hardware Interface (including icE1usb) - Bug #5490 (Feedback): ISO IN urb sometimes complet...https://osmocom.org/issues/54902022-03-14T08:22:23Zlaforge
<p>This is happening frequently at <a class="user active" href="https://osmocom.org/users/739890">gruetzkopf</a>:<br /><pre>
Assert failed size % 32 == 0 mux_demux.c:419
</pre></p>
<p>This means that a non-modulo-32 length (plus 5 byte header) was received in an ISO IN URB.</p>
<pre>
22:00 <@gruetzkopf> <0001> mux_demux.c:421 (I0:L0) Transfer cut short, size was 251 bytes
23:58 <@gruetzkopf> just so i don't forget: i've also seen 253 and 252 by now
</pre>
<p>So this means that instead of 256 (+4) we've seen 251-253 (+4) byte transfer length.</p>
<p>I've checked the firmware, an I don't see any way how the firmware could do something wrong here: It uses <code>(n * 32) + 4)</code> as length, whic hcan never be one of those odd values.</p>
<p>On the osmo-e1d side, we are always checking for LIBUSB_TRANSFER_COMPLETED state, so both the transfer/urb, as well as the individual packets have LIBUSB_TRANSFER_COMPLETED before passing them higher up to the mux_demux code which is asserting here.</p>
<p>So I guess the underlying question is: Is this a kernel/libusb bug? Is it legal for ISO IN packets to complete with a length less than what was submitted?</p>
<p>If this is legal, then the next question si why it it is happening.</p>
<p>We can of course plaster around the issue and substitute the missing data with 0xff or something, creating various bit errors, rathe than asserting.</p> Retronetworking - Feature #5463 (In Progress): X.21 hardware interfacehttps://osmocom.org/issues/54632022-02-20T13:34:31Zlaforge
<p>It's surprising how "dead" the X.21 interface seems to be. Apart from some super expensive RS232 to X.21 converters, and the odd FarSync card on ebay, it seems it's very hard to get anything that attaches to a modern computer and implements that interface.</p>
<p>After a bit of research, it seems electrically it's not really more than 6 differential RS-422 style signals. 4 in DCE->DTE direction, and 2 in the other. I'm tempted to do a simple board with a 15pin SUB-D connector and 6 half-duplex RS-422 drivers (so the direction can be switched).</p>
<p>The transceivers of course would be 3.3V supply + logic level, so they can be used with any modern uC/FPGA/...</p>
<p>The board should be configurable for both DTE and DCE role, as well as a passive sniffer, switching all channels to receive-only.</p>
<p>Would anyone be interested in that?</p>
<p>The idea is that such an interface could then be attached to a microcontroller (or fpga) implementing the actual protocol related bits.<br />Given that I'm more of a hardware + software and not a FPGA person, I'd probably try to hook it up to an ARM based uC.</p> rtl-sdr - Bug #5220 (New): Undefined reference to libusb_dev_mem_freehttps://osmocom.org/issues/52202021-08-28T22:14:52Zphysnoct
<p>Linker didn't found the libusb-1.0.<br />Libusb-1.0 is installed in /usr/local</p> OsmocomBB - Bug #5171 (Feedback): ccch_scan failedhttps://osmocom.org/issues/51712021-06-04T01:33:01Zthor123
<p><strong>when i excute the command :sudo ./ccch_scan -i 127.0.0.1 -a 50. i got the error msg. below is error msg detail.</strong><br />Assert failed l2_len == GSM_MACBLOCK_LEN app_ccch_scan.c:397 <br />backtrace() returned 20 addresses<br />/usr/local/lib/libosmocore.so.17(osmo_generate_backtrace+0x1e) [0xb7eedd3a]<br />/usr/local/lib/libosmocore.so.17(+0x1eb62) [0xb7eedb62]<br />/usr/local/lib/libosmocore.so.17(osmo_panic+0x48) [0xb7eedbaf]<br />./ccch_scan(+0x3976) [0x4f5976]<br />./ccch_scan(+0x3bf2) [0x4f5bf2]<br />./ccch_scan(+0x3ddb) [0x4f5ddb]<br />/usr/local/lib/libosmogsm.so.16(+0x2dbf1) [0xb7e7bbf1]<br />/usr/local/lib/libosmogsm.so.16(+0x2e03e) [0xb7e7c03e]<br />/usr/local/lib/libosmogsm.so.16(+0x2eed1) [0xb7e7ced1]<br />/usr/local/lib/libosmogsm.so.16(lapdm_phsap_up+0x118) [0xb7e7d143]<br />./ccch_scan(+0x57d4) [0x4f77d4]<br />./ccch_scan(+0x68ba) [0x4f88ba]<br />/usr/local/lib/libosmocore.so.17(osmo_wqueue_bfd_cb+0x36) [0xb7ee2b62]<br />/usr/local/lib/libosmocore.so.17(+0xc4bb) [0xb7edb4bb]<br />/usr/local/lib/libosmocore.so.17(+0xc589) [0xb7edb589]<br />/usr/local/lib/libosmocore.so.17(osmo_select_main+0x1d) [0xb7edb5b0]<br />./ccch_scan(+0x2a22) [0x4f4a22]<br />/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0x106) [0xb7c61e46]<br />./ccch_scan(+0x2bc1) [0x4f4bc1]<br />zsh: abort sudo ./ccch_scan -i 127.0.0.1 -a 50</p> Cellular Network Infrastructure - Bug #5043 (New): CNI overview diagram lacks osmo-cbc and osmo-smlchttps://osmocom.org/issues/50432021-02-23T17:32:46Zlaforge
The overview diagram at <a class="external" href="https://osmocom.org/projects/cellular-infrastructure/wiki">https://osmocom.org/projects/cellular-infrastructure/wiki</a> needs an update:
<ul>
<li>OsmoCBC (cell broadcast centre) needs to be added to CN, with
<ul>
<li>CBSP interface to OsmoBSC, and </li>
<li>SABP to OsmoHNBGW (mark that grey or dashed as it's work in progress)</li>
</ul>
</li>
<li>OsmoSMLC (serving mobile location centre) needs to be added to RAN, with
<ul>
<li>Lb interface to OsmoBSC (no other interfaces)</li>
</ul>
</li>
<li>OsmoMSC should indicate its SGs interface to an external LTE EPC MME like open5gs</li>
</ul> E1/T1 Hardware Interface (including icE1usb) - Feature #4910 (New): Automatically set the A / ala...https://osmocom.org/issues/49102020-12-16T20:20:22Zlaforge
<p>At least according to one of my German retronetworking books on PDH it is stated that an E1 interface must set the A[larm] bit in TS0 if no received signal is detected.</p>
<p>I expect we don't do that yet as we have no real concept of LOS.</p>
<p>Relying on the host software to insert that A bit is not really a good idea, as the host has the least idea of what's happening on the physical layer.</p>
<p>So I would guess, similar to the way how we automatically can generate the E bits in case of Rx CRC errors, it would be good to generate the A bits based on whether or not we see incoming Rx clock cycles.</p> rtl-sdr - Support #4367 (New): "Communications Toolbox Support Package for RTL-SDR Radio" from "M...https://osmocom.org/issues/43672020-01-17T17:18:02ZStarhowl
<p>When trying to install Communications Toolbox Support Package for RTL-SDR Radio from<br /><a class="external" href="https://de.mathworks.com/matlabcentral/fileexchange/44991-communications-toolbox-support-package-for-rtl-sdr-radio">https://de.mathworks.com/matlabcentral/fileexchange/44991-communications-toolbox-support-package-for-rtl-sdr-radio</a><br />, I get a 502-error from the installer on that webpage.</p>
<p>I posted an included link on Freenode, where to bot immediately delivered a 502 for<br /><a class="external" href="http://sdr.osmocom.org/trac/raw-attachment/wiki/rtl-sdr/RelWithDebInfo.zip">http://sdr.osmocom.org/trac/raw-attachment/wiki/rtl-sdr/RelWithDebInfo.zip</a><br />which appears to have moved to<br /><a class="external" href="https://osmocom.org/attachments/download/2242/RelWithDebInfo.zip">https://osmocom.org/attachments/download/2242/RelWithDebInfo.zip</a><br />instead.</p>
<p>Connecting via a German or US IP didn't resolve the issue, a different user on the same channel with the bot also confirmed the 502.</p>
<p>Can you please include the file at its former location to make the installer work again?</p> Miscellaneous Projects - Feature #3847 (New): Osmocom logo with/for black backgroundhttps://osmocom.org/issues/38472019-03-18T08:54:28Zlaforge
<p>It would be great to have a logo that can be rendered nicely on a black/dark background. This enables us to have black mugs/t-shirts but also stickers that don't look that "ugly" on black laptops...</p>
<p>Would be great if you have some ideas about this. If not, feel free to return the ticket to me so I can see if somebody else can help out on this.</p> rtl-sdr - Feature #3315 (New): review and possibly apply patches from debian packagehttps://osmocom.org/issues/33152018-06-03T13:16:31Zlaforge
<p>There's a number of patches in the Debian package whcih might be useful to apply to mainline.</p>
<p>I'm particularly thinking of the following patches:<br /><pre>
hurd-usb
improve-librtlsdr-pc-file
improve-scanning-range-parsing
ipv6-support
use-udev-uaccess-rules
</pre></p>
<p>which can be found at <a class="external" href="https://salsa.debian.org/bottoms/pkg-rtl-sdr/tree/debian/debian/patches">https://salsa.debian.org/bottoms/pkg-rtl-sdr/tree/debian/debian/patches</a></p> OsmoTRX - Bug #3222 (Stalled): include (tested) example config files for usrp1, uhd/b200 as well ...https://osmocom.org/issues/32222018-04-28T14:50:47Zlaforge
<p>Let's make sure we ship example configs for the various SDR hardware, just like we do in other osmocom projects that use vty / config files.</p> osmo-fl2k - Feature #3210 (New): man pageshttps://osmocom.org/issues/32102018-04-24T20:04:48Zalteholz
<p>it would be nice to have man pages for the four binaries available</p> OsmoTRX - Bug #3067 (New): osmo-trx usrp b100 time out and packet loss between host and devicehttps://osmocom.org/issues/30672018-03-15T16:30:22Zyangkkokk
<p>i used new branch master
<p>osmo-trx -C doc/examples/osmo-trx-limesdr.cfg</p>
</p>
<p>Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:84<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 488.323 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 488.418 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:85<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 488.459 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 488.503 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:86<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 488.549 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 488.634 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:87<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 488.716 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:88<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 488.801 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:89<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=3013829712] ClockInterface: sending IND CLOCK 1696638<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 488.847 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 488.925 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:90<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 488.958 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 489.007 sec.<br />Thu Mar 15 16:25:15 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:91<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 489.087 sec.<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:92<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 489.169 sec.<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:93<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 489.198 sec.<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 489.29 sec.<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:94<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=2992628816] Packet loss between host and device at 489.374 sec.<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] new latency: 7:95<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] UHD: Device send timed out<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] Transmit error 0<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] UHD: Device send timed out<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] Transmit error 0<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] UHD: Device send timed out<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] Transmit error 0<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] UHD: Device send timed out<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] Transmit error 0<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] UHD: Device send timed out<br />Thu Mar 15 16:25:16 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] Transmit error 0<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] UHD: Device send timed out<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] Transmit error 0<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] UHD: Device send timed out<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] Transmit error 0<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] UHD: Device send timed out<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] Transmit error 0<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] UHD: Device send timed out<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] Transmit error 0<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] reduced latency: 6:95<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] UHD: Device send timed out<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] Transmit error 0<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] UHD: Device send timed out<br />Thu Mar 15 16:25:17 2018 DMAIN <0000> Logger.cpp:53 [tid=3013862480] Transmit error 0</p> OsmoTRX - Feature #3054 (Stalled): Extended (11-bit) RACH support in OsmoTRXhttps://osmocom.org/issues/30542018-03-10T07:22:35Zlaforge
<p>OsmoTRX is currently only correlating with one of the three RACH sync sequences indicated in TS 05.02 5.2.7. We need to define TS1+TS2 as well as correlated against thosee during RACH detection</p>
<pre>
const BitVector GSM::gRACHSynchSequence("01001011011111111001100110101010001111000");
+const BitVector GSM::gRACHSynchSequenceTS1("01010100111110001000011000101111001001101"); /* EGPRS with 8PSK in uplink */
+const BitVector GSM::gRACHSynchSequenceTS2("11101111001001110101011000001101101110111"); /* EGPRS without 8PSK in uplink */
</pre> OsmocomBB - Feature #2555 (Stalled): script interface to OsmocomBB "mobile"https://osmocom.org/issues/25552017-10-06T14:47:31Zlaforge
<p>The idea here is to have some high-level scripting interface in the OsmocomBB "mobile" program, which can be used to automatically execute certain behavior. This is very useful for automatic testing.</p>
The commands should be very high-level operations, such as
<ul>
<li>perform network search</li>
<li>perform cell (re)selection</li>
<li>perform normal/periodic/attach LU</li>
<li>perform USSD</li>
<li>send MO-SMS</li>
<li>receive MT-SMS</li>
<li>make MO voice call</li>
<li>receive MT voice call</li>
</ul>
<p>In order to make the related scripts easy to write, the script language interface functions should expose blocking semantics. This means the "mobile" stack needs to be run in a thread/process with its usual event-driven osmo_fd architecture, and it needs to exchange primitives with another thread/process that runs the script commands.</p>
<p>As scripting language, I would suggest LUA as it's small to embed. Size does matter, as we likely will want to simultaneously run thousands to tens of thousandsof "mobile" instances on one machine.</p> OsmocomBB - Bug #1990 (Feedback): bb nand flash https://osmocom.org/issues/19902017-03-30T05:31:25Zyangkkokk
<p>I ported Fatfs, but the flash drive is missing annotations<br />Http://git.osmocom.org/osmocom-bb/tree/src/target/firmware/flash/cfi_flash.c</p>
<p> DSTATUS disk_initialize (BYTE);<br /> DSTATUS disk_status (BYTE);<br /> DRESULT disk_read (BYTE, BYTE *, DWORD, BYTE);<br /> DRESULT disk_write (BYTE, const BYTE *, DWORD, BYTE);<br /> DRESULT disk_ioctl (BYTE, BYTE, void *);</p>
<p>So, I hope to do some of the code of the Notes, or into a new structure, after all, many people like the simple and clear secondary development.</p> SIMtrace 2 - Feature #1911 (New): check if we can have an enclosed version of simtrace v2https://osmocom.org/issues/19112017-01-12T12:52:40Zlaforge
<p>It would be nice to have an enclosed device rather than a bare PCB. Let's review that option for v2 hardware.</p> OsmoSMSC - Bug #1690 (New): Insert: Generate message ID (e.g. UUID)https://osmocom.org/issues/16902016-04-06T12:26:34Zzecke
<p>Generate amessage id and use it consistently in debugging. Use a custom id before it even hits the DB. This allows to understand number re-writing being executed even before the message is stored in the database.</p> OsmoSMSC - Feature #1689 (New): insert: Change destination number based on criteria similiar to r...https://osmocom.org/issues/16892016-04-06T12:16:07Zzecke
<ul>
<li>Search destination number in system using REST service?</li>
<li>Re-write</li>
<li>then store to the database</li>
</ul> OsmoSMSC - Feature #1623 (New): Configure delivery report for the SMPP delivery linkshttps://osmocom.org/issues/16232016-02-24T13:49:27Zzecke
<p>In case SMPP is used as a delivery method it is not clear if the delivery is meant to be final and a delivery report should be created or if the final system will generate it. As part of the delivery method configuration one should be able to configure if a delivery report is created or not.</p> OsmoPCU - Feature #1533 (Feedback): Separate the window handling from the TBF more clearlyhttps://osmocom.org/issues/15332016-02-22T21:07:23Zzecke
<p>**The window handling can be more clearly separated from the TBF. This includes clean-ups to the ::assemble_forward_llc. The general multitude of calling dir.dl.window.m_v_b anddir.dl.window.increment_send.</p> UmTRX - Feature #1504 (New): LMS6002 phase error increases when Rx is enabled and varies with tem...https://osmocom.org/issues/15042016-02-19T22:52:47Z
<p>LMS6002 phase error increases when Rx is enabled and varies with temperature.</p>
<p>[Migrated from old Google Code tracker]</p> SDR (Software Defined Radio) - Bug #1474 (New): USB Claim Interface Errorhttps://osmocom.org/issues/14742016-02-19T22:50:52Z
<p>Hello,</p>
<p>I have heard lots of good things about this code. I have currently tried it on Win7HP and <a class="wiki-page new" href="https://osmocom.org/projects/sdr/wiki/WinXPH">WinXPH</a> but in both cases I see the error below.</p>
<p>C:\SpectrumAnalyser>rtl_sdr /tmp/capture.bin -s 1.8e6 -f 392e6<br />Found 1 device(s):<br /> 0: ezcap USB 2.0 DVB-T/DAB/FM dongle</p>
<p>Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle<br />usb_claim_interface error -12<br />Failed to open rtlsdr device #0.</p>
<p>C:\SpectrumAnalyser></p>
<p>----<br />Best regards, John.</p> OsmocomBB - Bug #1458 (New): AGC broken (strong cell cannot be syncedhttps://osmocom.org/issues/14582016-02-19T22:48:42Zlaforge
<p>There seems to be a problem when trying to sync to particularly strong cells, as we overload the input of the ADC.</p>
<p>As we're doing power measurements anyway, we need to use the received power level as input to the SCH and FCCH task and not start those with some default power level</p> Miscellaneous Projects - Bug #64 (New): osmo-bts-amp: 2.2uF capacitors next to PA need to be 0603...https://osmocom.org/issues/642016-02-19T22:47:33Zlaforge
<p>0805 capacitors are typically higher thant the PA module and would thus interfere with mounting it against a heatsink. Thus, we're using 0603 capacitors in 2.2uF, and the footprint can (and should) be shrinked from the current 0805</p>