Hi,
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 CONFIG_TX_ENABLE.
Is it with a recent checkout ?
In particular does it have this commit : 16ec2358a014f290be47e87e3489f98769681979
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 ...
Cheers,
Sylvain