I'm having issues getting the mobile application to work and I'm wondering if this is a gsm850 problem. I have a couple of debugging ideas but I thought I would post here just in case the answer is obvious to someone else.
I'm testing on both a c118 and a c139.
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.
I have a valid SIM in my phone that works with both phones using the default Motorola firmware. The 'sim reader 1' command is able to gather (most of) the necessary information. (The access class is not correctly read from the SIM but I haven't bothered tracking down why yet -- I just hardcoded an access class of 0xffff.)
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.)
So it appears that the tower never receives the channel request I send.
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.)
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.
Any other ideas to try here? Anyone else gotten this to work in the US?
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
Quoting 246tnt@gmail.com (246tnt@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.
Hi,
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?
No, I looked at it again this morning and it looks fine.
You can try to enable the warning (define at the top of the file) It shouldn't throw any (check that DCS is disabled in your mobile config or else it will throw some when doing power measurement in a bad band for your phone).
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.
Ah yes, I guess I could test with OpenBTS as well.
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.
Yes, but with _fft software alone it's not easy because RACH is very short and so what you see on the screen is not really the power. A real analyzer can be set to trigger on power level to capture 'only' the RACH and analyze the power in that.
A time graph might work tough. (or possibly waterfall with a very short fft size).
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.
You can look at the parameter chosen in the trf pll settings (A / B / Band) and post them here along with the ARFCN so I can check if they've been selected correctly.
I don't have much other ideas.
Cheers,
Sylvain
baseband-devel@lists.osmocom.org
-
246tnt＠gmail.com -
Joshua Lackey