Have any of you heard of the Tayloe detector? It's a nice design described over here: www.flex-radio.com/Data/Doc/qex1.pdf . I wonder if it would be suitable for receiving GSM? The main drawback is that it needs a clock 4x the carrier frequency.
Long On Sat, Jan 9, 2010 at 6:07 PM, Alexander Chemeris <[email protected]> wrote: > Hello Clemens, > > We plan to launch home page about the same time as first > prototype. We're in planning and designing stage now, so > if you have something to discuss and want to influence the > final hardware design - we're open for discussions and welcome > you to contact us off the list. > > On Sat, Jan 9, 2010 at 19:02, Clemens Gruber <[email protected]> wrote: >> Hello Alexander, >> >> is there a project homepage of this sdr module suitable for running a >> bts or is it at the moment just an idea to make this kind of hardware? >> >> best regards, >> Clemens >> >> On Sat, 2010-01-09 at 13:02 +0300, Alexander Chemeris wrote: >>> On Sat, Jan 9, 2010 at 12:09, darren <[email protected]> wrote: >>> > But I will confess I am a bit bemused by the timescales being issued for >>> > hardware to be ready, with so many companies now offering cheap >>> > prototyping >>> > and PCB services why does it need to take 6 to 12 months to get a handful >>> > of >>> > boards available for testing and using ? >>> >>> I'm a software guy myself, so I know how it looks like for you. >>> In short: >>> 1) It's a part-time project for us at least until we find an investor. >>> You're welcome >>> to support the project by investing your money into it. >>> 2) This is not "just a clone". We're changing pretty a lot of USRP design. >>> 3) Long lead time and long manufacture time also add to the total. And >>> "cheap" >>> prototyping services are not that cheap, if you want high-quality and fast >>> manufacture. >>> 4) We need to debug hardware, which is not like debugging software. It >>> consumes >>> quite a lot of time. Especially when it comes to RF part. >>> 5) Then we need to write firmware and host software for our hardware, which >>> in turn should be debuged and tested. Mixed hardware-software debug is not >>> an easy task also. >>> 6) And then we should fix found bugs (time!) and put this into production, >>> which require just a lot of time to get everything settled. And not to >>> mention, >>> that it's likely we do at least one more prototyping cycle before >>> manufacturing >>> to ensure that everything is ok. >>> >>> So yes, we can produce something in two months, but it will be just buggy >>> hardware with not software - not what everyone want. >>> >> >> _______________________________________________ >> A51 mailing list >> [email protected] >> http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51 >> > > > > -- > Regards, > Alexander Chemeris. > _______________________________________________ > 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
