21 Apr
2010
21 Apr
'10
9:19 a.m.
Hi,
I've hacked something together to quickly test non-combined CCCH.
However, I've hit a problem when trying to receive anything on another
timeslot than 0.
The TX side seems to work fine as the BTS can see my location update
request and answers with a reject, but on the MS side, I never see the
reject and wireshark only shows invalid incohrent data on the RX.
The frames for SDCCH/8 show really nothing valid (looks like random
bytes), things like
09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36
...
while the frames for the associated SAACH show at least something gsm-like :
03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
but that's not quite a SI5/6 ...
To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 *
156.25) when I'm in dedicated channel mode by chaning the 'start' in
l1s_tx_win_ctrl / l1s_rx_win_ctrl
Is there something else that should be done ?
Cheers,
Sylvain
21 Apr
21 Apr
9:27 a.m.
Hum, ... I just made a fool out of myself :)
The frames for SDCCH/8 show really nothing valid
(looks like random
bytes), things like
09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
That actually looks like SI5
09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe
6c 4f 56 4f 36
and that kinda looks like SI6
So maybe the problem might be else where ... time to look into LAPDm ...
Sylvain
10:16 p.m.
Some more infos ...
1) I changed the mframe_schedule a bit so that when changing task, we
deactivate the first then wait a little before activating the next
one. I think it would have been possible that previous MF task
scheduled something that would conflict with the new MF task ...
2) I replaced the SDCCH8_0 task with a custom one :
static const struct mframe_sched_item mf_rx_all_nb[] = {
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 0 },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 4 },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 8 },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 12 },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 16 },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 20 },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 24 },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 28 },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 32,
.flags = MF_F_SACCH },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 36,
.flags = MF_F_SACCH },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 40,
.flags = MF_F_SACCH },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 44,
.flags = MF_F_SACCH },
{ .sched_set = NULL }
};
This basically is RX only and receives all SDCCH and SAACH on the timeslot.
When I do this, I see the good data on SAACH and SDCCH correcponding
to subchannel 0. (everything else is garbage).
But if I try a custom task that just RX subchannel 0 :
static const struct mframe_sched_item mf_rx_all_nb[] = {
{ .sched_set = NB_QUAD_FH_DL, .modulo = 51, .frame_nr = 0 },
{ .sched_set = NB_QUAD_FH_DL, .modulo = 2*51, .frame_nr = 32,
.flags = MF_F_SACCH },
{ .sched_set = NULL }
};
Then, it doesn't work, I don't see the SI5/6 messages on SAACH.
Cheers,
Sylvain
20 Jul
20 Jul
3:38 p.m.
Hello Sylvain
I am using the burst_ind branch and have some doubts.
I am using a test network, and it has no encryption. Usually the n/w has a
low load and the channel structure followed during the assignment is
SDCCH/4 + SACCH/C4 or CBCH(SDCCH/4). and timeslot 0 .
The ccch_scan is able to capture the SMS sent on timeslot 0 and also only
one of the subchannel as per the above assignment.
Just for testing, When I use two phones and send an SMS from both of them
simultaneously both are assigned timeslot 0 and different subchannels.
CCCH_scan could capture only one SMS. meaning that it could only get one
subchannel.
Am I right about ccch_scan or does it have the capability to get a complete
timeslot. ?
Thank you
Altaf
--
View this message in context:
http://baseband-devel.722152.n3.nabble.com/Receiving-on-TS-1-tp739307p40252…
Sent from the baseband-devel mailing list archive at Nabble.com.
4:03 p.m.
DO NOT just reply to a 2 year old thread with a question that has
nothing to do with the original subject without even bothering to
change it ...
Learn to use a mailing list properly ... if you don't have the time to
do that, well then I don't have the time to answer your question
either ...
Cheers,
Sylvain
4:12 p.m.
I apologize about this.
--
View this message in context:
http://baseband-devel.722152.n3.nabble.com/Receiving-on-TS-1-tp739307p40252…
Sent from the baseband-devel mailing list archive at Nabble.com.
4312
days inactive
5133
days old
baseband-devel@lists.osmocom.org
5 comments
2 participants
participants (2)
-
Altaf -
Sylvain Munaut