From zero-kelvin at gmx.de Thu Aug 22 20:07:27 2013 From: zero-kelvin at gmx.de (dexter) Date: Thu, 22 Aug 2013 22:07:27 +0200 Subject: UPDATE -- Osmocom Berlin User Group meeting -- NEXT MEETING In-Reply-To: <20130605121428.GA10030@nataraja.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <51AF0097.10402@gmx.de> <20130605121428.GA10030@nataraja.gnumonks.org> Message-ID: <52166F7F.3080006@gmx.de> Hi All. It's time Again! This is the announcement for the next Osmocom Berlin meeting. Aug 28, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. I am looking forward to see you there! regards. Philipp From laforge at gnumonks.org Sat Aug 24 13:41:55 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 24 Aug 2013 15:41:55 +0200 Subject: UPDATE -- Osmocom Berlin User Group meeting -- NEXT MEETING In-Reply-To: <52166F7F.3080006@gmx.de> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <51AF0097.10402@gmx.de> <20130605121428.GA10030@nataraja.gnumonks.org> <52166F7F.3080006@gmx.de> Message-ID: <20130824134155.GD16941@nataraja.gnumonks.org> Hi Dexter, thanks again for continuing the tradition of the meeting. After a long period of absence, I am planning on attending again on August 28. Looking forward to it! Regards, Harald On Thu, Aug 22, 2013 at 10:07:27PM +0200, dexter wrote: > Hi All. > > It's time Again! > > This is the announcement for the next Osmocom Berlin meeting. > > Aug 28, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin > > There is no formal presentation scheduled for this meeting. > > If you are interested to show up, feel free to do so. There is no > registration required. The meeting is free as in "free beer", despite > no actual free beer being around. > > I am looking forward to see you there! > > regards. > Philipp > -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From craig_comstock at yahoo.com Tue Aug 20 13:39:03 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Tue, 20 Aug 2013 06:39:03 -0700 (PDT) Subject: chainload.compalram.bin missing? In-Reply-To: <51E9AB24.3090209@steve-m.de> References: <1374248354.79138.YahooMailNeo@web121001.mail.ne1.yahoo.com> <51E9AB24.3090209@steve-m.de> Message-ID: <1377005943.60314.YahooMailNeo@web121005.mail.ne1.yahoo.com> I tried but seem to be getting an error... pi at raspberrypi ~/osmocom-bb/src/host/osmocon $ ./osmocon -d tr -p /dev/ttyUSB0 -m c140 -c ../../target/firmware/board/compal_e86/hello_world.highram.bin got 1 bytes from modem, data looks like: 00? . got 6 bytes from modem, data looks like: 66 74 6d 74 6f 6f? ftmtoo got 1 bytes from modem, data looks like: 6c? l Received FTMTOOL from phone, ramloader has aborted got 1 bytes from modem, data looks like: 65? e got 1 bytes from modem, data looks like: 72? r got 1 bytes from modem, data looks like: 72? r got 1 bytes from modem, data looks like: 6f? o got 1 bytes from modem, data looks like: 72? r I tried a different computer that is definitely faster and that didn't solve it. I am using a different serial cable, this one a home wired cp2102 where before I think I got this working with a direct wire to the raspberry pi alt serial pins. Are there any links to describe what is going on at the beginning when you press the power button? I found these links as well... http://lists.osmocom.org/pipermail/baseband-devel/2011-February/001407.html (didn't try this, but can) http://lists.osmocom.org/pipermail/baseband-devel/2011-January/001053.html (tried this... same result) Thanks, Craig ________________________________ From: Steve Markgraf To: Craig Comstock Cc: "baseband-devel at lists.osmocom.org" Sent: Friday, July 19, 2013 4:09 PM Subject: Re: chainload.compalram.bin missing? Hi, On 19.07.2013 17:39, Craig Comstock wrote: > I was trying to load some apps to a Motorola C139 and found that after > building osmocom-bb that there were no chainload image files built. Am I > using the wrong branch somehow? Are the instructions out of date on this > page: > > http://bb.osmocom.org/trac/wiki/MotorolaC140 Yes, the instructions are out of date. Meanwhile the chainloader has been integrated into osmocon, you just need to run: > ./osmocon -p /dev/ttyUSB0 -m c140 -c ../../target/firmware/board/compal_e86/layer1.highram.bin Regards, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Tue Aug 20 14:13:07 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 20 Aug 2013 16:13:07 +0200 Subject: chainload.compalram.bin missing? In-Reply-To: <1377005943.60314.YahooMailNeo@web121005.mail.ne1.yahoo.com> References: <1374248354.79138.YahooMailNeo@web121001.mail.ne1.yahoo.com> <51E9AB24.3090209@steve-m.de> <1377005943.60314.YahooMailNeo@web121005.mail.ne1.yahoo.com> Message-ID: <20130820141307.29940.qmail@stuge.se> Craig Comstock wrote: > I tried but seem to be getting an error... > > pi at raspberrypi ~/osmocom-bb/src/host/osmocon $ ./osmocon -d tr -p /dev/ttyUSB0 -m c140 -c ../../target/firmware/board/compal_e86/hello_world.highram.bin > got 1 bytes from modem, data looks like: 00? . > got 6 bytes from modem, data looks like: 66 74 6d 74 6f 6f? ftmtoo > got 1 bytes from modem, data looks like: 6c? l > Received FTMTOOL from phone, ramloader has aborted Communications problem. Try different cables. If you had rpi working then go back to using that, rather than introducing new unknowns. //Peter From craig_comstock at yahoo.com Wed Aug 21 18:48:29 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Wed, 21 Aug 2013 11:48:29 -0700 (PDT) Subject: chainload.compalram.bin missing? In-Reply-To: <1377005943.60314.YahooMailNeo@web121005.mail.ne1.yahoo.com> References: <1374248354.79138.YahooMailNeo@web121001.mail.ne1.yahoo.com> <51E9AB24.3090209@steve-m.de> <1377005943.60314.YahooMailNeo@web121005.mail.ne1.yahoo.com> Message-ID: <1377110909.85807.YahooMailNeo@web121006.mail.ne1.yahoo.com> I got things working for both C115 and C139 w/ rpi, osmocom built natively on debian and a cheap cp2102 usb raw stick direct from china/ebay. For C139 ./osmocon -d tr -p /dev/ttyUSB0 -m c140xor -c ../../target/firmware/board/compal_e86/rssi.highram.bin For C115 ./osmocon -d tr -p /dev/ttyUSB0 -m c123xor -c ../../target/firmware/board/compal_e88/rssi.highram.bin Sorry for the trouble... looks like "xor" and chainloading via -c were my two problems. -Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Thu Aug 22 16:30:40 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Thu, 22 Aug 2013 09:30:40 -0700 (PDT) Subject: C139 loading problems - different flash/layout the reason? In-Reply-To: <1377110909.85807.YahooMailNeo@web121006.mail.ne1.yahoo.com> References: <1374248354.79138.YahooMailNeo@web121001.mail.ne1.yahoo.com> <51E9AB24.3090209@steve-m.de> <1377005943.60314.YahooMailNeo@web121005.mail.ne1.yahoo.com> <1377110909.85807.YahooMailNeo@web121006.mail.ne1.yahoo.com> Message-ID: <1377189040.75905.YahooMailNeo@web121003.mail.ne1.yahoo.com> So I looked and there seem to be two board layouts involved here. The one's with the Intel flash seem to work fine. The others that have the MemoCom? flash don't work. The one's with MemoCom are missing several test points visible from the battery compartment as visible on the images on the webpage: http://bb.osmocom.org/trac/wiki/MotorolaC140 So maybe there is something different about these other C140 that makes them not work with osmocon. I get: pi at raspberrypi ~/osmocom-bb/src/host/osmocon $ ./osmocon -d tr -p /dev/ttyUSB0 c140 ../../target/firmware/board/compal_e86/hello_world.compalram.bin got 7 bytes from modem, data looks like: 66 74 6d 74 6f 6f 6c? ftmtool Received FTMTOOL from phone, ramloader has aborted got 1 bytes from modem, data looks like: 65? e got 1 bytes from modem, data looks like: 72? r got 1 bytes from modem, data looks like: 72? r got 1 bytes from modem, data looks like: 6f? o got 1 bytes from modem, data looks like: 72? r got 1 bytes from modem, data looks like: 66? f got 1 bytes from modem, data looks like: 74? t got 1 bytes from modem, data looks like: 6d? m got 1 bytes from modem, data looks like: 74? t got 1 bytes from modem, data looks like: 6f? o got 1 bytes from modem, data looks like: 6f? o got 1 bytes from modem, data looks like: 6c? l -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahm.gwd at gmail.com Sun Aug 4 01:58:29 2013 From: ahm.gwd at gmail.com (Ahmed Gawad) Date: Sun, 4 Aug 2013 03:58:29 +0200 Subject: fmtool error Message-ID: Hello, I am trying to run osmocom on Motorola C117. Using the following : PC(Ubuntu12 64bit)<---->USB To Serial cable (5v)<---->serial to (3.3V)<---->phone when i press power button all i can get is "fmtoolerror" . and there is no more messages only that . I am wounding if that means the phone is not working properly or it could be a cable issue ? Thanks very much . -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahm.gwd at gmail.com Sun Aug 4 23:45:53 2013 From: ahm.gwd at gmail.com (Ahmed Gawad) Date: Sun, 4 Aug 2013 23:45:53 +0000 (UTC) Subject: fmtool error References: Message-ID: Ahmed Gawad gmail.com> writes: > > > > > > > Hello, > I am trying to run osmocom on Motorola C117. > Using the following :PC(Ubuntu12 64bit)<---->USB To Serial cable (5v)<---- >serial to (3.3V)<---->phone > when i press power button all i can get is "fmtoolerror" . and there is no more messages only that . > I am wounding if that means the phone is not working properly or it could be a cable issue ? > Thanks very much . > After some searches and tries i found that: It is an issue in the Phone (this phone doesn't supports ramload , only fmtool protocol) so I think i need to use another phone . Thanks. From soliton33 at live.com Sun Aug 4 04:18:20 2013 From: soliton33 at live.com (Neela Neela) Date: Sun, 4 Aug 2013 00:18:20 -0400 Subject: Filtering in baseband spectrum Message-ID: Hi I am a beginner with RTL and observing that the baseband spectrum is centred at 0 Hz and is asymmetric going from -1 MHz to +1 MHz. How does one filter a part of such a spectrum? For example if signal of interest lied in -300 kHz to -150 kHz. The filtering techniques for typical band pass filters work with positive frequencies and have symmetric frequency selection response. As such a 150 to 300 KHz band pass filter will select signal in both 150 to 300 kHz band as well as from -150 to 300 kHz. Is there a special filtering method available to work with negative frequencies and with an asymmetric baseband spectrum. I am sure this has been addressed as preassumably the FM and other signals of interest are filtered somehow. Anu indications will be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca at srlabs.de Mon Aug 5 15:12:38 2013 From: luca at srlabs.de (Luca Melette) Date: Mon, 5 Aug 2013 17:12:38 +0200 Subject: Filtering in baseband spectrum In-Reply-To: References: Message-ID: <20130805171238.478a362c@c7h5n3o6.sofago.net> Hi Neela, I find your question a bit off-topic in this mail list, but still interesting for SDR geeks. The asymmetric spectrum is quite normal when processing complex domain signals (I/Q). If you are only interested in a part of the spectrum, you would normally shift it to the origin and then apply a low-pass filter. In your case, you can apply a positive shift of 225 KHz, and then a filter with cutoff frequency 75 KHz. You can easily apply this transformation with GNU Radio block. After that, you can even downsample your signal if needed. Other methods to obtain the same result are: - apply an asymmetric filter (complex coefficients) and then shift to origin - use an FFT filter, and possibly invert the spectrum in baseband Cheers, LM From soliton33 at live.com Mon Aug 5 20:34:58 2013 From: soliton33 at live.com (Neela Neela) Date: Mon, 5 Aug 2013 16:34:58 -0400 Subject: Filtering in baseband spectrum In-Reply-To: <20130805171238.478a362c@c7h5n3o6.sofago.net> References: , <20130805171238.478a362c@c7h5n3o6.sofago.net> Message-ID: Hi Luca Thanks for your reply. Perhaps I am too old school. But how would one make a frequency shift of 225 KHz without running into issues with the folded image spectrum causing a havoc? Any more indications on asymmetric filter (complex coefficients) and then shift to origin. is there a link to any page that addresses this in detail. While I am being skpetic about these, I am sure everyone is doing it. How thowugh? Regards > Date: Mon, 5 Aug 2013 17:12:38 +0200 > From: luca at srlabs.de > To: baseband-devel at lists.osmocom.org > Subject: Re: Filtering in baseband spectrum > > > Hi Neela, > > I find your question a bit off-topic in this mail list, > but still interesting for SDR geeks. > > The asymmetric spectrum is quite normal when processing > complex domain signals (I/Q). > > If you are only interested in a part of the spectrum, you > would normally shift it to the origin and then apply a low-pass filter. > > In your case, you can apply a positive shift of 225 KHz, and then > a filter with cutoff frequency 75 KHz. > You can easily apply this transformation with GNU Radio block. > After that, you can even downsample your signal if needed. > > Other methods to obtain the same result are: > - apply an asymmetric filter (complex coefficients) and then > shift to origin > - use an FFT filter, and possibly invert the spectrum in baseband > > Cheers, > > LM > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagar1935 at hotmail.co.uk Mon Aug 12 00:58:37 2013 From: dagar1935 at hotmail.co.uk (dagar) Date: Sun, 11 Aug 2013 17:58:37 -0700 (PDT) Subject: Channel Request Info RACH GSMTAP Wireshark? Message-ID: <1376269117545-4026112.post@n3.nabble.com> hello, when reading gsm spec online i have understood that on an MT call the BTS pages the phone on the RR paging channel(PCH) the phone then asks for a channel in the RR channel request (RACH) the BTS replies with RR immediate assignment(AGCH) etc etc Now I have tried to see a live example of this using osmocom-bb layer1/mobile + gsmtap/wirehshark However I cannot figure out or see anywhere in these logs the *RR channel request (RACH) packet*. Does GSMTAP or OsmocomBB actually capture the RR channel request or am I missing something here?? the logs I get are like this (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) System Information Type 1 (CCCH) (RR) System Information Type 2 (CCCH) (RR) System Information Type 3 (CCCH) (SS) (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) Paging Request Type 1 (CCCH) (RR) Immediate Assignment and so on Thanks! -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Channel-Request-Info-RACH-GSMTAP-Wireshark-tp4026112.html Sent from the baseband-devel mailing list archive at Nabble.com. From 246tnt at gmail.com Mon Aug 12 05:53:57 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 12 Aug 2013 07:53:57 +0200 Subject: Channel Request Info RACH GSMTAP Wireshark? In-Reply-To: <1376269117545-4026112.post@n3.nabble.com> References: <1376269117545-4026112.post@n3.nabble.com> Message-ID: Hi, > However I cannot figure out or see anywhere in these logs the *RR channel > request (RACH) packet*. Does GSMTAP or OsmocomBB actually capture the RR > channel request or am I missing something here?? No. RACH are not nornal bursts. They're not captured nor forwarded to wireshark (which can't display them anyway). Cheers, Sylvain From msokolov at ivan.Harhan.ORG Wed Aug 14 20:10:19 2013 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Wed, 14 Aug 2013 20:10:19 GMT Subject: Calypso/Iota/Rita chip recommendations Message-ID: <1308142010.AA03225@ivan.Harhan.ORG> Hello fellow Calypso phone hackers, Not having found an already-existing Calypso phone that is exactly to my liking (of the ones supported by OsmocomBB, the Pirelli comes closest to my ideal, but even that one has a few things I don't like, and most important of all, the availability of these phones on the market has already shrunk down to zilch - so the day is near when it will be just as legendary-unobtainium as the TSM30), I am setting out to build my own. I am setting out to design and build a new Calypso/Iota/Rita phone, one that will be specifically designed to run Free Software as its firmware: either OsmocomBB or FreeCalypso (my own personal alternative free GSM firmware implementation), up to each user's individual choice. My design will be a phone, not a modem (i.e., complete with the essential UI elements, as in LCD and keypad), and it will be a dumb/plain/feature phone, i.e., the Calypso will be the main/sole CPU - not a smartphone like Openmoko etc. Before I tackle the difficult problem of either making a new plastic case or choosing some existing one, I will start out by building a bare GSM development board - basically a complete phone sans case, built on a non-form-factor-controlled PCB. This development board will probably end up being very similar to the one which Harard Welte has announced here a little over a year ago, but with one major difference: *all* hardware design source files (as in schematic, BOM and PCB layout source) will be openly released, with absolutely nothing withheld, and in fact the development itself will take place in a public source control repository. Therefore, regardless of whether I succeed or fail in the ultimate goal of producing a complete phone packaged in a plastic case, there will be an Open Source Hardware design for a working Calypso GSM board which others will be able to use as a starting point - something that wouldn't be possible (or at least less convenient) with Harald's PDF-schematics-only version. However, the above vaporware announcement is not the real purpose of my post. Instead, I am currently in the negotiations with several Chinese sellers of Calypso/Iota/Rita/etc chips, and I'm soliciting advice on exactly which variant of each chip I should use: * The Calypso chip in both GTA02 and Pirelli DP-L10 (the two existing designs I use as references to be copied whenever it makes sense) is PD751992AZHH. I can easily get this exact part, but I can also get ones with GHH or AGHH suffixes. I'm venturing a guess in that the A seems to go with the 751992 number, i.e., it's part of the die revision, and as to the difference between GHH and ZHH, I'm guessing that it's the RoHS difference: I'm guessing that GHH has balls made of real SnPb solder, whereas ZHH has the "lead-free solder" junk substituted instead. Because I'm very fortunate to NOT live in the EU or anywhere near, I'm not subject to any EU-nian laws like the RoHS idiocy, and I generally prefer to use real SnPb solder whenever possible. So I wonder: can someone confirm if indeed PD751992AGHH is the exact same Calypso chip as the PD751992AZHH used in the GTA02 and Pirelli phones, but with real non-RoHS solder balls instead, or is it something different? * Which Iota variant is better: TWL3014 or TWL3025? I'm thinking TWL3025, reasoning that it being newer probably means having some internal bugfixes or minor improvements, but perhaps the older TWL3014 is better instead? * As to the Rita, the base part number appears to be TRF6151C in all phones currently supported by OsmocomBB, so I'm sticking with this base part number. But there are additional suffixes after the 'C' in that P/N - would anyone happen to know what these suffixes mean, and which variant I should use? * For the RF PA, I see that the GTA02 uses RF3166 from RF Micro Devices (one of Harald Welte's posts regarding his planned Calypso board also mentioned him planning to use the same PA), whereas the Pirelli and most other feature phones supported by OsmocomBB tend to use Skyworks parts instead. Which is better? I'm currently leaning toward the RF3166, but if someone has a recommendation that is actually backed by some knowledge/reason rather than just a guess like mine, I'll listen. :-) * If I do go with the RF3166, any idea as to what the different suffix versions are? TIA for any input, SF From peter at stuge.se Wed Aug 14 20:30:21 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 14 Aug 2013 22:30:21 +0200 Subject: Calypso/Iota/Rita chip recommendations In-Reply-To: <1308142010.AA03225@ivan.Harhan.ORG> References: <1308142010.AA03225@ivan.Harhan.ORG> Message-ID: <20130814203021.23394.qmail@stuge.se> Michael Spacefalcon wrote: > TIA for any input, It would be neat if you choose a filter part with a footprint that can also accomodate a balun more easily than in the Compal phones, so that a phone could be assembled "either way". //Peter From 246tnt at gmail.com Wed Aug 14 20:59:55 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 14 Aug 2013 22:59:55 +0200 Subject: Calypso/Iota/Rita chip recommendations In-Reply-To: <1308142010.AA03225@ivan.Harhan.ORG> References: <1308142010.AA03225@ivan.Harhan.ORG> Message-ID: > TIA for any input, And why exactly should we help you when you publicly stated [1] that you'd rather shoot us then yourself than help us in any way ... Cheers, Sylvain From 246tnt at gmail.com Wed Aug 14 21:11:07 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 14 Aug 2013 23:11:07 +0200 Subject: Calypso/Iota/Rita chip recommendations In-Reply-To: References: <1308142010.AA03225@ivan.Harhan.ORG> Message-ID: >> TIA for any input, > > And why exactly should we help you when you publicly stated [1] that > you'd rather shoot us then yourself than help us in any way ... [1] http://lists.openmoko.org/pipermail/community/2012-March/066565.html From peter at stuge.se Wed Aug 14 21:20:51 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 14 Aug 2013 23:20:51 +0200 Subject: Calypso/Iota/Rita chip recommendations In-Reply-To: References: <1308142010.AA03225@ivan.Harhan.ORG>

