Quoting 246tnt(a)gmail.com (246tnt(a)gmail.com):
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 ...)
Yep, did that.
[...]
I'm using
the remotes/origin/sylvain/testing branch and this does have
quadband support. I've edited target/firmware/Makefile and defined
CONFIG_TX_ENABLE.
Is it with a recent checkout ?
In particular does it have this commit :
16ec2358a014f290be47e87e3489f98769681979
Yes, it is current as of yesterday evening and has that commit.
[...]
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.
Ah, good. It looks like you had to change trf6151_pll_tx() quite a bit.
Is there anything there that you are unsure of? Something I can test?
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)
I'll experiment with OpenBTS and try both GSM900 and GSM850
configurations.
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.
Well, I can monitor the uplink frequency and compare the signal
amplitude between the standard Motorola firmware and the osmocom code.
If there is still a weak signal problem, it should be fairly obvious.
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 ...
Erm, yes. The timing advance is calculated from where the RACH is
received. Thinking about it more, that code shouldn't be band-dependent
anyway.
If you have any other ideas, I'd be glad to test them out. I'll at
least try the above and figure out how strong the tx signal is. Not
sure what I can do after that though.