Hi,<br /><br /><br />> I'm testing on both a c118 and a c139.<br /><br />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 ...)<br /><br />But that shouldn't affect operation at 850.<br /><br /><br />> I'm using the remotes/origin/sylvain/testing branch and this does have<br />> quadband support.  I've edited target/firmware/Makefile and defined<br />> CONFIG_TX_ENABLE.<br /><br />Is it with a recent checkout ?<br /><br />In particular does it have this commit : 16ec2358a014f290be47e87e3489f98769681979<br /><br /><br />> The mobile program correctly scans the frequency ranges and finds a good<br />> tower and then attempts to do a location update.  It generates a RACH<br />> channel request and then (appears to) send it.<br />> <br />> The problem is that the phone never receives an immediate assignment<br />> response.  The log shows multiple immediate assignments received, but<br />> none match the request reference (RA and FN the burst was sent in.)<br /><br />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.<br /><br />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)<br /><br />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.<br /><br /><br />> The only test I have done so far is to monitor the uplink frequency with<br />> a USRP (uhd_fft.py) during the location update procedure.  It looks like<br />> the phone is actually transmitting at the correct times, but I am not<br />> positive.  (I'd have to write some custom code before I can definitively<br />> say one way or the other.)<br /><br />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.<br /><br /><br />> The only other idea I have right now is that perhaps the timing advance<br />> calculation is incorrect.  There are a couple of constants used without<br />> any explanation and I guess it is possible that these constants don't<br />> work for my configuration.  I'm going to start going through these<br />> constants to determine if I can find a value that works.<br /><br />There is no timing advance whatsoever during a RACH ... <br /><br /><br />Cheers,<br /><br />    Sylvain