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?
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
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)
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
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
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;
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)
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 !
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