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.
Can you please clarify how to re-assemble the full 33-byte traffic data structure from the burst_ind messages?
GSM 05.03
Thanks!
I'd like to believe that we already have code that does the work somewhere in the Osmocom project, even if it does it partially. 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!
Can you please point me in the right direction?
Thanks for your prompt replies.
B.
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
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@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
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
But I see two problems:
- Almost every alternate frame is missing.
... TCH/H ...
- 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
Sylvain, thanks for the prompt replies. But...
But I see two problems:
- Almost every alternate frame is missing.
... TCH/H ...
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.
- 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.
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.
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
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-burs... Sent from the baseband-devel mailing list archive at Nabble.com.
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@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-burs... Sent from the baseband-devel mailing list archive at Nabble.com.
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@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@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-burs... Sent from the baseband-devel mailing list archive at Nabble.com.
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-burs... Sent from the baseband-devel mailing list archive at Nabble.com.
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@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-burs... Sent from the baseband-devel mailing list archive at Nabble.com.
baseband-devel@lists.osmocom.org
-
Bhaskar11 -
Pe -
Sylvain Munaut