From frank at hvitehus.no Sun Nov 11 11:05:28 2012 From: frank at hvitehus.no (Frank A. Stevenson) Date: Sun, 11 Nov 2012 12:05:28 +0100 Subject: Strange offset in float_to_bits.c Message-ID: <1352631928.28828.5.camel@quant> I made this change: diff --git a/src/float_to_bits.c b/src/float_to_bits.c index 08fad54..4547ffe 100644 --- a/src/float_to_bits.c +++ b/src/float_to_bits.c @@ -113,7 +113,7 @@ int main(int argc, char **argv) exit(1); } else if (rc == 0) break; - rc = process_sym_fl(0.3f, fl); + rc = process_sym_fl(0.0f, fl); sym_int2bits(rc, bits); //printf("%2d %1u %1u %f\n", rc, bits[0], bits[1], fl); if (opt_verbose) Which improved decoding rate on correctly tuned captures. I think this 0.3 offset is an oversight that will generally increase BER. In other news, I have gotten my own GPU (openCL) assisted demodulator working, I am thinking about decoding multiple carriers concurrently with this code, but I think the gnu_radio demodulator has an edge with regards to BER, especially if the offset is set to 0.0f :-) Cheers, Frank From 246tnt at gmail.com Sun Nov 11 11:56:11 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 11 Nov 2012 12:56:11 +0100 Subject: Strange offset in float_to_bits.c In-Reply-To: <1352631928.28828.5.camel@quant> References: <1352631928.28828.5.camel@quant> Message-ID: Hi, > diff --git a/src/float_to_bits.c b/src/float_to_bits.c > index 08fad54..4547ffe 100644 > --- a/src/float_to_bits.c > +++ b/src/float_to_bits.c > @@ -113,7 +113,7 @@ int main(int argc, char **argv) > exit(1); > } else if (rc == 0) > break; > - rc = process_sym_fl(0.3f, fl); > + rc = process_sym_fl(0.0f, fl); > sym_int2bits(rc, bits); > //printf("%2d %1u %1u %f\n", rc, bits[0], bits[1], fl); > if (opt_verbose) Applied. > In other news, I have gotten my own GPU (openCL) assisted demodulator > working, I am thinking about decoding multiple carriers concurrently > with this code, but I think the gnu_radio demodulator has an edge with > regards to BER, especially if the offset is set to 0.0f :-) In my experience with OsmoGMR, the actual demod isn't all that CPU intensive. The channelization and resampling to a multiple of symbol rate is what's expensive. A few things I don't like in the current demod : - Don't use the FCCH to properly lock to carrier - Only works for continuous carrier .. can't possibly use it for DMO or even uplink I think. If yours could lift those limitation that'd be great :p Cheers, Sylvain From frank at hvitehus.no Sat Nov 17 20:39:28 2012 From: frank at hvitehus.no (Frank A. Stevenson) Date: Sat, 17 Nov 2012 21:39:28 +0100 Subject: Decoding multiple carriers Message-ID: <1353184768.6193.24.camel@quant> I have gotten some code working now to a proof of concept level. What it does is: A) Capture 2 MHz of spectrum to fifo (1) (gnuradio-companion) B) Frequency shift, filter and decimate fifo(1) -> fifo(2) using GPU C) Demodulate fifo (2) into bits to fifo(3) using my own "dodgy demodulator" D) Running tetra-rx from fifo(3) - for display in wireshark This runs realtime at around 30% CPU load (for a single core) and 30% GPU load on an ATI 5850 card. So I can easily add more carriers to tetra-rx (I have 2 such GPUs), but tetra-rx doesn't seem well prepared for handling such situations, for instance the GSMTAP packets are not tagged by ARFCN - besides I don't have a good understanding of what others would want to do when demodulating multiple carriers. Personally I have to limit myself to traffic analysis on a fully encrypted network. Are there any plans for how to progress tetra-rx that I can follow, or should I just rip the thing apart and make it do what I want it to do ? f From laforge at gnumonks.org Sun Nov 18 11:11:13 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Nov 2012 12:11:13 +0100 Subject: Strange offset in float_to_bits.c In-Reply-To: <1352631928.28828.5.camel@quant> References: <1352631928.28828.5.camel@quant> Message-ID: <20121118111112.GQ8595@prithivi.gnumonks.org> On Sun, Nov 11, 2012 at 12:05:28PM +0100, Frank A. Stevenson wrote: > - rc = process_sym_fl(0.3f, fl); > + rc = process_sym_fl(0.0f, fl); I think I put it there intentionally as the signal I was looking at that time had some offset. But I'm not 100% sure if I remeber correctly, it's been some time.. In any case, it was just a local hack, AFAIR. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Nov 18 11:15:01 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Nov 2012 12:15:01 +0100 Subject: Decoding multiple carriers In-Reply-To: <1353184768.6193.24.camel@quant> References: <1353184768.6193.24.camel@quant> Message-ID: <20121118111501.GR8595@prithivi.gnumonks.org> Hi Frank, On Sat, Nov 17, 2012 at 09:39:28PM +0100, Frank A. Stevenson wrote: > So I can easily add more carriers to tetra-rx (I have 2 such GPUs), > but tetra-rx doesn't seem well prepared for handling such situations, > for instance the GSMTAP packets are not tagged by ARFCN - Feel free to extend it in a way that keeps existing functionality but adds those bits as required. A lot of the state (like tetra_mac_state) is already not in global variables, so it should not be too hard. In terms of the ARFCN: I'd suggest just add the current arfcn to the PHY state and pass it up from there. > besides I don't have a good understanding of what others would want to > do when demodulating multiple carriers. Personally I have to limit > myself to traffic analysis on a fully encrypted network. I don't think anyone has any big plans for osmo-tetra at this point. It mostly works for what we originally wrote it. Feel free to post any patches here for review / merge. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jack at espectrodigital.com Mon Nov 19 08:59:58 2012 From: jack at espectrodigital.com (Jack) Date: Mon, 19 Nov 2012 09:59:58 +0100 Subject: osmotetra java port Message-ID: Hello, I just started to write a java port of osmotetra and I wonder if there is some people interested who can help me to debug, clean and make documentation (javadoc format) for this code. I want to write a java implementation of codec too, but I don't know if I can distribute the code or if its license forbids it, can you tell me about this? Thanks. Jes?s M. Tormo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank at hvitehus.no Sun Nov 25 22:29:11 2012 From: frank at hvitehus.no (Frank A. Stevenson) Date: Sun, 25 Nov 2012 23:29:11 +0100 Subject: Fix some uglyness Message-ID: <1353882551.6193.51.camel@quant> Attached is a patch that fixes some global ugliness. The dependencies are a bit iffy, so you need a make clean after applying this. This fix needs to be in place before you decode multiple carriers. I would like to suggest that tetra-rx.c be changed so that it can receive multiplexed streams of input. Byte values of 0 / 1 will be the primary stream, but other values can be used to encode the multiplexed streams. The easiest method is to use the high order bits of the input as a "stream id", and dynamically create new state structs as they appear in the stream. Does this sound like a decent solution ? f -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_ugly.diff Type: text/x-patch Size: 2198 bytes Desc: not available URL: From mailman at lists.osmocom.org Sun Nov 25 22:41:33 2012 From: mailman at lists.osmocom.org (mailman at lists.osmocom.org) Date: Sun, 25 Nov 2012 23:41:33 +0100 Subject: Bounce action notification Message-ID: This is a Mailman mailing list bounce action notice: List: tetra Member: jasperkanbier at wanadoo.nl Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at lists.osmocom.org. -------------- next part -------------- An embedded message was scrubbed... From: Mail Delivery System Subject: Mail delivery failed: returning message to sender Date: Sun, 25 Nov 2012 23:41:32 +0100 Size: 5750 URL: From frank at hvitehus.no Mon Nov 26 18:34:13 2012 From: frank at hvitehus.no (Frank A. Stevenson) Date: Mon, 26 Nov 2012 19:34:13 +0100 Subject: Fix some ugliness In-Reply-To: <1353882551.6193.51.camel@quant> References: <1353882551.6193.51.camel@quant> Message-ID: <1353954853.6193.60.camel@quant> On Sun, 2012-11-25 at 23:29 +0100, Frank A. Stevenson wrote: > Attached is a patch that fixes some global ugliness. The dependencies > are a bit iffy, so you need a make clean after applying this. > > This fix needs to be in place before you decode multiple carriers. I > would like to suggest that tetra-rx.c be changed so that it can receive > multiplexed streams of input. Byte values of 0 / 1 will be the primary > stream, but other values can be used to encode the multiplexed streams. > > The easiest method is to use the high order bits of the input as a > "stream id", and dynamically create new state structs as they appear in > the stream. > > Does this sound like a decent solution ? > > f I made changes such as outlined in my previous mail, which allows tetra-rx to decode 16 carriers from a multiplexed stream. This works quite well, but my emacs config is a bit off so I have spaces where there ought to be tabs, and the uint16_t for GSMTAP arfcn value is a bit mysterious, since I get arfcn 0,256,768,1024 etc :-) so I need a better system for assigning arfcn values to the different carriers in the multiplex. My git status is currently something like: # modified: tetra-rx.c # modified: tetra_common.h # modified: tetra_gsmtap.c # modified: tetra_gsmtap.h # modified: tetra_upper_mac.c (including the ugliness fix), so it may be better to keep the cleaned up patch off the list when it is ready for submission. Who would like to review the changes ? f From frank at hvitehus.no Wed Nov 28 21:08:18 2012 From: frank at hvitehus.no (Frank A. Stevenson) Date: Wed, 28 Nov 2012 22:08:18 +0100 Subject: Fix some ugliness In-Reply-To: <1353954853.6193.60.camel@quant> References: <1353882551.6193.51.camel@quant> <1353954853.6193.60.camel@quant> Message-ID: <1354136898.6193.68.camel@quant> I put up a patch with my changes here: http://traxme.net/usrp/multiplex.diff.gz I hope this passes muster, functionally it is the same as before, but tetra-rx now accepts multiplexed input. Make clean is required. f On Mon, 2012-11-26 at 19:34 +0100, Frank A. Stevenson wrote: > I made changes such as outlined in my previous mail,... > ...so it may be better to keep the cleaned up > patch off the list when it is ready for submission. Who would like to > review the changes ? > > f From holger at freyther.de Thu Nov 29 07:52:49 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 29 Nov 2012 08:52:49 +0100 Subject: Fix some ugliness In-Reply-To: <1354136898.6193.68.camel@quant> References: <1353882551.6193.51.camel@quant> <1353954853.6193.60.camel@quant> <1354136898.6193.68.camel@quant> Message-ID: <20121129075249.GE26529@xiaoyu.lan> On Wed, Nov 28, 2012 at 10:08:18PM +0100, Frank A. Stevenson wrote: Hi Frank, > > I hope this passes muster, functionally it is the same as before, but > tetra-rx now accepts multiplexed input. Make clean is required. My two cents.. + carrier_table[cid] = talloc_zero(tetra_tall_ctx, struct tetra_rx_carrier); + init_carrier(carrier_table[cid],(uint16_t)cid); should become carrier_table[cid] = tetra_create_carrier(cid); and the deinit then just tetra_delete_carrier(carrier_table[cid]) which then talloc free's the root. This way you can skip the NULL check and you stop to delete memory. talloc_free(NULL) will not cause a crash. holger PS: Feel free to send the entire patch to the ML.