Hi,
I was wondering if anyone heard of a nanoBTS without EFR support ?
I have one here that responds with BIND_NACK if the codec is EFR but works ok if I set V1
Sylvain
On Saturday 21 November 2009 00:19:12 Sylvain Munaut wrote:
Hi,
I was wondering if anyone heard of a nanoBTS without EFR support ?
I have one here that responds with BIND_NACK if the codec is EFR but works ok if I set V1
No idea, I just know it reboots when CRCX/binding EFR on a TCH/H.
z.
@Oystein: From the ML archive, I see you have a close version match, does EFR works on your nanoBTS ?
A little more infos for reference: The two nanoBTS are both 1800 round model (non-edge). Both 139 but one is 139_ and the other is 139U. I can't see any visible difference in the PCBs of both. I found what I think is the jtag port to the ppc, I might try to dump the flash ... As far as I can tell, the only non-volatile storage are the 4 flash chips next to the MPC855. 4 chips of 1Mx16, that's 8Mo of firmware.
The one where EFR doesn't work: - Marking on the side: nanoBTS model 139_ - ipaccess-find infos: Location 2='BTS_NBT131G' Equipment Version='111_029_23' Software Version='120a002_v149b42d0'
The one where EFR works: - Marking on the side: nanoBTS model 139U - ipaccess-find infos: Location 2='BTS_NBT131G' Equipment Version='139_029_41' Software Version='120a352_v267b22d0'
Sylvain
On Sat, Nov 21, 2009 at 12:19:12AM +0100, Sylvain Munaut wrote:
Hi,
I was wondering if anyone heard of a nanoBTS without EFR support ?
I think it is extremely unlikely, as all nanoBTS have been built long after EFR was introduced. I could imagine them not supporting AMR, but even that seems unlikely.
I have one here that responds with BIND_NACK if the codec is EFR but works ok if I set V1
meybe it's related to the RTP PAYLOAD TYPE IE or something like that...