gmr

gmr@lists.osmocom.org

51 discussions

Malformed Packet Error in your example data

by 101jordanmichael101＠gmail.com

Hi, ---> I opened the tnt-call-deciphered.pcap file that you uploaded with wireshark. ---> Then I opened the osmo-gmr code. I got a wireshark output myself using tnt-call-268-93600.cfile , tnt-call-267-93600.cfile and the password. ---> In the resulting wireshark output, the section with (CC) Setup appears as Malformed Packet. a) What is the cause of the Malformed Packet problem? b) How can I fix this problem?

4 months, 2 weeks

Can I build my own GMR satellite/base station and core network based on open source software (e.g. Osmo-bts) and SDR?

by 1191595017＠qq.com

Dear Osmocom community, I noticed that the OSMOGMR project is mainly about receiving and decoding downlink GMR data. Can I build my own GMR satellite/base station and core network based on open-source software (e.g. osmo-bts) and SDR? GMR is mentioned in the Osmo-bts user manual, but it doesn't say if it is implemented and how to configure it. If Osmo-bts doesn't work, is there any other project to build my own GMR base station and establish a connection with a GMR device? Best regards, Wei

1 year

Osmocom discourse as alternative to mailing lists

by Harald Welte

Dear Osmocom community, while many people with a long history in FOSS development have no issues at all with mailing lists as primary form of engaging with their community, they have undoubtedly fallen out of fashion in favor of various chat/messaging systems or web based forums. In Osmocom, we've just launched an installation of the discourse forum software available at https://discourse.osmocom.org/ providing an alternative to our traditional mailing lists at https://lists.osmocom.org/ We're looking forward to see whether this web-based approach will facilitate more and/or other people to engage with the Osmocom developer/contributor community. Feel free to join and get the discussions started. If there's a need for more categories or sub-categories, just let one of the moderators know and we can help with that. The old mailing lists will continue to remain available for those who prefer them. -- - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 year, 1 month

RACH scan

by Johann T.

Hi, I have made some captures on the L-band uplink channels and tried to decode the RACH messages. All four consecutive TCH channels (according to the spot beam) were recorded and a call was made during the recording. I am using the GRC block gmr_rach_scan.grc. I have removed the IQ swap from the graph, as suggested in the mailing list. The sampling rate and samples-per-symbol values have been set to 93.6k and 4, respectively. It ran fine without any errors, but I couldn't see any results either on the wireshark or under /tmp/rach.txt. Maybe I overlooked something here. Any ideas or remarks? Many thanks, Johann

1 year, 7 months

MES to Satellite decoding and A5-1-GMR decrypt

by Tiger Yi

Dear all, Right now I am studing on osmGMR code and try to understand how it works. From the code my understanding and concerns are as below: 1.  It looks like osmoGMR gmr1_rx only analyze and decode downlink(Satellite to MES) messages and data,  am I right?  If there any similar application that can decode both downlink and uplink(MES to Satellite)? Or osmoGMR needs input to implement downlink decode? 2.  A plaintext-decrypt is mentioned in osmoGMR wiki but no detail about how to implement it.   Is there a opensource code for A5-1-GMR? Or any other clue that can understand how plaintext decrypt  A5-1-GMR? Does osmoGMR need input to implemen it? Best Regards, Tiger

2 years, 3 months

Bug (+ patch) for sync_id retrieval code

by Bart Marinissen

Hi, Whilst working with this code, I came across some inconsistent sync-ids. Diving in deeper, I found a bug. It’s probably best explained by the patch itself, (see below) but I will also try and explain it in plain words. In short, when checking which sync_id has the highest correlation, the relevant bit of of the signal (with wiggle room) is correlated against the sync-id pattern into a buffer. This adds the output correlation to the buffer. Then, at the end, it was decided which sync_id was present by looking for the max correlation. In between sync-ids, the buffer was not reset. Hence when checking the last sync_id, the buffer does not hold the correlation between that sync_id and the signal, but the sum of correlations between the signal and all sync_id. Hence the results were very strongly biased towards the later sync_ids. The fix is easy. Clear the buffer before every correlation. See the patch below. The patch should apply to the master branch, I believe the bug exists in most branches though,. In my mind, the change is too trivial to be copyrighted. But for completeness sake, I give the osmocom-gmr project permission to use this patch. Kind regards, Bart Marinissen diff --git a/src/sdr/pi4cxpsk.c b/src/sdr/pi4cxpsk.c index 1ed40e01989bac05ff915ebd811835a60f95f61e..e8ab843a92d90622b64b5a59fcaff9ef4d01fea0 100644 --- a/src/sdr/pi4cxpsk.c +++ b/src/sdr/pi4cxpsk.c @@ -204,12 +204,12 @@ _gmr1_pi4cxpsk_sync_find(struct gmr1_pi4cxpsk_burst *burst_type, goto err; } - memset(corr->data, 0x00, sizeof(float complex) * corr->max_len); - corr->len = w; - /* Scan all possible training sequences */ for (i=0; (i < GMR1_MAX_SYNC) && (burst_type->sync[i] != NULL); i++) { + memset(corr->data, 0x00, sizeof(float complex) * corr->max_len); + corr->len = w; + struct gmr1_pi4cxpsk_sync *csync; float s_toa, s_pwr; float complex s_peak;

2 years, 6 months

OsmoDevCon 2022 ?

by Harald Welte

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)

