From sim at ijskes.org Tue Mar 1 07:54:55 2011 From: sim at ijskes.org (Sim IJskes) Date: Tue, 01 Mar 2011 08:54:55 +0100 Subject: identifying tetra Message-ID: <4D6CA64F.5070106@ijskes.org> I've identified 4 carriers in the 400Mhz band, with a clear 4 state constellation. Is there an easy way to verify it is indeed tetra? I'm using grc. Gr. Sim -------------- next part -------------- A non-text attachment was scrubbed... Name: sim.vcf Type: text/x-vcard Size: 113 bytes Desc: not available URL: From 246tnt at gmail.com Tue Mar 1 09:00:34 2011 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 1 Mar 2011 10:00:34 +0100 Subject: identifying tetra In-Reply-To: <4D6CA64F.5070106@ijskes.org> References: <4D6CA64F.5070106@ijskes.org> Message-ID: > I've identified 4 carriers in the 400Mhz band, with a clear 4 state > constellation. Is there an easy way to verify it is indeed tetra? I'm using > grc. Try to decode them using osmo-tetra ... (see previous annouce and the README to know how to). Sylvain From sim at ijskes.org Tue Mar 1 09:12:30 2011 From: sim at ijskes.org (Sim IJskes) Date: Tue, 01 Mar 2011 10:12:30 +0100 Subject: identifying tetra In-Reply-To: References: <4D6CA64F.5070106@ijskes.org> Message-ID: <4D6CB87E.7060409@ijskes.org> On 01-03-11 10:00, Sylvain Munaut wrote: >> I've identified 4 carriers in the 400Mhz band, with a clear 4 state >> constellation. Is there an easy way to verify it is indeed tetra? I'm using >> grc. > > Try to decode them using osmo-tetra ... (see previous annouce and the > README to know how to). Thanks. I'm struggling a bit how to get a GSMTAP dissector in wireshark. I need to recompile wireshark in order to get there, do i? BTW it looks that idling causes the 4 state diagram, when there is data, it turns into a 8 sided diamond. Gr. Sim From holger at freyther.de Tue Mar 1 09:20:11 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 01 Mar 2011 10:20:11 +0100 Subject: identifying tetra In-Reply-To: <4D6CB87E.7060409@ijskes.org> References: <4D6CA64F.5070106@ijskes.org> <4D6CB87E.7060409@ijskes.org> Message-ID: <4D6CBA4B.3050408@freyther.de> On 03/01/2011 10:12 AM, Sim IJskes wrote: > > Thanks. I'm struggling a bit how to get a GSMTAP dissector in wireshark. I > need to recompile wireshark in order to get there, do i? Yes, you will need to compile one of the 1.5 development versions of wireshark. If you are using Ubuntu there are some PPAs with wireshark 1.5.1. From sim at ijskes.org Tue Mar 1 09:44:09 2011 From: sim at ijskes.org (Sim IJskes) Date: Tue, 01 Mar 2011 10:44:09 +0100 Subject: identifying tetra In-Reply-To: <4D6CBA4B.3050408@freyther.de> References: <4D6CA64F.5070106@ijskes.org> <4D6CB87E.7060409@ijskes.org> <4D6CBA4B.3050408@freyther.de> Message-ID: <4D6CBFE9.5000309@ijskes.org> On 01-03-11 10:20, Holger Hans Peter Freyther wrote: > On 03/01/2011 10:12 AM, Sim IJskes wrote: > >> >> Thanks. I'm struggling a bit how to get a GSMTAP dissector in wireshark. I >> need to recompile wireshark in order to get there, do i? > > Yes, you will need to compile one of the 1.5 development versions of > wireshark. If you are using Ubuntu there are some PPAs with wireshark 1.5.1. Thanks. I've found a PPA @ it has GSMTAP as a protocol. I still don't have the right architectual image of GSMTAP i think. Do i need to direct wireshark to sniff on the same interface that tetra-rx opens its udp socket on, with a port filter, or is there a pseudo interface that listens for raw packets on the same UDP port? Gr. Sim From holger at freyther.de Tue Mar 1 09:54:58 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 01 Mar 2011 10:54:58 +0100 Subject: identifying tetra In-Reply-To: <4D6CBFE9.5000309@ijskes.org> References: <4D6CA64F.5070106@ijskes.org> <4D6CB87E.7060409@ijskes.org> <4D6CBA4B.3050408@freyther.de> <4D6CBFE9.5000309@ijskes.org> Message-ID: <4D6CC272.40304@freyther.de> On 03/01/2011 10:44 AM, Sim IJskes wrote: > Thanks. I've found a PPA @ it has > GSMTAP as a protocol. > > I still don't have the right architectual image of GSMTAP i think. Do i need > to direct wireshark to sniff on the same interface that tetra-rx opens its udp > socket on, with a port filter, or is there a pseudo interface that listens for > raw packets on the same UDP port? There is no pseudo interface. The tetra decoding program sends UDP packets to the IANA assigned port for GSMTAP on the specified ip address. E.g we like to use multicast addresses as this avoid seeing ICMP messages as the destination is not reachable. The easiest would be to use wireshark's pseudo interface to scan every interface and then filter for udp in the trace and select gsmtap in the filterbar of wireshark. From sim at ijskes.org Tue Mar 1 10:10:30 2011 From: sim at ijskes.org (Sim IJskes) Date: Tue, 01 Mar 2011 11:10:30 +0100 Subject: identifying tetra In-Reply-To: <4D6CC272.40304@freyther.de> References: <4D6CA64F.5070106@ijskes.org> <4D6CB87E.7060409@ijskes.org> <4D6CBA4B.3050408@freyther.de> <4D6CBFE9.5000309@ijskes.org> <4D6CC272.40304@freyther.de> Message-ID: <4D6CC616.8070502@ijskes.org> On 01-03-11 10:54, Holger Hans Peter Freyther wrote: >> I still don't have the right architectual image of GSMTAP i think. Do i need >> to direct wireshark to sniff on the same interface that tetra-rx opens its udp >> socket on, with a port filter, or is there a pseudo interface that listens for >> raw packets on the same UDP port? > > There is no pseudo interface. The tetra decoding program sends UDP packets to > the IANA assigned port for GSMTAP on the specified ip address. E.g we like to > use multicast addresses as this avoid seeing ICMP messages as the destination > is not reachable. > > The easiest would be to use wireshark's pseudo interface to scan every > interface and then filter for udp in the trace and select gsmtap in the > filterbar of wireshark. Ok. I've straced tetra-rx and it opens on 127.0.0.1. So i wiresharked it on lo with a port filter. That should work. But tetra-rx doesn't do a write on the udp-socket. That could of course mean there is no tetra data in the capture. I've rebuild the usrp1-tetra_demod.py in the latest grc from git trunk, and the 25Khz lowpass gives me a nasty spike on -22Khz. A 20Khz gives me a much sharper idle constellation. Do you see any problem with 20Khz lowpass? Gr. Sim -------------- next part -------------- A non-text attachment was scrubbed... Name: sim.vcf Type: text/x-vcard Size: 121 bytes Desc: not available URL: From sim at ijskes.org Tue Mar 1 13:52:31 2011 From: sim at ijskes.org (Sim IJskes) Date: Tue, 01 Mar 2011 14:52:31 +0100 Subject: calibration option Message-ID: <4D6CFA1F.404@ijskes.org> Is there a reason for the calibration option to be an int? A eng_float looks much more logical to me, as it is used the spec a freq. Gr. Sim -------------- next part -------------- A non-text attachment was scrubbed... Name: sim.vcf Type: text/x-vcard Size: 113 bytes Desc: not available URL: From laforge at gnumonks.org Tue Mar 1 18:18:52 2011 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 1 Mar 2011 19:18:52 +0100 Subject: calibration option In-Reply-To: <4D6CFA1F.404@ijskes.org> References: <4D6CFA1F.404@ijskes.org> Message-ID: <20110301181851.GA3859@prithivi.gnumonks.org> On Tue, Mar 01, 2011 at 02:52:31PM +0100, Sim IJskes wrote: > Is there a reason for the calibration option to be an int? A > eng_float looks much more logical to me, as it is used the spec a > freq. It indeed does not make sense to have this in integer. Feel free to test+submit a patch. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From sim at ijskes.org Tue Mar 1 20:42:01 2011 From: sim at ijskes.org (Sim IJskes) Date: Tue, 01 Mar 2011 21:42:01 +0100 Subject: calibration option In-Reply-To: <20110301181851.GA3859@prithivi.gnumonks.org> References: <4D6CFA1F.404@ijskes.org> <20110301181851.GA3859@prithivi.gnumonks.org> Message-ID: <4D6D5A19.20805@ijskes.org> On 01-03-11 19:18, Harald Welte wrote: > On Tue, Mar 01, 2011 at 02:52:31PM +0100, Sim IJskes wrote: >> Is there a reason for the calibration option to be an int? A >> eng_float looks much more logical to me, as it is used the spec a >> freq. > > It indeed does not make sense to have this in integer. Feel free to > test+submit a patch. > > Like this you mean? Testing is not possible other then running it. I've no working tetra reception yet. As you can see, i've changed the default to 0 to align with usrp1-tetra_demod.py behaviour. Gr. Sim -------------- next part -------------- A non-text attachment was scrubbed... Name: p.patch Type: text/x-patch Size: 770 bytes Desc: not available URL: From sim at ijskes.org Tue Mar 1 21:14:55 2011 From: sim at ijskes.org (Sim IJskes) Date: Tue, 01 Mar 2011 22:14:55 +0100 Subject: filter width Message-ID: <4D6D61CF.5080205@ijskes.org> When i interpret para 4 of ETSI TS 100 392-15 it looks like the channels are spaced at 25Khz. The default low_pass used in all of the demods is 25Khz. But when i look in the FFT of the complex signal, the 25Khz specified in the cutoff_freq of firdes.low_pass causes a passband of twice the width. Isn't this way to much? Shouldnt the cutoff_freq be 12.5Khz, giving a passband of 25Khz? (Or is there an intentional spectral overlap between adjacent channels?) If this is the cause, should we just change the parameter to filterwidth or channelspacing and use a /2 in the cutoff parm? Gr. Sim From laforge at gnumonks.org Wed Mar 2 07:26:54 2011 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 2 Mar 2011 08:26:54 +0100 Subject: calibration option In-Reply-To: <4D6D5A19.20805@ijskes.org> References: <4D6CFA1F.404@ijskes.org> <20110301181851.GA3859@prithivi.gnumonks.org> <4D6D5A19.20805@ijskes.org> Message-ID: <20110302072654.GJ3859@prithivi.gnumonks.org> Hi Sim, On Tue, Mar 01, 2011 at 09:42:01PM +0100, Sim IJskes wrote: > Like this you mean? Testing is not possible other then running it. > I've no working tetra reception yet. you could ask somebody to provide a trace to you :) > As you can see, i've changed the default to 0 to align with > usrp1-tetra_demod.py behaviour. ok, thanks. applied. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From lists at infosecurity.ch Mon Mar 7 08:03:45 2011 From: lists at infosecurity.ch (Fabio Pietrosanti) Date: Mon, 07 Mar 2011 09:03:45 +0100 Subject: Which hardware for playing out with tetra? Message-ID: <4D749161.3020702@pietrosanti.it> Hi all, i have an USRP1 with DRX and RFX900 daughterboard and wanted to play a bit with the basic tetra decoder. Which kind of daughterboard has been successfully tested with the current osmocom tetra? Fabio From 246tnt at gmail.com Mon Mar 7 08:43:06 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Mon, 07 Mar 2011 08:43:06 +0000 Subject: Which hardware for playing out with tetra? In-Reply-To: <4D749161.3020702@pietrosanti.it> Message-ID: <0015174c38c408f049049de07cc6@google.com> > i have an USRP1 with DRX and RFX900 daughterboard and wanted to play a > bit with the basic tetra decoder. > Which kind of daughterboard has been successfully tested with the > current osmocom tetra? I used the WBX to receive in the 400 MHz band. Both the RFX and DBSRX can't receive in that frequency ... Maybe the TVRX / TVRX 2 could receive it as well but I didn't test. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.abdolian at yahoo.com Mon Mar 7 09:05:14 2011 From: f.abdolian at yahoo.com (Farhad Abdolian) Date: Mon, 7 Mar 2011 01:05:14 -0800 (PST) Subject: Which hardware for playing out with tetra? In-Reply-To: <4D749161.3020702@pietrosanti.it> References: <4D749161.3020702@pietrosanti.it> Message-ID: <336586.82415.qm@web65409.mail.ac4.yahoo.com> I am using WBX with USRP1 I think that is the best design available for USRP. ________________________________ From: Fabio Pietrosanti To: tetra at lists.osmocom.org Sent: Mon, March 7, 2011 9:03:45 AM Subject: Which hardware for playing out with tetra? Hi all, i have an USRP1 with DRX and RFX900 daughterboard and wanted to play a bit with the basic tetra decoder. Which kind of daughterboard has been successfully tested with the current osmocom tetra? Fabio -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Mon Mar 7 10:10:12 2011 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 07 Mar 2011 11:10:12 +0100 Subject: Which hardware for playing out with tetra? In-Reply-To: <0015174c38c408f049049de07cc6@google.com> References: <0015174c38c408f049049de07cc6@google.com> Message-ID: <4D74AF04.80103@freyther.de> On 03/07/2011 09:43 AM, 246tnt at gmail.com wrote: > > Both the RFX and DBSRX can't receive in that frequency ... > Maybe the TVRX / TVRX 2 could receive it as well but I didn't test. I was trying with the TVRX and it didn't work. Either my stupidity to use GNU Radio, a bad antenna, lack of tetra in my area. I plan to get back to this after my vacation. From 246tnt at gmail.com Mon Mar 7 10:20:39 2011 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Mon, 07 Mar 2011 10:20:39 +0000 Subject: Which hardware for playing out with tetra? In-Reply-To: <4D74AF04.80103@freyther.de> Message-ID: <0016e6dd98abe7969c049de1d8c1@google.com> Hi, > I was trying with the TVRX and it didn't work. Either my stupidity to use > GNU > Radio, a bad antenna, lack of tetra in my area. I plan to get back to this > after my vacation. I know some people on the gnuradio list used to report pretty high phase noise with the TVRX ( the first version ), so that may be related. If try and you still have trouble, I could try it myself with my TVRX (I know I have good tetra signal here). Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.abdolian at yahoo.com Mon Mar 7 12:56:35 2011 From: f.abdolian at yahoo.com (Farhad Abdolian) Date: Mon, 7 Mar 2011 04:56:35 -0800 (PST) Subject: TETRA stream file? In-Reply-To: <0016e6dd98abe7969c049de1d8c1@google.com> References: <0016e6dd98abe7969c049de1d8c1@google.com> Message-ID: <486675.93417.qm@web65408.mail.ac4.yahoo.com> Hi, I am having problem with my RX data and wonder if anyone has a captured data file to share so I can see if the behavior of my code is the same with it compared to the one I have created myself. Thanks in advance, Farhad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ikj1234i at yahoo.com Tue Mar 22 15:13:05 2011 From: ikj1234i at yahoo.com (ikjtel) Date: Tue, 22 Mar 2011 08:13:05 -0700 (PDT) Subject: PI/4 DQPSK Message-ID: <999372.82816.qm@web39407.mail.mud.yahoo.com> Thanks for including my "cqpsk.py" decoder module in your distribution. That looks to be a very old version and there have been some further discoveries since that time which I wanted to pass along, FWIW... First, the Costas frequency lock loop in GR seems to work much better for PI/4 DQPSK signals if it's patched in phase_error_tracking() : #if ENABLE_COSTAS_CQPSK_HACK if (d_interp_counter & 1) // every other symbol sample = sample * PT_45; // rotate by +45 deg d_interp_counter++; #endif /* ENABLE_COSTAS_CQPSK_HACK */ The effect of adding this hack to the code can be seen in Fig. 10 at my page http://www.lightlink.com/mhp/lsm/ With the patch included, the time to achieve lock is much improved... Second, I've found that a Gardner symbol timing loop works much better in our application than the M&M loop used in GR gr_mpsk_receiver(). Both of these improvements are included in a new GR block which has been optimized for the particular flavor of "PI/4 CQPSK" (LSM). It's in our svn repo - see http://sedition.org.au/op25/wiki/BuildInstructionsPage Look for the block in the repeater/src/lib tree - see repeater_gardner_costas_cc.cc YMMV ;-) [update: Tues. morning] two more things... 1. There is also a new Polyphase Filter Bank receiver which has been added in the latest versions of GNU Radio. It would be interesting to test and compare the performance of that receiver with the current one... 2. Would it be possible to post complex sample files (preferably not encrypted) to permit evaluation of this signal type? Best Regards 73 de KA1RBI Max