This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Joshua Lackey jl at thre.atQuoting 246tnt at gmail.com (246tnt at 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.