the sign of a voice frame in the AMR codec

List overview All Threads
Download

newer

older

MOTO C 118 TP27 -- DLPWR...

GSM clock and phones

bob wisebob

12 Jul 2012 12 Jul '12

5:28 a.m.

Hi,List.

I am studying the TCH AMR codec;

I using the first 8 bits of any TCH frame block to decide whether it is a speech frame or a signal;

Although it will contain some non-speech frame; but I think it can capture all the speech frame and

the captured file can be decoded correctly. is that right?

Attachments:

attachment.html (text/html — 420 bytes)

Show replies by date

Harald Welte

12 Jul 12 Jul

9:07 a.m.

Hi Bob,

maybe it would be a good idea if you could introduce yourself, who you are, what you are working on, and in which context you are doing this.

You post a number of questions here, and expect people to help you. Unless we know if you are working on something useful, and will actually contribute that back to the community, why should somebody help you with those issues?

Also, your mails are often _very_ short and don't give a lot of context.

I don't want to scare you away, but just give you an explanation why your mails get so little feedback on this list. It's actually up to you to do something to change that.

Regards, Harald

-- - Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

lonelysurfer

1:28 p.m.

Hi Bob, I tried efr and fr in airprobe and your decoder but also without success. My filter for non voice frames is : /* Unpack (ignore hu/hl) */ osmo_pbit2ubit_ext(bt, 0, bi->bits, 0, 57, 0); osmo_pbit2ubit_ext(bt, 57, bi->bits, 57, 57, 0);

/* save stealing flags */ bt[114] = !!(bi->bits[14] & 0x10); // hl bt[115] = !!(bi->bits[14] & 0x20); // hu

if (bt[114] || bt[115]) { // printf("might be FACCH %x , %x\n", bt[114], bt[115]); return; }

You using the first 8 bits for indicating? Can you explain this?

-- View this message in context: http://baseband-devel.722152.n3.nabble.com/the-sign-of-a-voice-frame-in-the-... Sent from the baseband-devel mailing list archive at Nabble.com.

bob

13 Jul 13 Jul

2:25 a.m.

Hi firstly, you must Determine how your network code，whether it is EFR or AMR, it is Very different. secondly, I correct myself, the 8 indication is not fully true, it depend many things, I read the GSM0509, found this, I hope it can be use to you :

3.2.1 Frequent inband signalling for AMR codec mode adaptation 3.2.1.1 General aspects The codec mode information, which has to be transmitted on each link, consists of Codec Mode Indications and Codec Mode Commands in the downlink, respectively Codec Mode Indications and Codec Mode Requests in the uplink. Codec Mode Indications inform the receiver about the currently applied codec mode. Codec Mode Commands inform the other end about the codec mode to be applied on the other link. Codec Mode Requests inform the other end about the preferred codec mode on the other link. Codec mode information is transmitted inband in the speech traffic channel, using a part of its transmission capacity. The coding of codec modes in the inband signalling is given in subclause 3.4.1. Channel coding of codec mode information is specified in GSM 05.03 [4] for all frame types. Codec modes are constrained to change only every second speech frame. Codec Mode Commands/Requests and Codec Mode Indications are sub-sampled such that they occur only every second frame. Codec Mode Indications and Codec Mode Commands/Requests shall be transmitted alternating within consecutive speech frames. Both, Codec Mode Indication and Codec Mode Command/Request, shall be transmitted together within every RATSCCH frame.

3.2.1.3 Transmitter/Receiver Synchronisation The alternating transmission of the codec mode information requires synchronisation of transmitting and receiving ends, such that Codec Mode Indications and Codec Mode Commands/Requests are decoded in correct order. To ensure proper synchronisation, the codec mode information shall be transmitted aligned to the 26‑multiframe structure of the GSM system. For TCH/AFS, the default transmission phase shall be such that Codec Mode Indications are sent with speech frames having their first burst sent on TDMA frames 0, 8, 17 (modulo 26) in the uplink and TDMA frames 4, 13, 21 (modulo 26) in the downlink as defined in GSM 05.02 [3]. For TCH/AHS, the default transmission phase shall be such that Mode Indications are sent with speech frames having their first burst sent on TDMA frames 0, 8, 17 (modulo 26) or 1, 9, 18 (modulo 26) depending on the subchannel in the uplink and TDMA frames 4, 13, 21 (modulo 26) or 5, 14, 22 (modulo 26) depending on the subchannel, in the downlink, as defined in GSM 05.02 [3]. This default phase of the Codec Mode Indication in downlink direction is called "odd", the alternative phase, one speech frame shifted, is called "even". The phase in uplink is always the same and is never changed. At call set-up, after every successful handover and after a channel mode modify with consistent Multirate IE, the default phase (odd) shall be used in downlink direction. During a call, the phase of Codec Mode Indication may be changed in downlink by using a RATSCCH message. In case of handover failure and fall back to the BTS before the handover attempt, the phase before the handover attempt shall be used again (except if a RATSCCH procedure is pending, see section 3.2.2.2 bullet 6).

-- View this message in context: http://baseband-devel.722152.n3.nabble.com/the-sign-of-a-voice-frame-in-the-... Sent from the baseband-devel mailing list archive at Nabble.com.

4864

Age (days ago)

4865

Last active (days ago)

baseband-devel@lists.osmocom.org

3 comments

4 participants

tags (0)

participants (4)

bob
bob wisebob
Harald Welte
lonelysurfer