Dobrica Pavlinušić's random unstructured stuff
osmocom: Revision 11
Contents


voice info

17:42 < dpavlin> stupid question about by first experiment with osmocom-bb 
http://blog.rot13.org/2011/01/osmocom-bb_-_free_software_finally_comes_to_gsm.html - are hex 
                 numbers I see scroll by voice data by any chance or controll stream?
17:42 < steve|m> dpavlin: that's the voice_ind
17:43 < steve|m> http://bb.osmocom.org/trac/changeset/a4e34316c403a49ca57fd907e55a16b721629e35/src
17:43 < steve|m> so maybe revert this commit in your local branch if you don't need that 
                 (transferring voice data to the host)
17:45 < dpavlin> Great. With something like pipe I could go a long way :-)
17:46 < dpavlin> Can I inject it over serial port? For something like text2speech?
17:46 < steve|m> tnt has code for that, but he hasn't committed it yet
17:46 < steve|m> jolly even has written an interface to LCR
17:49 < dpavlin> I would love to help test it, if such help is needed.

19:21 < dpavlin> tnt: do you have any pointers to information about calypso voice format I can read?
19:23 < dw> the code? :)
19:26 < dpavlin> I tried reading code under src/target/firmware/calypso but I'm probably looking in wrong place, 
                 because I'm not closer to understanding voice.raw format than I was few days ago.
19:30 < steve|m> dpavlin: looked at 
http://bb.osmocom.org/trac/browser/src/target_dsp/calypso/dsp_sniff.S?rev=d1cb8ea9b784c7acbafbb2fdcedbdf4655c2f6f5 ?
19:31 < tnt> steve|m: that's not for voice.raw
19:31 < tnt> There is just no written reference anywhere of the buffer format.
19:31 < steve|m> ah, sorry, confused that..
19:44 < tnt> dpavlin: from memory, it's all the class 1 bits, then some bits always at 0 (4 bits IIRC), then all the 
             class 2 bits of a GSM 610 frame.  They're packet in 16 bits works, MSB first

1297284215 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> I have a question about burst_ind branch of bb
@1297284218 <mkf00!~mkf00@85-127-108-141.dynamic.xdsl-line.inode.at> hallo
@1297284279 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> In l1ctl_burst_ind I understand that the two stealing bits are in bits 58 & 59 (without the training)
@1297284286 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> is this correct?
@1297284318 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> this is because I think that both must be the same bit 0 for data/voice and 1 for FACCH
@1297284347 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> tnt?
@1297284376 <tnt!~tnt@mojito.smartwebsearching.be> no it's not correct
@1297284389 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> uhm!
@1297284391 <tnt!~tnt@mojito.smartwebsearching.be> the two stealing bits are at the end, the DSP puts them there.
@1297284439 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> both are together?
@1297284440 <tnt!~tnt@mojito.smartwebsearching.be> On the air you are correct they're in the middle but during the packing, the DSP puts the 2*57 bits and then the two stealing bits at the end.
@1297284538 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> from my code:
@1297284542 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> <0001> layer3.c:418 LEO BURST: 58 93 b5 f6 95 37 9c 83 f7 f1 95 f2 62 fd 10
@1297284605 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> we don't need the first 4 bits
@1297284618 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> but the next one is 1
@1297284633 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> only one stealing bit filled?
@1297284671 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> only one stealing bit with 1?
@1297284908 <tnt!~tnt@mojito.smartwebsearching.be> Fatuo: yup. so ?
@1297284945 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> I thought that both must be the same....
@1297284983 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> Can be FACCH and voice/data in the same frame? I don think so...
@1297285078 <tnt!~tnt@mojito.smartwebsearching.be> well, you think wrong :)
@1297285108 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> oh
@1297285111 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> tanks :)
@1297285111 <tnt!~tnt@mojito.smartwebsearching.be> you need to re-read GSM 05.03. TCH has diagonal block interleaving.
@1297285148 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> ok, i will do right now, thanks a lot
@1297285149 <tnt!~tnt@mojito.smartwebsearching.be> so the 4 * 114 bits are split into 8 half bursts and sent over 8 bursts, half mixing with the next / prev frame.
@1297285247 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> I see
@1297285275 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> I'll go re-reading that doc
@1297285277 <Fatuo!~n0p@79.198.19.95.dynamic.jazztel.es> bye

A5/1

git clone git://git.srlabs.de/kraken

13:35 < tomash2> [Thu 13:56] Hi
13:35 < tomash2> [Thu 13:58] When receiving bursts via sylvain/burst_ind, is the frame number for uplink bursts correct?
13:35 < tomash2> [Thu 13:59] Assembled packets appear to be on differrent channel that uplink ones
13:35 < tomash2> [Thu 14:01] It works to do fn=fn-15 for unencrypted packets, but not for encrypted ones
13:35 < tomash2> [Thu 14:01] So how to get correct fn for uplink bursts?
13:35 < tnt> [Thu 14:06] the fn is correct, your code is wrong obviously ...
13:35 < tomash2> [Thu 14:08] Strange, downlink decrypting works, and I do uplink the same way...
13:35 < tomash2> [Thu 14:08] Thakns, I'll go to search for the bug...
13:35 < tnt> [Thu 14:10] ... then that's your problem.
13:35 < tnt> [Thu 14:10] uplink is _not_ same as downlink
13:35 < tnt> [Thu 14:10] the first 116 bits of A5 is for DL, then you need the 116 after that for UL.
13:35 < tomash2> [17:11] tnt: And these second 116 bits are computed from Kc and fn the same way as in uplink?
13:35 < tnt> [17:13] yup
13:35 < tnt> [17:13] 114 not 116 btw
13:35 < tnt> [17:13] stealing bits aren't ciphered
13:35 < tnt> [17:13] (afair)
13:35 < tomash2> [17:14] tnt: That's what I'm doing. But it is not working for uplink
13:35 < tnt> [17:15] well you're doing it wrong :)
13:35 < tomash2> [17:16] tnt: maybe :-)
13:35 < tnt> [17:16] your a5 keystream genreator should generate 228 bits of outpout per frame, the first 114 for DL the next 114 for UL.
13:35 < tomash2> [17:17] tnt: huh
13:35 < tnt> [17:17] That's what I told you above:
13:35 < tnt> [17:17] 14:10 < tnt> the first 116 bits of A5 is for DL, then you need the 116 after that for UL.
13:35 < tomash2> [17:17] so uplink bits are _not_ computed from fn of the uplink burst?
13:35 < tnt> [17:18] ... of course they are
13:35 < xorAxAx> [17:18] frame count!
13:35 < tnt> [17:19] xorAxAx: frame count is just another representation of fn ... (how to feed them in A5). If the DL decryption works, then that part is obviously correct.
13:35 < xorAxAx> [17:19] yeah
13:35 < tnt> [17:20] tomash2: for SDCCH the UL and DL are in different frame, so you would only use one of the pair of 114 bits ... but for TCH you'd use both.
13:35 < tnt> [17:21] but it doesn't matter ... UL is always the second and you _have_ to compute the first 114 bits of DL even if you won't use them.
13:35 < tomash2> [17:22] tnt: I'm talking about SDCCH all the time, I didn't try TCH yet...
13:35 < tnt> [17:22] and as I said : It doesn't matter ...

Neo

BTS