From zero-kelvin at gmx.de Tue May 11 11:01:02 2010 From: zero-kelvin at gmx.de (dexter) Date: Tue, 11 May 2010 13:01:02 +0200 Subject: Greetings In-Reply-To: <20100410072605.GA14576@prithivi.gnumonks.org> References: <20100409133458.GA20983@vogel.cx> <20100410072605.GA14576@prithivi.gnumonks.org> Message-ID: <4BE938EE.9050707@gmx.de> Hi Folks. I only wanted to let you know that i am still alive ;-) I am currently very busy with my industrial practical so i have not much time at all but... Currently i am implementing an easy to use API to the basic simcard functions. After that i will build an API on top of this that handles the sim requests in an atomic way to make it easy to give other processes random access to the sim through a message queue. regards. Philipp From squalyl at gmail.com Tue May 11 12:58:44 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Tue, 11 May 2010 14:58:44 +0200 Subject: Greetings In-Reply-To: <4BE938EE.9050707@gmx.de> References: <20100409133458.GA20983@vogel.cx> <20100410072605.GA14576@prithivi.gnumonks.org> <4BE938EE.9050707@gmx.de> Message-ID: Hi dexter, Someone (IIRC, ) suggested to implement the SIM access profile. Do you know that? Is it a generic protocol we could implement over the serial line (to access the real sim in the phone) and/or a function call interface (to access a sim through PCSC) ? Regards Sebastien On Tue, May 11, 2010 at 1:01 PM, dexter wrote: > Hi Folks. > > I only wanted to let you know that i am still alive ;-) I am currently very > busy with my industrial practical so i have not much time at all but... > > Currently i am implementing an easy to use API to the basic simcard > functions. After that i will build an API on top of this that handles the > sim requests in an atomic way to make it easy to give other processes random > access to the sim through a message queue. > > regards. > Philipp > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zero-kelvin at gmx.de Thu May 13 15:10:29 2010 From: zero-kelvin at gmx.de (dexter) Date: Thu, 13 May 2010 17:10:29 +0200 Subject: Greetings In-Reply-To: References: <20100409133458.GA20983@vogel.cx> <20100410072605.GA14576@prithivi.gnumonks.org> <4BE938EE.9050707@gmx.de> Message-ID: <4BEC1665.2060007@gmx.de> Hello S?bastien. > Someone (IIRC, > ) suggested to implement the > SIM access profile. Do you know that? Is it a generic protocol we > could implement over the serial line (to access the real sim in the > phone) and/or a function call interface (to access a sim through PCSC) ? Why? I don't see any advantages in this and i do not have the know how to implement SIM access profile. I think it is enough if we have our own simple simcard API that works for us. We should not overengineer this. Regards. Philipp From squalyl at gmail.com Thu May 13 16:28:16 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Thu, 13 May 2010 18:28:16 +0200 Subject: Greetings In-Reply-To: <4BEC1665.2060007@gmx.de> References: <20100409133458.GA20983@vogel.cx> <20100410072605.GA14576@prithivi.gnumonks.org> <4BE938EE.9050707@gmx.de> <4BEC1665.2060007@gmx.de> Message-ID: Hello, I have to say that I agree with you. I was just reporting the idea I heard about :-) Regards Sebastien On Thu, May 13, 2010 at 5:10 PM, dexter wrote: > Hello S?bastien. > >> Someone (IIRC, > kevredon at mail.tsaitgaist.info>> ) suggested to implement the SIM access >> profile. Do you know that? Is it a generic protocol we could implement over >> the serial line (to access the real sim in the phone) and/or a function call >> interface (to access a sim through PCSC) ? >> > Why? I don't see any advantages in this and i do not have the know how to > implement SIM access profile. I think it is enough if we have our own simple > simcard API that works for us. We should not overengineer this. > > Regards. > Philipp > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Thu May 13 16:36:31 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 13 May 2010 18:36:31 +0200 Subject: Greetings In-Reply-To: <4BEC1665.2060007@gmx.de> References: <20100409133458.GA20983@vogel.cx> <20100410072605.GA14576@prithivi.gnumonks.org> <4BE938EE.9050707@gmx.de> <4BEC1665.2060007@gmx.de> Message-ID: <20100513163631.12076.qmail@stuge.se> dexter wrote: >> suggested to implement the SIM access profile. > Why? I don't see any advantages in this There's at least one significant advantage; it becomes trivial and convenient to use a real SIM in another phone on your desk. > and i do not have the know how to implement SIM access profile. There was a link to the (pretty short) spec in the email thread. > I think it is enough if we have our own simple simcard API that > works for us. We should not overengineer this. At least I think the SIM access profile is a good idea. I haven't looked into detail, but maybe it's actually similar to the simple API? //Peter From nibbler at ccc.de Fri May 14 03:19:59 2010 From: nibbler at ccc.de (nibbler) Date: Fri, 14 May 2010 05:19:59 +0200 Subject: Greetings In-Reply-To: <20100513163631.12076.qmail@stuge.se> References: <20100409133458.GA20983@vogel.cx> <20100410072605.GA14576@prithivi.gnumonks.org> <4BE938EE.9050707@gmx.de> <4BEC1665.2060007@gmx.de> <20100513163631.12076.qmail@stuge.se> Message-ID: <20100514051959.57298f44@minime.club.berlin.ccc.de> On Thu, 13 May 2010 18:36:31 +0200 Peter Stuge wrote: > dexter wrote: > >> suggested to implement the SIM access profile. > > Why? I don't see any advantages in this Did you have a look at the spec? http://nibbler.de/attic/bluetooth/profile%20SAP%20v1.1.pdf See page 23 and 32. It basically implements a minimalistic remote card reader that forwards APDUs to and from the SIM. All the lower level protocols have already been implemented e.g. in the Linux kernel. While it might indeed be not a thing to implement first, it still looks worth keeping it in mind and interfaces open for a later integration of SAP as a convenient way to access SIMs remotely. cheers, nibbler p.s. don't spread the link as i don't know exactly about the copyright implications of all the bluetooth documents in that folder. I happened to have an account for the SIG document repository thus found it handy to mirror the specification documents which to my knowledge are not publicly available. From squalyl at gmail.com Fri May 14 07:08:35 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Fri, 14 May 2010 09:08:35 +0200 Subject: Greetings In-Reply-To: <20100514051959.57298f44@minime.club.berlin.ccc.de> References: <20100409133458.GA20983@vogel.cx> <20100410072605.GA14576@prithivi.gnumonks.org> <4BE938EE.9050707@gmx.de> <4BEC1665.2060007@gmx.de> <20100513163631.12076.qmail@stuge.se> <20100514051959.57298f44@minime.club.berlin.ccc.de> Message-ID: Hi, Well after seeing the spec, the protocol does not seem too over engineered. These are just messages in byte buffers that can be exchanged over any link, be it bluetooth, serial or struct{} in a function call. So instead of reinventing a wheel that will look like this, why not implement a simplified version of this spec? we only have to implement the messages required for our needs. Regards Sebastien On Fri, May 14, 2010 at 5:19 AM, nibbler wrote: > On Thu, 13 May 2010 18:36:31 +0200 > Peter Stuge wrote: > > > dexter wrote: > > >> suggested to implement the SIM access profile. > > > Why? I don't see any advantages in this > > Did you have a look at the spec? > > http://nibbler.de/attic/bluetooth/profile%20SAP%20v1.1.pdf > > See page 23 and 32. > > It basically implements a minimalistic remote card reader that > forwards APDUs to and from the SIM. All the lower level protocols have > already been implemented e.g. in the Linux kernel. > > While it might indeed be not a thing to implement first, it still looks > worth keeping it in mind and interfaces open for a later integration of > SAP as a convenient way to access SIMs remotely. > > cheers, > nibbler > > p.s. don't spread the link as i don't know exactly about the copyright > implications of all the bluetooth documents in that folder. I happened > to have an account for the SIG document repository thus found it handy > to mirror the specification documents which to my knowledge are not > publicly available. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zero-kelvin at gmx.de Fri May 14 08:17:21 2010 From: zero-kelvin at gmx.de (dexter) Date: Fri, 14 May 2010 10:17:21 +0200 Subject: Greetings In-Reply-To: References: <20100409133458.GA20983@vogel.cx> <20100410072605.GA14576@prithivi.gnumonks.org> <4BE938EE.9050707@gmx.de> <4BEC1665.2060007@gmx.de> <20100513163631.12076.qmail@stuge.se> <20100514051959.57298f44@minime.club.berlin.ccc.de> Message-ID: <4BED0711.3060103@gmx.de> Hi All. > So instead of reinventing a wheel that will look like this, why not > implement a simplified version of this spec? we only have to implement > the messages required for our needs. I think that does not help us much. We need a layer that abstracts the SIM functions to atomic high level functions so that different processes can access the sim randomly (This is not my idea that was haralds idea ;-) As i can see the SAP is hooked to the low level APDU interface. Is there any way to arbitrate the requests? What is when someone from outside selects a file while the mobile already has selected a file and is about to do a read binary for example? Anyway. I have not the time to read and understand the entire SAP spec. If you think that SAP works better for us you are free to continue the work instead of me. I will then concentrate on the SIM driver itsselef - there is much work left to do there and the low level stuff is more that what i am experienced with. Currently we have an APDU interface to the sim. You can send APDUs to the sim and you get the answer and status word back. T=0 protocol is fully implemented. regards. Philipp From laforge at gnumonks.org Sun May 9 09:16:14 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 9 May 2010 11:16:14 +0200 Subject: CECT C3100 / MT6223 (was Re: public project with MTK baseband firmware project) In-Reply-To: <20100419072140.GA2947@devel.wolf> References: <20100412125247.GB19994@prithivi.gnumonks.org> <20100413124039.GA12383@devel.wolf> <20100413152620.GB28773@prithivi.gnumonks.org> <20100419072140.GA2947@devel.wolf> Message-ID: <20100509091614.GE7162@prithivi.gnumonks.org> Hi all, On Mon, Apr 19, 2010 at 07:21:40AM +0000, Wolfgang Spraul wrote: > 5) CECT C3100, ca 20 USD, MT6223CA, MT6139BN, RDA6212+ > > The standard set of 5 test points I seem to find on all MTK phones are PWRKEY, > RX, TX, GND and VBAT. > Beyond that test points are rare. The CECT C3100 had a few small ones right > next to the CPU (but under a soldered shielding case). Might be something > interesting but not sure yet. I've used the PCB layers to trace the JTAG wires. They should be assigned as indicated in the picture at http://en.qi-hardware.com/wiki/File:C3100_testpads_jtag.png The "RTCK" is a bit strange, it is the 'return jtag clock', i.e. you get back the clock that you send to TCK. I haven't tested any of those yet, but maybe at some point during the next weeks... Happy hacking, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mail at t-kindler.de Mon May 10 10:51:15 2010 From: mail at t-kindler.de (Thomas Kindler) Date: Mon, 10 May 2010 12:51:15 +0200 Subject: CECT C3100 / MT6223 (was Re: public project with MTK baseband firmware project) In-Reply-To: <20100509091614.GE7162@prithivi.gnumonks.org> References: <20100412125247.GB19994@prithivi.gnumonks.org> <20100413124039.GA12383@devel.wolf> <20100413152620.GB28773@prithivi.gnumonks.org> <20100419072140.GA2947@devel.wolf> <20100509091614.GE7162@prithivi.gnumonks.org> Message-ID: <4BE7E523.6030803@t-kindler.de> Harald Welte wrote: > The "RTCK" is a bit strange, it is the 'return jtag clock', i.e. you get back > the clock that you send to TCK. It's not so strange -- RTCK can be used to let the target generate the JTAG clock. This way you can debug targets which reduce their clock in power saving states more easily. From Andreas.Eversberg at versatel.de Mon May 3 10:47:59 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 3 May 2010 12:47:59 +0200 Subject: I see cells Message-ID: hi, tests with layer 3 pointed out a problem. when i select a cell, i get updates of system informations, paging requests and immediate assignments. after about half an hour, i get some corrupt frames. i don't know yet what is wrong. 1. is the communication between the layer 1 and layer 2 (over serial link) secure? 2. i must be sure that a message between layers always are: - never get lost (except unit-data or data when connection is aborted) - never are corrupt - received in the order they are sent 3. does layer 1 drop (bcch) frames, if they have biterrors? (as it should do) andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon May 3 11:23:32 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 3 May 2010 13:23:32 +0200 Subject: I see cells In-Reply-To: References: Message-ID: > tests with layer 3 pointed out a problem. when i select a cell, i get > updates of system informations, paging requests and immediate assignments. > after about half an hour, i get some corrupt frames. i don't know yet what > is wrong. There is no timing regulation loop so it will loose alignement after a while. We see that with the racal. Sylvain From laforge at gnumonks.org Mon May 3 12:29:49 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 3 May 2010 14:29:49 +0200 Subject: I see cells In-Reply-To: References: Message-ID: <20100503122949.GC556@prithivi.gnumonks.org> Hi Andreas, On Mon, May 03, 2010 at 12:47:59PM +0200, Andreas.Eversberg wrote: > tests with layer 3 pointed out a problem. when i select a cell, i get > updates of system informations, paging requests and immediate > assignments. > after about half an hour, i get some corrupt frames. i don't know yet what is > wrong. it might be that the oversimplified agc or afc code simply drifts away from the carrier. I've never used layer1 for that long so far, and I doubt somebody else has yet. Sorry :/ > 1. is the communication between the layer 1 and layer 2 (over serial > link) secure? well, as secure as any rs232 line is. there is no checksum on the rs232 (no-parity) and if ther is too much data than we can send at 115200, we have to drop frames. > 2. i must be sure that a message between layers always are: > - never get lost (except unit-data or data when connection is aborted) see above. > - never are corrupt see above (rs232) and below (Um interface) > - received in the order they are sent i don't think we can have re-ordering > 3. does layer 1 drop (bcch) frames, if they have biterrors? (as it > should do) No, it does not. And this is quite intentional. We don't want to simply build a phone, but a generic tool to explore GSM networks and their protocols. E.g. in wireshark it might still be interesting to see such frames, even if they're known to have bit errors. However, what is not intentional, is that the number of bit errors (as computed by the DSP) is not yet passed up in the l1ctl header. This way, the higher layers could drop corrupted frames. This per-burst biterror information should be included in the l1ctl header and passed up. Cheers, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From marco.rust at fokus.fraunhofer.de Mon May 3 13:10:44 2010 From: marco.rust at fokus.fraunhofer.de (Rust, Marco) Date: Mon, 3 May 2010 15:10:44 +0200 Subject: Osmoloader stored in Flash? Message-ID: <70524A4436C03E43A293958B505008B602ABC8EF@EXCHSRV.fokus.fraunhofer.de> Hello, I checkout the prom/loader AND prom/loader-crc part and merged it (perhaps I use git wrong way) When I run the loader with "osmcon -m c123xor" the loader starts but says "Failed to initialize flash". I tried to "romload" it with "-m romload" there only beacons but no valid response from phone. Sending beacon... Sending beacon... got 1 bytes from modem, data looks like: ff got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: ff Sending beacon... Sending beacon... Sending beacon... Sending beacon... 1. Why the flash initialization fails? 2. Is it (currently) possible to run programs (ex. L1test from flash)? I (think I)read all this rom/ram/bootloader stuff. ------------------------- Marco Rust FOKUS - Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31, 10589 Berlin marco.rust at fokus.fraunhofer.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Mon May 3 13:24:08 2010 From: zecke at selfish.org (Holger Freyther) Date: Mon, 03 May 2010 21:24:08 +0800 Subject: Osmoloader stored in Flash? In-Reply-To: <70524A4436C03E43A293958B505008B602ABC8EF@EXCHSRV.fokus.fraunhofer.de> References: <70524A4436C03E43A293958B505008B602ABC8EF@EXCHSRV.fokus.fraunhofer.de> Message-ID: <4BDECE78.9020808@selfish.org> On 05/03/2010 09:10 PM, Rust, Marco wrote: > Hello, Hi Marco, what is your goal, or better which guide did you follow? What was your goal in merging these two branches? regards holger From marco.rust at fokus.fraunhofer.de Mon May 3 13:30:57 2010 From: marco.rust at fokus.fraunhofer.de (Rust, Marco) Date: Mon, 3 May 2010 15:30:57 +0200 Subject: AW: Osmoloader stored in Flash? In-Reply-To: <4BDECE78.9020808@selfish.org> References: <70524A4436C03E43A293958B505008B602ABC8EF@EXCHSRV.fokus.fraunhofer.de> <4BDECE78.9020808@selfish.org> Message-ID: <70524A4436C03E43A293958B505008B602ABC8F4@EXCHSRV.fokus.fraunhofer.de> The goal is to simple measure gsm rssi values of several channels very quickly. Therefore I need a independent solution that not has to be "ramloaded" every time when booting. ------------------------- Marco Rust FOKUS - Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31, 10589 Berlin marco.rust at fokus.fraunhofer.de ------------------------ -----Urspr?ngliche Nachricht----- Von: baseband-devel-bounces at lists.osmocom.org [mailto:baseband-devel-bounces at lists.osmocom.org] Im Auftrag von Holger Freyther Gesendet: Montag, 3. Mai 2010 15:24 An: baseband-devel at lists.osmocom.org Betreff: Re: Osmoloader stored in Flash? On 05/03/2010 09:10 PM, Rust, Marco wrote: > Hello, Hi Marco, what is your goal, or better which guide did you follow? What was your goal in merging these two branches? regards holger From marco.rust at fokus.fraunhofer.de Mon May 3 13:41:44 2010 From: marco.rust at fokus.fraunhofer.de (Rust, Marco) Date: Mon, 3 May 2010 15:41:44 +0200 Subject: AW: Osmoloader stored in Flash? In-Reply-To: <70524A4436C03E43A293958B505008B602ABC8F4@EXCHSRV.fokus.fraunhofer.de> References: <70524A4436C03E43A293958B505008B602ABC8EF@EXCHSRV.fokus.fraunhofer.de><4BDECE78.9020808@selfish.org> <70524A4436C03E43A293958B505008B602ABC8F4@EXCHSRV.fokus.fraunhofer.de> Message-ID: <70524A4436C03E43A293958B505008B602ABC8FA@EXCHSRV.fokus.fraunhofer.de> Additional, I merged the shared directory to from "loader-crc" in "loader" branch because it was not able to successful compile the newer "loader" branch. ------------------------- Marco Rust FOKUS - Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31, 10589 Berlin marco.rust at fokus.fraunhofer.de ------------------------ -----Urspr?ngliche Nachricht----- Von: baseband-devel-bounces at lists.osmocom.org [mailto:baseband-devel-bounces at lists.osmocom.org] Im Auftrag von Rust, Marco Gesendet: Montag, 3. Mai 2010 15:31 An: baseband-devel at lists.osmocom.org Betreff: AW: Osmoloader stored in Flash? The goal is to simple measure gsm rssi values of several channels very quickly. Therefore I need a independent solution that not has to be "ramloaded" every time when booting. ------------------------- Marco Rust FOKUS - Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31, 10589 Berlin marco.rust at fokus.fraunhofer.de ------------------------ -----Urspr?ngliche Nachricht----- Von: baseband-devel-bounces at lists.osmocom.org [mailto:baseband-devel-bounces at lists.osmocom.org] Im Auftrag von Holger Freyther Gesendet: Montag, 3. Mai 2010 15:24 An: baseband-devel at lists.osmocom.org Betreff: Re: Osmoloader stored in Flash? On 05/03/2010 09:10 PM, Rust, Marco wrote: > Hello, Hi Marco, what is your goal, or better which guide did you follow? What was your goal in merging these two branches? regards holger From steve at steve-m.de Mon May 3 15:29:28 2010 From: steve at steve-m.de (Steve Markgraf) Date: Mon, 03 May 2010 17:29:28 +0200 Subject: AW: Osmoloader stored in Flash? In-Reply-To: <70524A4436C03E43A293958B505008B602ABC8FA@EXCHSRV.fokus.fraunhofer.de> References: <70524A4436C03E43A293958B505008B602ABC8EF@EXCHSRV.fokus.fraunhofer.de><4BDECE78.9020808@selfish.org> <70524A4436C03E43A293958B505008B602ABC8F4@EXCHSRV.fokus.fraunhofer.de> <70524A4436C03E43A293958B505008B602ABC8FA@EXCHSRV.fokus.fraunhofer.de> Message-ID: <4BDEEBD8.7090202@steve-m.de> Hi, well, at first: the "-m romload"-switch is only intended for phones which use the TI Romloader (which the Compal phones don't, and is called "Romloader" because its stored in the maskrom of the Calypso). Rust, Marco wrote: > When I run the loader with "osmcon --m c123xor" the loader starts but > says "Failed to initialize flash". This is basically the right approach, but the support for running applications from flash is still under development. Ingo had it already working as far as I know, but it still needs some work to be usable for the public. Did you use the flash unlock command first, before trying to write to it? Regards, Steve From marco.rust at fokus.fraunhofer.de Mon May 3 17:17:59 2010 From: marco.rust at fokus.fraunhofer.de (Rust, Marco) Date: Mon, 3 May 2010 19:17:59 +0200 Subject: AW: AW: Osmoloader stored in Flash? References: <70524A4436C03E43A293958B505008B602ABC8EF@EXCHSRV.fokus.fraunhofer.de><4BDECE78.9020808@selfish.org> <70524A4436C03E43A293958B505008B602ABC8F4@EXCHSRV.fokus.fraunhofer.de> <70524A4436C03E43A293958B505008B602ABC8FA@EXCHSRV.fokus.fraunhofer.de> <4BDEEBD8.7090202@steve-m.de> Message-ID: <70524A4436C03E43A293958B505008B60222CD7F@EXCHSRV.fokus.fraunhofer.de> >well, at first: the "-m romload"-switch is only intended for phones >which use the TI Romloader (which the Compal phones don't, and is called >"Romloader" because its stored in the maskrom of the Calypso). I thought both modes are supported. > > When I run the loader with "osmcon --m c123xor" the loader starts but > > says "Failed to initialize flash". >This is basically the right approach, but the support for running >applications from flash is still under development. Ingo had it already >working as far as I know, but it still needs some work to be usable for >the public. >Did you use the flash unlock command first, before trying to write to it? The message is shown at start of osmoload. it looks like the "cfi_algo enumeration" makes trouble at line 518 in cfi-flash.c if(qry.p_id != CFI_ALGO_INTEL_3) { /* we only support algo 3 */ return -ENOTSUP; } I am not sure but I commented out everything in flash_init() function and finally remove the comments again one after another. At line 518 the result is'nt 0 anymore. Is that flash not supported? It is hard to debug further because no printf() or puts() are possible in cfi-flash.c Regards, Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon May 3 17:32:53 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 3 May 2010 19:32:53 +0200 Subject: AW: Osmoloader stored in Flash? In-Reply-To: <70524A4436C03E43A293958B505008B60222CD7F@EXCHSRV.fokus.fraunhofer.de> References: <70524A4436C03E43A293958B505008B602ABC8EF@EXCHSRV.fokus.fraunhofer.de> <4BDECE78.9020808@selfish.org> <70524A4436C03E43A293958B505008B602ABC8F4@EXCHSRV.fokus.fraunhofer.de> <70524A4436C03E43A293958B505008B602ABC8FA@EXCHSRV.fokus.fraunhofer.de> <4BDEEBD8.7090202@steve-m.de> <70524A4436C03E43A293958B505008B60222CD7F@EXCHSRV.fokus.fraunhofer.de> Message-ID: <20100503173253.GQ556@prithivi.gnumonks.org> Hi Marco, On Mon, May 03, 2010 at 07:17:59PM +0200, Rust, Marco wrote: > >well, at first: the "-m romload"-switch is only intended for phones > >which use the TI Romloader (which the Compal phones don't, and is called > >"Romloader" because its stored in the maskrom of the Calypso). > > I thought both modes are supported. The calypso always supports booting from rom _BUT_ the nIBOOT pin determines whether it boots from external NOR flash or from internal mask-rom. Since that pin is hard-wired on the circuit board, you will only be able to activate the calypso romloader on our supported motorola/compal phones if you unsolder the Calypso BGA package, do some re-work and re-solder it ;) Generally speaking: As far as I know, only prom (the original author) has been using/testing the flash support so far. Only he would be able to know what is supposed to work right now and what isn't. -- - 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 Wed May 5 11:41:19 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 5 May 2010 13:41:19 +0200 Subject: Request for help with VCTCXO measurements Message-ID: <20100505114119.GJ6543@prithivi.gnumonks.org> Hi all! Right now, one of our many issues in L1 is the frequency stability (or lack thereof). What we do right now is very primitive and is mostly based on guesswork, rather than measurements and good algorithms. In order to change this, we need some measurements to be done. As I am currently again travelling a lot, and my time for OsmocomBB is more limited now, I hope that somebody else will be able to take the measurements as described below. There is a big number of people in this project who now have a Racal 6103 (or similar) measurement device. Also, for those in Berlin, the CCC Berlin has one in its basement lab. What needs to be done: 1) Determine the relation between AFCDAC output and actual carrier frequency. All that is needed is some manual control over the AFCDAC value (e.g. based on keypad events) while the AFC is disabled. Then we continuously transmit bursts (content is unimportant) to the Racal 6103 and note the measured frequency error by the 6103 for every AFC value that we input. Those measurements should then be repeated for each supported band of the phone, preferrably each with a low-frequency channel, a medium frequency and a high-frequency channel. This means something like 10 different AFC values for 3 different channels of each of the 2 bands that the c123/c155 support. Basd on those measurements (preferrably do that series with 2-3 phones) we can construct a function that will tell us which AFCDAC value we should program if we want a given carrier frequency increase/decrease. 2) Determine the temperature related frequency drift and corresponding temperature ADC reading Especially when we transmit, the temperature in the RF section of the phone is assumed to change quite a bit. This means we need to measure the temperature in the oscillator (using the RITA-internal temperature sensor connected to one of the ADC channels of IOTA) and compare that with the frequency drift. In order to measure this, we first need a temperature-ADC driver. Once that exists, we can lock onto a BCCH, then make sure the AFC is disabled and the AFCDAC output value will be stable. Next, one can use e.g. a hairdryer or ice spray to change the temperature. While doing that, we can measure the difference in carrier frequency with the Racal 6103. The absolute temperature in centigrade/kelvin is not actually interesting to us all. All we want to know is: What is the 6103-measured frequency error at a given temperature-ADC-reading. Once again, the measurements should be done for high (1800) and low (900) band independently, just to be sure. Based on their relation we can also model a function, table or other approximation and include that in our AFC code. I think I'll be able to write the code even while I'm on the road - if somebody is able to do the measurements and post them to the mailing list. Thanks in advance, Harald -- - 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 Wed May 5 16:44:13 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 5 May 2010 18:44:13 +0200 Subject: Request for help with PA power measurements In-Reply-To: <20100505114119.GJ6543@prithivi.gnumonks.org> References: <20100505114119.GJ6543@prithivi.gnumonks.org> Message-ID: <20100505164413.GE19231@prithivi.gnumonks.org> Hi again, Similar to the VCTCXO measurements, we also need to do RF-PA output power measurements. The Racal 6103 can measure the power level of bursts we transmit. The Tx power is set at "dsp_api.db_w->d_power_ctl = ABB_VAL(AUXAPC, 0xC0)" so we need to determine for which AUXAPC value we get how much power at the antenna connector. Using the resulting table of measurement results, we can compute what AUXAPC value we should use for what intended transmit power. I am aware that those measurements should idaelly be done on each and every phone, as they might differ. However, I'm quite confident that by using values that are correct on one phone, we shouldn't be too much off on other phones. At least not by an order of magnitude ;) Thanks in advance, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From steve at steve-m.de Mon May 10 15:59:25 2010 From: steve at steve-m.de (Steve Markgraf) Date: Mon, 10 May 2010 17:59:25 +0200 Subject: Request for help with PA power measurements In-Reply-To: <20100505164413.GE19231@prithivi.gnumonks.org> References: <20100505114119.GJ6543@prithivi.gnumonks.org> <20100505164413.GE19231@prithivi.gnumonks.org> Message-ID: <4BE82D5D.1080708@steve-m.de> Hi, Harald Welte wrote: > Similar to the VCTCXO measurements, we also need to do RF-PA output > power measurements. The Racal 6103 can measure the power level of > bursts we transmit. Attached to this mail you'll find my measurements in GSM900, ARFCN 33. I've done some short tests for DCS1800 and higher ARFCNs in GSM900 as well, so far the offsets to my measurements seem to be linear, so we can most likely use a correction value and don't need to store everything twice. I'll investigate in this later... Regards, Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: auxapc_raw.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: auxapc_gsm900.ods Type: application/vnd.oasis.opendocument.spreadsheet Size: 42119 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: auxapc_gsm900_graph.png Type: image/png Size: 27224 bytes Desc: not available URL: From laforge at gnumonks.org Mon May 10 16:11:00 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 10 May 2010 18:11:00 +0200 Subject: Request for help with PA power measurements In-Reply-To: <4BE82D5D.1080708@steve-m.de> References: <20100505114119.GJ6543@prithivi.gnumonks.org> <20100505164413.GE19231@prithivi.gnumonks.org> <4BE82D5D.1080708@steve-m.de> Message-ID: <20100510161100.GG23723@prithivi.gnumonks.org> Hi Steve, thanks a lot for your measurements. The only thing that puzzles me: It seems to max out at about 30.7dBm, that's about 1.17 Watts, i.e. much less than the 4W (36dBm) that it should be able to transmit as maximum power in GSM900... Dieter: Could this related to the APC ramp? I.e. the ramp settings somehow limiting the power? -- - 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 Mon May 10 17:01:29 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 10 May 2010 19:01:29 +0200 Subject: Request for help with PA power measurements In-Reply-To: <20100510161100.GG23723@prithivi.gnumonks.org> References: <20100505114119.GJ6543@prithivi.gnumonks.org> <20100505164413.GE19231@prithivi.gnumonks.org> <4BE82D5D.1080708@steve-m.de> <20100510161100.GG23723@prithivi.gnumonks.org> Message-ID: <20100510170129.GJ23723@prithivi.gnumonks.org> On Mon, May 10, 2010 at 06:11:00PM +0200, Harald Welte wrote: > The only thing that puzzles me: It seems to max out at about 30.7dBm, that's > about 1.17 Watts, i.e. much less than the 4W (36dBm) that it should be able to > transmit as maximum power in GSM900... Ok, my wrong. The RF-PA (SKY77324) used in the phone cannot actually transmit more than 35dBm. As there is additional loss incurred by the cables, antenna connector and the antenna switch (the diode switch between antenna socket and PA), the 30.something dBm actually seem quite reasonable. 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 vogelchr at vogel.cx Sun May 9 14:29:06 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Sun, 9 May 2010 16:29:06 +0200 Subject: VCXO measurements In-Reply-To: <20100505114119.GJ6543@prithivi.gnumonks.org> References: <20100505114119.GJ6543@prithivi.gnumonks.org> Message-ID: <20100509142851.GA11767@vogel.cx> Hi, I've measured how the 26 MHz VCXO changes frequency depending on the AFC DAC output. See the attached plots and the data file. Tapping point is between C132 and C210 (RITA Xout). On my 20 MHz scope it's 300 mVpp, but I'm hitting the bandwidth limit of the scope, the frequency counter says -0.03 V ...+0.02 V after a x10 probe (500mVpp). I'll put it in the fridge later on to check the temperature coefficient. Pictures: http://lh6.ggpht.com/_zKkNaqX3vkM/S-avbZbCmJI/AAAAAAAAAwE/EfsMRB08iJ8/s1600-h/IMG_1522%5B3%5D.jpg http://lh3.ggpht.com/_zKkNaqX3vkM/S-ave-aRv_I/AAAAAAAAAwM/3f1RfuZD05E/s1600-h/IMG_1523%5B4%5D.jpg http://lh3.ggpht.com/_zKkNaqX3vkM/S-aviUpzWNI/AAAAAAAAAwU/AshSJr3qzwM/s1600-h/IMG_1524%5B3%5D.jpg http://lh3.ggpht.com/_zKkNaqX3vkM/S-avmomSpgI/AAAAAAAAAwc/NJSJoW5fqd4/s1600-h/IMG_1525%5B3%5D.jpg http://lh6.ggpht.com/_zKkNaqX3vkM/S-avqB3veGI/AAAAAAAAAwk/uPQPARv3osk/s1600-h/IMG_1526_w_label%5B3%5D.jpg Chris -------------- next part -------------- # GPSDO locked, Ch2, Frequency, Peak/Peak: 30mV/-20mV # DAC, 1st measurement, 2nd measurement 0 25.999876 25.9998634 256 25.9999336 25.9999225 512 25.9999915 25.9999818 768 26.0000501 26.0000412 1024 26.0001089 26.0001008 1280 26.0001680 26.0001605 1536 26.0002275 26.0002203 1792 26.0002871 26.0002800 2048 26.0003454 26.0003396 2304 - 26.0003988 2560 26.0004637 26.0004581 2816 26.0005218 26.0005169 3072 26.0005791 26.0005754 3328 26.0006366 - 3584 26.0006935 26.0006915 3840 26.0007496 26.0007486 4095 26.0008047 26.0008047 -------------- next part -------------- A non-text attachment was scrubbed... Name: vcxo_meas1.png Type: image/png Size: 7854 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vcxo_meas2.png Type: image/png Size: 7882 bytes Desc: not available URL: From laforge at gnumonks.org Sun May 9 19:47:27 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 9 May 2010 21:47:27 +0200 Subject: VCXO measurements In-Reply-To: <20100509142851.GA11767@vogel.cx> References: <20100505114119.GJ6543@prithivi.gnumonks.org> <20100509142851.GA11767@vogel.cx> Message-ID: <20100509194727.GI7162@prithivi.gnumonks.org> On Sun, May 09, 2010 at 04:29:06PM +0200, Christian Vogel wrote: > Hi, > > I've measured how the 26 MHz VCXO changes frequency depending on the > AFC DAC output. See the attached plots and the data file. thanks a lot! > Tapping point is between C132 and C210 (RITA Xout). > On my 20 MHz scope it's 300 mVpp, but I'm hitting the bandwidth > limit of the scope, the frequency counter says -0.03 V ...+0.02 V > after a x10 probe (500mVpp). You should consider to use the 13MHz signal. it's buffered and a simple divide-by-two of the 26MHz oscillator output. Anyway, from your data I would say: At DAC=500 we have 26 MHz At interpolated DAC=2750 we have 500Hz more So this means the voltage control slope is 500/2750 = 0.1818 Hz / LSB Converting this into ppb: 0.1818 /.026 = 6.993 ppb / LSB The TSM30-based algorithm seems to assume 4.9 ppb / LSB, and for reasons I don't remember we currently seem to use 9.76ppb/LSB (AFC_SLOPE in layer1/afc.c) Of course this value is highly dependent on the particular XO and its peripheral parts, so I'm not surprised to see that much difference. Based on this, the ideal value for AFC_SLOPE according to the measurements should be 229. I haven't tested that, this is just my thinking: 0.006993 * 32768 = 229 Also, to give you some idea what this means in terms of "Hz carrier frequency / LSB": Center of GSM 900 between UL and DL: (960+880)/2 = 920 MHz overall multiplication factor for mid-band GSM900: 35.38 resulting theoretical slope: 6.43 Hz / LSB Center of GSM 1800 between UL and DL: (1710+1880)/2 = 1795 MHz overall multiplication factor for mid-band GSM900: 69.04 resulting theoretical slope: 12.55 Hz / LSB 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 laforge at gnumonks.org Sun May 9 20:12:49 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 9 May 2010 22:12:49 +0200 Subject: VCXO measurements In-Reply-To: <20100509194727.GI7162@prithivi.gnumonks.org> References: <20100505114119.GJ6543@prithivi.gnumonks.org> <20100509142851.GA11767@vogel.cx> <20100509194727.GI7162@prithivi.gnumonks.org> Message-ID: <20100509201248.GJ7162@prithivi.gnumonks.org> As Christian has just pointed out, 0.228Hz/LSB is a better approximation, and I've re-computed as follows: So this means the voltage control slope is 500/2750 = 0.228 Hz / LSB Converting this into ppb: 0.228 /.026 = 8.769 ppb / LSB Based on this, the ideal value for AFC_SLOPE according to the measurements should be 229. I haven't tested that, this is just my thinking: 0.008769 * 32768 = 287 Also, to give you some idea what this means in terms of "Hz carrier frequency / LSB": Center of GSM 900 between UL and DL: (960+880)/2 = 920 MHz overall multiplication factor for mid-band GSM900: 35.38 resulting theoretical slope: 8.07 Hz / LSB Center of GSM 1800 between UL and DL: (1710+1880)/2 = 1795 MHz overall multiplication factor for mid-band GSM900: 69.04 resulting theoretical slope: 15.74 Hz / LSB -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Wed May 12 12:58:36 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 12 May 2010 14:58:36 +0200 Subject: update on layer 3 work Message-ID: hi, i like to give a short update: currently i am testing the processes of selecting a cell and the network. the processes depend on the coverage, the sim card (network, inserted or not) and the mode (manual or automatic network selection). i hope i will finish this week. to configure mode and sim card and other parameters in the future, i use the VTY, you already know from the OpenBSC project. there you can get informations about the subscriber, the mobile station and the received cells (system informations). i will move all hacked parameters (test sim) to VTY config file. manual network selection mode requires reaction of the user, so it will also be added to the VTY. later the VTY can also command the "call" part to dial, answer and hangup a call. my idea: later these VTY command structure may be used for the phone's menu (up - down - enter - escape), if compiled appropiate. also: if layer 3 is running on the phone, the serial port could directly connect to the VTY, so the phone gets a console interface for debugging and faster configuration. currently the process (with sim card) ends while trying to do a location update. if the given channel is not supported, the program exits. to prevent this, just keep radio TX feature disable. the cell will be re-selected again and again (hopefully if the process works correct). sometimes, especially at the first run, the radio process stops. (no results for measurements, no sync to selected frequency.) also there is something i am wondering: calibration especially for the burst signal phase is measured and then stored on the eeprom by the manufacturer. do we use it? or do we need to do our own calibration? regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu May 13 16:39:04 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 13 May 2010 18:39:04 +0200 Subject: calibration (was Re: update on layer 3 work) In-Reply-To: References: Message-ID: <20100513163904.GS10052@prithivi.gnumonks.org> Hi Andreas, On Wed, May 12, 2010 at 02:58:36PM +0200, Andreas.Eversberg wrote: > also there is something i am wondering: calibration especially for the > burst signal phase is measured and then stored on the eeprom by the > manufacturer. do we use it? or do we need to do our own calibration? there is no eeprom, it is stored in the same nor flash as the software is. we have not yet been able to clearly identify and decode the parameters that they store. Without knowing the exact parameters and their interpretation, it will not be possible to use them from our software. compal/motorola doesn't seem to use the standard method of storing those parameters in the FFS (flash file system) at the end of the image, but rather somewhere else :/ So yes, at the moment we will either use default parameters or have to calibrate the phones individually. Cheers from Iceland, Harald -- - 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 Thu May 13 16:42:38 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 13 May 2010 18:42:38 +0200 Subject: vty / menu In-Reply-To: References: Message-ID: <20100513164238.GT10052@prithivi.gnumonks.org> Hi Andreas, On Wed, May 12, 2010 at 02:58:36PM +0200, Andreas.Eversberg wrote: > my idea: later these VTY command structure may be used for the phone's > menu (up - down - enter - escape), if compiled appropiate. also: if > layer 3 is running on the phone, the serial port could directly connect > to the VTY, so the phone gets a console interface for debugging and > faster configuration. I really like the idea, but I think we need to move to something much more flexible than the current VTY data structures to make that work. The existing VTY code is a pretty useful tool, but it has quite some limitations and shortcomings that cannot be fixed quickly. One of its uglinesses is how you specify the context sensitive help strings (as multi-line strings with \n in them, part of what you pass to DEFUN). Other aspects are that all new nodes need to be hacked into the VTY core and you cannot define them yourself (see the NS_NODE that I have just introduced 2 days ago). Once those issues are resolved, the VTY code could become a standard feature of libosmocore, and we wouldn't need to hack that code while still implementing any command line menu structure we'd like. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From steve at steve-m.de Fri May 14 21:56:58 2010 From: steve at steve-m.de (Steve Markgraf) Date: Fri, 14 May 2010 23:56:58 +0200 Subject: MTK status update Message-ID: <4BEDC72A.2090605@steve-m.de> Hi all, I wanted to give a short status update on the MTK platform, I spent the last day implementing a minimal subset of the MTK romloader protocol in osmocon. We can now run our own C-code on the MT622x, I started by modifying the linker script and run proms loader (because it doesn't need interrupts, the interrupt redirection isn't yet figured out). When writing something to the UART TX register, I see the output in osmocon, and writing to the Baseband powerup register works as well (otherwise you would have to hold down the power-button all the time). Unfortunately there are no schematics for the Mobistel phone I've been testing this with, so I haven't found out how to enable e.g. the backlight, nothing happens when activating PWM1/2. Today I tried to modify the Calypso UART driver for the MTK UART, but currently I'm stuck with a strange hang somewhere in the driver, maybe I'll look after it tomorrow. That was it for the moment... Regards, Steve From laforge at gnumonks.org Sat May 15 23:00:49 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 16 May 2010 01:00:49 +0200 Subject: MTK status update In-Reply-To: <4BEDC72A.2090605@steve-m.de> References: <4BEDC72A.2090605@steve-m.de> Message-ID: <20100515230049.GC7265@prithivi.gnumonks.org> Hi Steve, On Fri, May 14, 2010 at 11:56:58PM +0200, Steve Markgraf wrote: > I wanted to give a short status update on the MTK platform, I spent > the last day implementing a minimal subset of the MTK romloader > protocol in osmocon. cool. > When writing something to the UART TX register, I see the output in > osmocon, and writing to the Baseband powerup register works as well > (otherwise you would have to hold down the power-button all the > time). ok. > Unfortunately there are no schematics for the Mobistel phone I've > been testing this with, so I haven't found out how to enable e.g. > the backlight, nothing happens when activating PWM1/2. yes, most likely the I/O pin function modes need to be set correctly. It might be best to try to read them from a (running) normal firmware. > Today I tried to modify the Calypso UART driver for the MTK UART, > but currently I'm stuck with a strange hang somewhere in the driver, > maybe I'll look after it tomorrow. if you have any specific questions, please le me know. I haven't yet checked how compatible the UART types of the two devices are. Good luck! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jal2 at gmx.de Sat May 15 00:07:08 2010 From: jal2 at gmx.de (Joerg Albert) Date: Sat, 15 May 2010 02:07:08 +0200 Subject: Newbie + questions: C123 and Racal 6103 Message-ID: <4BEDE5AC.3030701@gmx.de> Hi, I've recently got pointed to this project. Haven't dealt with any GSM software since the mid-90ies, so I thought it may be some fun to look at the software and participate if I find enough time. I've got access to a Racal 6103 and a C123 to start with. A couple of questions: 1) Do I need attenuators if I wire the C123 to the Racal? Guess not, but I don't want to fry the input of the Racal. 2) External antenna connector on the C123 seems to be a MS-147. I got a couple of HF cables from a WLAN card with this connector: http://shop.meconet.de/artikeldet.php?suchspeicher=110448&proid=550&bez=Crimp%20male%20MS-147,%20CG-B1%20-%203.0mm,%200-6GHz,%2090%B0%20r/a but the inner conductor of the plug seems to be a bit short (may be my fault during assembly). Does the MS-147 jack on the C123 switch off the internal antenna if anything is plugged in? 3) Does the PA of the C123 survive without any antenna connected (i.e. if it gets most of the HF reflected back) e.g. in continuous transmit mode? 4) A C123 without battery doesn't start the vendor firmware, display is blank, LED are on, flicker from time to time. Is this a hardware problem or just the vendor firmware missing the battery, i.e. any problem to download osmocom software without any battery? Thanks for any answers! From steve at steve-m.de Sat May 15 01:05:02 2010 From: steve at steve-m.de (Steve Markgraf) Date: Sat, 15 May 2010 03:05:02 +0200 Subject: Newbie + questions: C123 and Racal 6103 In-Reply-To: <4BEDE5AC.3030701@gmx.de> References: <4BEDE5AC.3030701@gmx.de> Message-ID: <4BEDF33E.9090003@steve-m.de> Hi Joerg, Joerg Albert wrote: > I've recently got pointed to this project. Haven't dealt with any GSM > software since the mid-90ies, so I thought it may be some fun to look > at the software and participate if I find enough time. I've got access > to a Racal 6103 and a C123 to start with. Your help is very appreciated! > 1) Do I need attenuators if I wire the C123 to the Racal? Guess not, > but I don't want to fry the input of the Racal. No, but you have to connect it to the "Main RF" N-connector, which also has some large attenuator in its RF path. And, regarding to the manual, you have to terminate the "AUX RF" with a 50 Ohms resistor in this case. If you only want to play with the higher layers and don't want to do any accurate power measurements, you just can put some wire in the AUX RF connector and turn the TX power to -40dBm, in my case this works almost throughout the whole basement. > Does the MS-147 jack on the C123 switch off the internal antenna if > anything is plugged in? Yes, this is the right connector, and it does switch off the antenna. But I have no idea about the required length of the middle pin, my MS-147 cable is still on the way. > 3) Does the PA of the C123 survive without any antenna connected (i.e. > if it gets most of the HF reflected back) e.g. in continuous transmit mode? Well, it may "survive" somehow, but I heard from the USRP that the PA may wear out if no load is connected, and this is rather a slow process instead of an instant failure. I wouldn't try it though, especially when continously transmitting. > 4) A C123 without battery doesn't start the vendor firmware, display is > blank, LED are on, flicker from time to time. > Is this a hardware problem or just the vendor firmware missing the battery, > i.e. any problem to download osmocom software without any battery? The current supplied by the charger is not enough, and since the Calypso itself controls charging, this won't work, neither with the original firmware, nor with osmocom. The flickering of the charging-LED stops immediately if a battery is inserted. See http://lists.osmocom.org/pipermail/baseband-devel/2010-March/000255.html as well. Regards, Steve From jluebbe at debian.org Sun May 16 15:31:21 2010 From: jluebbe at debian.org (Jan Luebbe) Date: Sun, 16 May 2010 17:31:21 +0200 Subject: [PATCH 1/2] osmocon: extend hexdump to show all printable characters Message-ID: <1274023882-20390-1-git-send-email-jluebbe@debian.org> --- src/host/osmocon/osmocon.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index b823b5b..4ad48e2 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -22,6 +22,7 @@ * */ +#include #include #include #include @@ -418,11 +419,16 @@ int read_file(const char *filename) static void hexdump(const uint8_t *data, unsigned int len) { - const uint8_t *bufptr = data; int n; - for (n=0; n < len; n++, bufptr++) - printf("%02x ", *bufptr); + for (n=0; n < len; n++) + printf("%02x ", data[n]); + printf(" "); + for (n=0; n < len; n++) + if (isprint(data[n])) + putchar(data[n]); + else + putchar('.'); printf("\n"); } -- 1.7.1 From jluebbe at debian.org Sun May 16 15:31:22 2010 From: jluebbe at debian.org (Jan Luebbe) Date: Sun, 16 May 2010 17:31:22 +0200 Subject: [PATCH 2/2] layer1: add l1s_run_handler and call it from prim_pm.c In-Reply-To: <1274023882-20390-1-git-send-email-jluebbe@debian.org> References: <1274023882-20390-1-git-send-email-jluebbe@debian.org> Message-ID: <1274023882-20390-2-git-send-email-jluebbe@debian.org> In f7af19661a43457fc6489391ecc70aab238abcb4 we stopped running the callback, which broke the l1test app. Now it works again. --- src/target/firmware/include/layer1/sync.h | 1 + src/target/firmware/layer1/prim_pm.c | 2 ++ src/target/firmware/layer1/sync.c | 6 ++++++ 3 files changed, 9 insertions(+), 0 deletions(-) diff --git a/src/target/firmware/include/layer1/sync.h b/src/target/firmware/include/layer1/sync.h index d053c93..c5ff4c1 100644 --- a/src/target/firmware/include/layer1/sync.h +++ b/src/target/firmware/include/layer1/sync.h @@ -115,6 +115,7 @@ struct l1_signal { typedef void (*l1s_cb_t)(struct l1_signal *sig); void l1s_set_handler(l1s_cb_t handler); +void l1s_run_handler(struct l1_signal *sig); int16_t l1s_snr_int(uint16_t snr); uint16_t l1s_snr_fract(uint16_t snr); diff --git a/src/target/firmware/layer1/prim_pm.c b/src/target/firmware/layer1/prim_pm.c index 85fc8d1..4a5c75c 100644 --- a/src/target/firmware/layer1/prim_pm.c +++ b/src/target/firmware/layer1/prim_pm.c @@ -96,6 +96,8 @@ static int l1s_pm_resp(__unused uint8_t p1, __unused uint8_t p2, sig.pm.dbm8[0] = agc_inp_dbm8_by_pm(pm_level[0]); sig.pm.dbm8[1] = agc_inp_dbm8_by_pm(pm_level[1]); + l1s_run_handler(&sig); + if (!l1s.pm.msg) l1s.pm.msg = l1ctl_msgb_alloc(L1CTL_PM_RESP); diff --git a/src/target/firmware/layer1/sync.c b/src/target/firmware/layer1/sync.c index f5629cf..a4b3a65 100644 --- a/src/target/firmware/layer1/sync.c +++ b/src/target/firmware/layer1/sync.c @@ -65,6 +65,12 @@ void l1s_set_handler(l1s_cb_t cb) l1s_cb = cb; } +void l1s_run_handler(struct l1_signal *sig) +{ + if (l1s_cb) + l1s_cb(sig); +} + void l1s_time_inc(struct gsm_time *time, uint32_t delta_fn) { ADD_MODULO(time->fn, delta_fn, GSM_MAX_FN); -- 1.7.1 From laforge at gnumonks.org Wed May 19 18:31:31 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 May 2010 20:31:31 +0200 Subject: [PATCH 1/2] osmocon: extend hexdump to show all printable characters In-Reply-To: <1274023882-20390-1-git-send-email-jluebbe@debian.org> References: <1274023882-20390-1-git-send-email-jluebbe@debian.org> Message-ID: <20100519183130.GA14287@prithivi.gnumonks.org> thanks, finally I have applied that patch to master. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From daniel at totalueberwachung.de Sun May 16 23:37:01 2010 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Mon, 17 May 2010 01:37:01 +0200 Subject: [PATCH 0/2] Add gta0x board support In-Reply-To: References: Message-ID: Hello, these patches enable osmocom to be run on the Openmoko GTA0x devices (only tested with GTA02). The first patch fixes an issue with baudrate setting in osmocon.c (termios setting wasn't read prior to writing). The second patch adds a gta0x board (currently only copied from compal_e88) and implements the differences in controlling the RF frontend. Use it as follows (on the device): kill all processes communicating with the modem (fso, gsm0710muxd) gta02# echo 1 > /sys/bus/platform/devices/neo1973-pm-gsm.0/download Then on the PC connect the download cable and start osmocon: # ./osmocon -m romload -p /dev/ttyUSB0 ../../target/firmware/board/gta0x/l1test.osmoload.bin To initiate the download toggle baseband power on the phone: gta02# echo 0 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on && > echo 1 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on After the firmware is transferred the app should start. Regards, Daniel Willmann Daniel Willmann (2): osmocon.c: Fix serial_set_baudrate function Add new board gta0x (for Openmoko Freerunner devices) and build it src/host/osmocon/osmocon.c | 5 + src/target/firmware/Makefile | 4 +- .../firmware/board/common/rffe_gta0x_triband.c | 88 +++++++++++++ src/target/firmware/board/gta0x/init.c | 131 ++++++++++++++++++++ 4 files changed, 227 insertions(+), 1 deletions(-) create mode 100644 src/target/firmware/board/common/rffe_gta0x_triband.c create mode 100644 src/target/firmware/board/gta0x/init.c From osmocom at ngolde.de Mon May 17 14:00:28 2010 From: osmocom at ngolde.de (Nico Golde) Date: Mon, 17 May 2010 16:00:28 +0200 Subject: [PATCH 2/2] Add new board gta0x (for Openmoko Freerunner devices) and build it In-Reply-To: <219afc34fe44fe8ef852a40ba6f162a368529a06.1274051274.git.daniel@totalueberwachung.de> References: <219afc34fe44fe8ef852a40ba6f162a368529a06.1274051274.git.daniel@totalueberwachung.de> Message-ID: <20100517140028.GA5213@pool.math.tu-berlin.de> Hi, * Daniel Willmann [2010-05-17 11:48]: > For now just copied over the compal_e88 init.c and adapted the RF > frontend functions. For osmocon to work with the GSM download cable > SERCOMM_UART_NR and CONS_UART_NR need to be switched. [...] > +/* describe how the RF frontend is wired on the Openmoko GTA0x boards */ > + > +#define RITA_RESET TSPACT(0) /* Reset of the Rita TRF6151 */ > +#define PA_ENABLE TSPACT(9) /* Enable the Power Amplifier */ > +#define GSM_TX TSPACT(3) /* PA GSM switch, low-active */ > + > +/* All VCn controls are low-active */ > +#define ASM_VC1 TSPACT(2) /* Antenna switch VC1 */ > +#define ASM_VC2 TSPACT(1) /* Antenna switch VC2 */ > +#define ASM_VC3 TSPACT(4) /* Antenna switch VC3 */ > + > +#define IOTA_STROBE TSPEN0 /* Strobe for the Iota TSP */ > +#define RITA_STROBE TSPEN2 /* Strobe for the Rita TSP */ > + > +/* switch RF Frontend Mode */ > +void rffe_mode(enum gsm_band band, int tx) > +{ > + uint16_t tspact = tsp_act_state(); > + > + /* First we mask off all bits from the state cache */ > + tspact &= ~PA_ENABLE; > + tspact |= GSM_TXEN; /* low-active */ [...] I'm not sure what the correct value is in this case but GSM_TXEN is not defined at this point. Cheers Nico From steve at steve-m.de Mon May 17 14:12:39 2010 From: steve at steve-m.de (Steve Markgraf) Date: Mon, 17 May 2010 16:12:39 +0200 Subject: [PATCH 2/2] Add new board gta0x (for Openmoko Freerunner devices) and build it In-Reply-To: <20100517140028.GA5213@pool.math.tu-berlin.de> References: <219afc34fe44fe8ef852a40ba6f162a368529a06.1274051274.git.daniel@totalueberwachung.de> <20100517140028.GA5213@pool.math.tu-berlin.de> Message-ID: <4BF14ED7.9040904@steve-m.de> Hi, Nico Golde wrote: > I'm not sure what the correct value is in this case but > GSM_TXEN is not defined at this point. Yes, just noticed it, too, currently preparing osmocon patches and will commit that to my branch today. diff --git a/src/target/firmware/board/common/rffe_gta0x_triband.c b/src/target/firmware/board/common/rffe_gta0x_triband.c index 63003d4..6406f04 100644 --- a/src/target/firmware/board/common/rffe_gta0x_triband.c +++ b/src/target/firmware/board/common/rffe_gta0x_triband.c @@ -11,7 +11,7 @@ #define RITA_RESET TSPACT(0) /* Reset of the Rita TRF6151 */ #define PA_ENABLE TSPACT(9) /* Enable the Power Amplifier */ -#define GSM_TX TSPACT(3) /* PA GSM switch, low-active */ +#define GSM_TXEN TSPACT(3) /* PA GSM switch, low-active */ /* All VCn controls are low-active */ #define ASM_VC1 TSPACT(2) /* Antenna switch VC1 */ -- Regards, Steve From daniel at totalueberwachung.de Tue May 18 11:05:06 2010 From: daniel at totalueberwachung.de (Daniel Willmann) Date: Tue, 18 May 2010 13:05:06 +0200 Subject: [PATCH 2/2] Add new board gta0x (for Openmoko Freerunner devices) and build it In-Reply-To: <4BF14ED7.9040904@steve-m.de> References: <219afc34fe44fe8ef852a40ba6f162a368529a06.1274051274.git.daniel@totalueberwachung.de> <20100517140028.GA5213@pool.math.tu-berlin.de> <4BF14ED7.9040904@steve-m.de> Message-ID: <20100518130506.537a3d3d@adrastea.totalueberwachung.de> Hi, On Mon, 17 May 2010 16:12:39 +0200 Steve Markgraf wrote: > Nico Golde wrote: > > > I'm not sure what the correct value is in this case but > > GSM_TXEN is not defined at this point. > > Yes, just noticed it, too, currently preparing osmocon patches and > will commit that to my branch today. sorry, must have been too late for last minute cleanup. Thanks for fixing it. Regards, Daniel Willmann From laforge at gnumonks.org Wed May 19 18:31:56 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 May 2010 20:31:56 +0200 Subject: [PATCH 2/2] Add new board gta0x (for Openmoko Freerunner devices) and build it In-Reply-To: <4BF14ED7.9040904@steve-m.de> References: <219afc34fe44fe8ef852a40ba6f162a368529a06.1274051274.git.daniel@totalueberwachung.de> <20100517140028.GA5213@pool.math.tu-berlin.de> <4BF14ED7.9040904@steve-m.de> Message-ID: <20100519183156.GB14287@prithivi.gnumonks.org> Hi Steve, On Mon, May 17, 2010 at 04:12:39PM +0200, Steve Markgraf wrote: > >I'm not sure what the correct value is in this case but GSM_TXEN > >is not defined at this point. > > Yes, just noticed it, too, currently preparing osmocon patches and > will commit that to my branch today. ... and i've merged it to master now. -- - 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 Thu May 20 21:43:11 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 20 May 2010 23:43:11 +0200 Subject: Finally... FB/SB Layer1 changes working/merged Message-ID: <20100520214311.GV14287@prithivi.gnumonks.org> Hi all! I've merged a number of layer1 related changes that I've been working on for quite some time. The major difference is: there is no L1CTL_NEW_CCCH_REQ anymore, it has been replaced by L1CTL_FBSB_REQ. When issuing FBSB_REQ, you can specify what tasks you want the layer1 to perform (any bitmask of FB0, FB1, SB). Also, if the acquisition fails completely, you will get a L1CTL_FBSB_RESP with result=0xff. This means there is now proper error reporting. Let's say you want a relatively quick indication if the ARFCN specified could at all be a BCCH, then issuing FBSB_REQ only with FB0 should return even more quickly. You will definitely get a response after some 15 TDMA frames if there was a frequency burst or not. Furthermore, I have changed some details of the FB/SB acquisition process: Rather than waiting for a fixed amount (500) TDMA frames before switching from FB0->FB1 or FB1->SB, the switch is now done based on thesholds for frequency delta and SNR. The frequency thresholds can actually be specified by L1CTL, the SNR thresholds are hardcoded. One problem with fast scanning was that by erroneous FB0 reports, we tuned our VCO so far off the desired frequency that it never synced to any cell at all anymore. I have reduced that problem by simply resetting the AFC-DAC to its default value every time we start a FBSB acquisition. Andreas: I think it would make sense to use the S_L1CTL_FBSB_RESP and S_L1CTL_FBSB_ERR signals in 'mobile', especially if you receive an _ERR, you can immediately switch to the next ARFCN without wasting further time. My next API change will be to introduce a separate command, i.e. FBSB_REQ will no longer start the multiframe task for BCCH NORMAL/EXTENDED, but the application will have to explicitly request that. However, I don't think I'll find much time throughout the next 10 days or so.. .sorry :/ Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)