2 years, 6 months

osmo-live error

by 선경미

3 years, 3 months

Few questions about Osmo-GMR

by Anton Minchev

Hello , last week i worked with osmo-gmr projest ,but still have some questions: 1. I need some more info about S band GMR - what sat is this , az / el , what trafic etc. 2. About gmr1 ambe decode - i tried about dozens of .dat files from gmr1 rx live , some give me ! codec errors , some not , but all .wav audio files are scrambled ,speesh is not recognized at all .. is there some clear traffic at all, or all is A5/2 coded ? 3. If all is scrambled where i may find offline tables / H n matrix/,any source that may generate them ? And if i have tables how they will be integrated with existing osmo-gmr ? I see gmr1_gen_mat that generates G/g matrix .. some more info about that .. .G and .g files seems so small .. Thanks in advance !

3 years, 3 months

rach

by Peter Wallereres

Dear list , i am still trying to compile the gnuradio blocks for the rach. But the building stops after 52%. Could it be that there is something wrong in the source code? Anyone else already succeeded to build the blocks? I am using Ubuntu 18.04.5 LTS, with gnu-radio 3.7, the compiler give me the following error: [ 52%] Building CXX object lib/CMakeFiles/gnuradio-gmr1.dir/gsmtap_sink_impl.cc.o /home/peter/Radio/Thuraya/sylvain-gr/osmo-gmr/gr-gmr1/lib/gsmtap_sink_impl.cc: In constructor ‘gr::gmr1::gsmtap_sink_impl::gsmtap_sink_impl(const string&, uint16_t)’: /home/peter/Radio/Thuraya/sylvain-gr/osmo-gmr/gr-gmr1/lib/gsmtap_sink_impl.cc:58:27: error: ‘PDU_PORT_ID’ was not declared in this scope message_port_register_in(PDU_PORT_ID); ^~~~~~~~~~~ /home/peter/Radio/Thuraya/sylvain-gr/osmo-gmr/gr-gmr1/lib/gsmtap_sink_impl.cc: In member function ‘void gr::gmr1::gsmtap_sink_impl::send_pdu(pmt::pmt_t)’: /home/peter/Radio/Thuraya/sylvain-gr/osmo-gmr/gr-gmr1/lib/gsmtap_sink_impl.cc:94:2: error: invalid conversion from ‘const uint8_t* {aka const unsigned char*}’ to ‘uint8_t {aka unsigned char}’ [-fpermissive] )); ^ /home/peter/Radio/Thuraya/sylvain-gr/osmo-gmr/gr-gmr1/lib/gsmtap_sink_impl.cc:94:2: error: invalid conversion from ‘size_t {aka long unsigned int}’ to ‘const uint8_t* {aka const unsigned char*}’ [-fpermissive] /home/peter/Radio/Thuraya/sylvain-gr/osmo-gmr/gr-gmr1/lib/gsmtap_sink_impl.cc:94:2: error: too few arguments to function ‘msgb* gmr1_gsmtap_makemsg(uint8_t, uint16_t, uint32_t, uint8_t, const uint8_t*, int)’ In file included from /home/peter/Radio/Thuraya/sylvain-gr/osmo-gmr/gr-gmr1/lib/gsmtap_sink_impl.cc:34:0: /home/peter/Radio/Thuraya/sylvain-gr/osmo-gmr/gr-gmr1/../include/osmocom/gmr1/gsmtap.h:36:14: note: declared here struct msgb *gmr1_gsmtap_makemsg( ^~~~~~~~~~~~~~~~~~~ lib/CMakeFiles/gnuradio-gmr1.dir/build.make:309: recipe for target 'lib/CMakeFiles/gnuradio-gmr1.dir/gsmtap_sink_impl.cc.o' failed make[2]: *** [lib/CMakeFiles/gnuradio-gmr1.dir/gsmtap_sink_impl.cc.o] Error 1 CMakeFiles/Makefile2:254: recipe for target 'lib/CMakeFiles/gnuradio-gmr1.dir/all' failed make[1]: *** [lib/CMakeFiles/gnuradio-gmr1.dir/all] Error 2 Makefile:140: recipe for target 'all' failed make: *** [all] Error 2

3 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

gmr