RunRyder RC Helicopter Topic - Homebrew PCM Receiver: QPSK/RF Design

RR Rated M For Mature

HOME rrTV-PHOTO GALLERIES MY GALLERY HELP-FAQ

myHOME PM pmRR MEMBERS 626 ONLINE 82 EVENTS SEARCH REGISTER START HERE

12 pages [ << < 1 2 ( 3 ) 4 5 NEXT >> ]

20386 views

POST REPLY

MTA Hobbies	.	Model Rectifier Corp	.	EDGE Rotorblades
	.		.

Radio - Servo - Gyro - Gov - Batt > Homebrew PCM Receiver: QPSK/RF Design

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Howdy, Gang!

I thought I'd post a few comments about frequencies and bandwidth. I'd mentioned earlier that I'd love to reuse existing crystal frequencies, but as nice as that would be, doing so would probably reduce the performance of this radio. The reason for this is tied to basic material physics: 455 KHz and 10.7 MHz intermediate frequencies have become so popular because they correspond to "natural" resonant frequency ranges for ceramic, and quartz crystals, respectively. While a ceramic filter can do a decent job and is cheap, in and of itself, it can't come close to the performance of a good crystal filter. In other words, a 10.7 MHz I.F. is pretty appealing just for the materials that are available there.

So, at the moment I'm leaning towards the use of a 10.7 MHz single I.F. for both the transmitter and the receiver, with a single four-pole crystal filter used there to provide superior adjacent channel interference elimination. I'll have to learn more before I'll know for sure whether this is the way to go, but it's an appealing possibility. If we do go this route, the first I.F. stage will require a (10.7 - .024) = 10.676 MHz crystal, and the second crystal will bring us directly to the transmit frequency (the final crystal would be the transmit frequency - 10.7 MHz). My guess is that this should work well for both the transmitter and the receiver, but we'll see! [In particular, I'm concerned about the potential for intermodulation products with those four crystals, so this might not be such a good idea, after all. Experts???]

As far as bandwidths go, I wouldn't be surprised if you were confused by all the bandwidth numbers I've been mentioning. To understand them, let's start with the symbol rate, which is the number of output data symbols that are sent per second. QPSK sends two bits for every symbol, so a 12,000 bits/second data rate will yield a symbol rate of 6,000 symbols/second. I'd mentioned previously that this design needs to pick a specific value for "alpha", which is the "excess bandwidth" constant. In this case, it's 0.35. What that means is that the output bandwidth that is required for this signal is 6,000 + 6,000 * 0.35 = 8,100 Hz. Indeed, at the -25 dB point, the signal is right around that bandwidth (slightly better, since the FCC mandates at least -25 dB reduction in signal strength at an 8,000 Hz bandwidth). The way the FCC limits bandwidth is to talk about a +/- range, so they specify the emissions limits at +/- 4000 Hz from the center of the transmit waveform (along with additional limits at +/- 5 KHz, +/- 20 KHz, etc).

Yet another bandwidth figure I've mentioned is 6,000 Hz: this is the nominal bandwidth of the Square-Root Raised Cosine filter that's used in both the transmitter and the receiver, corresponding to a carrier-modulated signal. This is the bandwidth at the -3dB point - in other words, the range of frequencies that the filter will pass. Between 6 KHz (+/- 3,000 Hz) and 8 KHz (+/- 4,000 Hz) the transmitter's output falls off sharply. However, no realistic filter can just cutoff frequencies at one point, so you'll always see a gradual transition from what's called the "passband" to the "stopband". Furthermore, when moving from baseband to carrier modulation, the bandwidth doubles, as you can see in the spectrum plots in this thread.

With all that kept in mind, it is completely correct to refer to this project as needing a bandwidth of 3 KHz (in a spectrum plot showing the baseband of either I or Q, and referring to the -3 dB cutoff point), 4 KHz (in a spectrum plot at baseband referring to the -25 dB cutoff point), 4.5 KHz (baseband, -60 dB), 6 KHz (carrier-modulation, -3 dB), 8 KHz (carrier modulation, -25 dB), 9 KHz (carrier modulation, -60 dB), or 10 KHz (nominal channel bandwidth, as defined by the FCC)!

