24 Jan
2013
24 Jan
'13
5:21 p.m.
I'm experimenting with burst-ind branch and am able to track control
messages in ccch_scan.
I then send an Assignment Command to change to a traffic channel. I can see
the bursts come in, but cannot make out the format of the data.
If I understand right, the burst_ind structure holds 15 bytes of data, but
the traffic data should be 33 bytes. I assume the traffic data is spread
across several burst-ind messages.
Can you please clarify how to re-assemble the full 33-byte traffic data
structure from the burst_ind messages?
Thanks.
B.
8:08 p.m.
Can you please
clarify how to re-assemble the full 33-byte traffic data
structure from the burst_ind messages?
GSM 05.03
8:43 p.m.
Hi,
I see some interesting
code in rx_l1_traffic_ind() in l1ctl.c. But that already assumes 33 bytes
received. If possible I'd rather build on existing code that build from
scratch!
There is no code that does what's needed for traffic channels in
osmocom-bb. During normal operation, this is entirely dealt with
inside the DSP, and traffic_ind deals with some TI specific stuff that
has no relevance whatsoever in this case.
Can you please point me in the right direction?
again ... GSM 05.03
I will not repeat myself, a third time ...
Cheers,
Sylvain
26 Jan
26 Jan
8:17 p.m.
I'm able to track the channel and extract the data. But to detect end of
traffic I follow the similar code as in ccch_scan by checking the signal to
noise ratio of the bursts on the downlink but during SACCH bursts only.
In most cases app_state.dch_badcnt quickly climbs beyond 6, and the channel
is dropped within barely a second. Much of the traffic data bursts also
have a very low snr. Very occasionally, the channel stays on for 3 to 5
seconds, then drops. During these rare occasions the traffic data remains
with high snr for longer time also.
What am I doing wrong? Is this the right way to detect end of traffic data?
Is it normal for this channel to have low snr?
B
On Fri, Jan 25, 2013 at 1:13 AM, Sylvain Munaut <246tnt(a)gmail.com> wrote:
Hi,
I see some interesting
code in rx_l1_traffic_ind() in l1ctl.c. But that already assumes 33 bytes
received. If possible I'd rather build on existing code that build from
scratch!
There is no code that does what's needed for traffic channels in
osmocom-bb. During normal operation, this is entirely dealt with
inside the DSP, and traffic_ind deals with some TI specific stuff that
has no relevance whatsoever in this case.
Can you please point me in the right direction?
again ... GSM 05.03
I will not repeat myself, a third time ...
Cheers,
Sylvain
28 Jan
28 Jan
3:49 p.m.
I'm trying to decode TCH data using burst_ind. Below is info from the
frames as they come.
The SACCHs are correctly separated by 26 frames in the frame number so I
know the data is valid. I detect upload/download of frame by checking
(bi->flags & BI_FLG_SACCH).
But I see two problems:
1. Almost every alternate frame is missing.
2. I should not be seeing any upload frames, as I am not using
filter-rework.
Can you please guide me on what could be wrong?
Data received:
TCH/H (hl=1, hu=1) in FN=379183 DL SACCH
TCH/H (hl=0, hu=1) in FN=379183 UL SACCH
TCH/H (hl=1, hu=1) in FN=379185 DL
TCH/H (hl=1, hu=1) in FN=379185 UL
TCH/H (hl=1, hu=1) in FN=379187 DL
TCH/H (hl=0, hu=0) in FN=379187 UL
TCH/H (hl=1, hu=0) in FN=379189 DL
TCH/H (hl=0, hu=1) in FN=379189 UL
TCH/H (hl=1, hu=1) in FN=379191 DL
TCH/H (hl=0, hu=1) in FN=379191 UL
TCH/H (hl=1, hu=1) in FN=379193 DL
TCH/H (hl=0, hu=0) in FN=379193 UL
TCH/H (hl=1, hu=1) in FN=379195 DL
TCH/H (hl=0, hu=1) in FN=379195 UL
TCH/H (hl=1, hu=1) in FN=379198 DL
TCH/H (hl=1, hu=0) in FN=379198 UL
TCH/H (hl=1, hu=1) in FN=379200 DL
TCH/H (hl=0, hu=1) in FN=379200 UL
TCH/H (hl=1, hu=1) in FN=379202 DL
TCH/H (hl=1, hu=0) in FN=379202 UL
TCH/H (hl=0, hu=0) in FN=379204 DL
TCH/H (hl=1, hu=0) in FN=379204 UL
TCH/H (hl=0, hu=0) in FN=379206 DL
TCH/H (hl=1, hu=0) in FN=379206 UL
TCH/H (hl=1, hu=1) in FN=379208 DL
TCH/H (hl=0, hu=1) in FN=379208 UL
TCH/H (hl=0, hu=0) in FN=379209 DL SACCH
TCH/H (hl=1, hu=1) in FN=379209 UL SACCH
TCH/H (hl=0, hu=0) in FN=379211 DL
TCH/H (hl=1, hu=1) in FN=379211 UL
TCH/H (hl=1, hu=1) in FN=379213 DL
TCH/H (hl=0, hu=0) in FN=379213 UL
TCH/H (hl=1, hu=1) in FN=379215 DL
TCH/H (hl=0, hu=0) in FN=379215 UL
TCH/H (hl=1, hu=1) in FN=379217 DL
TCH/H (hl=1, hu=1) in FN=379217 UL
TCH/H (hl=1, hu=1) in FN=379219 DL
TCH/H (hl=0, hu=0) in FN=379219 UL
TCH/H (hl=1, hu=1) in FN=379221 DL
TCH/H (hl=0, hu=1) in FN=379221 UL
TCH/H (hl=1, hu=1) in FN=379224 DL
TCH/H (hl=1, hu=0) in FN=379224 UL
TCH/H (hl=1, hu=1) in FN=379226 DL
TCH/H (hl=1, hu=1) in FN=379226 UL
TCH/H (hl=1, hu=1) in FN=379228 DL
TCH/H (hl=1, hu=1) in FN=379228 UL
TCH/H (hl=1, hu=1) in FN=379230 DL
TCH/H (hl=1, hu=1) in FN=379230 UL
TCH/H (hl=1, hu=1) in FN=379232 DL
TCH/H (hl=1, hu=1) in FN=379232 UL
TCH/H (hl=1, hu=1) in FN=379234 DL
TCH/H (hl=0, hu=0) in FN=379234 UL
TCH/H (hl=1, hu=1) in FN=379235 DL SACCH
TCH/H (hl=0, hu=1) in FN=379235 UL SACCH
TCH/H (hl=1, hu=1) in FN=379237 DL
TCH/H (hl=1, hu=1) in FN=379237 UL
TCH/H (hl=0, hu=0) in FN=379239 DL
TCH/H (hl=1, hu=0) in FN=379239 UL
TCH/H (hl=0, hu=0) in FN=379241 DL
TCH/H (hl=1, hu=0) in FN=379241 UL
TCH/H (hl=0, hu=0) in FN=379243 DL
TCH/H (hl=0, hu=1) in FN=379243 UL
TCH/H (hl=0, hu=0) in FN=379245 DL
TCH/H (hl=0, hu=0) in FN=379245 UL
TCH/H (hl=1, hu=1) in FN=379247 DL
TCH/H (hl=0, hu=1) in FN=379247 UL
TCH/H (hl=1, hu=1) in FN=379250 DL
TCH/H (hl=0, hu=0) in FN=379250 UL
TCH/H (hl=1, hu=1) in FN=379252 DL
TCH/H (hl=1, hu=1) in FN=379252 UL
TCH/H (hl=1, hu=1) in FN=379254 DL
TCH/H (hl=1, hu=0) in FN=379254 UL
TCH/H (hl=1, hu=1) in FN=379256 DL
TCH/H (hl=1, hu=1) in FN=379256 UL
TCH/H (hl=1, hu=1) in FN=379258 DL
TCH/H (hl=1, hu=0) in FN=379258 UL
TCH/H (hl=1, hu=1) in FN=379260 DL
TCH/H (hl=0, hu=0) in FN=379260 UL
TCH/H (hl=1, hu=1) in FN=379261 DL SACCH
TCH/H (hl=1, hu=0) in FN=379261 UL SACCH
TCH/H (hl=1, hu=1) in FN=379263 DL
TCH/H (hl=0, hu=0) in FN=379263 UL
TCH/H (hl=1, hu=1) in FN=379265 DL
4:19 p.m.
But I see two problems:
1. Almost every alternate frame is missing.
... TCH/H ...
2. I should not be seeing any upload frames, as I am
not using
filter-rework.
The filters only attenuate the signal ... if the victim phone is close
enough, they will go through anyway.
Also, AFAIR the phone will transmit a burst_ind packet in anycase ...
which might be complete gibberish, that up to you to try to interpret
it.
Cheers,
Sylvain
8:54 p.m.
Sylvain, thanks for the prompt replies. But...
In your experience, up to what distance does this kind of interference come
in a typical scenario? Is it in the range of dozens of metres or hundreds?
B.
But I see two problems:
I re-read the specs: 05.03 / 3.2.4. If the data is spread across 4 blocks,
should that not mean some of the data will be on each successive burst?
The specs don't mention skipping alternate bursts. So, I still don't
understand why the entire burst would be missing alternately.
I seem to have missed something important here.
1. Almost every alternate frame is missing.
... TCH/H ... 2. I should
not be seeing any upload frames, as I am not using
filter-rework.
The filters only attenuate the signal ... if the victim phone is close
enough, they will go through anyway.
Also, AFAIR the phone will transmit a burst_ind packet in anycase ...
which might be complete gibberish, that up to you to try to interpret
it.
10 p.m.
Hi,
I re-read the specs: 05.03 / 3.2.4. If the data is
spread across 4 blocks,
should that not mean some of the data will be on each successive burst?
sucessive burst ... on the logical channel, not the physical channel.
You need to read 05.02 now.
The specs don't mention skipping alternate bursts.
Sure they do. You just haven't read them all yet.
I seem to have missed something important here.
Yes, it would seem so.
In your experience, up to what distance does this kind
of interference come
in a typical scenario? Is it in the range of dozens of metres or hundreds?
No idea, never did any testing beyond a single room.
Cheers,
Sylvain
31 Jan
31 Jan
4:08 p.m.
Hi, Bhaskar11
Did you resolve problem with low snr?
Do you make synchronization on SCH before going to TCH, after Assignment
Command?
--
View this message in context:
http://baseband-devel.722152.n3.nabble.com/Structure-of-traffic-data-in-bur…
Sent from the baseband-devel mailing list archive at Nabble.com.
1 Feb
1 Feb
6:12 a.m.
Yes, I send the command
l1ctl_tx_fbsb_req(ms, ms->test_arfcn,
L1CTL_FBSB_F_FB0 | L1CTL_FBSB_F_SB, 100, 0,
app_state.ccch_mode, dbm2rxlev(-85));
before switching channels.
Now most of the channels stick on for much longer, but a few drop within
seconds.
But I cannot know for sure if this has "worked" until I can decode and
recognise some FACCH commands.
On AMR HR I get data like:
TCH/H (hl=0, hu=0) in FN=1864368 DL SACCH
Detected FACCH (hl=1, hu=0) in FN=1864369 DL
Detected FACCH (hl=1, hu=0) in FN=1864371 DL
Detected FACCH (hl=1, hu=1) in FN=1864373 DL
Detected FACCH (hl=1, hu=1) in FN=1864375 DL
Detected FACCH (hl=1, hu=1) in FN=1864386 DL
Detected FACCH (hl=1, hu=1) in FN=1864388 DL
Detected FACCH (hl=1, hu=1) in FN=1864390 DL
Detected FACCH (hl=1, hu=1) in FN=1864392 DL
TCH/H (hl=0, hu=0) in FN=1864394 DL SACCH
Detected FACCH (hl=1, hu=1) in FN=1864395 DL
Detected FACCH (hl=1, hu=1) in FN=1864397 DL
Detected FACCH (hl=1, hu=1) in FN=1864399 DL
Detected FACCH (hl=1, hu=0) in FN=1864401 DL
Detected FACCH (hl=1, hu=1) in FN=1864403 DL
Detected FACCH (hl=1, hu=0) in FN=1864405 DL
Detected FACCH (hl=1, hu=1) in FN=1864408 DL
Detected FACCH (hl=1, hu=0) in FN=1864410 DL
TCH/H (hl=0, hu=0) in FN=1864420 DL SACCH
which does not look correct because I think the FACCH should be in groups
of 4.
Any explanations? Suggestions?
B.
On Thu, Jan 31, 2013 at 8:38 PM, Pe <oxccoxcc(a)yandex.ru> wrote:
Hi, Bhaskar11
Did you resolve problem with low snr?
Do you make synchronization on SCH before going to TCH, after Assignment
Command?
--
View this message in context:
http://baseband-devel.722152.n3.nabble.com/Structure-of-traffic-data-in-bur…
Sent from the baseband-devel mailing list archive at Nabble.com.
9:10 p.m.
Looks like the problem is because of DTX because the FACCH bursts vanish
during speech and return during pause.
Anyone has experience with DTX?
B.
On Fri, Feb 1, 2013 at 10:42 AM, Bhaskar11 <niceguy108(a)gmail.com> wrote:
Yes, I send the command
l1ctl_tx_fbsb_req(ms, ms->test_arfcn,
L1CTL_FBSB_F_FB0 | L1CTL_FBSB_F_SB, 100, 0,
app_state.ccch_mode, dbm2rxlev(-85));
before switching channels.
Now most of the channels stick on for much longer, but a few drop within
seconds.
But I cannot know for sure if this has "worked" until I can decode and
recognise some FACCH commands.
On AMR HR I get data like:
TCH/H (hl=0, hu=0) in FN=1864368 DL SACCH
Detected FACCH (hl=1, hu=0) in FN=1864369 DL
Detected FACCH (hl=1, hu=0) in FN=1864371 DL
Detected FACCH (hl=1, hu=1) in FN=1864373 DL
Detected FACCH (hl=1, hu=1) in FN=1864375 DL
Detected FACCH (hl=1, hu=1) in FN=1864386 DL
Detected FACCH (hl=1, hu=1) in FN=1864388 DL
Detected FACCH (hl=1, hu=1) in FN=1864390 DL
Detected FACCH (hl=1, hu=1) in FN=1864392 DL
TCH/H (hl=0, hu=0) in FN=1864394 DL SACCH
Detected FACCH (hl=1, hu=1) in FN=1864395 DL
Detected FACCH (hl=1, hu=1) in FN=1864397 DL
Detected FACCH (hl=1, hu=1) in FN=1864399 DL
Detected FACCH (hl=1, hu=0) in FN=1864401 DL
Detected FACCH (hl=1, hu=1) in FN=1864403 DL
Detected FACCH (hl=1, hu=0) in FN=1864405 DL
Detected FACCH (hl=1, hu=1) in FN=1864408 DL
Detected FACCH (hl=1, hu=0) in FN=1864410 DL
TCH/H (hl=0, hu=0) in FN=1864420 DL SACCH
which does not look correct because I think the FACCH should be in groups
of 4.
Any explanations? Suggestions?
B.
On Thu, Jan 31, 2013 at 8:38 PM, Pe <oxccoxcc(a)yandex.ru> wrote:
Hi, Bhaskar11
Did you resolve problem with low snr?
Do you make synchronization on SCH before going to TCH, after Assignment
Command?
--
View this message in context:
http://baseband-devel.722152.n3.nabble.com/Structure-of-traffic-data-in-bur…
Sent from the baseband-devel mailing list archive at Nabble.com.
12 Feb
12 Feb
1:16 p.m.
Hi, Bhaskar
I have the same problem with periodical channel dropping from snr 255 to snr
less then 10. It is not because of DTX, as i think. May be it is because of
handovers, but dropping is too often.
I did not use FACCH information yet.
Can you get a reference to document with facch decoding scheme? google didnt
help.
--
View this message in context:
http://baseband-devel.722152.n3.nabble.com/Structure-of-traffic-data-in-bur…
Sent from the baseband-devel mailing list archive at Nabble.com.
2:37 p.m.
You can know if it is DTX by checking for SID messages before it drops and
before it resumes. A simple way to check if it is DTX is to watch SNR
level during speech/pause.
If you are *not* using AMR, then you can check signal strength only for the
mandatory frames which are listed in TS 05.08 / 8.3.
FACCH specs will be in TS 05.03. But AFAIK it will not help for this
purpose.
You cannot Google these things. You will have to read the specs from
the 3GPP website http://www.3gpp.org/specification-numbering
B
On Tue, Feb 12, 2013 at 5:46 PM, Pe <oxccoxcc(a)yandex.ru> wrote:
Hi, Bhaskar
I have the same problem with periodical channel dropping from snr 255 to
snr
less then 10. It is not because of DTX, as i think. May be it is because of
handovers, but dropping is too often.
I did not use FACCH information yet.
Can you get a reference to document with facch decoding scheme? google
didnt
help.
--
View this message in context:
http://baseband-devel.722152.n3.nabble.com/Structure-of-traffic-data-in-bur…
Sent from the baseband-devel mailing list archive at Nabble.com.
4097
days inactive
4116
days old
baseband-devel@lists.osmocom.org
13 comments
3 participants
participants (3)
-
Bhaskar11 -
Pe -
Sylvain Munaut