Re: [Discuss-gnuradio] Broadcast FM is crap!
On Sun, Feb 19, 2012 at 03:19:21PM -0500, Marcus D. Leech wrote: > So, on a related topic, how do commercial FM-MPX receivers maintain > proper balance between > L-R and L+R -- do they just have a gain control that they tweak at > the factory and glue in place? > > If the gain balance is off, separation starts to go to heck really > quickly. And obviously, you can't use > AGC, since that would cause a lot of noise to be injected when the > L-R channel was mostly zero. There is a well known design trick... the level of the DSBSC difference signal in the FM baseband was chosen such that if you sample the FM baseband out of the FM detector - including the stereo subcarrier energy - in phase with the suppressed 38 KHz carrier (eg on peaks or troughs of the suppressed carrier) you get either L or R depending on whether the samples are on carrier peaks or troughs. In effect the difference signal sideband phasors either add (L+R) + (L-R) producing 2L or subtract it a half cycle later producing 2R. This of course simply requires correct frequency response of the FM detector and deemphasis network and suitable flat group delay for good stereo separation... rather than carefully matched gain of the baseband and subcarrier path. -- Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [alanhen...@aim.com: [Scan-DC] Warning of increased GSM + TETRA attacks]
GoMo News February 13, 2012 Monday 12:43 PM EST Warning of increased GSM + TETRA attacks LENGTH: 471 words Rating: We're back to Squidgygate and police radio scanners again Here's a bit of an ominous warning. Much worse than mere voicemail hacking. Greg Jones, a director of wireless security specialist, Digital Assurance, is warning of the dangers posed by the increasing availability of low cost software defined radio (SDR) solutions. He says, "It's extremely likely that criminal gangs, hacktivists and others will all show a growing interest in [SDR]. And we're not just talking about the hacking of individual mobile phones here but the possible compromise of critical infrastructure." In a nutshell, what Mr Jones is suggesting is that thanks to SDR it's no longer possible to assume that calls made over commercial and specialist wireless networks are inherently secure. We're back to the bad old days when ham radio enthusiasts could list into analogue cellular calls. Who remembers the infamous Squidgygate tapes, for example?There's nothing inherently evil about SDR technology. In effect, its arrival has helped to make devices like cellular phones c heaper by dispensing with the need for multiple, dedicated wireless chipsets. So what's going on? Jones says, "Those attempting to compromise wireless communications systems in the past have used expensive equipment coupled with advanced signal analysis skills." This is a reference to the fact that breaking standard GSM signals previously required a supercomputer. Not any more, apparently. "SDR devices typically use a standard PC to capture and manipulate radio spectrum potentially allowing an attacker to capture and demodulate advanced radio systems which were previously inaccessible to the hacking community," Jones explains. He doesn't actually mention it but if that 'standard PC' includes a laptop we could be in deep trouble. Think innocuous white van sitting outside your home/office. Which advanced systems is he talking about? Well, the list includes mobile networks such as GSM, Wi-fi, WiMAX, DECT and even TETRA. So that's not just your mobile phone, your laptop and your cordless phone - we're also looking at hacking emergency services. Think police radio scanners used by crooks to know if they've been detected yet. Just to make the point Jones even names the tools a budding SDR hacker needs. The USRP (Universal Software Radio Peripheral) coupled with open source software like GNU Radio. Oops. What particularly worries GoMo News is the potential to 'spoof' a GSM base station and intercept the calls you think you are making to your bank. Jones is a master of understatement. "If one were to consider the implications of a co-ordinated attack against a critical communications system over say London - even if the attack were restricted simply to signal jamming - the potential is there to cause massive disruption," Greg Jones stated. Olympics 2012, anyone? __ Scan-DC mailing list Home: http://mailman.qth.net/mailman/listinfo/scan-dc Help: http://mailman.qth.net/mmfaq.htm Post: mailto:scan...@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html - End forwarded message - -- Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [noaaport] NOAAPORT DVB-S2 VCM Question
On Sat, Jun 11, 2011 at 07:40:54PM +0300, Patrik Tast wrote: > Hi All, > > As you all know, VCM is short for Variable Coded Modulation. > > As I have read on your forum, the new DVBS-2 NOAAPORT transmission is > variable. > So far I have noted that users use 8PSK demodulation and FEC?. > FEC?, due to users use AUTO most likely (search all HW supported FEC and lock > when found, I guess it is 9/10?). > http://www.novra.com/Website/Novra_Products-Receivers-S200.html VCM is a standardized optional mode of DVB-S2. It allows each S2 frame of data to be sent in a specified and changeable modulation. The actual modulation used is one of the standard set available in S2 ranging from QPSK to 32APSK... with any of the standard FECs from 1/2 to 9/10. All VCM implies is that rather than using the same modulation all the time for everything it can be changed by the transmitting end on the fly as conditions or requirements change. Unfortunately for those in possession of normal demodulators designed for CCM (Constant Coding Modulation) the ability to read and understand the BPSK FEC 1/2 control messages and headers/sync words when the demod is set to the actual modulation used for the data doesn't exist for the most part and such demods will treat such as errors and perhaps drop lock or fail to recognize valid data frames properly even though the data is actually in a format they understand. This applies even if the data is ALWAYS in the same format. A proper VCM demod chip will read the header and control message and set up to the required modulation and FEC fast enough to recover the frame transmitted in that format. This can be used to partition traffic into a high and low priority stream or streams with different modulation parameters, but need not be. A receiver receiving a VCM stream sees a series of frames one after the other and separated by the BPSK control messages and special sync headers, some it may be able to relaibly demodulate without uncorrected errors, some not depending on Eb/No (carrier to noise). If the data is partitioned into different classes sent with different modulation a driver for such a chip would have to sort out the frames it was interested in from those it wasn't and forward them on to higher layers of processing as needed. This might be implemented as multiple separate streams sent to multiple separate endpoints, or as the whole stream forwarded as received with frames that got garbled marked as such for sorting out by upper layers. As far as I currently understand it, NOAAPORT is not yet (or maybe ever) transmitting different priority streams using different modulations - but they could. But as implemented currently the modulation used on all the NOAAPORT streams can be changed from time to time as reception conditions at critical sites deteriorate.Without VCM doing this would require that all demods in the entire system be subject to being switched by remote control from modulation to modulation dynamically by some sort of control mechanism via some highly reliable path - with VCM this reliable path is built into the signal as the BPSK FEC 1/2 control messages are very robust and repeated regularly in the signal stream. And such switches can be done without losing any data. Further a demod that has been off line and comes on line will be able to immediately determine the mode in use, rather than having to search or wait for some kind of off line command message. The downside is that VCM is not currently supported by cheap DVB-S2 demod cards... though that is coming. -- Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] udp source - endianness anomaly?
On Mon, Oct 12, 2009 at 11:16:11AM +1300, Richard Clarke wrote: > Hi All, > > I was wondering if anyone has had any issues with the interpretation of > shorts by the GNU Radio udp source function, when the shorts are > transmitted from a big endian based platform? In my situation I am > transmitting UDP packets comprised of 16 bit samples from an AVR32 (big > endian) which utilises the LWIP open source TCP/IP stack. On my GNU Radio > destination PC (Intel Pentium D CPU, little endian) I construct a simple > flowgraph (using GRC/GNU Radio v3.2.1) with a UDP source set to interpret > incoming data as shorts, into the short to float block and then straight > into the GUI scope. I'm receiving the UDP packets OK which I assume means > that all the protocol header info is being interpreted with the correct > endianness, but the waveform displayed in the scope is corrupt, until that > is, I manually re-order the LSB and MSB of the transmitted samples at the > AVR32 end. Normally the lower level network code would take care of byte > reordering as required to match network byte order to the relevant host byte > order, however this doesn't appear to be happening correctly on the GNU > Radio side. I must be missing something simple here, can anyone shed some > light? > Is there a good reason to have packets in something other than network byte order (to match the IP headers) ? -- Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New external clock board for USRP
On Fri, Sep 25, 2009 at 12:00:34AM +0400, Alexander Chemeris wrote: > Power will be taken from USRP 6V, clock output will be SMA to > connect to USRP directly. Frequency control will be accessible > over RS-232 (aka COM-port) with simple text-based protocol. We're > going to use ATMega for this. Ideally we want tighter integration > with USRP, so it can be controlled via the same USB connection, > so you can control clocks right from GnuRadio. But to date we can't > figure out how to do this cleanly. All suggestions are welcome. Have you any sense of how much additional phase noise - sampling clock jitter - the ATMega will introduce compared to the TXCO Matt uses ? This impacts SNR... especially with higher nyquist n subsampling. -- Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Carrier Phase Recovery
On Sat, Apr 04, 2009 at 11:16:42PM +0500, Sajjad Sarwar wrote: > I am doing my UG project on "optimized packet radio" in SDR. Presently, I am > using costas loop block but i think it's recovering only the frequency of > local oscillator but not the phase. Please correct me if i am wrong. Now the > problem is i dont want to use dqpsk because it would cause a 3dB loss of > power to attain the same BER which would kill the aim of optimization. So > please give me some solution for "phase recovery" so that i can use simple > qpsk without differential coding. Thank you. A Costas loop WILL recover phase on a QPSK signal, but with a pi/2 (90 degree) phase ambiguity meaning there are 4 possible mappings of the constellation points to bits (four possible rotations of the constellation). The usual way of handling this is to try all four possible rotations to see which one provides correct low error rate decoding of the FEC code used. Only one will have a zero or low error rate, the others will be full of errors. Convolutional or other related inner FEC is almost universally used with QPSK in actual practice - often with Vitirbi or other soft decision decode - so this falls out for free. It is also possible to look for a specific preamble/sync pattern in a burst (packet) environment, especially if that pattern is chosen to be unambiguous across the four possible rotations of the constellation (eg only one of them produces the correct pattern). -- Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] implement d8psk on benchmark_tx.py
On Mon, Feb 16, 2009 at 08:30:26PM -0800, Firas Abbas wrote: > Hi, > > > On Tue, 2/17/09, George Nychis wrote: > > > Hello, Tianning/Bill/Daniel! > > > > The performance of 8PSK matches pretty similarly to 16-QAM. > > So, 8PSK is usually never used in a real system as you get > > better spectral efficiency with 16-QAM without taking a huge > > hit in required SNR. > > > > - Rick Stevens > > 8PSK modulation is widely used by VSAT modems for SCPC-SCPC links. And for both DTH (DirecTV and Dish HD) and broadcast/cable satellite signal distribution... witness the DVB-S2 8PSK modes being rapidly deployed and the older DSNG-trellis 8PSK. It is prefered for the non-linear environment of satellite transponders with significant HPA compression... 16-QAM takes better linearity... and many satellite channels are power rather than BW limited. -- Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
On Fri, Mar 21, 2008 at 04:23:00PM -0500, Rick Parrish wrote: > Jeff Brower wrote: > >All the standardized codecs that I know of, both ones with IP rights > >requirements and free ones, provide a reference design, typically > >fixed-point C code plus test vectors. I wonder why DVSI has not done > >the same. > > Perhaps the APCO and TIA committees did not require it when the > algorithm was published ten years ago. I'm sure there was a bit of negotiation to get the best available vocoder technology and still preserve MIT's and DVSI's interests. A full reference implementation in C would have been immediately employed by a variety of entities seeking to use the technology without the royalties and control DVSI and MIT wanted - anything published like that would have been impossible to control. And history indicates they made a choice that served their interests well - radio hobby and hacker and far east clone (read "Chinese copy") use of P25 IMBE on a PC or in unlicensed hardware has not been a major issue for 10 years, though no doubt more than a few versions do exist outside of official DVSI licensees. It is hard to believe this would have been true if the standard came with C source code... regardless of its license status and the formal restrictions on using it. And this has no doubt made it easier to collect revenue from the hefty fees for licenses... if only because at least some major users haven't been as annoyed by hobby software that scares their law enforcement customers away from P25 + IMBE as they no doubt would have been if unofficial copies of the C from the standard were available and in wide use in PC radio hobby software. It is at least probably true that at least two common VHF/UHF non P25 digital radio systems that currently are not supported by readily purchased scanner would be readily monitorable by the general public if IMBE source was available, even with the potential patent infringement involved - and I am sure this hasn't escaped notice. -- Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
On Wed, Mar 19, 2008 at 07:38:13PM -0500, Rick Parrish wrote: > Jeff Brower wrote: > >If you're looking at low bitrate codecs for GNU radio, why use a > >hardware (dongle)dependent solution? You might look at MELPe, which > >provides 600, 1200, and 2400 bps,and can be implemented as a software > >solution. MELPe is a US/NATO standard (STANAG4591). Common > >applications are HF radio and L band satellite apps where bandwidth is > >very limited. > My interest is what is actually being used - which in the case of public > safety communications is the P25 variant of IMBE. FWIW, a closed source > PC hosted IMBE vocoder exists now. Is this a DVSI licensed and publically available closed source module or something "unofficial" or not generally available to the world at large ? It has obviously long been possible to recode some reverse engineered DSP chip based IMBE implemenation into C++ source code for Wintel/Unix/BSD use, but this would not be free of license and patent issues... and could not be made part of an open sourced project or product without a DVSI deal (and it appears they don't see this as in their interest). -- Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Frequency Offsets in RFX 2400
On Fri, Jan 11, 2008 at 06:46:46AM -0800, Johnathan Corgan wrote: > David I. Emery wrote: > > > A hack I have thought about adding to the USRP FPGA code (but not > > implemented yet) would allow collection of the count in a > > continuously rolling 64 MHz counter driven by the current 64 MHz > > clock on a rising or falling edge of a 1 PPS signal brought in on > > some spare pin and stuff this value in a register that could be read... > > I think would be very easy to do in the Verilog. Is there a simple > (read cheap) PPS generator I could purchase? Yes, several... Many GPS receivers (notably the Motorola Oncore series and it's successor the M12/M12+) have a highly accurate 1 PPS output when they are locked to the satellite constellation. Typical accuracy of the 1 PPS when seeing good satellite coverage in timing mode is around 20 ns from true UTC. Motorola Oncore family receivers are often available on Ebay used or NOS for around $20-50.The M12+ is available new for reasonable prices as well. Many other GPS devices output a 1 PPS pulse of varying accuracy and stability, most are accurate to under 1 us though many of those will have several hundred ns jitter and wander on the 1 PPS. And for those who want something better, there are lots of surplus time and frequency reference boxes that show up on eBay surplus from CDMA cell sites. These contain a 10 MHz OCXO or rubidium standard disciplined by GPS to typical accuracies in the part in 10^10 to 10^11 or better area and usually provide precision 10 MHz with low phase noise, high short term stability and very good long term accuracy when GPS locked. They also provide a 1 PPS locked to GPS derived from the 10 MHz and usually ASCII RS-232/422 output of the time of day once a second. Small units of this sort - notably made by Datum, Trimble (Thunderbolt and successors) and Symmetricom are quite often available on Ebay for prices in the $100-$400 area. The Z3801A/Z3816A made by HP (now Symmetricom) is very popular with hams and available on eBay and sometimes at Hamfests - these contain one of HP's best OCXOs... (the 10811 family). > Is the standard PPS output compatible with the GPIO pins on the USRP > (voltage, drive level, rise time, etc.)? Most GPS 1 PPS is 5 volt TTL level. As such I think they will work with the USRP FPGA, but I defer to experts on the exact rules of signals for that (too lazy to look it up) usually the 1 PPS is fairly heavy drive current and can drive significant lengths of 50/75 ohm cable (though that varies - the Oncore receivers don't have as mogey drivers I don't believe). Any interested in this topic should look up the time-nuts mailing list at febo.com... -- Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Frequency Offsets in RFX 2400
On Thu, Jan 10, 2008 at 08:46:09AM -0600, LRK wrote: > > While the 'right' fix would be to supply a stable frequency source to > the USRP, it would be difficult. Not impossibly difficult... it would, however, have been nice to have a VCXO option for the USRP-1 that would have allowed external phase locking circuitry to phase lock the 64 MHz to something without significantly impacting phase noise (AKA clock jitter) of the 64 MHz when not phased locked (or for that matter, when phase locked). It is quite a bit easier to use some fairly straightforward external PLL hardware to lock a 64 MHz clock by tweaking an EFC DC voltage input than it is to actually generate a clean, low phase noise external 64 MHz clock and import it correctly to the USRP so clock jitter (and thus S/N of the ASC sampling) is as good as with the current oscillator. > > Next best would be an 'offset' or 'calibration' value in the environment > which would be included in the frequency calculations. This should be an > indication of the error at 64 MHz and scaled. Thus '+914.125 Hz' at 64 MHz > would cause a 914.125 x 35.15625 = +32137 Hz correction at 2250 MHz > (which is what I need at this moment :). > This change is acutely needed... and everything that computes a frequency based on the 64 MHz timebase should use it... > And best in the future would be a source on the USRP which could just > lock itself to a 1PPS signal from a GPS at 0-5 volt levels. I'm not sure I want Matt and Eric to do an entire GPSDO as part of a new USRP... much better to just build a USRP clock generator that takes the universal standard reference frequency of 10 MHz as an input like most all of the world's current test equipment and many radios and most satellite and telecom gear... 10 MHz GPSDOs are a standard item - readily available and highly accurate (and even pretty cheap on Ebay) and no other reference frequency is as widely used. And one can find cheap surplus ex-telcom rubidiums that will supply 10 MHz within parts in 10^10th or so if one doesn't want to (or can't) use GPS as a reference but still needs accurate frequency. A hack I have thought about adding to the USRP FPGA code (but not implemented yet) would allow collection of the count in a continuously rolling 64 MHz counter driven by the current 64 MHz clock on a rising or falling edge of a 1 PPS signal brought in on some spare pin and stuff this value in a register that could be read via the I2C mechanism. I think this takes few enough FPGA resources to be doable with the current USRP code, but again I haven't tried it yet. This would allow software in gnuradio to compute frequency error every second (or whatever rate the ticks came in at) by determining whether the time stamp on the 1 PPS edge was early or late relative to the count of 64 MHz clocks. A while back I proposed a more general and less inelegant approach involving passing back time stamp messages in the data stream in the new message passing format based on such external pin events as a 1 PPS and I hope this eventually gets implemented, but simply providing a register that contains the clock count sampled on the last rising (or falling) edge of an input signal is pretty simple and should allow real time compensation for frequency error and drift of the TXCO clock at a rate sufficient to solve the frequency error problem for many applications - if not all of them - provided one has a suitable source of an accurate reference clock at some useful frequency (typically 1 PPS, but other values like 1 or 10 KHz are possible). -- Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Soft-DVB working flawlessly
On Mon, Nov 26, 2007 at 11:18:53AM -0700, Chuck Swiger wrote: > Quoting John Clark <[EMAIL PROTECTED]>: > > >John Gilmore schrieb: > >>I can already think of one use that others can make of your > >>transmitter. EFF and I are interested in measuring the DRM responses > > I am interested in a dvb-s receiver, but if I understand correctly > most open/free satellite transponders are wider than our current 8MHz > bandwidth. Yes, and no. Most signals you might be interested in are, but not all ... there are lots and lots of SD DSNG signals from satellite news trucks with symbol rates around 3978.7 Ksym/sec (a standard for a 5.5 Mbs transport stream with 3/4 FEC) and a few other rates near that in use. These signals should be narrow enough to work with the USRP. I am hoping the USRP II will have the resources to do full transponder DVB-S and DVB-S2 stuff in some mode or another - there is definately a need for this for signal analysis/transponder IDing... -- Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on US digital cable ...
On Tue, Aug 14, 2007 at 10:55:40AM -0400, Vijay Ramasami wrote: > Thanks for the information David. I will look up ITU-J.83B ... > > Do you happen to have any captured QAM cable data (or any website that > lists the data) ? I wanted to see if I can put together a software > demod for digital cable ... Not conveniantly available... -- Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on US digital cable ...
On Mon, Aug 13, 2007 at 10:52:54AM -0400, Vijay Ramasami wrote: > Hi, > > I have a couple of questions: > > 1. Does the US digital cable system follow the DVB-C standard (or one > of its annexes) ? Is there any information (website) on the typical > symbol rates, bandwidths (I am guessing approx 6 MHz), used ? There is a Cablelabs spec that defines what is used. The ETSI standards (ITU-T J.83B) also define the particular parameters as well. I can look up detailed references if needed... The are actually only two standard modulations in wide use 64QAM with a particular set of parameters that yields a 30 Mb/s signal with a 5.056941 Msym/symbol rate and a 256QAM signal which yields a 38.9 Mb/s signal with a symbol rate of 5.360537 Msym/s Both signals are 6 MHz wide as US CATV is universally 6 MHz channel based. > 2. Has anyone successfully captured (preferably unencrypted) digital > QAM transmissions using the USRP ? If so, can you please send me a > link to the data ? Given that the symbol rates are in the range of 5-6 > Ms/s, it must be possible to use 16 MHz sampling frequency to > demodulate the signals. > I have used a number of purpose built demods, but not yet tried a USRP solution. Some of the cable transport streams have open channels, but you will find most are encrypted except the local OTA HD signals and a few freebie promos. It is also possible to MODULATE QAM cable standard signals, something that gets more useful every month as more QAM/ATSC tuners are shipped for cable ready setups with CableCards rather than set top boxes. This of course allows direct input of MPEG transport streams into the digital domain of LCD/plasma panels with no analog step... -- Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Freq center auto adjust
On Mon, Mar 12, 2007 at 10:45:14AM -0700, Johnathan Corgan wrote: > This is typically call Automatic Frequency Control and shortened to AFC. > > Accomplishing AFC is modulation specific; in GNU Radio one typically > builds a flow graph that incorporates AFC by using an appropriate > phase-locked loop. Probably I am quibbling terribly, but mostly AFC implies a frequency locked loop... usually used to correct the LO frequency so a signal sits in the center of the passband. Sometimes the VCO (NCO) frequency offset of a PLL IS used for this, but it doesn't have to be... -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] No BPSK modulator?
On Tue, Feb 27, 2007 at 11:01:58PM -0800, Matt Ettus wrote: > > >(which makes me > >curious, does anyone use non-differential 8PSK?). > > > > Yes, satellites often do. I might add that non differential PSK/QPSK has a theoretical noise advantage if some mechanism exists to figure out the correct initial rotation and not lose it later on. And this is often pretty easy to do when using convolutional code inner FEC from the FEC correction which works with few errors for only one of the two or four possible rotations. Basicly best case in differential modulation an error in detecting a symbol causes TWO bit errors in the data while a single symbol error in absolute phase, non-differential modulation causes only one bit error in the data before FEC. -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RDS / TMC / DAB / DVB-S/T ?
On Sat, Oct 14, 2006 at 02:06:01PM -0400, Robert McGwier wrote: > David I. Emery wrote: > > > > This implies that the USRP with a 6 to 8 mhz bandwidth might be > >able to successfully demodulate the SCPC DVB-S QPSK video transmissions > >at symbol rates like 3.9876 megasymbols/sec (5.5 mbs transport stream at > >FEC 3/4) commonly used by satellite trucks for news feeds. Most of > >these signals carrying single channel NTSC video (720 by 480 MPEG 2) run > >at either 3.9 megasymbols/sec or 4.2 megasymbols/sec. > > As is typical of many signals of this type (geostationary satellite > signals), it needs very little dynamic range, mostly enough to > accomodate weather and multipath fades but not what would expect to have > to accommodate on a different type of FDM channel where you could see > serious near-far problems. I suspect the 8 bit DDS might work nicely > indeed here. In fact many of the chip sets used to implement DVB modems (and other satellite QPSK demodulators) in the early days before highly integrated mixed signal ASIC stuff took over used actual 6 or 8 bit A/Ds feeding the digitry - either digitizing IF or I and Q from a downconversion. If I remember correctly some of the early Stanford Telecom chips only accepted 6 or even 4 bits of I and Q. Obviously typical satellite receiver designs which work over an IF power range from around -65 to -70 dbm to around -30 dbm or so include AGC - usually controlled by the signal processor digitally to set the power at the constellation points to a nominal value (in vector space). And equally obviously, the USRP has the hardware on board to do just that. The loop bandwidth for this AGC is uncritical - satellite carrier powers change slowly with weather fade and antenna motion (mostly unintended of course) and satellite motion - one needs hundreds of milliseconds here, not hundreds of hz. There are some of us looking at using the USRP for making measurements on, characterizing modulation parameters of, and demodulating satellite BPSK, QPSK, OQPSK, and 8PSK signals. There are obviously very many of these, as few other modulations are employed on the bent pipe repeaters of modern communications satellites. And using the DBSRX daughter board allows coverage of the IF range of most modern LNBs - for S, C, X, Ku, and Ka and K bands. And it also directly covers the 1.5 and 1.6 ghz L band frequencies used for mobile satellite service (INMARSAT, Iridium, Globalstar). -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RDS / TMC / DAB / DVB-S/T ?
On Sat, Oct 14, 2006 at 06:49:03AM -0700, Eric Blossom wrote: > The USRP could receive the raw signals for DVB-T in the 6 and 7 MHz wide > channel format. The 8 MHz wide version could be somewhat degraded > because of filter rolloff at the edges of the passband of the digital > downconverter in the FPGA. Shifting to 8-bit I&Q would allow the full > 8 MHz wide signal to fit across the USB at the expense of dynamic range. > > I'm not sure of the bandwidth required for DVB-S and thus can't comment. DVB-S as used for video is usually upwards of 3 megasymbols/sec as this kind of data rate is required to support sufficient transport stream bandwidth for adequate distribution grade video. Many of the actual signals on satellite, however, are multiplexes of multiple video and audio streams sent at symbol rates as high as 26 to 29 megasymbols/sec. Currently almost all signals are QPSK (NOT DQPSK, absolute phase counts) although the standards permit 8PSK and even 16QAM. 8PSK IS used for some HDTV feeds (notably the US broadcast networks ABC and NBC and the Canadian network CBC) and some HDTV backhauls. Roughly speaking, the actual rf bandwidth required to demodulate QPSK is perhaps 1.1 to 1.2 times the symbol rate with a higher sampling rate than that probably necessary to get good results. This implies that the USRP with a 6 to 8 mhz bandwidth might be able to successfully demodulate the SCPC DVB-S QPSK video transmissions at symbol rates like 3.9876 megasymbols/sec (5.5 mbs transport stream at FEC 3/4) commonly used by satellite trucks for news feeds. Most of these signals carrying single channel NTSC video (720 by 480 MPEG 2) run at either 3.9 megasymbols/sec or 4.2 megasymbols/sec. Making it demodulate the wider band signals used for video distribution and HDTV is probably not possible, nor for that matter is the processor bandwidth required to munch the samples any more likely available than that required to handle ATSC (though demodulating satellite QPSK on a nice clean linear channel off the satellite should take MUCH less compute than ATSC with equalization and so forth). There are a few DVB-S signals that run at unusually low data rates (hey it's cheap since satellite charges are based on bandwidth and power used) down to as little as 1.6 megasymbols/sec. And the same basic modulation is sometimes used for sending audio streams like Muzak for stores and restaurants at lower rates. These doubtless could be demodulated by the USRP. Obviously the back end compute required to munch sample streams this fast is not inconsiderable - processing DVB-S requires estimating and tracking carrier phase and recovering symbol clock and then doing Vitirbi (k=7 trellis) on the resultant low pass filtered I and Q sample stream. The only good thing here is that a satellite transponder is a benign medium with no multipath or amplitude/delay distortion to speak of, thus elaborate FIR filters with huge numbers of taps are not needed to compensate for this as they are for ATSC. As for the underlying data - many signals are in the clear (almost all satellite truck newsfeeds are for example) and contain standard MPEG 2 transport streams that can be displayed by existing open source utilities. Some others, of course, are encrypted (mostly with DES) and not accessible. -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Homing in on the mystery of Pulsy McGrooder
On Wed, Sep 13, 2006 at 10:05:56AM -0400, Marcus Leech wrote: > >>There are double pulses that I'm seeing, with variable timing between > >>the main pulse > >>and the sub-pulse. The other 1350Mhz radar is much further away from > >>me, but > >>perhaps the "sub pulses" I'm seeing are coming from the other radar > >>station, and > >>they're drifting in and out of phase with respect to one another. The > >>sub pulses > >>are weaker than the main pulses by quite a bit. > > > The timing difference between the "main" and "sub pulse" varies between > a fraction of > a second, and about 1.5 seconds. OK, you confused me (awfully easy to do these days as I sink into senility) because I think of radar related events on a microsecond and not a second scale. Obviously more or less the only thing happening on a second scale is antenna rotation. And I believe when you speak of "pulses" you mean BURSTS of pulses. PRF of radars tends to be in 100-500 hz area typically in this kind of application so almost certainly what you are seeing is clusters or bursts of tens or more probably hundreds of pulses - not individual couple of microsecond or so duration typical pulsed radar pulses. And now it is obvious to me you were referring to the inter burst interval and not the inter pulse interval. All of which leads me to comment that either the two radars you think might be responsible are remarkably well synchronized in rotation speed (which is possible I guess but I tend to think unlikely), or your observations are not over a long enough period to see them drift more randomly out of phase, or you are seeing something in the antenna pattern of one SINGLE radar that results in multiple lobes pointing toward you. This could be features in its antenna pattern (such a broad secondary beam and a narrow primary beam) or due to reflections off some distant but highly reflective object not exactly between you and the radar but capable of reflecting a significant amount of energy your way when illuminated by the radar at peak intensity. Remember that the reflections off aircraft I mentioned in my last comments would be expected to show up not only at the azimuth of the radar when the radar is pointed right at you but when the radar is pointed in other directions - eg at the aircraft, illuminating that particular aircraft well with its beam. This would imply that aircraft echoes would appear on other azimuths as seen by you than the main beam of the radar and more importantly at DIFFERENT times in the seconds timescale rotation of the radar than when the main lobe sweeps directly by you. And yes, moving aircraft would result in the time interval between the peak of the reflected energy from the aircraft and the main lobe of beam sweeping past you changing over seconds or minutes. But because they are reflections from the beam of that one radar they would always relate in timing to the rotation of that antenna and the timing of the main direct path lobe as observed by you. This is not of course true of a second radar. One possible way to distinguish between energy from a second radar on approximately the same frequency and reflections off aircraft or other reflectors not directly between you and the radar is to determine if the PRF of the secondary burst energy is exactly the same as the PRF of the primary lobe as it sweeps by you. There is a pretty good chance that the "other" radar would not use exactly the same PRF (no obvious reason to) and if it didn't and that is what you were seeing you'd see two distinctly different "buzz" frequencies which ought to be obvious with a suitable measurement (eg a FFT of the low pass filtered detected video). > > I plan to acquire a narrower filter than I'm currently using. I > estimate that the > new filter has about 55dB of rejection at 1350. That should help > some, although the > sideband components from such a radar are also something to think about. They tend to filter them pretty well in the radar in order to keep them from causing problems out of band. > > Another odd feature of this pulse noise is that it prefers to appear at > night, although > it also appears during the day sometimes, too. My theory is that > during the day, > my sidelobe noise is dominated by the Sun, with the radar pulses not > being able > to compete. Whereas at night, there's no Sun noise for the radar > pulses to > compete with. Sun noise is pretty damn weak compared to your estimate of -40 dbm for the radar.But obviously such a phenomenon as you describe (sun noise in the sidelobes) should show up as huge diurnal variation in background directly correlated with the movement of the sun across the sky. This should be pretty obvious from your data independent of the radars. > My other theory is that perhaps the ERP of the radar is pumped up at > night for some > reason, or simply that propagation is
Re: [Discuss-gnuradio] Homing in on the mystery of Pulsy McGrooder
On Tue, Sep 12, 2006 at 08:01:51AM -0400, Marcus Leech wrote: > David I. Emery wrote: > > > > The transponders are 1090/1030 mhz and not 1350. 1350 is just > >radar. > > > There are double pulses that I'm seeing, with variable timing between > the main pulse > and the sub-pulse. The other 1350Mhz radar is much further away from > me, but > perhaps the "sub pulses" I'm seeing are coming from the other radar > station, and > they're drifting in and out of phase with respect to one another. The > sub pulses > are weaker than the main pulses by quite a bit. I very much doubt that the "other radar" is responsible for the secondary pulses you see unless they arrive at a distinctly different time in the 5 second (I think you said earlier) rotation cycle of the radar. I presume from your description that each main pulse is either proceeded or followed (by some short (us) interval that is unclear from what you have written) by a weaker secondary pulse. Almost certainly two independent radars would operate at slightly different PRF's (depending on how old they are that might be by a percent or two or for more modern gear by the difference in typical crystal oscillators in the two time bases, perhaps 10-100 ppm in usual cases). This would result in a steady phase change between the pulses each pulse - if you can measure it you'd presumably find it basically linear in microseconds per pulse. But because their antenna rotations are unlikely to be accurately synchronized and the chance of their beams both pointing at you at the same time slim it would be unlikely to find the pulses of one present at the same time in the five second antenna rotation cycle as the other at least for any extended period. And very unlikely that the relative strength of the strong pulse and weak pulse would remain the same as the two antennas swept past you from different distances. Likely one would peak before the other and this could obviously result in one being stronger for a while and then the other becoming the strong one. It does sound to me like one of two other explanations is at work here. Either you are seeing actual echos (reflections off aircraft or ground based scatterers) which would of course always follow the main pulse by some time interval that would depend on the additional path length. Or the other explanation is that the radar deliberately radiates a secondary pulse before or after the primary one (sometimes from a different feed on the antenna). Actual real live echoes from aircraft strike me as quite possible to pretty probable at least unless you have a direct line of sight to the radar and can actually see it in the distance and therefore see such walloping huge signal from it that any echoes are too weak by comparison to be visible within the dynamic range of your gear. Likely the "direct" path involves Fresnel scattering and lots of attenuation by foliage and the like and is many tens of db more lossy than the free space path loss equation would suggest. And likely reflections from passing planes and perhaps even certain fixed mutually visible scatterers like towers or mountains involve direct unobstructed paths from the radar to the target (airplane) and from the target (airplane) to you. These would have much less attenuation by close to the ground propagation effects than the nominally direct path, and while a reflective target often scatters energy more or less in all directions (thus the fourth power law of returned signal in the classic radar equation) this energy can still be considerable relative to a trans horizon direct path if little or no energy is lost by close to the ground absorbers and scatterers in the reflected path. And if you see the delay between main pulse and secondary moving with time, well flying airplanes do move with time too... What you have of course is a simple bistatic radar system. The other possibility would be more likely if the delay between the runt pulse and the main one was constant. Some radar systems, especially those intended to operate with active transponders on the target, transmit a secondary pulse using an antenna with a different pattern. Typically these secondary antennas have a broader beam pattern than the primary beam so the secondary pulse is stronger relative to the primary pulse except when the primary antenna is pointed right at the target. Used with a transponder that can distinguish between primary and secondary pulses this allows the transponder to only reply when it sees the primary pulse stronger than the secondary pulse indicating the antenna is pointed right at it. This of course is important if the transponder (eg aircraft) is near the antenna (with low free space path loss) as it may see enough signal from antenna sidel
Re: [Discuss-gnuradio] Homing in on the mystery of Pulsy McGrooder
On Mon, Sep 11, 2006 at 11:30:47PM -0500, Rick Parrish wrote: > *giggle* > > Marcus ... that's an aircraft transponder. Except for some vintage > 1930's aircraft that don't have an electrical system - every plane / > helicopter has one. Hit Google or Yahoo! for "Mode-C" and "Mode-S" > transponder. > > The ground radar "pings" the aircraft's transponder (interrogation). The > transponder sends back a reply. Some replies carry a 12 bit ID code plus > altitude. Others might have actual GPS coordinates. The transponders are 1090/1030 mhz and not 1350. 1350 is just radar. Also FWIW, TACAN and JTIDS systems operate between 960 and 1240 mhz with pulsed emissions as well as radars. But Marcus's description of signals every 5 seconds sounds exactly like radar and I bet if he has ID'd the right radar as the culprit he can go visit it and watch it turning around at exactly the interburst interval he sees. That might in fact be a good test if he cannot find a better method of verifying that is his radar as various actual radars tend to use different antenna RPMs. I might also add that unless propagation is strictly line of sight one needs more sophisticated path models to determine expected signal power. -11 dbm sounds rather loud. -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MovieBeam
On Fri, Jun 02, 2006 at 10:30:36AM -0700, Matt Ettus wrote: > > > Just read about MovieBeam on Slashdot. They mention that it > "piggybacks" on a PBS signal. I assume they mean a digital TV channel, > but they have a very small antenna. While I have no specific inside information at the moment, I am almost certain this is a matter of dedicating some percentage of the 19 Mb/s ATSC transport stream bandwidth on the over the air channel to TV over IP and writing the data to the disk in the box 24/7 as a continuous "background" task. Pretty clearly not real time delivery of the movies. Obviously basically a means of funding PBS stations, unclear as to what percentage of the OTA bandwidth it uses or whether this is dynamically assigned (replacing (otherwise) null packets in the transport stream) or a fixed partition which obviously will degrade best possible HDTV quality somewhat. I do have tools to look at the transport stream here for our (famous - WGBH) PBS stations in Boston, maybe I'll fire them up. Obviously the very very strong presumption is that the IP stream is completely encrypted or at least the movie files it contains are tightly encrypted so without the right keys they aren't accessible to be hacked (eg stolen). PBS has long carried program guide information for GEMSTAR in its analog signals in the vertical blanking interval data transmission zone. And many VCRs can use this stream to set the time of day (no blinking 12:00 AM). TV over IP is very much the coming thing in the broadcast industry and PBS is up front as one of the first major users. This technology allows prefeeds of shows and promos and commercials (yes even PBS runs those now) to PC based video servers as MPEG 2 or 4 PES files and is rapidly replacing videotape in syndication/newsfeed distribution. Much cheaper to have the server capture a broadcast of a file than have some master control operator have load and start videotape gear for a scheduled feed in real time. And I understand that they back up the satellite transmission of the IP streams with a broadband connection, so if there is a dropout in some section of the transmission due to a burst of uncorrectable errors the video server software can request that chunk of the file over a net connection. Presumably Moviebeam system does this by repeating the same feed over and over and handling errors by filling in the holes with data from later feeds. The viablity of the Moviebeam business model is left to others to decide - and whether they have a secure protocol or not is as well (shame on them if they don't don't in this day and age). But it does provide a means of selling some otherwise unused bandwidth (and maybe selling some otherwise useful bandwidth that might have been dedicated to better quality video for PBS programming). -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] frequency tuning word quantization
On Sun, Mar 05, 2006 at 12:03:33PM -0800, Eric Blossom wrote: > Good question. I've wanted to revisit it myself too. > As I recall it was to reduce the spurs in the DDC output. > If you get a chance, please see if you can find relevant papers. > I suggest searching for "DDS spurs", or something like that. > > In looking at the DDS's from Analog Devices, etc., they maintain a > full precision frequency tuning word and phase accumulator, and then > use only the high part to feed into the sin/cos generator. We also > do that in the FPGA. The question is whether we should be doing the > coarse quanitization of the frequency tuning word the way we are, or > some other way, or not at all. Obviously the sin/cos generator probably has only limited precision and certainly any DAC involved certainly does, so feeding in only an approximation of the phase angle makes some sense. The actual accumulated phase, however, can have arbitrary precision depending on the number of bits in the phase increment and phase accumulate registers and adders. It may be significantly more precise than the smallest resolvable unit of phase angle at the sin/cos level or hardware DAC level. And the higher the precision of the accumulated phase (more bits past the decimal point) the smaller the frequency step that can be set (which in our USRP case would be a big win) - or seen another way, the more precise the frequency setting can be, given an arbitrary frequency. Certainly there is no reason why the NCO should be limited by anything but bit width of the register/adder path. As for spurs resulting from this - I would have to do a literature check. But the mechanism for generating them is not obvious. > > Anybody else got something to contribute to this discussion? The above is my attempt... -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] frequency tuning word quantization
On Sun, Mar 05, 2006 at 05:53:44PM -0800, Eric Blossom wrote: > > In the FPGA, the phase word (not the accumulator) is approximately > 15-bits wide. This gives worst case phase-truncation spurs of -90 dBc. > This looks small enough that we can safely ignore it. Therefore, > I suggest we stop truncating the tuning word on the host side. > > Also, if we stop truncating on the host, then our frequency tuning > resolution will be 64e6 / 2**31 = 0.03 Hz. Probably fine enough for > most uses. I'd certainly suggest that if you decide NOT to support this high resolution setting as a default, you provide a method for doing so for applications where best spurious performance is less critical than the myriad advantages of being able to set the downconverter right on channel rather than synthesizing that (in a bunch of cycles) with various errors and resource consumption. -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DBS Dish Feeds
On Tue, Dec 06, 2005 at 04:34:34PM -0800, Matt Ettus wrote: > > DBS small satellite dish systems often have LNB feedhorns capable of > multiple polarizations and/or multiple bands. This is often controlled > by changing the voltage which powers the device. However, some have a > more complex control system involving tones in the 20kHz range if my > memory serves correctly. Is there anyone who has a reference on this > control system, or who knows how it works? I want to use these for > radio astronomy with the USRP and need to know how to control them. This is something called DiSEqC control and is documented in various ETSI specs available on the web (you have to register an account with ETSI to get copies) There are several generations of this protocol in use, all of which use superimposed 22 khz tones on the 13 or 18 volt power supply to the LNB or LNBF. A quick check shows that EN 61319-1 is one of the controlling specs with several implementation levels specified. I think I remember there are a couple of others involved as well. Basically the simplest versions use the presence or absence of low level 22 khz tone on the LNB power on the 75 ohm coax to select the lower or upper of two LO frequencies in "universal" European LNBs which cover 10.65 to 12.7 ghz and require two selectable LO frequencies to get all that bandwidth to fit into the standard 950-2150 satellite TV IF range. Usually the presence of 22 khz selects the higher LO frequency. The most standard (Level 1) configuration is for the polarization (either RHC or LHC or Vertical or Horizontal) to be selected by choice of 13 volts or 18 volts up the cable and the upper or lower LO frequency to be selected by the 22 khz. But as home satellite systems in Europe where this protocol originated have become more complex with multiple clusters of DBS satellites at various longitudes and thus potentially multiple feeds on multiple dishes in a typical installation this protocol has been extended greatly by allowing the 22 khz tone to be amplitude shift keyed (ASK) with digital signaling that can be used to control both cascades of rf switches and more significantly small motorized antenna positioners powered by the LNB 13 or 18 volts up the cable.This allows small (usually under 1 meter) Ku band dishes to be completely steerable (in the plane of the Clarke orbit) with only one single coax and no other control wires running back to the receiver which obviously has considerable advantages cost and convenience wise. The latest versions of the DiSEqC spec anticipate use of small microcomputers (PIC class) to interpret the 22 khz ASk signaling on the cable and thus can provide quite complex control of antenna mounted intelligent devices (including the ability to position to point at particular longitudes or satellites as in the USALS version of DiSEqC). This all replaces a group of interfaces that grew up with the US domestic C band TVRO market that has traditionally used three wires for PWM signaling for polarity control using a modified RC airplane servo motor to rotate a probe in the feed, and +-36 volt DC power to drive a motorized jack-screw to move the dish back and forth (with several amps of current in larger installations). Position feedback has usually been via optical interrupters or reed switches driven by rotating magnet wheels - both of which generate contact closures as the jack-screw shaft turns which get counted to determine postion. Obviously this US TVRO interface requires multiple wires (ribbon cables with all the usual wires and a couple of coaxes for C and Ku band IF were the standard) which is more expensive than just one 75 ohm coax, but of course with 36 volts at several amps there is much more energy available to move a dish than with perhaps half an amp at 13 volts. But maybe more relevant, the US DBS industry (currently DISH and DirecTV) adopted the 22 khz and 13/18 volt signaling scheme to control selection of multiple LNBs and polarizations in US DBS systems operating at 12.2 to 12.7 ghz. Universally US DBS systems use the 13 and 18 volt signaling on the cable from the set top box to the dish to select RHC or LHC polarization, and current DBS systems with multiple feeds on on one dish (local channels or HDTV or both are on satellites at other longitudes because of limited bandwidth in 12.2-12.7) now use 22 khz tone to select which LNB to get signal from. AFAIK, use of ASK of the 22 khz tone to perform more complex functions in US DBS antenna systems is only just starting (I think in some DISH network installations), most just use 22 khz on and 22 khz off as the only choices, though there has been some limited use of 11 khz to select RF inputs as well. Multiswitches for the US DBS industry are a standard cheap product, and provide the ability to select one of four (or more) RF basebands by the 13/18V and 22 khz signalin
Re: [Discuss-gnuradio] DBSRX Noise Figure
On Wed, Nov 30, 2005 at 05:12:11PM +1030, Daniel O'Connor wrote: > On Wed, 30 Nov 2005 16:33, Matt Ettus wrote: > > A useful application would be to control a calibrated noise source and > > measure the power in a given bandwidth with it on and off. This is how > > a noise figure meter works. > > Noise sources are pretty expensive :( > We have one at work though, if someone local is interested in testing it :) Expensive is somewhat relative. I have bought several at the MIT flea for around $75 per, and one with the cal documents on eBay for around 100. They take 24-28 volts to turn the noise on BTW... And I might note that nothing in tuners used on the USRP is particularly optimized for noise figure, if one wants good noise figures one needs external LNAs.. -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