Message-ID: <20130814212051.1762.qmail@stuge.se> Sylvain Munaut wrote: > > And why exactly should we help you when you publicly stated [1] that > > you'd rather shoot us then yourself than help us in any way ... > > [1] http://lists.openmoko.org/pipermail/community/2012-March/066565.html Not very neat. //Peter From msokolov at ivan.Harhan.ORG Wed Aug 14 21:01:16 2013 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Wed, 14 Aug 2013 21:01:16 GMT Subject: Calypso/Iota/Rita chip recommendations Message-ID: <1308142101.AA03416@ivan.Harhan.ORG> Peter Stuge wrote: > It would be neat if you choose a filter part with a footprint that > can also accomodate a balun more easily than in the Compal phones, Actually my hope is to build a quad-band phone (unlike the dual- or tri-band ones we have so far) by copying this reference design from TI: ftp://ftp.ifctf.org/pub/GSM/Calypso/Leonardo_plus_quadband_schem.pdf [The above PDF came from one of the Chinese sites; the /pub/GSM directory of my FTP site above is my own sort of mini-Wikileaks for all things dealing with the Calypso and related things - I encourage everyone to check out the collection of goodies which I've accumulated so far, and which only keeps growing. :-)] As you can see on that schematic, instead of using separate antenna switch and Rx SAW filter parts, the Leonardo reference boards used integrated RF front-end modules - in the case of the quad-band Leonardo Plus, it's a quad-band RF FEM that works perfectly with the Rita. The specific part on that Leonardo+ board seems to be Epcos M034F. A quick search for that part hasn't shown up any availability, but then it was only a very quick search, and even if that specific part isn't available, I reason that there must be functional equivalents from other manufacturers. > so that a phone could be assembled "either way". You mean a filterless sniffer version? I have to admit that sniffing and other GSM hacking aren't really my areas of interest - instead all I want is a 100% "normal" cellphone, but with just one difference: running software/firmware whose full source is physically available (be it legal or otherwise) for the exercise of the Four Freedoms defined by the FSF, as a moral requirement. SF From peter at stuge.se Wed Aug 14 21:17:28 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 14 Aug 2013 23:17:28 +0200 Subject: Calypso/Iota/Rita chip recommendations In-Reply-To: <1308142101.AA03416@ivan.Harhan.ORG> References: <1308142101.AA03416@ivan.Harhan.ORG> Message-ID: <20130814211728.1055.qmail@stuge.se> Michael Spacefalcon wrote: > Actually my hope is to build a quad-band phone That would be neat too. > > so that a phone could be assembled "either way". > > You mean a filterless sniffer version? I was thinking about phone-as-BTS, but same principle, no (or just the appropriate) filters. //Peter From msokolov at ivan.Harhan.ORG Wed Aug 14 21:40:45 2013 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Wed, 14 Aug 2013 21:40:45 GMT Subject: Calypso/Iota/Rita chip recommendations Message-ID: <1308142140.AA03514@ivan.Harhan.ORG> Sylvain Munaut <246tnt at gmail.com> wrote: > And why exactly should we help you when you publicly stated [1] that > you'd rather shoot us then yourself > [1] http://lists.openmoko.org/pipermail/community/2012-March/066565.html A little clarification is in order: * In my past negative interactions with certain individuals who have previously served as employees or contractors of Openmoko-Inc and who currently serve as lead developers of OsmocomBB, the crux of the dispute was those individuals' unwillingness to share with all Humanity (yes, *all Humanity*, *not* "me" - I could be dead tomorrow and nothing will change) those COFF object files with symbolic information which Om-Inc had received from TI, and/or their voluntary choice to live and/or accept voluntary citizenship in a country that deems such sharing to be illegal - obviously a voluntary choice which I have NOT made. * There has been one major change in the year and a half since that post of mine quoted by Sylvain - I have discovered this: http://scottn.us/downloads/peek/ [In case ScottN, whoever he is, takes the ware down from his website, it's already archived on my mini-Wikileaks at ftp.ifctf.org/pub/GSM/LoCosto - but for as long as ScottN's copy is up, it should be much faster.] The discovery of the above source (which is almost complete source with very little in object-only form) makes it now unnecessary for me to sacrifice my life in a gunfire exchange with German or Russian police in order to free Openmoko's COFF objects - I'm pretty confident in my ability to recreate something very similar, but full-source from this recently discovered "peek" ware and other more recently discovered leaks, also on my FTP site. > than help us in any way ... It is true that I have chosen to use a different Free Software GSM stack (plus UI etc) implementation for my personal use, hence any contributions from me to the software side of the OsmocomBB project are indeed unlikely. However, I am hoping that the project to build new free phone hardware can be done as a joint project between the two camps. The hardware design files will be free for anyone to download and do with as s/he pleases, and obviously each user is free to run whatever software s/he likes: OsmocomBB, FreeCalypso, or some 3rd or 4th or other choice that may exist in the future. SF From noloader at gmail.com Wed Aug 14 21:51:55 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 14 Aug 2013 17:51:55 -0400 Subject: Calypso/Iota/Rita chip recommendations In-Reply-To: <1308142140.AA03514@ivan.Harhan.ORG> References: <1308142140.AA03514@ivan.Harhan.ORG> Message-ID: On Wed, Aug 14, 2013 at 5:40 PM, Michael Spacefalcon < msokolov at ivan.harhan.org> wrote: > ... > > ... and/or their voluntary > choice to live and/or accept voluntary citizenship in a country that > deems such sharing to be illegal - obviously a voluntary choice which > I have NOT made. > Are you serious? You're claiming (or stating) that someone should move to a country which better aligns with your view of the world? Surely this can't be on-topic..... (Sorry about the fodder). Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From msokolov at ivan.Harhan.ORG Wed Aug 14 22:00:02 2013 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Wed, 14 Aug 2013 22:00:02 GMT Subject: Calypso/Iota/Rita chip recommendations Message-ID: <1308142200.AA03579@ivan.Harhan.ORG> Peter Stuge wrote: > > Actually my hope is to build a quad-band phone > That would be neat too. > [...] > I was thinking about phone-as-BTS, but same principle, no > (or just the appropriate) filters. Unfortunately these two goals (quad-band support on the one hand, and filter hackability on the other hand) seem to be in conflict. It seems to me that trying to build a quad-band phone using separate antenna switch and Rx SAW filter components would be very messy, probably too messy for an RF-clean PCB layout - hence necessitating the use of an integrated RF front-end part that has all that mess hidden inside. (See ftp.ifctf.org/pub/GSM/Calypso/M034F.pdf for an example of wha I mean.) But using an integrated RF FEM like that M034F would surely preclude the possibility of filter hacking... Once again, my goal is to produce a Totally Free Phone for everyday use in one's pocket/purse, not GSM hacking - and I reason I must not be the only person on this list who desires such; I reason that there must be other lurkers on this list who watch with frustration as the years go by, there are all kinds of hacks made, but virtually zero progress toward an end-user-usable Free phone. It's obvious that OsmocomBB and FreeCalypso will always be two separate projects: the former focused on GSM hacking and security research, the latter on everyday-phone end-user needs. All I'm hoping for is that the two projects could be at least somewhat amicable, and cooperate in things like amassing hardware knowledge - rather than be all-out hostile. SF From elke_robert at gmx.at Thu Aug 15 14:48:51 2013 From: elke_robert at gmx.at (robert) Date: Thu, 15 Aug 2013 14:48:51 +0000 (UTC) Subject: osmocombb / mobile app ... sms without simcard Message-ID: hello! how is it possible to send a sms without a sim-card in my C123? with simcard its possible ... :-) how to use "sim testcard 1"? From elke_robert at gmx.at Thu Aug 15 14:59:05 2013 From: elke_robert at gmx.at (=?UTF-8?Q?=22Robert_K=C3=B6berl=22?=) Date: Thu, 15 Aug 2013 16:59:05 +0200 (CEST) Subject: howto use osmocom / mobile app without a sim-card Message-ID: An HTML attachment was scrubbed... URL: From Max.Suraev at fairwaves.ru Mon Aug 19 15:14:38 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Mon, 19 Aug 2013 17:14:38 +0200 Subject: howto use osmocom / mobile app without a sim-card In-Reply-To: References: Message-ID: <5212365E.3000108@fairwaves.ru> 15.08.2013 16:59, "Robert K?berl" ?????: > hello! > > how can i "simulate" a simcard to send a sms with my C123? > i want to do that without a simcard ... with a simcard it works ... :-) > > please help The thing is - simcard is required by BTS, not by osmocom itself, so if you have your own network (with openbts or openbsc) than it's possible to use "test" or "virtual" sim card. Otherwise it won't work. -- best regards, Max, http://fairwaves.ru From gandguladze at hotmail.com Thu Aug 22 08:03:34 2013 From: gandguladze at hotmail.com (George Andguladze) Date: Thu, 22 Aug 2013 08:03:34 +0000 Subject: Uplink sniffing Message-ID: Dear all, I was wondering if uplink sniffing is enabled by default in latest firmware as file "osmocom-bb/src/target/firmware/layer1/prim_sniff.c" has been modified and does not hold "#if 0" bit at line 288 anymore. Thanks, George Andguladze -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Tue Aug 27 09:06:06 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Tue, 27 Aug 2013 02:06:06 -0700 (PDT) Subject: UI work - qemu and key repeating Message-ID: <1377594366.54317.YahooMailNeo@web121004.mail.ne1.yahoo.com> Was wondering if anyone has tried to use qemu to make a device emulator? I'm writing some UI/firmware and it seems like it might be a nice way to iterate on code. Also was thinking I would need to rework keypad.c so that I can get key hold/repeat events since I want to know when a key is being held down at some fairly short interval. Any suggestions/previous work/cautions? Thanks, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From ubuntugirl2013 at gmail.com Tue Aug 27 18:29:44 2013 From: ubuntugirl2013 at gmail.com (ubuntugirl) Date: Tue, 27 Aug 2013 11:29:44 -0700 Subject: UI work - qemu and key repeating In-Reply-To: <1377594366.54317.YahooMailNeo@web121004.mail.ne1.yahoo.com> References: <1377594366.54317.YahooMailNeo@web121004.mail.ne1.yahoo.com> Message-ID: On 8/27/13, Craig Comstock wrote: > I'm writing some UI/firmware [...] That sounds neat... are you doing it in some visible git repository perchance? Kim From craig_comstock at yahoo.com Thu Aug 29 15:34:05 2013 From: craig_comstock at yahoo.com (Craig Comstock) Date: Thu, 29 Aug 2013 08:34:05 -0700 (PDT) Subject: UI work - qemu and key repeating In-Reply-To: References: Message-ID: <1377790445.23520.YahooMailNeo@web121003.mail.ne1.yahoo.com> > > I'm writing some UI/firmware [...] > That sounds neat... are you doing it in some visible git repository perchance? I'm just hacking on layer1/main.c right now. Not even sure I would put in a repo since I want to implement some form of t-9 character and word fanciness. Maybe I could make that a module or think of an open-source/free paradigm for entering text w/ the keypad. http://www.google.com/patents?id=PmgCAAAAEBAJ (T9) http://www.google.com/patents/US3967273 (funny bell labs method using two key presses always) (the list goes on and on I think...) My thinking is that I might start with this hacked layer1 and gradually try to bring bits of mobile into the firmware/ui. Also just wanting to fiddle around with how the phone will "feel" with a console interface. aka UI prototyping. Cheers, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From Max.Suraev at fairwaves.ru Thu Aug 29 15:57:22 2013 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Thu, 29 Aug 2013 17:57:22 +0200 Subject: [PATCH] Improve cell_log Message-ID: <521F6F62.2000309@fairwaves.ru> Hi. Attached are set of patches with small improvements to cell_log, si_dump and mcc/mnc printers. Please review and merge if code is ok. -- best regards, Max, http://fairwaves.ru From Max.Suraev at fairwaves.ru Thu Aug 29 15:47:56 2013 From: Max.Suraev at fairwaves.ru (Max) Date: Thu, 29 Aug 2013 17:47:56 +0200 Subject: [PATCH 1/4] Comment out print duplicating debug output. Message-ID: --- src/host/layer23/src/common/l1ctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/host/layer23/src/common/l1ctl.c b/src/host/layer23/src/common/l1ctl.c index 91bab89..80aa4df 100644 --- a/src/host/layer23/src/common/l1ctl.c +++ b/src/host/layer23/src/common/l1ctl.c @@ -244,7 +244,7 @@ static int rx_ph_data_ind(struct osmocom_ms *ms, struct msgb *msg) } if (dl->fire_crc >= 2) { -printf("Dropping frame with %u bit errors\n", dl->num_biterr); +//printf("Dropping frame with %u bit errors\n", dl->num_biterr); LOGP(DL1C, LOGL_NOTICE, "Dropping frame with %u bit errors\n", dl->num_biterr); msgb_free(msg); -- 1.8.1.2 --------------000206000400030101050401 Content-Type: text/x-patch; name="0002-Declare-constant-parameters-as-constant.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0002-Declare-constant-parameters-as-constant.patch" From Max.Suraev at fairwaves.ru Thu Aug 29 15:49:02 2013 From: Max.Suraev at fairwaves.ru (Max) Date: Thu, 29 Aug 2013 17:49:02 +0200 Subject: [PATCH 2/4] Declare constant parameters as constant. Message-ID: --- src/host/layer23/include/osmocom/bb/common/networks.h | 4 ++-- src/host/layer23/src/common/networks.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/common/networks.h b/src/host/layer23/include/osmocom/bb/common/networks.h index d34f316..9311f6f 100644 --- a/src/host/layer23/include/osmocom/bb/common/networks.h +++ b/src/host/layer23/include/osmocom/bb/common/networks.h @@ -17,8 +17,8 @@ const char *gsm_get_mcc(uint16_t mcc); const char *gsm_get_mnc(uint16_t mcc, uint16_t mnc); const char *gsm_imsi_mcc(char *imsi); const char *gsm_imsi_mnc(char *imsi); -const uint16_t gsm_input_mcc(char *string); -const uint16_t gsm_input_mnc(char *string); +const uint16_t gsm_input_mcc(const char *string); +const uint16_t gsm_input_mnc(const char *string); #endif /* _NETWORKS_H */ diff --git a/src/host/layer23/src/common/networks.c b/src/host/layer23/src/common/networks.c index ad2caa6..0bb143f 100644 --- a/src/host/layer23/src/common/networks.c +++ b/src/host/layer23/src/common/networks.c @@ -1852,7 +1852,7 @@ const char *gsm_print_mnc(uint16_t mnc) return string; } -const uint16_t gsm_input_mcc(char *string) +const uint16_t gsm_input_mcc(const char *string) { uint16_t mcc; @@ -1873,7 +1873,7 @@ const uint16_t gsm_input_mcc(char *string) return mcc; } -const uint16_t gsm_input_mnc(char *string) +const uint16_t gsm_input_mnc(const char *string) { uint16_t mnc = 0; -- 1.8.1.2 --------------000206000400030101050401 Content-Type: text/x-patch; name="0003-Make-SI-printing-more-flexible.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0003-Make-SI-printing-more-flexible.patch" From Max.Suraev at fairwaves.ru Thu Aug 29 15:49:42 2013 From: Max.Suraev at fairwaves.ru (Max) Date: Thu, 29 Aug 2013 17:49:42 +0200 Subject: [PATCH 3/4] Make SI printing more flexible. Message-ID: --- .../layer23/include/osmocom/bb/common/sysinfo.h | 3 ++ src/host/layer23/src/common/sysinfo.c | 46 +++++++++++++--------- 2 files changed, 30 insertions(+), 19 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/common/sysinfo.h b/src/host/layer23/include/osmocom/bb/common/sysinfo.h index f843f27..f0af7ba 100644 --- a/src/host/layer23/include/osmocom/bb/common/sysinfo.h +++ b/src/host/layer23/include/osmocom/bb/common/sysinfo.h @@ -125,6 +125,9 @@ uint8_t gsm_refer_pcs(uint16_t arfcn, struct gsm48_sysinfo *s); int gsm48_sysinfo_dump(struct gsm48_sysinfo *s, uint16_t arfcn, void (*print)(void *, const char *, ...), void *priv, uint8_t *freq_map); +int gsm48_sysinfo_dump_ext(struct gsm48_sysinfo *s, uint16_t arfcn, + void (*print)(void *, const char *, ...), void *priv, + uint8_t *freq_map, uint8_t no_map, uint8_t print_stat); int gsm48_decode_lai(struct gsm48_loc_area_id *lai, uint16_t *mcc, uint16_t *mnc, uint16_t *lac); int gsm48_decode_chan_h0(struct gsm48_chan_desc *cd, uint8_t *tsc, diff --git a/src/host/layer23/src/common/sysinfo.c b/src/host/layer23/src/common/sysinfo.c index b42bd65..3892d1b 100644 --- a/src/host/layer23/src/common/sysinfo.c +++ b/src/host/layer23/src/common/sysinfo.c @@ -68,40 +68,46 @@ uint8_t gsm_refer_pcs(uint16_t arfcn, struct gsm48_sysinfo *s) } int gsm48_sysinfo_dump(struct gsm48_sysinfo *s, uint16_t arfcn, - void (*print)(void *, const char *, ...), void *priv, uint8_t *freq_map) + void (*print)(void *, const char *, ...), void *priv, uint8_t *freq_map) +{ + return gsm48_sysinfo_dump_ext(s, arfcn, print, priv, freq_map, 0, 1); +} + +int gsm48_sysinfo_dump_ext(struct gsm48_sysinfo *s, uint16_t arfcn, + void (*print)(void *, const char *, ...), void *priv, uint8_t *freq_map, uint8_t no_map, uint8_t print_stat) { char buffer[81]; int i, j, k, index; int refer_pcs = gsm_refer_pcs(arfcn, s); - /* available sysinfos */ - print(priv, "ARFCN = %s channels 512+ refer to %s\n", - gsm_print_arfcn(arfcn), - (refer_pcs) ? "PCS (1900)" : "DCS (1800)"); - print(priv, "Available SYSTEM INFORMATIONS ="); - if (s->si1) + if (print_stat) {/* available sysinfos */ + print(priv, "ARFCN = %s channels 512+ refer to %s\n", + gsm_print_arfcn(arfcn), + (refer_pcs) ? "PCS (1900)" : "DCS (1800)"); + print(priv, "Available SYSTEM INFORMATIONS ="); + if (s->si1) print(priv, " 1"); - if (s->si2) + if (s->si2) print(priv, " 2"); - if (s->si2bis) + if (s->si2bis) print(priv, " 2bis"); - if (s->si2ter) + if (s->si2ter) print(priv, " 2ter"); - if (s->si3) + if (s->si3) print(priv, " 3"); - if (s->si4) + if (s->si4) print(priv, " 4"); - if (s->si5) + if (s->si5) print(priv, " 5"); - if (s->si5bis) + if (s->si5bis) print(priv, " 5bis"); - if (s->si5ter) + if (s->si5ter) print(priv, " 5ter"); - if (s->si6) + if (s->si6) print(priv, " 6"); - print(priv, "\n"); - print(priv, "\n"); - + print(priv, "\n"); + print(priv, "\n"); + } /* frequency list */ j = 0; k = 0; for (i = 0; i < 1024; i++) { @@ -173,6 +179,8 @@ int gsm48_sysinfo_dump(struct gsm48_sysinfo *s, uint16_t arfcn, } print(priv, "\n"); + if (no_map) return 0; + /* frequency map */ for (i = 0; i < 1024; i += 64) { sprintf(buffer, " %3d ", i); -- 1.8.1.2 --------------000206000400030101050401 Content-Type: text/x-patch; name="0004-Add-filtering-and-additional-information-printing-to.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0004-Add-filtering-and-additional-information-printing-to.pa"; filename*1="tch" From Max.Suraev at fairwaves.ru Thu Aug 29 15:50:09 2013 From: Max.Suraev at fairwaves.ru (Max) Date: Thu, 29 Aug 2013 17:50:09 +0200 Subject: [PATCH 4/4] Add filtering and additional information printing to cell_log. Message-ID: --- src/host/layer23/src/misc/app_cell_log.c | 53 ++++++++++++++++++++++++++------ src/host/layer23/src/misc/cell_log.c | 52 +++++++++++++++++++++---------- 2 files changed, 78 insertions(+), 27 deletions(-) diff --git a/src/host/layer23/src/misc/app_cell_log.c b/src/host/layer23/src/misc/app_cell_log.c index a7f42c3..1f69c31 100644 --- a/src/host/layer23/src/misc/app_cell_log.c +++ b/src/host/layer23/src/misc/app_cell_log.c @@ -27,6 +27,7 @@ #include #include +#include #include #include #include @@ -45,6 +46,7 @@ extern uint16_t (*band_range)[][2]; char *logname = "/var/log/osmocom.log"; int RACH_MAX = 2; +uint16_t MCC = 0, MNC = 0, QUIET_PRINT = 0, PRINT_XTRA = 0, SCAN_ONCE = 0; int _scan_work(struct osmocom_ms *ms) { @@ -94,16 +96,21 @@ static int l23_cfg_supported() static int l23_getopt_options(struct option **options) { static struct option opts [] = { - {"logfile", 1, 0, 'l'}, - {"rach", 1, 0, 'r'}, - {"no-rach", 1, 0, 'n'}, + {"logfile", required_argument, NULL, 'l'}, + {"rach", required_argument, NULL, 'r'}, + {"no-rach", no_argument, NULL, 'n'}, #ifdef _HAVE_GPSD - {"gpsd-host", 1, 0, 'g'}, - {"gpsd-port", 1, 0, 'p'}, + {"gpsd-host", required_argument, NULL, 'g'}, + {"gpsd-port", required_argument, NULL, 'p'}, #endif - {"gps", 1, 0, 'g'}, - {"baud", 1, 0, 'b'}, - {"arfcns", 1, 0, 'A'} + {"gps", required_argument, NULL, 'g'}, + {"baud", required_argument, NULL, 'b'}, + {"arfcns", required_argument, NULL, 'A'}, + {"mcc", required_argument, NULL, 'c'}, + {"mnc", required_argument, NULL, 'm'}, + {"quiet", no_argument, NULL, 'q'}, + {"extra", no_argument, NULL, 'x'}, + {"once", no_argument, NULL, 'o'} }; *options = opts; @@ -162,7 +169,11 @@ static int l23_cfg_print_help() printf(" -f --gps DEVICE /dev/ttyACM0. GPS serial device.\n"); printf(" -b --baud BAUDRAT The baud rate of the GPS device\n"); printf(" -A --arfcns ARFCNS The list of arfcns to be monitored\n"); - + printf(" -c --mcc 000 The MCC to look for.\n"); + printf(" -m --mnc 00 The MNC to look for.\n"); + printf(" -q --quiet Do not print additional information.\n"); + printf(" -x --extra Print additional info from SI.\n"); + printf(" -o --once Exit after first scan is complete.\n"); return 0; } @@ -180,6 +191,15 @@ static int l23_cfg_handle(int c, const char *optarg) case 'n': RACH_MAX = 0; break; + case 'q': + QUIET_PRINT = 1; + break; + case 'x': + PRINT_XTRA = 1; + break; + case 'o': + SCAN_ONCE = 1; + break; case 'g': #ifdef _HAVE_GPSD snprintf(g.gpsd_host, ARRAY_SIZE(g.gpsd_host), "%s", optarg); @@ -224,6 +244,19 @@ static int l23_cfg_handle(int c, const char *optarg) parse_band_range((char*)optarg); printf("New frequencies range: %s\n", print_band_range(*band_range, buf, sizeof(buf))); break; + case 'c': + MCC = atoi(optarg); + if (GSM_INPUT_INVALID == MCC) MCC = 0; + else LOGP(DGPS, LOGL_INFO, "Target MCC is %s (%s)\n", gsm_print_mcc(MCC), gsm_get_mcc(MCC)); + break; + case 'm': + MNC = gsm_input_mnc(optarg); + if (GSM_INPUT_INVALID == MNC) MNC = 0; + if (0 != MCC) + LOGP(DGPS, LOGL_INFO, "Target MNC is %s (%s)\n", gsm_print_mnc(MNC), gsm_get_mnc(MCC, MNC)); + else + LOGP(DGPS, LOGL_INFO, "Target MNC is %s\n", gsm_print_mnc(MNC)); + break; } return 0; @@ -234,7 +267,7 @@ cmd_line_error: static struct l23_app_info info = { .copyright = "Copyright (C) 2010 Andreas Eversberg\n", - .getopt_string = "g:p:l:r:nf:b:A:", + .getopt_string = "g:p:l:r:noqxf:b:A:c:m:", .cfg_supported = l23_cfg_supported, .cfg_getopt_opt = l23_getopt_options, .cfg_handle_opt = l23_cfg_handle, diff --git a/src/host/layer23/src/misc/cell_log.c b/src/host/layer23/src/misc/cell_log.c index 7340dcb..8740965 100644 --- a/src/host/layer23/src/misc/cell_log.c +++ b/src/host/layer23/src/misc/cell_log.c @@ -37,6 +37,7 @@ #include #include +#include #include #include #include @@ -78,7 +79,7 @@ static struct pm_info { int8_t rxlev_dbm; } pm[1024]; -static int started = 0; +static int started = 0, measured = 0; static int state; static int8_t min_rxlev_dbm = MIN_RXLEV_DBM; static int sync_count; @@ -89,7 +90,11 @@ static int rach_count; static FILE *logfp = NULL; extern char *logname; extern int RACH_MAX; - +extern uint16_t QUIET_PRINT; +extern uint16_t PRINT_XTRA; +extern uint16_t SCAN_ONCE; +extern uint16_t MCC; +extern uint16_t MNC; static struct gsm48_sysinfo sysinfo; @@ -135,14 +140,17 @@ static void log_time(void) LOGFILE("time %lu\n", now); } -static void log_frame(char *tag, uint8_t *data) +static void si_printer(void *priv, const char *fmt, ...) { - int i; + va_list a; + va_start(a, fmt); + fprintf(priv, fmt, a); + va_end(a); +} - LOGFILE("%s", tag); - for (i = 0; i < 23; i++) - LOGFILE(" %02x", *data++); - LOGFILE("\n"); +static void log_frame(char *tag, uint8_t *data) +{ + LOGFILE("%s %s\n", tag, osmo_hexdump(data, 23)); } static void log_pm(void) @@ -183,6 +191,8 @@ static void log_sysinfo(void) int8_t rxlev_dbm; char ta_str[32] = ""; + if (((0 != MCC) && (s->mcc != MCC)) || ((0 != MNC) && (s->mnc != MNC))) return; + if (log_si.ta != 0xff) sprintf(ta_str, " TA=%d", log_si.ta); @@ -198,20 +208,21 @@ static void log_sysinfo(void) rxlev_dbm = meas->rxlev / meas->frames - 110; LOGFILE("rxlev %d\n", rxlev_dbm); if (s->si1) - log_frame("si1", s->si1_msg); + log_frame("si1", s->si1_msg); if (s->si2) - log_frame("si2", s->si2_msg); + log_frame("si2", s->si2_msg); if (s->si2bis) - log_frame("si2bis", s->si2b_msg); + log_frame("si2bis", s->si2b_msg); if (s->si2ter) - log_frame("si2ter", s->si2t_msg); + log_frame("si2ter", s->si2t_msg); if (s->si3) - log_frame("si3", s->si3_msg); + log_frame("si3", s->si3_msg); if (s->si4) - log_frame("si4", s->si4_msg); + log_frame("si4", s->si4_msg); if (log_si.ta != 0xff) LOGFILE("ta %d\n", log_si.ta); - + if (PRINT_XTRA) + gsm48_sysinfo_dump_ext(s, s->arfcn, si_printer, logfp, NULL, 1, 0); LOGFILE("\n"); LOGFLUSH(); } @@ -337,8 +348,10 @@ static void start_sync(void) return; } pm[arfcn].flags |= INFO_FLG_SYNC; - LOGP(DSUM, LOGL_INFO, "Sync ARFCN %d (rxlev %d, %d syncs left)%s\n", - arfcn, pm[arfcn].rxlev_dbm, sync_count--, dist_str); + if (!QUIET_PRINT) { + LOGP(DSUM, LOGL_INFO, "Sync ARFCN %d (rxlev %d, %d syncs left)%s\n", + arfcn, pm[arfcn].rxlev_dbm, sync_count--, dist_str); + } memset(&sysinfo, 0, sizeof(sysinfo)); sysinfo.arfcn = arfcn; state = SCAN_STATE_SYNC; @@ -351,12 +364,17 @@ static void start_pm(void) { uint16_t from, to; + if (measured && SCAN_ONCE) { + l23_app_exit(NULL); + exit(0); + } state = SCAN_STATE_PM; from = (*band_range)[pm_index][0]; to = (*band_range)[pm_index][1]; if (from == 0 && to == 0) { LOGP(DSUM, LOGL_INFO, "Measurement done\n"); + measured = 1; pm_gps_valid = g.enable && g.valid; if (pm_gps_valid) geo2space(&pm_gps_x, &pm_gps_y, &pm_gps_z, -- 1.8.1.2 --------------000206000400030101050401--