Peter Stuge <peter(a)stuge.se> 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
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…
Sent from the baseband-devel mailing list archive at Nabble.com.
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.
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 .
On 7/27/13, Steve Markgraf <steve(a)steve-m.de> wrote:
> Unfortunately there's only a datasheet of the SPCA554 floating around,
> just search for "SPCA554AV02".
Found it, thanks.
> unfortunately the SPCA552 and 554 seem to have quite a few differences,
> so not everything could be figured out.
Yeah, the differences do seem big indeed. While I was searching around
for an SPCA552E datasheet, I found this:
http://www.download.revosupport.com/scp2009_download_folder!/BONUS%20MEMBER…
On page 12 of that schematic there's our lovely Sunplus chip. Of
course it's a totally different phone, but at least we can see what
are the pin interfaces coming off this chip.
In the above schematic, we see that SPCA552E connects to just the host
CPU, the LCM and the camera - no frills. But the 554 datasheet you've
found describes a much more complex device - adds USB, audio, mass
storage...
> At least it was enough information to get the bypass mode working,
> which was my main goal.
Were you ever able to figure out just how the backlight works on this
display? Your code has a comment about a particular register in the
SPCA supposedly turning the BL on or off, but looking at the pin
interfaces of this SPCA in the Nokia schematic, I don't see anything
even remotely related to the backlight... Yet the original firmware is
able to not only turn this BL on and off at will, but also change the
brightness - during calls, the display dims instead of blanking
completely.
On a related note, were you ever able to figure out the pinout of the
30-pin flex between the main PCB and the LCM? If this pinout were
known, I could probably trace out the stuff of interest to me (like
the backlight) on the main PCB using your layer pictures, but if I
have to reverse-eng the LCM itself, that might be a bit above my skill
level. :(
> Since the SPCA has an integrated 8051 core, you probably need to upload
> proprietary code to get the camera working, or you have to rewrite the
> firmware for this chip as well...
Bummer. But just out of curiosity, how did you figure out that it's an
8051? Did you see the original phone fw pushing something to the SPCA
that looked like 8051 instructions?
FWIW, the 554 datasheet describes its CPU as a "32-bit RISC processor"
- too closed to even name what it is!
Kim
Hello,
I finally got some time to play with OsmocomBB again. It works
intermittently on my Pirelli DP-L10: sometimes ok, other times MO call
attempts fail inexplicably and there are messages pouring in the vty
window about network contact being lost and reestablished.
I suspect that the lack of RF calibration may be an issue, especially
considering that I'm in PCS land whereas most active developers are in
EGSM/DCS. So I got this crazy idea: what if we can figure out where
and how the original factory calibration values are stored, and make
use of them? It looks like the last 64kb sector of the flash (at
0x027f0000 as seen by the cpu) is where the factory data are stored,
but the format looks incomprehensible. :(
So here's what I'm thinking: I would like to try putting JTAG on this
phone, and using a hardware watchpoint to catch where the proprietary
fw reads from the 0x027f0000-0x027fffff region.
I saw in the Wiki that there is an unpopulated footprint for a JTAG
connector, and upon taking my phone apart, I have confirmed that it's
there indeed. But I wonder, has anyone here (steve-m perhaps?)
actually used this JTAG interface and got it to work? If someone has,
I'd like to ask the following:
* What connector part did you populate on that footprint?
* What actual JTAG adapter gadget did you use?
* How did you connect that JTAG adapter gadget to the phone?
Thanks,
Kim
Dear Osmocom community,
I'm currently looking for one or multiple volunteers who are willing to
tend to the mailman 'moderator queue' of the various osmocom mailing
lists (baseband-devel, openbsc, simtrace, tetra, osmocom-pcu, ...)
Our lists are 'member posting only' to protect them from spam. This
means that spammers will be caught in the list moderation queue together
with the occasional legitimate message from a non-subscriber.
You need to manually look over that queue in the mailman web interface,
select those legitimate posts as 'approve' and 'defer' all others.
The task requires very few minutes, but it requires them every day or
second day. It is a perfect opportunity how non-developers can
contribute to the project :)
Please let me know if anyone is willing to take care of this. Thanks!
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi list,
Since getting Sylvain's transceiver to work with my C118, I started to look at scapy and specifically the gsm-um code as another interesting tool in the fuzzer's arsenal.
I see that Laurent Weber's personal website, http://0xbadcab1e.lu/scapy_gsm_um-howto.txt, where he apparently had posted some examples and tips on playing with his code, is no longer available.
Does anyone have a copy of those instructions? Has anyone tried running gsm-um with the TRX firmware? Any tips or pointers before I dive in?
Cheers,
Miguel
