summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-07-07trxcon/scheduler: subst_frame_loss(): print current TDMA fnVadim Yanitskiy1-2/+2
Change-Id: I3d769ba3cbadc19bac0b25224460af8f06d0d776
2020-06-19trxcon: use libosmocore's TDMA frame number APIVadim Yanitskiy5-39/+22
Depends: (libosmocore) Ic291fd3644f34964374227a191c7045d79d77e0d Change-Id: I49a043d8483e116cf2d91820edb511846175173f
2020-06-18trxcon/scheduler: cosmetic: clarify lost frame counter descriptionVadim Yanitskiy1-1/+1
Change-Id: Ied5ea8524f2ec6c324e9fd37256111d099c23e6c
2020-06-18trxcon/scheduler: cosmetic: use enumerated type instead of uint8_tVadim Yanitskiy1-1/+1
Change-Id: Idde328d176b4cbd89c62712e4a247095dd596105
2020-06-18firmware/layer1: cosmetic: add missing comma to debug printVadim Yanitskiy1-1/+1
Change-Id: Icfc403e500c24628da722ab378fba31923afd1a1
2020-06-18firmware/apps/rssi: enlarge text buffer in refresh_display()Vadim Yanitskiy1-1/+1
This change fixes several warnings reported by GCC 10.1.0: apps/rssi/main.c:238:30: warning: 'sprintf' may write a terminating nul past the end of the destination apps/rssi/main.c:238:4: note: 'sprintf' output between 10 and 17 bytes into a destination of size 16 apps/rssi/main.c:413:26: warning: '.' directive writing 1 byte into a region of size between 0 and 9 apps/rssi/main.c:413:3: note: 'sprintf' output between 10 and 20 bytes into a destination of size 16 Change-Id: I7980727b78f7622d792d82170f73c90ac5770397
2020-06-14trxcon: use osmo_{store,load}32be() to pack / unpack TDMA fnVadim Yanitskiy1-5/+2
Change-Id: I9eff9b8e4b8ce9e0563a1ec3c485ab8b0f306491
2020-06-10trxcon: fix potential buffer overflow in l1ctl_proc_est_req_h1()Vadim Yanitskiy1-0/+3
Change-Id: I10f03ca66412a4a7094b0f4a7319411d5d5818ef
2020-06-09firmware/layer1: remove redundant l1a_*_req declarationsVadim Yanitskiy1-6/+0
Both symbols are declared in 'layer1/prim.h'. Change-Id: I36f41870bd63c70259316204ee17071853257ca4
2020-06-09firmware: fix compilation with arm-none-eabi-gcc 10.1.0Vadim Yanitskiy2-7/+0
These symbols are defined, but never used: - struct last_rach - seems to be copy-pasted from prim_rach.c, - tall_msgb_ctx - already defined in libosmocore. Change-Id: I6077c8e9b441f7848d1a4c25a8b5e1aed82f4b7d
2020-06-03fake_trx: Support SETPOWER and NOMTXPOWER TRXC cmdsPau Espin Pedrol2-3/+40
By default RSSI on the Rx side is computed based on transmitter's tx power and then substracting the the Rx path loss. If FAKE_RSSI is used, then the values in there are used instead. A default hardcoded value of tx nominal power = 50 dBm is set to keep old behavior of RSSI=-60dB after calculations. Change-Id: I3ee1a32ca22c3272e66b3ca78e4f67d283844c80
2020-05-28trxcon: fix l1ctl_proc_est_req_h0(): convert to host byte orderVadim Yanitskiy1-2/+7
L1CTL is using the network byte order, because this protocol is spoken between different devices and architectures. Somehow I forgot about this while adding SETFH command back in 2018. Change-Id: Ia2f70f0d5e35b6bf05e1fa6fb51a15c1bbe3ca4c Related: OS#4546
2020-05-22trx_toolkit: cosmetic: get rid of 'i' where it is not usedVadim Yanitskiy4-9/+9
Change-Id: I00126a90446e5f3fb77a46be9d7d5dbff89fa221
2020-05-22trx_toolkit/data_dump.py: fix return value of parse_msg()Vadim Yanitskiy2-6/+6
Jenkins build #2516 has uncovered a problem in DATADumpFile.parse_msg(): ====================================================================== FAIL: test_parse_empty (test_data_dump.DATADump_Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "/build/src/target/trx_toolkit/test_data_dump.py", line 138, in test_parse_empty self.assertEqual(msg, False) AssertionError: None != False I did a quick investigation, and figured out that this failure happens when trying to call parse_msg() with idx == 0, because DATADumpFile._seek2msg() basically does nothing in this case and thus always returns True. The None itself comes from DATADumpFile._parse_msg(). Let's ensure that DATADumpFile.parse_msg() always returns None, even if DATADumpFile._seek2msg() fails. Also, update the unit test, so we always test a wide range of 'idx' values. Change-Id: Ifcfa9c5208636a0f9309f5ba8e47d282dc6a03f4
2020-05-17trxcon: refactor trx_if_cmd_setfh(): send Rx/Tx frequenciesVadim Yanitskiy1-20/+36
It would make sense to send the ARFCN list in parameters of SETFH command, if there was a clear distinction between transceivers in fake_trx.py, i.e. which one is an MS and which is a BTS. Right now, every Transceiver is an abstract entity that emits and receives bursts. So when you convert an ARFCN to a pair of Downlink/Uplink frequencies, you don't know whether it maps as Rx/Tx or as Tx/Rx for a given Transceiver. Of course, we could assume that this is an MS specific feature, and a pair of Downlink/Uplink frequencies always corresponds to Rx/Tx, but what if some day we would need to implement and test a similar approach for the BTS side? Also, by sending frequency values in kHz (rather than ARFCNs) we can avoid inconsistency with the existing RXTUNE / TXTUNE commands. Change-Id: Ia2bf08797f1a37b56cf47945694b901f92765b58 Related: I587e4f5da67c7b7f28e010ed46b24622c31a3fdd Related: OS#4546
2020-05-17trxcon: use buffer size macros for TRXC/TRXD messagesVadim Yanitskiy2-4/+7
Change-Id: I6f2b8682c4691ed3da1bf804e302a7169f33e283
2020-05-17trx_toolkit/transceiver.py: add frequency hopping supportVadim Yanitskiy5-18/+140
There are two ways to implement frequency hopping: a) The Transceiver is configured with the hopping parameters, in particular HSN, MAIO, and the list of ARFCNs (channels), so the actual Rx/Tx frequencies are changed by the Transceiver itself depending on the current TDMA frame number. b) The L1 maintains several Transceivers (two or more), so each instance is assigned one dedicated RF carrier frequency, and hence the number of available hopping frequencies is equal to the number of Transceivers. In this case, it's the task of the L1 to commutate bursts between Transceivers (frequencies). Variant a) is commonly known as "synthesizer frequency hopping" whereas b) is known as "baseband frequency hopping". For the MS side, a) is preferred, because a phone usually has only one Transceiver (per RAT). On the other hand, b) is more suitable for the BTS side, because it's relatively easy to implement and there is no technical limitation on the amount of Transceivers. FakeTRX obviously does support b) since multi-TRX feature has been implemented, as well as a) by resolving UL/DL frequencies using a preconfigured (by the L1) set of the hopping parameters. The later can be enabled using the SETFH control command: CMD SETFH <HSN> <MAIO> <RXF1> <TXF1> [... <RXFN> <TXFN>] where <RXFN> and <TXFN> is a pair of Rx/Tx frequencies (in kHz) corresponding to one ARFCN the Mobile Allocation. Note that the channel list is expected to be sorted in ascending order. NOTE: in the current implementation, mode a) applies to the whole Transceiver and all its timeslots, so using in for the BTS side does not make any sense (imagine BCCH hopping together with DCCH). Change-Id: I587e4f5da67c7b7f28e010ed46b24622c31a3fdd
2020-05-17trx_toolkit/gsm_shared.py: implement hopping sequence generationVadim Yanitskiy1-2/+73
Based on firmware/layer1/rfch.c:rfch_hop_seq_gen() by Sylvain Munaut. Change-Id: I9ecabfef6f5a4e4180956c6a019c386ccb1c9acd
2020-05-16trx_toolkit/rand_burst_gen.py: use list comprehensionVadim Yanitskiy1-10/+5
See previous commit, TL;DR this approach is significantly faster. Change-Id: I5dc0dda89443d2763bfae50cc402724935cc91b3
2020-05-16trx_toolkit/data_msg.py: use list comprehension for bit conversionVadim Yanitskiy1-37/+6
This approach is much better than buf.append() in terms of performance. Consider the following bit conversion benchmark code: usbits = [random.randint(0, 254) for i in range(GSM_BURST_LEN)] ubits = [int(b > 128) for b in usbits] for i in range(100000): sbits = DATAMSG.usbit2sbit(usbits) assert(DATAMSG.sbit2usbit(sbits) == usbits) sbits = DATAMSG.ubit2sbit(ubits) assert(DATAMSG.sbit2ubit(sbits) == ubits) === Before this patch: 59603795 function calls (59603761 primitive calls) in 11.357 seconds Ordered by: internal time ncalls tottime percall cumtime percall filename:lineno(function) 59200093 3.389 0.000 3.389 0.000 {method 'append' of 'list' objects} 100000 2.212 0.000 3.062 0.000 data_msg.py:191(usbit2sbit) 100000 1.920 0.000 2.762 0.000 data_msg.py:214(sbit2ubit) 100000 1.835 0.000 2.677 0.000 data_msg.py:204(sbit2usbit) 100000 1.760 0.000 2.613 0.000 data_msg.py:224(ubit2sbit) === After this patch: 803794 function calls (803760 primitive calls) in 3.547 seconds Ordered by: internal time ncalls tottime percall cumtime percall filename:lineno(function) 100000 1.284 0.000 1.284 0.000 data_msg.py:203(<listcomp>) 100000 0.864 0.000 0.864 0.000 data_msg.py:193(<listcomp>) 100000 0.523 0.000 0.523 0.000 data_msg.py:198(<listcomp>) 100000 0.500 0.000 0.500 0.000 data_msg.py:208(<listcomp>) 1 0.237 0.237 3.547 3.547 data_msg.py:25(<module>) 100000 0.035 0.000 0.899 0.000 data_msg.py:191(usbit2sbit) 100000 0.035 0.000 0.558 0.000 data_msg.py:196(sbit2usbit) 100000 0.033 0.000 0.533 0.000 data_msg.py:206(ubit2sbit) 100000 0.033 0.000 1.317 0.000 data_msg.py:201(sbit2ubit) So the new implementation is ~70% faster in this case, and takes significantly less function calls according to cProfile [1]. [1] https://docs.python.org/3.8/library/profile.html Change-Id: I01c07160064c8107e5db7d913ac6dec6fc419945
2020-05-15virt_phy: tweak log levelsHarald Welte4-11/+11
Related: SYS#4822 Change-Id: Ia7e368cda8e016a4141b21e5219697420a503124
2020-05-05mobile: loopback: support EFROliver Smith1-4/+23
Related: SYS#4924 Change-Id: I73d1f88b0865ad97b85418ff76739febf2e128a7
2020-05-05mobile: traffic req check: support EFROliver Smith2-11/+47
L1CTL handling code should not be involved in such high level checks, so while at it, move the check into a separate function in gsm48_rr.c and add a length check. gsm48_rr_tx_voice() is the only caller of l1ctl_tx_traffic_req(). Related: SYS#4924 Change-Id: Iba84f5d60ff5b1a2db8fb6af5131e185965df7c9
2020-05-05mobile: implement 'loopback' TCH frame I/O handlerNeels Hofmeyr1-7/+22
Use newly added audio / loopback config vty node to provide audio loopback from mobile app. Only FR is supported for now. Change-Id: Icd0b8d00c855db1a6ff5e35e10c8ff67b7ad5c83
2020-05-05mobile: add audio config, with unused audio loopback settingNeels Hofmeyr6-0/+90
The aim is to add configurable audio loopback to mobile. An existing patch on a branch from fixeria [1] adds the audio config section. Add a reduced version of this audio config to be compatible with the future merge. Add the audio loopback setting, so far without functionality. Subsequent patch adds the actual loopback. [1] osmocom-bb branch fixeria/audio, patch "mobile/vty_interface.c: add new 'audio' section" Change-id I62cd5ef22ca2290fcafe65c78537ddbcb39fb8c6 Change-Id: Ie03e4a6c6f81ea3925266dd22e87506d722a6e1a
2020-04-25firmware/rfch.[ch]: Document functions + constify input argumentsHarald Welte2-5/+16
Change-Id: I16d5190b3cdc997c5609b52d41203f10264b017c
2020-04-09trxcon/logging: print category, level and extended timestampVadim Yanitskiy1-2/+8
Since we're heavily using trxcon in ttcn3-bts-test, the logging output should contain as much information as possible. Ideally we should introduce the VTY interface (see OS#3666) and get logging configuration options as a bonus. But let's just use some beneficial hard-coded defaults for now: - print category and level (huh, we use NOTICE everywhere?), - do not print category-hex (who needs it anyway?), - print extended timestamp, so we're in synce with other logs. P.S. This configuration is based on my own debugging experience. Change-Id: Ie3d259f3255d8af80e6780f850b808fa243f97b4
2020-04-09trx_toolkit/app_common: add options to enable time printingVadim Yanitskiy1-5/+24
Change-Id: Ie5d14a261e17af554f7132b03d58549a4831dcdb
2020-04-09trx_toolkit/app_common: introduce auxiliary add_log_handler()Vadim Yanitskiy1-8/+14
Change-Id: Ied32764cf1c34dc7e0f746f4f085ea20168775cb
2020-04-01firmware/layer1: introduce experimental PDCH supportVadim Yanitskiy5-1/+71
This change implements basic (receive only) support of the PDCH channels that are used in GPRS. Several coding schemes are defined by 3GPP TS 45.003, however we can only do CS-1 for now, since it's basically an equivalent of xCCH. In order to support the other schemes (CS2-4), we would need to know how to configure the DSP (look at Freecalypso code?). Change-Id: I44531bbe8743c188cc5d4a6ca2a63000e41d6189
2020-03-30trx_toolkit/trx_sniff.py: add options to filter bursts by RSSIVadim Yanitskiy1-0/+14
Change-Id: I16dd29d2f1e14e634029195599fa49a9be9219ab
2020-03-30trx_toolkit/trx_sniff.py: add option to ignore NOPE / IDLE indicationsVadim Yanitskiy1-0/+9
Change-Id: If51052af04289f10bfaefd5374049908de05319a
2020-03-30trx_toolkit/trx_sniff.py: pass the whole msg to burst_pass_filter()Vadim Yanitskiy1-12/+13
Change-Id: I3da62249a4d62078b79ce5e79c86923e59c1e457
2020-03-17layer23/l1ctl: fix: do not pass PDCH and CBCH frames to LAPDmVadim Yanitskiy1-0/+10
GPRS (PDCH) and CBCH related frames have nothing to do with LAPDm. The former uses LLC for the user-plane data, while CBCH involves its own segmentation described in 3GPP TS 23.041 and TS 44.012. There is currently no code for handling these kinds of frames, so let's just send them to GSMTAP and release the memory (msgb). Change-Id: I59b4acbe22217f8989f73b79b128a43e8bcdfa2f Related: OS#4439
2020-03-16trxcon/scheduler: print TDMA statistics on lchan deactivationVadim Yanitskiy1-0/+10
Change-Id: If8688ca331a7b1f841aa21f7a5ebc9750327b90a
2020-03-16trxcon/scheduler: be safe against a theoretical integer overflowVadim Yanitskiy1-1/+10
As was noted by Pau Espin Pedrol, there is a theoretical chance that lchan->tdma.num_proc would overflow, so as a consequence, subst_frame_loss() will be unable to compensate one (potentionally lost) Downlink burst. On practice, given the size of unsigned long and duration of a single TDMA frame, it would only happen once in roughly ~6 years. FRAME_DURATION = 4615 * 10e-6 ULONG_MAX = 2 ** 32 - 1 FRAME_DURATION * ULONG_MAX -> ~198212740 seconds -> ~55059 hours -> ~2294 days -> ~6 years. Chances are that trxcon would crash much earlier, or even GSM would be completely forgotten after such a long time run, but let's work this around and simply start counting from 1 if that overflow eventually happens. Change-Id: I3d40ef09b06039a85df52af06ab38de314e1a434
2020-03-16trxcon/scheduler: do not abort on incomplete set of burstsVadim Yanitskiy2-4/+2
Change-Id: Iea2d1b75b50c2889d4766687ef4fe6ae4ea39a50
2020-03-16trxcon/scheduler: TCH/F: fix Downlink burst completeness checkVadim Yanitskiy1-1/+1
A TCH/F or FACCH/F frame is interleaved over 8 bursts, not 4. Change-Id: I2ee4a216a18e9b077b27887235d982481991d9c4
2020-03-16trxcon/scheduler: align Downlink reception to the first burstVadim Yanitskiy3-9/+18
It may happen that the burst reception would start from bid != 0: <0005> sched_trx.c:263 (Re)configure TDMA timeslot #2 as TCH/H+SACCH <0005> sched_trx.c:420 Activating lchan=TCH/H(0) on ts=2 <0005> sched_trx.c:420 Activating lchan=SACCH/TH(0) on ts=2 <0006> sched_lchan_xcch.c:96 Received incomplete data frame at fn=0 (0/104) for SACCH/TH(0) <0006> sched_lchan_xcch.c:106 Received bad data frame at fn=0 (0/104) for SACCH/TH(0) so in that case, both measurement processing and the frame number calculation would yield incorrect and/or incomplete results. The Rx burst mask can be used to eliminate this problem. In particular, if we shift it left instead of cleaning, it would never be equal 0x00 after at least one burst is received. This would allow us to skip decoding of an incomplete frame at the beginning when the logical channel was just activated. Note that TCH/H handler is not affected because it already uses the strategy described above, so we keep it unchanged. Change-Id: Ib8ddf2edd5ef84f2ab12155f7a8874c9fc56d436 Related: OS#3554
2020-03-16trxcon/scheduler: constify Downlink burst bits where possibleVadim Yanitskiy8-13/+12
Change-Id: Ib3e3a0a5b4551126b1a9439000d4438c58a6a90a
2020-03-16trxcon/scheduler: substitute lost TDMA frames on DownlinkVadim Yanitskiy2-55/+100
It may happen that one or more Downlink bursts are lost on their way to the MS due to a variety of reasons. Modern transceivers supporting TRXDv1 protocol would substitute lost bursts with so-called NOPE indications. Hovewer, neither fake_trx.py nor grgsm_trx do support this feature at the moment. We can still detect and compensate TDMA frame loss per logical channels in the same way as it's already done in osmo-bts-trx. In short, we should keep TDMA frame number of the last received burst in the logical channel state, and using the appropriate multiframe layout, check if there were any gaps between TDMA frame number of the current burst and the stored one. Change-Id: I3551d79796a3730565c2c70577e9d134e636f275
2020-03-16trxcon/scheduler: refactor TDMA frame number calculationVadim Yanitskiy8-46/+33
Using TDMA frame number of a burst with bid=0 is fine for xCCH, but not for TCH and FACCH, because they use the block-diagonel interleaving. A single block on TCH may be interleaved over 8, 4 or even 6 consecutive bursts depending on its type. Since we now have the measurement history, we can attach TDMA frame number to each measurement set, and then look up N-th one when averaging the measurements in sched_trx_meas_avg(). Change-Id: I9221957297a6154edc1767a0e3753f5ee383173f
2020-03-10virtphy: Delay response between L1SAP_PM_REQ and L1SAP_PM_CONFHarald Welte2-9/+28
Change-Id: I443b5512c4966c232107aeb73e1fd8b83335d63d
2020-03-10virtphy: Add command line arguments to set multicast netdev + TTLHarald Welte1-3/+15
This allows us to bind the multicast sockets to a given network device and/or to set the TTL of the multicast frames and hence control their reach in terms of number of network hops. Change-Id: Ia74aa381a4c1921cb8c7e263842a864ea8028139 Related: OS#2966
2020-03-10virtphy: Sync virtual_um.[ch] with osmo-btsHarald Welte3-26/+54
The files are used in both projects, and while the osmo-bts code has evolved, this copy didn't. Let's sync again (to libosmocore change-Id I303f2e616d2d32b5a8005c3dcf0f5fad19ad3445). Change-Id: I189ee28a85a6d7a7a07b062f6b07012478503e8f Depends: libosmocore.git Ib52d22710020b56965aefcef09bde8247ace4a9c Related: OS#2966
2020-03-09virtphy: Fix GSMTAP ARFCN use with multi-TRX BTSHarald Welte5-14/+35
In case we get assignments to secondary TRXs, the ARFCN of that TRX must be used, and not the serving cell BCCH ARFCN. Change-Id: Ief6cf5816969d819ff9506be70bec9b8d0d9d9be
2020-03-09virt_phy: implement GSMTAP_CHANNEL_VOICEHarald Welte3-14/+63
GSMTAP_CHANNEL_VOICE is the mechanism by which GSMTAP can [finally!] be used to transport circuit-switched voice codec payload, and not just signalling. Original patch by Neels Hofmeyr, heavily extended by Harald Welte. Change-Id: Id72cf23b7c6587efae4cdaa7b50ab4d85b8c8d22
2020-03-08trxcon/scheduler: fix n_errors for BFI triggered by FACCHVadim Yanitskiy2-2/+6
These BFI (Bad Frame Indications) substitute speech frames stolen by FACCH/F or FACCH/H frames, so there can be no bit errors in something that was not even transmitted over the air interface. Change-Id: Icdb6209f75ead6581e3c18aeee0da9831aaa272a
2020-03-08trxcon/scheduler: FACCH: ensure fake measurements for BFIVadim Yanitskiy2-2/+4
According to 3GPP TS 45.003, clauses 4.2.5 and 4.3.5: - one FACCH/F frame steals a single speech frame, - one FACCH/H frame steals two speech frames. A BFI (Bad Frame Indication) needs to be sent for each stolen speech frame. This does not apply to CSD (data) channels though. The BFI frames must have measurement data attached to them, and due to their virtual nature (they do not actually come from the air interface), the measurements must be crafted by trxcon. Assigning a negative value to n_errors makes the code below the 'bfi' label craft fake measurement data. Otherwise, the actual measurements belonging to the FACCH frame will be used. Change-Id: Ia2f7c3cf7b1ef3737da6b1818cae2f001ee8768f
2020-03-08trxcon/scheduler: refactor Downlink measurement processingVadim Yanitskiy10-74/+140
So far we used to store the sums of ToA and RSSI measurements in the logical channel state, and after decoding of a block, we did calculate the average. This approach works fine for xCCH and PDTCH, but when it comes to block-diagonal interleaving (which is used on TCH/F and TCH/H channels), the results are incorrect. The problem is that a burst on TCH may carry 57 bits of one encoded frame and 57 bits of another. Instead of calculating the sum of measurements on the fly, let's push them into a circular buffer (the measurement history), and keep them there even after decoding of a block. This would allow us to calculate the average of N last measurements depending on the interleaving type. A single circular buffer can hold up to 8 unique measurements, so the recent measurements would basically override the oldest ones. Change-Id: I211ee3314f0a284112a4deddc0e93028f4a27cef