rrTV-PHOTO   New HD TV
HOME   rrTV-PHOTO   GALLERIES   MY GALLERY   HELP-FAQ
myHOME PM pmRR MEMBERS 578 ONLINE 19 EVENTS SEARCH REGISTER  START HERE
 
12 pages [ <<    <     7      8     ( 9 )     10      11     NEXT    >> ]19270 viewsPOST REPLY
ZoomsHobbies . HeliHobby . Ron’s HeliProz South

.
.
Radio - Servo - Gyro - Gov - Batt > Homebrew PCM Receiver: QPSK/RF Design
 
 
RC-CAM
Senior Heliman
Location: USA

I used to do the opposite. I needed a network analyzer and only had full time access to spectrum analyzer. Luckily the SA had the tracking generator option, so a coupler was all I had to dig up. This allowed me to make simple network measurements (nothing fancy, but functional).

In your case, I would expect that you will be able to use the NWA as a SA of some sort (it really depends on the software). Once you get the unit you will be able to review the manual to see what it can do. Then improvise as necessary.

RC-CAM
09-27-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Gang!

RC-CAM: Thanks for the response! Unfortunately, I inadvertently sent an e-Check via Paypal instead of Visa, so that's going to delay things by a week. I'll be anxiously awaiting to see how flexible the instrument is!

A quick update on other progress. Premier will be delivering the VCO samples soon, and they are currently checking into the possibility of creating a new version of the V-0305-05 that would have the same output power, but would instead support the 50 MHz band. This would enable a simple build difference for 2 alternate VCOs to support all three R/C bands. I'll let you know what they come up with.

I've been trying to select a CAD and simulation package, and have spent quite a bit of time looking around. While I'm intrigued by a package called AutoTRAX EDA with its integration of SPICE, I'm worried that it still seems a bit too buggy for me (the $95 price is something else, though!). We'll probably wind up sticking with Eagle for schematic entry and PCB design for now, though that leaves the simulation problem open. It would be great if I could find a simulator that accepts S-Parameter models, but it appears at this early stage that this might only be supported on the high-end ("Big Ticket") simulators. I'll keep hunting... As always, advice would be greatly appreciated!

I've also spent more time in the Blackfin documentation and schematics, in preparation for starting up a new codebase for that part. The key architectural decision point is determining whether to perform frequency-domain (like the SDR-1000) or time-domain (conventional) filtering. Right now, the most significant roadblock to frequency-domain filtering is that the Blackfin DSP library's FFT routines perform "input scaling" to prevent integer overflow. Since they operate on 16-bit data samples to begin with, that means that they are throwing away far too much precision to support the dynamic range that we'll need. For example, with a 1K-point FFT, we'd wind up with only six bits of dynamic range, which is just about useless.

I pinged Analog Devices several weeks ago to see if they offer a higher-precision FFT, but haven't received a response yet. Perhaps I'll try asking the folks at Digi-Key support to help out... If nothing else, we could always try the standard open-source FFTW library, but given the very unusual architecture of the Blackfin, it'll no doubt deliver comparatively poor performance. This situation really does call for an assembly-optimized 32 bit FFT routine. Hopefully, I won't have to add that to my to-do list!

That's the current update - I'll keep you posted as I learn more.

Have Fun!
MarkF
09-28-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Gang!

Wow - I'm realizing just how out of date I am! S-Parameters were invented in the late 60s, and the ham radio materials I learned from in the early 70s hadn't included any information on this concept. As I'm thinking through the consequences of this design approach, I feel like I'm coming out of the Stone Age! Even the few RF gurus I've been fortunate enough to work with were also old-timers that taught the standard R-L-C "lumped component" school of RF design.

I'll bet that any college kids that have been following this must be laughing their butts off at my ignorance. The S-Parameter school of RF design changes everything! In place of the "black magic" that RF design has been traditionally, S-parameters totally transform the way that you think about a system. It's perhaps not much of an overstatement to think of this approach as being the difference between art and science! Now, S-Parameters become truly indispensible only at higher frequencies, but they're nonetheless extremely useful at HF, too.

