grmgs_capture tried to do too many things for a simple recorder.
It was simplified by removing the receiver and ability to
save data to bursts files.
All other stuff that is not necessary for recording signal to disk was
also removed:
-setters/getters,
-storing of parameters that never will be changed.
The 'fc' parameter name was changed to 'freq' to follow GNU Radio
guidelines.
The 'shiftoff' parameter was removed.
'bb_gain' and 'if_gain' parameters were added.
Variables specific to some of SDR's like:
-gains at different stages,
-bandwidth (not all devices can set it),
-antennas (some devices have just one, some not),
were moved to separate options group.
What is left to be exposed is:
-dc_offset_mode,
-iq_balance_mode,
-gain_mode.
Change-Id: I092a43eaddb09a99c6cc05fde13f0ae94d9e0251
In the GSM input adaptor and GSM Receiver blocks the osr was hardcoded
to 4 and cannot be changed using the command line parameter.
Change-Id: I4e85b898f05db636f18fdea6e5fee4fed6e0382a
- Include grgsm/endian.h in tch_h_decoder_impl.cc
- Revert 0ed39fbf93 as linking with
boost_thread is needed
Fixes GH-444
Change-Id: I00884962295082cff3eb64fa21e9f73437be0001
The old name was quite long, resulting into cumbersome imports:
from change_sign_of_dict_elements import change_sign_of_dict_elements
let's use a shorter variant:
from dict_toggle_sign import dict_toggle_sign
Change-Id: Ie75e1d6e5e74c7c1cf34154633c1472e4b85dbb6
This change is done to make keeping track of sample counter
at the input of the resampler easier from blocks connected
to its output. Each tag leaving the resampler has accompanying
"original_offset" tag with its offset before sample rate change.
Change-Id: Iea8ca4a092029f774406dced8a97a17810f21f62
When tag appears at the last sample of the ouput buffer
it will be added again in the next run of the work function.
Here this issue was solved by changing the codition so the
tag appearing at the end of the output buffer is not added.
Change-Id: Ia4f0923e2071184879a023d0fe01026d8e9ccbda
This is the output format of rtl_sdr and hackrf_transfer and this would
allow direct channelization without an additional post processing.
Change-Id: Ia489eca9ec7defc3a83946c42f1ae3f136efe4e8
Checking if freq_offset is None doesn't make sense currently
as it's always set to a float value by argparse (to 0 by default).
Change-Id: Ie8bae1ccde60d07fc25e0b874afa5aaaac04d8a7
- Read bursts with pmt::deserialize directly from the std::filebuf
- Remove the unused unserialized variable
- Add tests
Since df978693 when the rx_time tags are present in the incomming stream
the gsm receiver adds fm_time to the burst's PMT and the bursts that
burst file sink writes becomes longer because of the additional field.
The burst file source block was expecting all burst to be 147 bytes long
and reading files with longer bursts was failing with an unhandled exception.
terminate called after throwing an instance of 'pmt::exception'
thread[thread-per-block[5]: <block dummy_burst_filter (2)>]: pmt_cdr: wrong_type : #f
what(): pmt::deserialize: malformed input stream, tag value = : 115
Change-Id: I989b0d6a6b214088b7880e5cbf7bb6725492dbfc
This fixes the garbled output when multiple printers are used in a
flowgraph.
closes #255
closes #420
Change-Id: I1012ed26371b4c67163545652f0a1ce0f576af9e
When set the stdout and stderr won't be redirected to /dev/null which
will facilitate resolving issues
Change-Id: I11e99facb5a1ab9c9bfee3c314a91a74f98a2523
Argparse makes adding new parameters easier and
adds consistent way of handling default values of
parameters and printing of their help info.
Change-Id: Idf99fd7a581464aa2f77fe01e721dbd162686811
An ability to shift the baseband frequency would allow one to
run both base stations and (OsmocomBB-based) mobile stations on
any frequency (e.g. in 2.4 GHz WiFi band)!
This is achieved by adding a given frequency offset to the
result of "ARFCN -> RX/TX frequency" calculation.
Usage example:
grgsm_trx --freq-offset -500M
Both RX (Downlink) and TX (Uplink) frequencies will be shifted
by 500 MHz back, e.g. tuning request to ARFCN 105 would result
in tuning the radio to 456.0 MHz (instead of 956.0 MHz).
Related: OS#3520 (https://osmocom.org/versions/136)
Change-Id: I42e397e47402a87f4141ef31b25eff4c8c1267e2
Piotr Krysik