gsm850 and host/layer23/src/mobile
246tnt at gmail.com
246tnt at gmail.com
Thu Jun 2 21:45:30 UTC 2011
> I'm testing on both a c118 and a c139.
If they're natively 850 / 1900 you might need to change in
src/target/firmware/board/compal/rffe_dualband.c , in the
rffe_get_rx_ports(), replace the PORT_DCS1800 by PORT_PCS1900 (to indicate
that the antenna high band output is connected to the RITA PCS port and not
the DCS port ... It's a board variation not handled by the build system ...)
But that shouldn't affect operation at 850.
> I'm using the remotes/origin/sylvain/testing branch and this does have
> quadband support. I've edited target/firmware/Makefile and defined
Is it with a recent checkout ?
In particular does it have this commit :
> The mobile program correctly scans the frequency ranges and finds a good
> tower and then attempts to do a location update. It generates a RACH
> channel request and then (appears to) send it.
> The problem is that the phone never receives an immediate assignment
> response. The log shows multiple immediate assignments received, but
> none match the request reference (RA and FN the burst was sent in.)
When I was in the US, I tested this and had the exact same problem, so when
I came back I did some testing and found some wrong settings in the RFFE
for the 850 band using a spectrum analyzer and I fixed them.
But obviously I couldn't test with a real BTS (because I'm not in the US
and the racal 6103e doesn't support GSM850)
The main symptom was a very weak signal viewed by the spectrum analyzer ...
but obviously the USRP can't actually "trigger" off a particular signal so
I'm not sure if you can measure that.
> The only test I have done so far is to monitor the uplink frequency with
> a USRP (uhd_fft.py) during the location update procedure. It looks like
> the phone is actually transmitting at the correct times, but I am not
> positive. (I'd have to write some custom code before I can definitively
> say one way or the other.)
You might have to do that ... If you have two receive board you can
probably capture the BCCH and uplink at the same time and if you do a time
capture 'long enough' the RACH power spikes should be obvious. and then you
can check where they are in relation to the FCCH.
> The only other idea I have right now is that perhaps the timing advance
> calculation is incorrect. There are a couple of constants used without
> any explanation and I guess it is possible that these constants don't
> work for my configuration. I'm going to start going through these
> constants to determine if I can find a value that works.
There is no timing advance whatsoever during a RACH ...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the baseband-devel