(This is a patch against the latest, as of last night, git master.)
If you enable PCS, you'll never make it out of power-measurement without this patch: (This should be applied by everyone.)
---8<--- diff --git a/src/host/layer23/src/mobile/gsm322.c b/src/host/layer23/src/mobile/gsm322.c index ce5e1e1..ffecfc3 100644 --- a/src/host/layer23/src/mobile/gsm322.c +++ b/src/host/layer23/src/mobile/gsm322.c @@ -300,11 +300,14 @@ uint16_t index2arfcn(int index)
int arfcn2index(uint16_t arfcn) { - if ((arfcn & ARFCN_PCS) && arfcn >= 512 && arfcn <= 810) + int is_pcs = arfcn & ARFCN_PCS; + arfcn &= ~ARFCN_FLAG_MASK; + if ((is_pcs) && (arfcn >= 512) && (arfcn <= 810)) return (arfcn & 1023)-512+1024; return arfcn & 1023; }
+ static char *bargraph(int value, int min, int max) { static char bar[128]; ---8<---
If you enable PCS, you'll never receive packets without this patch: (which I only include for e88 and e86 but it should work for others) (This should be applied if you don't use DCS in your area.)
---8<---
diff --git a/src/target/firmware/board/compal/rffe_dualband.c b/src/target/firmware/board/compal/rffe_dualband.c index f4b7361..5df1dfc 100644 --- a/src/target/firmware/board/compal/rffe_dualband.c +++ b/src/target/firmware/board/compal/rffe_dualband.c @@ -47,7 +47,8 @@ void rffe_mode(enum gsm_band band, int tx) /* Returns RF wiring */ uint32_t rffe_get_rx_ports(void) { - return (1 << PORT_LO) | (1 << PORT_DCS1800); + // return (1 << PORT_LO) | (1 << PORT_DCS1800); + return (1 << PORT_LO) | (1 << PORT_PCS1900); }
uint32_t rffe_get_tx_ports(void) diff --git a/src/target/firmware/board/compal_e86/rffe_dualband_e86.c b/src/target/firmware/board/compal_e86/rffe_dualband_e86.c index 25bb099..10459d9 100644 --- a/src/target/firmware/board/compal_e86/rffe_dualband_e86.c +++ b/src/target/firmware/board/compal_e86/rffe_dualband_e86.c @@ -51,7 +51,8 @@ void rffe_mode(enum gsm_band band, int tx) /* Returns RF wiring */ uint32_t rffe_get_rx_ports(void) { - return (1 << PORT_LO) | (1 << PORT_DCS1800); + // return (1 << PORT_LO) | (1 << PORT_DCS1800); + return (1 << PORT_LO) | (1 << PORT_PCS1900); }
uint32_t rffe_get_tx_ports(void)
---8<---
hi joshua,
i applied the patch for gsm322.c. i cannot apply the patch for rffe_dualband.c, because i am not into it. maybe anyone else can review it.
best regards,
andreas
i applied the patch for gsm322.c. i cannot apply the patch for rffe_dualband.c, because i am not into it. maybe anyone else can review it.
Nothing to review really ... if you apply it it'll break all DCS users. There is no way to detect which phone submodel we run on.
Cheers,
Sylvain
Hi Joshua,
What problems are you having with osmocom-bb? It works fine for me on 850/1900 using the sylvain/testing branch (i think that's what it was) with similar patches to yours (the only difference is a patch related to simreader).
Nik
I was going to say that I got sylvain/testing to work after a bit of playing around with. But I figured it was a useless thing to say unless I typed up the details. (Which I haven't done yet.)
On Thu, Nov 15, 2012 at 3:02 PM, Nikola Kozina nkozina@ryerson.ca wrote:
Hi Joshua,
What problems are you having with osmocom-bb? It works fine for me on 850/1900 using the sylvain/testing branch (i think that's what it was) with similar patches to yours (the only difference is a patch related to simreader).
Nik
Hi Sylvain and others,
On Thu, Nov 15, 2012 at 11:59:27AM +0100, Sylvain Munaut wrote:
i applied the patch for gsm322.c. i cannot apply the patch for rffe_dualband.c, because i am not into it. maybe anyone else can review it.
Nothing to review really ... if you apply it it'll break all DCS users. There is no way to detect which phone submodel we run on.
We should probably have a better solution than to manually patch the source. I could imagine:
1) build a DCS and a PCS version of the firmware images 2) have the user set a #define that is evaluated in the RFFE 3) simply include DCS and PCS support in the firmware builds and rely on a configuration file / 'mobile' to define what bands to use
What do you think?
Hi,
We should probably have a better solution than to manually patch the source. I could imagine:
- build a DCS and a PCS version of the firmware images
That would require de-duplicating all the code for each target ... it's already a pain as it is.
Or we just give up the idea of building all the fw image all the time and have like a menuconfig system, but that's a massive build system change.
- have the user set a #define that is evaluated in the RFFE
Changing define or changing a DCS into PCS in a file doesn't change much. People won't read the doc anyway.
- simply include DCS and PCS support in the firmware builds and rely on a configuration file / 'mobile' to define what bands to use
mobile has a config file ... But it specifies which band to use, not the RF port on the RITA to use.
There are (I have one) PCS phone that have the DCS input of the RITA connected and not the PCS one. (They're pretty much symmetrical, not internal differences)
So that RFFE config specifies which internal RF port is connected, not the band to use. Then the internal sw logic will try to find how to configure the switch (like if mobile asks for a PCS ARFCN but the RFFE config says only the DCS RF port is connected, it will try using that port and not the PCS port of the RITA where there is nothing connected).
Cheers,
Sylvain
Hi,
There are (I have one) PCS phone that have the DCS input of the RITA connected and not the PCS one. (They're pretty much symmetrical, not internal differences)
OTOH, It seems there isn't all that many of those phones (only the J100i and nobody really uses it AFAIK), the properly wired ones are more common.
So the RFFE config could reflect that both DCS and PCS are wired and then it would just work for most users in normal situations.
The down side is you then can't longer use a PCS phone in DCS band or a DCS phone in the PCS band ...
Cheers,
Sylvain
baseband-devel@lists.osmocom.org
-
Harald Welte -
jolly -
Joshua Lackey -
Nikola Kozina -
Sylvain Munaut