To those few of you that might be in the same boat that I was, S-Parameters are simply Scattering parameters, and they are precisely the same as optical scattering parameters. For each element of a circuit, four numbers fully characterize that element at a specific frequency (/wavelength) and impedance: the input power, the power reflected back from the input to the source, the output power, and the power reflected by the output back to the input. That's essentially it! However, it's the ability to directly measure S-parameters with a vector network analyzer that makes this such a powerful technique: it completely closes the loop, enabling full characterization of circuits, sub-circuits, or circuit elements. With that characterization, correction for optimal performance becomes quantitative, not qualitative.

Fantastic stuff! For those of you who've patiently listened to my ramblings, and my utter lack of knowledge of S-parameters, I appreciate your indulgence and tact. I'm finally beginning to come out of the Stone Age! On the off chance that you'd like to learn more about the S-Parameter approach, I've found an outstanding presentation from HP called S-Parameter Techniques - it's been a mind-altering experience for me!

Have Fun!
MarkF
09-28-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Gang!

Things are coming along very nicely. I'd mentioned previously that Analog Devices hadn't responded to my original request for a 32-bit FFT, so I tried it through Digi-Key. Delightfully, I received the source code for a very fast 32-bit 1024 point complex FFT the very next day! I'm certainly impressed with the quality of support that Digi-Key's offering, and again, special thanks to Paul Fuchs, their Application Engineer!

Why a 1024-point FFT? On the 72 MHz band, the receiver's analog input bandpass filter will be 1 MHz wide. Including filter skirts, let's call it ~2 MHz of RF input bandwidth. The QuickSwitch commutator will then be passing along that 2 MHz bandwidth to a baseband audio amplifier, with response nulls at even harmonics, and peaks at odd harmonics of 96 KHz. The audio amp will be configured as an active filter that will roll off the signal beyond 96 KHz, to prevent out of band interferers from inducing clipping in the A/D converter. After that, the A/D converter will sample the complex signal at 96 KHz.

If we pass 960 of the A/D samples to a 1024-point FFT (zero-filling the last 64 entries), then the output will be a series of 960 frequency bins, each of which is 100 Hz wide. This level of precision will mean that it'll be possible to build an accurate tracking filter that will remove the gross frequency error from the QPSK signal's 24 KHz intermediate carrier frequency. To remove frequency error in the frequency domain, we'll literally just move the FFT bins around until the signal's peak amplitude is centered on 24 KHz! After this error is reduced to within a few hundred Hz, then the existing carrier recovery block (from the S/W Architecture Diagram) will serve to perform the final frequency and phase alignment prior to demodulation.

There's another terrific benefit of this routine. I'd initially planned on using the 16-bit sampling mode of the Crystal A/D converter. However, a 32-bit, 1024-point FFT routine means that we'll have 22 bits of available dynamic range! As a result, it'll be possible to change to use the 24-bit sampling mode of the A/D converter. Now, 22 bits of dynamic range is theoretically ~134 dB, which is way more than we'll need. So, the limits of this receiver will definitely be determined by the analog circuitry, not by the digital processing!

So, how fast is this "fast" FFT? The only timing information included with the source code claims 6,677 CPU clocks for the 128-point FFT routine. Since FFTs scale as N*log(N), the 1024-point FFT should take about 11.4X longer, or about 76,300 CPU clocks. Considering that we'll be running the Blackfin at 400 MHz, that means that the CPU can perform about 5,200 32-bit 1024-point complex FFTs per second!

How many FFTs will we need? Since the receiver will be using a 96 KHz sampling rate, with 960 of those samples consumed per FFT, there would normally be 100 "input groups" per second. However, to prevent "leakage" (distortion caused by finite FFT lengths), we'll use "overlap-add" processing, where 480 new samples are combined with the previous 480 samples for each input group. Thus, there'll be 200 input groups/second. For each input group, we'll need to perform a forward FFT to get into the frequency domain, the filtering will be performed, and then we'll need to perform an inverse FFT to get the final 24 KHz QPSK carrier. So, all told, we'll perform 400 FFTs/second, which will only require about 8% of the CPU! To put this all in perspective, everything listed here will be performed prior to the conventional demodulation functions shown in the S/W Architecture Diagram.

