Sounds very interesting, the Spartan-6 FPGA SP601 Evaluation Kit may be a capable and not expensive (295$) model with GbE.
So 700$ for the USRP, 550$ for 2 RFX-900s / 2 RFX-1800s and the 295$ for the FPGA kit, that will be 1545$ for either a full GSM900 or GSM1800 Sniffer, or 1840$ to have the possibility to do both? can anybody confirm that the RFX1800 general i/o lines can be accessed the same way as for the RFX900? (btw. what about these threads on the gnuradio-mailinglist about converting a rfx1800 to a rfx900 and backwards..? is that possible?) best regards On Tue, 2010-01-05 at 07:47 +0300, coredump wrote: > On Mon, 04 Jan 2010 13:06:17 +0100, Clemens Gruber <[email protected]> > wrote: > Hi, > > > see this listing of the nokia 3210 hardware: > > https://www.pqgruber.com/other/Portable.pdf > > Maybe we can use similar parts and build our own peripheral perfectly > > fitting our needs.. it should be much cheaper than 2 usrp2s with > > daughterboards etc. > > if there are enough interested people, it will be possible. > > > > on the other hand, the idea of combining a usrp1 with a new fpga-card > > (spartan, virtex, ...) sounds very good because the fpga seems to be the > > bottleneck. > > does anybody know if it's possible to create a fast > > data-transfer-connection between these 2 devices? > > I have read a bit in this usrp/gnuradio documentation > http://www.scribd.com/doc/9688095/USRP-Documentation and found some > interesting information to your question: > > -- > > Page 11: Daughterboards / Basic TX/RX Daughterboards > "[..] The BasicTX and BasicRX give direct access to all of the signals on > the daughterboard interface (including 16 bits of high-speed digital I/O, > SPI and I2C buses, and the low-speed ADCs and DACs). Each of the Basic > TX/RX boards has logic analyzer connecters for the 16 general purpose IOs. > These pins can be used to help debugging your FPGA design by providing > access to internal signals." > > Page 39 to 43: Digital I/O Pins Control Questions > [..] > * Each daughterboard has 16-bits of general purpose i/o. > * Setting the bit makes it an output from the FPGA to the daughterboard. > [..] > bool _write_oe (int which_dboard, int value, int mask); > [..] > I have the TV_RX board in slot B and Basic RX in slot A of the USRP. I am > trying to get the raw A/D data that comes into the FPGA, out on the > daughter card connector. I would like to use the 16-bit general purpose > debug pins from the FPGA on the connector on Basic RX. However, I’d like > to be careful before I write to the direction register using the _write_oe > given that an improper setting can cause damage. [..] > > -- > > It seems possible to get the raw data from the ADC (FPGA) through the debug > pins on the Basic RX/TX-Daughterboard. > Possible Setup #1: GSM data -> USRP: { Antenna -> RFX900 -> ADC -> (Onboard > FPGA for downconverting) -> Basic RX/TX} -> own FPGA-Card for > (downconverting,) demodulation (,decoding) and finally sending the relevant > binary data to the PC via GBe-Interface. > > It would be nice, if downconverting could be left on the onboard fpga, but > I could not find any more detailed information about. Decoding on the FPGA > will be too hard, sending only the demodulated data of active gsm channels > to the pc should be sufficient. With this setup we can theoretically use > the full 30Mhz bandwidth of one RFX900 daughterboard > (http://www.ettus.com/downloads/er_ds_transceiver_dbrds_v5b.pdf). > > In addition, it might be possible to put 2 RFX900 Cards in the USRP1 and > get the raw output data from the ADC using the 16-bits general I/O lines of > each RFX900 instead of the additional Basix TX/RX cards: > > -- > > See page 42 of the documentation: Q) I would like access to I and Q output > data (12 bits each) from ADC U601 using the debug headers from two RFX2400 > daughterboard [..] > > -- > > Perfect Setup #2: GSM data -> USRP: { 2x Antenna -> 2x RFX900 -> ADC -> > Onboard FPGA for downconverting -> 2x RFX900 general I/O lines} -> own > FPGA-Card for demodulation, decoding and finally sending the relevant > binary data to the PC via GBe-Interface. > > Hard work, but this might be a setup for full GSM900 capturing > (up&downlink: 2x25Mhz) with one USRP1 at moderate hardware costs (and much > lower cpu utilization). > > regards > > > > > On Mon, 2010-01-04 at 14:16 +0330, p q wrote: > >> thanks for the last two questions > >> this was also the important facts that nobody mentioned them . to do > >> a successful attack to A5/1 enabled GSM you need to capture signal on > >> a wide-band style meaning you need to capture all the bands that may > >> have carrier on them . this is highly depended on the network > >> configuration specially the design on BTS . > >> > >> > >> real world BTSs are offering services on different bands and calls are > >> always get handover between the bands due to radio resource > >> management . for a sucsessful GSM interception you at least need to > >> capture Downlink . considering the current opensource and cheap > >> hardware you can simple forget to capture both uplink and downlink , > >> that's just not possible . > >> > >> > >> to capture Downlink of a BTS that offers GSM1800 you need to capture > >> at least 75 MB of the spectrum space . this is far more than USRP and > >> also beyond USRP2 > >> yes its possible to do this on GSM900 but you have to first find a BTS > >> that only offers downlink on GSM900 and this is not going to be easy > >> > >> > >> the idea of being able to build the RF part of a GSM interceptor that > >> works on real world BTSs across the world using cheap stuff like USRP > >> is just delusional . never gonna happen . this is another truth about > >> this work . giving ourselves promises that's just not technically > >> possible is not going to go far > >> > >> > >> what is possible to do ? it is possible to build a GSM900-only capture > >> system using at least two USRP2 and still it depends on the number of > >> TRXs that's installed on the BTS . if we want to go out there and > >> really capture data from a real BTS we need to consider these things > >> before getting ahead of ourselves . a two-unit USRP2 system might be > >> able to fully capture the downlink of a real BTS operating in GSM900 > >> only in a not so crowded area > >> > >> > >> i saw people are fantasizing this work to put it on some hacker CD > >> like Wifi and WEP stuff . i'm going to go out and say it : people , > >> this is far more complicated and more expensive than that . this is > >> all just because of the expensive and close nature of cellular network > >> business and RF problems , not just because of the cryptography like i > >> said before A5/1 is just a part of the problem . even if we can prove > >> we can crack A5/1 which is not happened yet next step is the real pain > >> in the ass > >> > >> > >> regards > >> > >> > >> > >> > >> On Mon, Jan 4, 2010 at 1:58 PM, Gregory Maxwell <[email protected]> > >> wrote: > >> [Please don't send HTML mail to mailing lists] > >> On Mon, Jan 4, 2010 at 4:31 AM, p q <[email protected]> > >> wrote: > >> > > >> > USRP even in a two-unit configuration is no good since it > >> can not handle GSM1800 > >> > >> > >> I was under the impression that provider allocations are still > >> no more > >> than 10mhz wide in the 1800mhz band, are they not? > >> > >> > >> _______________________________________________ > >> A51 mailing list > >> [email protected] > >> http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51 > > > > _______________________________________________ > > A51 mailing list > > [email protected] > > http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51 _______________________________________________ A51 mailing list [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