I'm confused, too!

Cheers!
MarkF

07-17-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

Phil Cole
Veteran
Location: Redwood City CA

My Posts This: Topic Forum

Mark,

I don't think a four-pole crystal filter at 10.7 MHz will give good adjacent channel rejection (probably only about 40 dB). Six or eight poles would be more typical. Twenty years ago (when I was an active ham), crystal filters for this application were about the size of an R149DP.

455 kHz IFs are used to keep power down, and because the ceramic filters are much smaller than 10.7 MHz crystal filters.

The four-pole filter will probably be OK for rejecting a 48 kHz image if you do the final filtering as part of your RF processing at 24 kHz. Just be sure that the side-lobes don't end up somewere bad.

I don't think crystal filters cause intermodulation since they are pretty linear at small signal levels. It's not like you have a bunch of closely spaced oscillators running at the resonant frequencies of the crystals - unless the damping is so bad that they all start undamped ringing when hit with a signal.

Do you plan on buying the filters, or building them out of discrete components? Tuning narrow passband crystal filters for good amplitude response is bad enough, never mind getting the phase response nice and linear as well. And then we will want to bang it around inside a model helicopter!

One more thought:

Why not just undersample the 10.7 MHz IF? A filter good enough to keep images out of your 24 kHz IF will be good enough to keep aliased signals out of your signal processor.

07-17-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Hi, Phil!