So, with this in hand, the decision is made! We'll be using frequency domain processing somewhat along the lines described above. Unfortunately, there's one important point I haven't figured out how to do yet. If you'll remember back to the point where I described converting the baseband QPSK signal to a carrier-based signal, the output was a real signal, not a complex one. However, the approach shown here will require a conversion from a complex 24 KHz signal to a complex baseband signal - I'll have to do some more research to figure out how to accomplish this efficiently. In fact, I'm going to see if it might be possible to move the Square Root Raised Cosine filter into the frequency domain, as well. Time to go learn more...

All in all, this is good progress. Thanks again to Digi-Key and Analog Devices!

Have Fun!
MarkF
09-30-2004 Over year old.
HOMEPAGE  
 
 
Phil Cole
Veteran
Location: Redwood City CA

Mark,

If I'm following along correctly, you are using FFTs and IFFTs in place of a normal FIR filter to perform passband filtering functions?

Since you have some canned FFTs ready to go, is it that this is easier than coming up with the coefficients for the FIR filter taps?

Phil
09-30-2004 Over year old.
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Phil!

The motivation for going to frequency domain processing is that it's much more efficient when you are implementing a high number of filter taps. I've seen one site which claims on the basis of theoretical ops that frequency domain filtering can break even with time domain filtering with filters as small as 17 taps! Realistically, given the increased number of overhead operations in an FFT, the more common estimate appears to be at around 50-60 taps with general-purpose CPUs. [Update: The crossover point is higher with DSPs, since they're so highly optimized for FIR filtering; in the case of the Blackfin performing 32-bit complex FFTs, the breakeven appears to be at around 160 taps.]

So far, I've done all my work in the time domain, including the existing PC-based QPSK audio transmitter code. In the experiments there, I found that I needed some pretty long filters to get really high performance. The beauty of frequency domain filtering is that after the FFT is done, just a single multiply is needed for each I & Q sample (well, thanks to the overlap and add technique, we'll actually need two multiplies per I & Q sample). This applies regardless of the number of time-domain taps in the prototype filter!

By the way, my previous question of whether or not it was possible to do the SRRC filter in the frequency domain was pretty dumb. Of course it's possible. All that we'll do is to multiply the frequency-corrected FFT spectrum by a bandpass square-root raised cosine response at the 24 KHz intermediate carrier frequency, instead of by the usual lowpass SRRC time-domain response at baseband. The neat part about frequency domain processing is that it can be the equivalent of a 1,000 tap filter!

The final advantage of the FFT approach is in the tracking filter. It's a lot easier for me to visualize the means to identify and track frequency errors in the frequency domain, and I love the trivial frequency correction of moving bins around!

All in all, it's Gerald, the creator of the SDR-1000, that really pointed me in this direction with his work on the SDR-1000. However, in doing the research to understand the alternatives, the benefits really are significant!

It's good to hear from you again!

Best Wishes!
MarkF
09-30-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Phil!

Wait a minute. After posting all that, I realized that I made one absolutely crucial oversight: latency.

That was a huge mistake. Just on the basis of the size of the input groups, we'd be adding 10+ mSec of latency by using the FFT approach!

Oh, brother - somebody shoot me. In this application, processing efficiency is only a secondary concern - as long as it fits within the capabilities of the CPU, we're fine. Latency is the primary concern, and despite all of the wonderful advantages of frequency domain processing, it does add latency.

Now, we could reduce the latency significantly by going to much smaller FFTs, but that would then limit the number of effective filter taps that could be emulated. Not to mention that a granularity of, say, 1 KHz in the tracking filter would totally suck.

Phil, thank you! Your question made me realize that it's once again time to do a 180 degree turn and reverse my previous decision. We're going to have to do this in the time domain. Shoot! I was really looking forward to implementing this approach, but latency is our prime evil here, and I very nearly went over to the dark side!

As always, your feedback is very much appreciated!!!

Cheers!
MarkF
09-30-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Folks!

Wow, there's just so much to learn here! Lately, we've been targeting 12K bits/second in an effectively 8 KHz R/C channel. To accomplish this, we've selected an excess bandwidth ("filter rolloff") constant of 0.35. I'd noticed when performing the initial experiments that the amplitude peaks of single-bit high or low data signals were considerably lower than in cases where two bits were the same value. It made sense, due to the bandwidth restrictions of the narrower SRRC filter, but those amplitude variations were always a gnawing concern. Clearly, reduced amplitude signals for single-bit transitions would mean a higher bit error rate.

