blob: 491693c6c3d0f703fab3c44166beaed2a0c97779 [file] [log] [blame]
dburgessb3a0ca42011-10-12 07:44:40 +00001The Transceiver
2
3The transceiver consists of three modules:
4 --- transceiver
5 --- radioInterface
6 --- USRPDevice
7
8The USRPDevice module is basically a driver that reads/writes
9packets to a USRP with two RFX900 daughterboards, board
10A is the Tx chain and board B is the Rx chain.
11
12The radioInterface module is basically an interface b/w the
13transceiver and the USRP. It operates the basestation clock
14based upon the sample count of received USRP samples. Packets
15from the USRP are queued and segmented into GSM bursts that are
16passed up to the transceiver; bursts from the transceiver are
17passed down to the USRP.
18
19The transceiver basically operates "layer 0" of the GSM stack,
20performing the modulation, detection, and demodulation of GSM
21bursts. It communicates with the GSM stack via three UDP sockets,
22one socket for data, one for control messages, and one socket to
23pass clocking information. The transceiver contains a priority
24queue to sort to-be-transmitted bursts, and a filler table to fill
25in timeslots that do not have bursts in the priority queue. The
26transceiver tries to stay ahead of the basestation clock, adapting
27its latency when underruns are reported by the radioInterface/USRP.
28Received bursts (from the radioInterface) pass through a simple
29energy detector, a RACH or midamble correlator, and a DFE-based demodulator.
30
31NOTE: There's a SWLOOPBACK #define statement, where the USRP is replaced
32with a memory buffer. In this mode, data written to the USRP is actually stored
33in a buffer, and read commands to the USRP simply pull data from this buffer.
34This was very useful in early testing, and still may be useful in testing basic
35Transceiver and radioInterface functionality.