Heh, am I glad to see you around here!!! [Phil's been kind enough to help me out behind the scenes on hardware issues, but then I disappeared into that work black hole, and we got out of touch.]

Thank you very much for the information! I've been looking at commercial crystal filters from ECS, and yes, I'm definitely relying on having very good S/W filtering from ~5 KHz to 24 KHz.

[The spectrum plots I've posted use no H/W filtering at all, other than the antialiasing filter in the DAC, and they're just as clean when running at very low bitrates like 200 Hz, so harmonics of the baseband/24 KHz carrier aren't a direct concern, at least not on transmit].

If we need to move to a six- (or even 8-) pole crystal filter, then that's what we'll do - I'm wide-open to your advice! While I'm probably out to lunch, I'd been thinking that the 48 KHz would double-alias in the upper frequency range around ~20-24 KHz - did I get that wrong? If I did, and it's wrapping into the 0-4 KHz range, we'll definitely pick a new plan! That's great news about the intermod, too - I had indeed been wrongly thinking that the crystals might act like oscillators in the presence of interfering signals. That helps a lot!

Your idea on undersampling is very interesting! I know that A/Ds are available with a 10.7 MHz analog front-end bandwidth with a 96 KHz sample rate that'll handle signal frequencies up to 29 KHz, but aren't they kind of expensive? I've also seen a couple of articles that showed rather poor performance in undersampling applications, and the problem was that I didn't know enough to determine whether these were poor implementations, or something inherent to the process. Can this deliver the same RF performance as we can get with sampling the 24 KHz I.F.? It's certainly an intriguing way to simplify the hardware!

Thanks again for your advice - it's very much appreciated!

Have Fun!
MarkF

07-17-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

MarkF

Senior Heliman - Location: Palo Alto, CA - My Posts This: Topic Forum

Hi, Phil!

Here's an example of what the filtering can look like. This is the frequency response of the 640-tap polyphase receive filter/interpolator that I'd mentioned earlier:

Now here's a 56-tap Hanning-windowed polyphase interpolator filter to change from the 48 KHz sampling rate to the 12 KHz sampling rate. Note that I've let the response be so-so from 6-8 KHz, under the belief that it would fold around back to the 6-4 KHz range at 12K samples/second, where the SRRC filter has very good rejection. I'd definitely appreciate your feedback as to whether I'm approaching this correctly!

As you can see, it looks pretty darned good! Hopefully, this filter combination will help simplify the H/W design quite a bit.

By the way, your comments prompted me to reexamine the baseband filtering, and I noticed that I'd been losing a lot of filter quality to quantization. I've realized that I was making the wrong tradeoff, trying too hard to get the MAC sums to fit into 32 bits. By adding just one additional clock/filter tap, the ARM can accumulate 64-bit filter results. So, by increasing the number of bits of precision in the filter quantization, the polyphase filters are looking much better. I may well have to reexamine this for the transmitter later on...

Anyway, this'll hopefully give you a good idea of what the software's up to.

[EDIT] Whoops! I think that I was wrong about the 48 KHz; I believe that it will fold back to drop right into the baseband 0-4 KHz range, as you suggested. As a result, let's go for a better crystal filter! Here's the ECS Crystal Filter PDF file. The only problem is that their ECS-10.7-7.5 filters are just a bit too narrow, but they may well work fine. As always, I'd appreciate your thoughts!

Thanks again!
MarkF

07-17-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Hi, Gang!

As the never-ending debate rages on in other threads about single-conversion versus dual-conversion receivers, it's interesting to note that the architecture that we're discussing would actually be a dual-conversion receiver. Unlike most such receivers, though, the second IF is taken care of by software, with only one hardware I.F.! What makes this neat is that software can perform awfully good filtering at 24 KHz compared to most 455 KHz low I.F.s.

[UPDATE: It appears that this is something of a hybrid approach, with one conventional I.F., followed by what's known as a "VLIF" (Very Low Intermediate Frequency; i.e. <100 KHz.]

Now, if we can only find a single 10.7 MHz I.F. receiver front-end chip that includes AGC and AFC, we'll have it made! There's a very frustrating problem these days: as I.C.s have gotten faster, and communications frequencies have gotten higher, most of the parts that support our "low" R.C. frequencies have been end-of-lifed! Previously, I'd been hunting for a dual-conversion chip, and they've been getting quite rare at low frequencies. However, now that software's handling the second I.F., it may well open up new possibilities that I hadn't been seeking before. I'll let you know if I find anything!

Have Fun!
MarkF

P.S. I know that I jump around a lot, from FSK RX code to QPSK S/W architecture, to QPSK H/W, back to FSK H/W, etc. I'm sorry about this, because I know that it makes it harder to follow what's going on. As someone once told me "You think sideways", and I'd have to agree that that's true. My development style does indeed go at problems "sideways". Rather than the traditional top-down or bottom-up design approaches, I do tend to bounce around back and forth between high and low level issues that seem to be critical to me. Please accept my apologies, but I'm afraid that this is just the way I'm hard-wired!

07-17-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Hi, Folks!

While hunting for I.C.s, I came across a very interesting white paper that talks about single-conversion versus dual-conversion receivers as it applies to R.C., and include it here because it does a good job of explaining why 10.7 MHz I.F.s are so common, and about some of the receiver design tradeoffs that need to be made. Check out R/C Receiver Performance Considerations.

Best Regards!
MarkF

07-17-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Howdy!

It's been a very productive day - I've determined the data structures for the QPSK receiver, and have spent most of the day working on simplifying the algorithms for the various processing blocks so that it'll be possible to execute this on a normal 60 MHz ARM7 CPU. For what it's worth, I do this by coding in "pseudo"-C, finding ways to eliminate code, and then iterate as I see opportunities to reduce the work that needs to be performed.

I imagine that the details of this are far too boring for most folks, so I won't post a play-by-play unless someone asks. However, a few interesting examples include:

Completely eliminating multiplications in the \"Costas\" Carrier Recovery phase detector with no loss of performance.
Eliminating multiplications in the Symbol Timing Recovery phase detector with no loss of performance.
In both of the PLL loops, identifying a sequence of eight simplifications, built on top of each other, that make the loops much faster and easier, especially on integer CPUs like the ARM7.
Realizing that it's possible to completely eliminate the entire Carrier->Baseband conversion block with zero instructions, just by changing the decimator's filter coefficients!

Can you tell that I'm an efficiency buff?

Naturally, I'll try to document these improvements in the code itself, but I'll hold off on posting about them here from now on unless someone else is interested (say so if you'd like to learn more).

Ultimately, the point of all this is that I'm becoming increasingly confident that this can be performed on a non-floating point 60 MHz ARM7, as long as it contains DMA for the RF input port. And... I'm even contemplating the possibility that we might even be able to pull this off without DMA, but I'm definitely not committing to this yet!

I don't want to just ramble on about stuff that folks aren't interested in, so if there's something specific you'd like me to focus on, just let me know! Even more important, if you see an error, please let me know! While I might eventually discover and learn from those mistakes, it's a lot more efficient to learn about them up-front!

Have Fun!
MarkF

07-19-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Good Morning/Afternoon/Evening!

Let's talk a bit more about the hardware requirements for this project. Note that all the components selected for this design will use a power supply voltage of no more than 3.3V, and ideally will support "core" (internal) voltages of 1.8V, as does the CPU. The reason for this is that R/C helicopters, in particular, have very high voltage drops when driving all those digital servos in parallel - planks tend to have less simultaneous servo motion. As discussed in the other threads on this project, this receiver won't just drive the servos at the same time, it will drive all of them in parallel at literally the same nanosecond. This will undoubtedly place higher demands on the power bus, leading to greater voltage variation. Selecting very low-voltage components will ensure that the receiver will run properly at any battery voltage at which the servos can still move, letting us maintain control as long as possible. Some existing receivers do a poor job of this, and enter failsafe at too high a voltage. In conjunction with careful power design inside the receiver, we'll deliver longer usable battery life by preventing these power spikes from becoming a problem.

So far, so good. Unfortunately, some parts are harder to find at very low voltages, and A/D converters are in this camp. Fortunately, I've come across a very useful A/D converter by Cirrus Logic (previously Crystal Semiconductor): it's the Cirrus CS53L32A , a low-power stereo I2S codec (I2S is an audio-interface standard that's well suited for DMA interfacing; that is, for letting the audio samples be moved into the CPU's memory without processor intervention). While the Cirrus website claims that it's not recommended for new designs, a little birdie told me that it's OK in this case (a successor part is coming that'll be easy to transition to later on).

What makes this part so great is that it's a low-voltage part, is highly integrated in a small package, supports 16-bit outputs, and most importantly, its internal filter will support a full 48 KHz frequency range at a 96 KHz sampling rate. As a result, this'll be perfect for digitizing the analog input signal in the receiver. If we stick with the current plan for using a DMA input, this is by far the best A/D I've seen for this application.

Having said that, I can't help but wonder whether another approach might be possible. As I'm beginning to understand the amount of CPU horsepower that'll be required for all the QPSK processing tasks, it's at least becoming possible to contemplate performing the A/D conversion under software control (i.e. without DMA). Thus far, I've been using the Philips LPC2104 ARM CPU. While this CPU is very well-suited for the FSK receiver, it doesn't support DMA, which makes it poorly suited for the QPSK version. To create the QPSK version, I'd have to move to a different ARM CPU from a different manufacturer, get a new prototype board, possibly need new debug tools, etc - all a pain in the rear.

However, Philips has recently released a sister part, the LPC2194 ARM CPU. While it doesn't support DMA either, it does contain an on-chip 10-bit A/D converter. While several of the new Philips ARM CPUs have this same on-chip A/D capability, I've also discovered that a German firm called MCT has a great little module that contains the LPC2194, and it's only 70 Euros in quantity one! This would be a very nice start for prototyping the QPSK receiver.

The idea behind this alternative would be to allow the CPU's A/D converter to continuously sample the RF input at 96 KHz, and then the CPU would receive a "FIQ" (ARM nomenclature for a special Fast Interrupt reQuest), each time a sample was ready. The problem, of course, is that the CPU would have to accept an interrupt every 10.4 microseconds. Talk about a software challenge - yikes! Just thinking about trying to support this speed while having to simultaneously drive the servos with ~100 nS accuracy gives me a headache, but I can't say that it's impossible. If we could make this work, though, it'd sure be nice, and would be extremely cost-effective.

In addition to a more difficult software effort, though, the first downside to this approach is that the receiver would need to have a good hardware Automatic Gain Control that would limit the RF input voltage to the CPU to a tighter range. Fortunately, many receiver front-end ICs have this capability already. The second disadvantage is that it would place greater demands on the hardware filtering to achieve the same level of RF performance (with fewer bits to work with, the receiver software couldn't be as effective at filtering out noise or interference, so the hardware would have to do a better job). Ultimately, the loss of software filtering performance may prevent this from being the right approach, but it's still an intriguing alternative. If nothing else, it may well be the fastest way for me to begin prototyping the QPSK version of the receiver, even if we do move to a full 16-bit external A/D converter later on.

Interesting stuff (at least to me)!

Have Fun!
MarkF

07-19-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

Phil Cole
Veteran
Location: Redwood City CA

My Posts This: Topic Forum

Hi Mark,

Some of those filters look pretty good.

If you are designing for 10 kHz channel spacing (you want to reject pager signals, etc. slotted between RC channels, or include countries which use 10 kHz RC spacing), then you are are stuck with the narrow BW, either in the first IF filter, or in your DSP code.

Either way will get you the adjacent channel suppression that you need.

If you want to rely in the DSP IF filter, all the first IF filter has to do is block images of the first to second IF conversion. This assumes that you have adequate dyanmic range in your second IF. If this is the case, you could use the 12 kHz wide filters. You need the big dynamic range since the adjacent channel signal could be much stronger than the desired channel signal, depending on the physical location of the receiver with respect to the transmitters.

In any case, it looks like you need the 6-pole filters with the 48 kHz second IF. The two and four-pole filters don't appear to have any guaranteed stop band, and the ultimate attenuation doesn't kick in until at least 200 kHz. You image is at 96 kHz, so it will be there in appreciable quantity. I'm assuming you want something like 60 dB image rejection. The 96 kHz images will correspond to RC channels five channels away, but 4 kHz off centre. This is probably too close to filter in the second IF (it's right on the edge of the example response you show above).

The conservative approach would be to use a 6 or 8-pole +/- 3.75 kHz filter in the first IF to do all your RF filtering. This way, the only signal that the DSP have to deal with is the the intended signal. If you want to keep the pager signals out, the 8-pole filter would be better, but if you only worry about adjacent RC channels at 20 kHz spacing, the 6-pole filter will get the job done.

You can save CPU cycles by not having to do any serious passband filtering, and can also reduce the dynamic range since you don't have to extract the wanted signal from a stronger interfering signal.

It's a tradeoff between DSP complexity and the cost of the cost of the good analog filter. Maintaining the 60 dB rejection of the filter will require some attention in the layout of the RF board as well.

07-19-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Hi, Phil!

Wow - I really appreciate your invaluable advice! To find out what the actual cost tradeoff was, I called the factory and talked to them about pricing. According to them, there's very little demand these days for six or eight pole filters industry-wide, since most folks opt for more cost-effective design approaches. However, given that using a part like this could essentially solve the entire filtering problem in one component, I agree with you that it's the right way to go (especially since we don't have a development budget, to speak of!). The costs are in the $13 range for the 6-pole @1K, and about $16 for the 8-pole @1K. Consequently, it's a no-brainer to me: we'll go with the 8-pole crystal filter. In volume, this part is less than $10, which actually seems like a very reasonable price to me for the performance that it will deliver, especially considering the number of hardware components that it will displace (ergo, which won't need to be designed, either)!

There's only two big downsides to this part: lead time and sample price. Even for samples, the lead time is seven weeks, since they custom-make them when you place the order. On top of that, they told me that the samples will be "very expensive", since they have to set up a production run just for that order. Ouch! I'll start contacting the distributor today to see how much this is gonna' hurt!

Based on this part, I guess I'll have to spend more time thinking about the software sampling route, using the Philips LPC2194's on-board A/D! Per your earlier recommendation, should I seriously consider directly digitizing the output of the first I.F.? If the hardware design is really clean, and if it isn't necessary to do any filtering other than the "basic" decimation and SRRC filtering, then that would certainly simplify the hardware design!

Many, many thanks for your help, Phil!

Cheers!
MarkF

07-19-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

Phil Cole
Veteran
Location: Redwood City CA

My Posts This: Topic Forum

That's not sounding too good if they have to go out and make them just for you.

Are there commercial narrow-band QPSK systems in use? Would be practical to use the components they use for the critical analogue functions if you could align your design with the architecture of those systems?

07-19-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Hi, Phil!

That's an excellent question! Unfortunately, the only markets that I'm personally aware of are digital cable TV set-top boxes (256K->2M bps), satellite (~~40M-60M bps), and spacecraft (narrow band, but not much of a market to piggy-back off of

)! I assume that there must be one somewhere, but I just don't know what it might be.

Let's see how much these will actually be - I'll post again once I know how much the samples will cost. The lead time isn't all that bad: I doubt that I'd be ready for these parts much before then, anyway.

Best Regards!
MarkF

07-19-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Hi, Phil!

I'm a complete idiot. I don't know why I temporarily forgot about this, but by far the most common radio communication system in the world is largely based on QPSK! Cell phones, in fact. Duh. The IS-136 standard specifies a data rate of 48.6K bps - still too wide for our needs, though. More importantly, all the cellular stuff is 900MHz and up, so the RF architectures look very different than we need here (with tons of custom silicon, to boot).

Sorry for the (hopefully temporary) loss of brain!

Cheers!
MarkF

07-20-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Hi, Folks!

No, I don't have the quote yet, but as I've thought over the crystal filter + on-chip A/D approach, the more I like it. One thing I just realized is that there is a lot of delay in Sigma-Delta converters like the CS53L32A. In this case, it's almost exactly a millisecond - one/eighth of the total frame time! Considering how much work I went through to eliminate one millisecond of time from the system by overlapping the servo pulses, I'll work even harder to keep from losing it again.

The other thing I realized is that if the RF input really is as clean as the specs suggest, then I wouldn't even need a decimator! We could simply change the filter coefficients in the SRRC filter to eliminate the carrier->baseband conversion block, and then just throw away 3 out of 4 samples, without any decimation filtering required at all. Now, I won't do this, since we'll have better RF performance by continuing to take advantage of the oversampled RF input, but the decimation and SRRC filters will become much, much simpler. The only hard part will be that tight timing, but the benefits are important enough to make the effort worthwhile!

I'm also updating the QPSK receiver's RF Software Architecture to Version 0.5. There are two changes in this release. First, I realized that the indexing operation must occur at the same point the Interpolator function occurs, so that will now occur in the SRRC filtering block. I addition, I'd inadvertently dropped a sign() operation from the Costas loop's phase detector - this has been corrected.

Have Fun!
MarkF

07-20-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Howdy, Gang:

I'm still awaiting the crystal filter sample pricing, but I've kept busy in a couple of different areas. First, after taking another look at the block diagram, yet another function block may disappear completely! The software AGC's function was primarily to limit the input to a narrow range so that the carrier frequency and symbol timing recovery Phase-Locked Loops would perform as specified. Otherwise, with wide-ranging input levels, their behavior becomes unpredictable. However, only the phase detector portions of these designs actually "touch" the input signals, so they're the only sections that are sensitive to varying signal levels. With the change to the Version 0.5 architecture slide, it becomes clear that both of the phase detectors use sign() blocks at their outputs. As a result, the relative signal amplitude is now irrelevant! [The I & Q components of the QPSK waveform still need to be balanced, but this is guaranteed by the digital carrier/baseband detector used here.] Ergo, even less math is needed, and the block diagram will get simpler again! As before, I'll think this over a day or two to make sure that I'm not missing anything, and if not, I'll post an update to Version 0.6.

Another decision I've made is that I'll prototype the basic QPSK function blocks in Matlab, a powerful math tool that's commonly used for simulation - not the complete receiver, but just the basics, to make sure that they're functioning properly. In particular, PLLs often require a bit of futzing around to get right, and that's a lot easier in Matlab than it is in the target environment.

Phil: May I ask for your recommendation on a CAD tools package? I've previously used the freeware version of Eagle, and am ready to upgrade to the "Standard" version that will handle four-layer boards. I'm assuming that a four-layer PCB will be sufficient for clean power and grounds (especially for a good RF groundplane). Does that seem reasonable to you? Before I buy anything, though, I'd greatly appreciate your guidance on the best way to go!

Have Fun, Folks!
MarkF

07-22-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

Phil Cole
Veteran
Location: Redwood City CA

My Posts This: Topic Forum

Mark,

I have only used the high end PCB design packages, and only on Unix workstations, so I really haven't looked at the smaller ones. The boards I work on have every second layer as power or ground, and sixteen or eighteen layers is common.

I am always amazed at PC motherboards that have only four or six layers and still work reliably.

I'd say go with what you know. You probably have a geometry library that you want to keep.

The other consideration is that you are able to produce output files that the PCB fab houses can deal with without giving you any hassles.

If you only have one power supply voltage, then one power and one ground (the inner layers) with routing on the outside will be OK, provided you can get it routed in the space you have.

With the crystal filters, one thing to watch is their phase response. With lots of high-Q poles and zero the phase response will get pretty wild near and in the skirts, so you'd want your IF spectrum to be well inside the filter's passband. I think I alluded to this before, but it's worth repeating that you should make sure the filter you choose has a phase response that's linear enough for your application. The filters were originally designed for AM or FM voice applications where phase response is not all that important, particularly for the narrower BWs.

07-22-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Hi, Phil!

You're a PCB designer, and you've got R.F. design experience, too! Very nice!!!

As always, your advice is really helpful. I've spent so much time recently playing with ~linear-phase software filters that I completely forgot to check out the crystal filter! I've asked ECS for a phase or group-delay plot so that I can see how bad it is. Assuming that it's reasonably flat through most of the passband, it may be necessary to reduce the transmit bitrate slightly to accomodate the filter for the prototypes. Hopefully, it won't be necessary, but if that's what it takes to get going, it's definitely something I'll consider.

I wish I had your CAD tools (Ummm, actually then I'd have to learn them... I take that back

)! My groups have used Cadence and Mentor over the years, and have even done a couple of 18-layer boards, but I've personally never used any of the "real" tools. It sure would be nice to have goodies like constant-impedance routing, but I'm assuming that the relevant traces will be short enough that it's not a big issue for this project.

For the power planes, we will need a small amount of 1.8V, but it's likely to just be the CPU core, and at < 50 mA core current, it shouldn't be too difficult to manage! Now that we're using the internal A/D, everything else will probably just be 3.3V in the digital realm (other than potentially adding a servo output buffer that might grab its I/O voltage from the battery rail). However, I haven't been able to find a suitable R.F. front-end I.C. yet, so the situation may change. Fortunately, Eagle lets you upgrade to higher layer counts just by paying the price difference, if that happens.

Thank you once again for the excellent advice!

Best Regards!
MarkF

07-23-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

Phil Cole
Veteran
Location: Redwood City CA

My Posts This: Topic Forum

I'm not actually a PCB designer, but I have done it in the past. The last board I personally did had a 16 MHz 80186 and was about eight layers.

I design large digital datacom systems and get to watch over the the PCB guys just to make sure it's my fault when the boards don't work. So I get to know what it takes to make the boards work, but I don't know how to drive the tools any more. Schematic entry and poring over plots and screens is a close as I get now.

You'll probably need to do a split plane to get the 1.8 V supply to the processor tied down, esp. at 60 MHz. Make sure your SW can do this without making power shorts (check the Gerbers - don't trust the layout plots and screens - I speak from bitter experience here).

07-23-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE

MarkF
Senior Heliman
Location: Palo Alto, CA

My Posts This: Topic Forum

Hi, Phil!

It sounds like we may have similar backgrounds, though mine's more focused on firmware/software and systems architecture than it is on hands-on H/W design. I'm happy to benefit from your advice!

Well, you just saved me from wasting a lot of time and money. The Director of Engineering at ECS recommended against their monolithic crystal filters for phase-sensitive applications. To give you an idea of how large the group-delay variance of the 8-pole 7.5 KHz filter must be, he mentioned that the 4-pole 30 KHz wide filter's group delay variance is 25 uS, but "only" ~5 uS across the center 15 KHz (which is still twice as wide a filter bandwidth than we need). Not to criticize ECS, at all. They've been extremely helpful, and have gone out of their way to accomodate me. It's just that yours truly forgot to ask the right questions... sigh. Anyway, kudos to ECS - they're good guys!!!

Darn. Whenever something seems too good to be true... it usually is. Thank you very much for preventing me from making a big mistake! Well, I guess it's back to the drawing board to figure out what the RF hardware architecture will be like.

Best Regards,
MarkF

07-23-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

MarkF

Senior Heliman - Location: Palo Alto, CA - My Posts This: Topic Forum

Hi, Gang,

After getting very little done the last few days thanks to a cold, I finally managed to make some progress this morning with the Matlab simulation. While there's still a bug to chase down, the Carrier Frequency/Phase tracking and Symbol Timing Recovery loops are working! To help further explain how the process of receiving QPSK works, I've put together a couple of diagrams that show what happens to the received signal at the different stages of the receiver.

This first signal is taken at a high (60 dB) Signal/Noise ratio - i.e. the sort of signal the receiver will see while it's near the transmitter. By the way: the "blue" points are the signal, and the "cyan" points are the 180 degree samples - in other words, with two samples/symbol, the blue colored points are the proper samples, and the cyan colored points are the "other" samples:

The sequence of processing steps is Raw Signal, Symbol Timing Recovery, Carrier Frequency/Phase Recovery, and then finally Received data. First, note the raw signal. This shows a receiver/transmitter carrier frequency error (the constallation is spinning), as well as mismatched symbol timing (the data is "fuzzy"/spread out from the origin). After the receiver's done its thing, see how "tight" the four constellation points are - that means that it's easy for the receiver to figure out what data was actually being sent.

Unfortunately, the real world isn't always this nice. Here's what the signal will look like under more marginal conditions, with a Signal/Noise ratio of 10dB (perhaps at extreme range, etc):

As you can see, noise has the effect of "blurring", or spreading out the constellation points in a way that isn't correctable, making it more challenging to identify what data was transmitted. Fortunately, this image also shows that this receiver should deliver very good R.F. performance: it's properly locked on to the carrier and to the signal timing, despite the high noise level. While 10 dB is right around the threshold of operation for QPSK, this image shows ~60 frames of data that are being received in this case with no errors.

It's nice to see things start to work, even if it is just a basic simulation!

Have Fun!
MarkF

07-24-2004 Over year old.

PROFILE PM EMAIL POSTS BUDDY IGNORE HOMEPAGE

12 pages [ << < 1 2 ( 3 ) 4 5 NEXT >> ]

20386 views

POST REPLY

ReadyHeli	.	Power Helis	.	CANOMOD
	.		.

Radio - Servo - Gyro - Gov - Batt > Homebrew PCM Receiver: QPSK/RF Design

Print TOPIC

Advertisers

Subscribe to This Topic