Fortunately, in one of her many excellent tutorials on communications theory, Charan Langton posted a great writeup on Inter-Symbol Interference (ISI). In the paper, she discusses how alpha values of less than 0.40 require a form of "predistortion" in the transmitter (if you're in a hurry, just search the PDF for "figure 24"). What happens is that the transmitter's SRRC filter is modified to compensate for the tighter bandwidth of the SRRC constraint, given real-world sampling, in a process known as sinc equalization. This intentional predistortion then results in a perfect raised cosine response at the receiver - very cool!

Though we're not really focusing on the transmitter yet, this is a very important ingredient to allow us to maintain high bandwidth efficiency at low bit error rates. The question is whether or not we'll have to reduce the transmit bit rate after applying sinc equalization, and I suspect that it might be necessary. Nonetheless, as long as we can exceed the original goal of >10K bps... Great stuff!
Happy Flying!
MarkF
09-30-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Gang!

Wait another minute! We've been focusing on ways to reduce latency, and the pure block-based approach obviously adds too much latency. However, conventional FIR filtering adds latency, too - the delay in a conventional FIR filter is 1/2 the number of taps in the filter. Now, what if it were possible to perform digital filtering with no input/output latency? You won't believe this, but William G. Gardner of MIT published a paper in the Journal of the Audio Engineering Society in 1994 titled Efficient Convolution Without Input-Output Delay! Unfortunately, I can't link to it, since it costs $10 through the A.E.S. website (search for "efficient convolution delay" [without the quotes] to get lucky).

I'm still reading through it, but this really is a legitimate approach that's heavily referenced by folks that are performing acoustic correction for listening spaces, where latency is crucial - at 44.1 KHz sampling, their FIR filters are 88,200 taps long! It's a hybrid between time domain and frequency domain filtering that requires breaking up the filtering operation into variable sized blocks, and it schedules the execution of the blocks in parallel through a task scheduler, where the blocks are recombined to form the processed output. The full implementation is quite complex, and would require that we use the VisualDSP O.S. kernel, but the author fortunately presents some simplified forms, as well.

In one variant, frequency domain processing starts with a small block of N samples (32 as an example), then processing proceeds in block sizes of N, N, 2N, 4N, 4N... This would yield a filtering latency of just 667 uS for any length filter! Figure 6 in the paper suggests a theoretical overhead of about 128 multiplies per output sample for a 1024-tap filter. If we compare the 667 uS latency to the 2.667 mS that would be required for the straight 512-tap SRRC filter I posted early on in the thread, it's a huge win!

This is giving me way too much stuff to think about - my head hurts! The true zero-latency filtering algorithm is far too complex, but the simplified form is actually quite intriguing. This has the downside of losing the elegance of the conventional frequency domain filtering approach, since it just handles filtering - we won't be able to do the tracking filter in the frequency domain. Still, with latency reduction as our first and foremost goal, I'm going to have to explore Gardner's technique in more detail.

I know it sounds like snake oil, but if you're really skeptical, the paper's worth ten bucks! I'll let you know more after I get the chance to read through it a few more times!

Have Fun!
MarkF

[Update: A.E.S. doubled their pricing for articles to $20 the day after I posted this. I guess that I shouldn't have said that it was worth $10, eh? Sorry about that!]
09-30-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Gang!

While I'm mulling over the consequences of the Gardner paper, I think I may have a possible way of handling the tracking filter problem in the time domain. The existing carrier recovery loop is essentially just a Phase-Locked Loop with a phase rotator that can handle less than 90 degrees of error. Consequently, the maximum range that it can track is constrained by the fact that it's working at baseband, where QPSK modulation is indistinguishable from frequency error! It works only because, by definition, we declare that all phase errors greater than X degrees must be information, rather than frequency error.

Now, let's imagine that we move the carrier recovery loop much earlier in the receiver's software processing chain, all the way out in front. In that case, the 24 KHz intermediate carrier frequency itself could be used for tracking frequency errors, but for one problem: the PLL would be subjected to tremendous amounts of noise from all the signals in a 2 MHz range. The tracking performance would no doubt be quite poor.

So, let's rearrange things again, and implement the square root raised cosine filter as the very first digital processing step, right after A/D conversion. To do this, a bandpass filter centered at 24 KHz would be used (possibly implemented via the Gardner technique for reduced latency). The phase detector portion of the PLL would then simply compare the filtered complex incoming signal to a 24 KHz Numerically Controlled Oscillator (i.e. a digital VCO). Over time, the digital NCO will align in phase and frequency with the received 24 KHz I.F. carrier.

Now here's the area that I'm not entirely sure of, but I think might just work. It seems to me that it might be possible to apply carrier rotation after the phase detector, and in so doing the NCO could serve as the L.O. in a traditional complex mixer to rotate the 24 KHz modulated carrier directly to baseband. We'd then continue with the remaining software functions like AGC, demodulation, etc.

Computationally, this is very straightforward (with the exception of the SRRC filter, as always). Now, if it'd only work...

Cheers!
MarkF
09-30-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi!

I think I just realized how to change this from "maybe" to something that will work. The problem with the approach as stated is that the SRRC filter will chop off the edges of the signal bandwidth in the presence of frequency error. To correct this, we could use two software oscillators. Instead of running at the carrier rate, the NCO would run at the frequency error rate - i.e. between -3 KHz to +3 KHz, and we'd place the carrier rotator before the SRRC filter. The output of the SRRC filter would then be a frequency corrected 24 KHz carrier. We'd then feed a second fixed 24 KHz NCO to a second carrier rotator that's operating as a conventional mixer, which would serve to rotate the carrier from 24 KHz down to baseband.

This is actually starting to sound pretty good, though I do need to verify that I can build a -3 KHz to +3 KHz NCO. Can anyone see any downsides to this approach?

Thanks a bunch for hanging in there!

Best Wishes!
MarkF
09-30-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Howdy!

There is a way that we can avoid the need for a -3 KHz to +3 KHz NCO. It's an awfully funky approach, but the NCO could operate as a 21-27 KHz NCO (which is presumably relatively straightforward), and we could apply a -24 KHz carrier rotation to it (negative frequency conversions are performed by performing a complex division instead of a complex multiplication). The -3 KHz to +3 KHz output of this mixer could then be used to align the received signal prior to the SRRC filter.

The reason for this very odd approach is that we can't apply the 24 KHz NCO to the signal immediately, or we'd go directly to baseband. Once we're at baseband, the frequency error range of the phase detector is no good. However, we still need to align the received signal prior to the SRRC filter to prevent bandwidth cutoff, hence the strange -3 KHz to +3 KHz correction range.

I'm pretty sure that this could be built, but I'm really hoping that somebody'll come along and offer up a simpler method! If nothing else, it'd be great if it's possible to build a reasonable -3KHz to +3 KHz NCO, so we can skip this bizarre last step. Any advice or feedback you might have would be terrific!

Have Fun!
MarkF
09-30-2004 Over year old.
HOMEPAGE  
 
 
Bezjak
Heliman
Location: Boca Raton, FL

Mark,

To create a -3 to +3 kHz Complex NCO:

1. Create a routine which takes a phase angle and returns the cosine and sine of this phase angle. I use a combination of table look up and interpolation.

2. Before calling this routine, retrieve the last phase angle used to call the routine and update it by adding the desired phase increment. For positive frequencies, the phase increment is positive, for negative frequencies, the phase increment is negative. Save the new phase value, then call the routine.


In my NCO implementations, the phase angle is actually an integer that spans the range of integers that the DSP can represent. A phase angle of Pi is the most positive integer, and a phase angle of negative Pi is the most negative integer. This way, I don't have to worry about phase wrap around. It is handled automatically by the DSP. When the phase increment added to the last phase is greater than Pi, it magically wraps around to become a negative phase angle.

Greg
10-02-2004 Over year old.
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Greg!

That makes perfect sense to me! I like the "MAX_INT" approach, too - very nice! I suppose that I've been nervous because "0" and "Hz" tend to be incompatible in RF. Ahh, but your discussion of sine and cosine strikes right at the core of the concern. I've had something nagging me in the back of my head about processing artifacts near 0 Hz (you know, DC, and all). But because we're in quadrature form, 0 Hz stops being anyplace special - it'll just be some arbitrary phase rotation, instead of "0 volts". In other words, I'd been uncomfortable thinking about 0 Hz in terms of RF mixing - as long as I think of it in terms of carrier rotation, I'm happy again! Thank you!

Now that you've gotten me back on track, you've also helped me to be able to restate the problem in less bizarre terms:

"By comparing the received signal to a fixed 24 KHz NCO reference, the phase detector drives a variable NCO that's used by the carrier rotator to remove any TX/RX frequency mismatch. The frequency corrected signal is SRRC bandpass filtered, and is then mixed with the fixed 24 KHz NCO to recover the baseband I & Q signals. Note that the phase detector samples the signal after the bandpass filter, to prevent out of band signals from interfering with frequency correction."

That almost sounds normal! Thank you very much for your help!!!

Have Fun!
MarkF
10-02-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Howdy!

"So an acoustics engineer and a communications engineer walk into a bar..."

Nah, I'd probably just put you to sleep. OK, we'll keep it straight: I now understand the Gardner paper.

Concisely, the issue is that Gardner does indeed provide a means to dramatically reduce computational complexity for long FIR filters, and it does so while adding zero sample delay. It's terrific, and can, in fact, output an impulse right when the 0th sample is received (if that's what the filter calls for). However, the transfer function of the filter doesn't change.

It's the language difference between acoustics and communications that misled me into thinking that this could do even more. Let me revise my earlier statement. From the viewpoint of an acoustics engineer, FIR filters are "zero-delay" filters! It is true that an FIR filter can have a full-scale output right after the 0th sample is received. But... working in communications, we all know that "the delay of an FIR filter is 1/2 the number of taps". What gives?

Doh - it's the transfer function that counts! In communications, we use symmetrical FIR filter transfer functions. Look at the coefficients for just about any FIR filter, and you'll see what I mean. Highpass, lowpass, bandpass, SRRC, Parks-MacClelland; it doesn't matter. They're all symmetrical: peaks in the middle, and near-zero at the start and the end. That's important, too! If I tried to use one half of an SRRC filter, it wouldn't work at all. It's the transfer function that determines the latency, not the FIR filter itself. While Gardner's algorithm is quite impressive, he can't change the transfer functions that are essential to communications.

That places us right back with the choice of a 2.6 mS SRRC FIR filter latency in the time domain (w/512 taps) or the 10+ mS latency required for frequency-domain processing. Both stink. Gardner's algorithm gives us the alternative to perform more efficient frequency-domain filtering while adding only 0 or 667 uS to the existing 2.6 mS time domain latency, though at the expense of significantly increased complexity. Neat, but the 2.6 mS latency is already too long!

At moments like these, I hope you'll forgive me for resorting to metaphor. An FIR filter is like a hammer. Keep whacking away, and you'll eventually get through that wall - it just takes a long time. There's another type of filter out there known as IIR, but it's more like a bottle of nitroglycerine. Potent, but difficult to control; ready to explode at the worst possible moment. Still, it can sure get the job done quickly!

IIR filters can deliver much higher performance for a given filter length. That's a good thing, for the potential is there to improve latency. However, it can be quite difficult to design one to meet high dynamic range specifications, and particularly hard to maintain the linear phase performance that's essential for QPSK.

I guess that I'll take a look at IIR filters next. If you hear a really loud boom, it probably didn't work!

Have Fun!
MarkF
10-02-2004 Over year old.
HOMEPAGE  
 
 
Bezjak
Heliman
Location: Boca Raton, FL

Mark,

PM me your e-mail. I will send you some NCO source code I wrote for a home project for the ADSP-2181.

Greg
10-02-2004 Over year old.
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, RC-CAM!

There's good news on the invesment front. The Advantest network analyzer arrived, it's in even better shape than I expected, and it appears to be meeting its original factory specs. One very pleasant surprise is that the seller even calibrated it before shipping it out! I'm also relieved: the network analyzer together with the S-Parameter test set can indeed perform all of the tasks that I'd need a spectrum analyzer to do, and with very high precision, to boot. In fact, the default when the unit is powered up is a 300 KHz-3.6 GHz real-time spectrum display. With the S-Parameter test set, the "secret" is actually quite simple: just measure transmission power with a single cable running into the test port that the unit isn't driving - i.e. S21 or S12. It works like a champ!

It's pretty cool to set the frequency span down to 100 Hz or less with a 10 Hz detector bandwidth, and to dial the sweep speed way down to 20-30 seconds: you can actually see the exact shape of the Elecraft XG-1 reference oscillator's very clean spectrum. Network analyzers are like microscopes: you can zoom right in to see the effects of phase noise!

There were a couple of surprises along the way. For those who haven't gotten into network analyzers before, plan on additional expenses. All told, you'll need a calibration test set (an obscenely expensive handful of what look like screwy connectors), a power splitter, an RF bridge, a FET probe, a bunch of adapters, and, of course, high-quality test cables. On the flip side, the reason that network analyzers hold their value so well is that they essentially never go out of amplitude or phase calibration, since every measurement is preceded by a (sometimes quite extensive) self-calibration procedure that removes the effects of the specific test setup from the measurement.

Anyway, along with my crappy little 200 MHz oscilloscope, I guess that I am set for test equipment!

Cheers!
MarkF
10-02-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Greg!

Wow - that would be very much appreciated! You've got a PM! I really appreciate your help and advice!!! By the way, if you don't get the PM, please post so here. The last two PMs I've sent in response to folks in this thread never yielded a response from them - it might be that there's a problem with my account somehow!

Cheers!
MarkF
10-02-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hi, Folks!

With all the different topics that we're juggling here, I completely forgot to pass along some good news from Lattice Semiconductor. I'd asked their tech support group to estimate the power consumption of the ispGAL 22V10AV-23 PLD in this quadrature clocking application. While they emphasized that it's only an estimate, the estimate at 312 MHz is just 18 mA at 1.8V! There'll certainly be additional pad power at 3.3V, but the signals will be so lightly loaded that total power consumption will definitely be far below the ECL alternative. I'm still nervous about phase noise, but at least this is looking really good from a power perspective.

Greg: You do great work! Greg's written efficient assembly language routines for the ADSP-2181 that are very nicely done - super job! I'm definitely going to model my own NCO after yours, and you'll be credited in the source, for sure! Again, I very much appreciate your taking the time to pass along this valuable component! THANK YOU!

Cheers!
MarkF
10-02-2004 Over year old.
HOMEPAGE  
 
 
MarkF
Senior Heliman
Location: Palo Alto, CA

Hello, Gang!

I guess that my stupid question about bandpass SRRC filtering wasn't quite as dumb as I'd thought. I contacted the author of Filter Solutions, but he'd never even heard of a bandpass SRRC filter, yet his program supports dozens of different types of filters! Fortunately, all is not lost. Googling around a bit confirms that the concept is indeed valid, with the most common references I've found pointing to use in near-zero I.F. cellphone implementations and 8VSB modulators for digital TV broadcasting.

So far, the other filter design programs I've checked out are in the same boat: they support lowpass SRRC filters, but not bandpass SRRC filters. So, while we have an architectural solution, the problem will be figuring out how to design an implementation! If all else fails, I may have to try learning how to do this from scratch in Matlab, but that would definitely be a last resort. If you're familiar with a program that can design SRRC bandpass filters (ideally IIR SRRC filters), please let me know!

Thanks, everybody!
MarkF
10-03-2004 Over year old.
HOMEPAGE  
 
 
12 pages [ <<    <     7      8     ( 9 )     10      11     NEXT    >> ]19270 viewsPOST REPLY
Century Helicopter . MTA Hobbies . Model Rectifier Corp

.
.
Radio - Servo - Gyro - Gov - Batt > Homebrew PCM Receiver: QPSK/RF Design
 PRINT TOPIC Advertisers 

Subscribe to This Topic

Tuesday, December 2 - 5:18 am - Copyright © 2000 - 2008 runryder.com | email | link to rr | runryder needs cookie