4
\$\begingroup\$

I have a 32MHz MCU (Atmel XMEGA A4) and I need to recover a digital signal coming from a GPS front end chip which is outputting SIGN and MAGNITUDE data at 16.368MHz. Clearly this is a hell of a task for the XMEGA running at only 32MHz. Is there any way that this is possible?

I ultimately want to save the data in a compressed form to some memory. I'd like to convert the 16.368MHz data stream to I/Q samples at baseband (0Hz IF). Using some DSP techniques this is quite feasible, I could filter the incoming data and then downsample (keep every M'th sample and discard all others). This could be done in a reasonable number of clock cycles although it does seem like a bit of a task for the 32MHz XMEGA.

So is an MCU even the right tool for this job? I've chosen this one because the final application is a battery powered device and every nanoCoulomb needs to be conserved. With this in mind, if there's no good way to accomplish this with the XMEGA, should I maybe be looking at some kind of DSP chip? Or possibly a low power FPGA?

\$\endgroup\$
9
  • \$\begingroup\$ How long is the sequence you want to capture? \$\endgroup\$
    – johnfound
    Commented Oct 29, 2013 at 15:05
  • 2
    \$\begingroup\$ Are you sure that's the right frequency? st.com/web/en/catalog/sense_power/FM1934/catalog/mmc/FM1934/… downconverts to 4MHz. You'll probably require a DSP anyway; is there a good reason not to build around a reference GPS implementation? \$\endgroup\$
    – pjc50
    Commented Oct 29, 2013 at 15:07
  • 1
    \$\begingroup\$ As slow as GPS updates, there is no reason there should be a 16MHz data stream. \$\endgroup\$
    – Matt Young
    Commented Oct 29, 2013 at 15:15
  • 1
    \$\begingroup\$ @MattYoung: The bandwidth of the raw spread-spectrum GPS C/A signal is on the order of 8 MHz. Clearly, the OP is attempting to record the raw IF signal so that he can do software-defined radio and apply advanced post-processing techniques for maximum precision. \$\endgroup\$
    – Dave Tweed
    Commented Oct 29, 2013 at 16:02
  • 1
    \$\begingroup\$ If you were to run an MCU at an integer multiple of your sampling frequency, and you could capture sufficient data using DMA (for which you probably need a substantially more capable MCU than an 8-bit Atmel toy), then you might be able to do it in an MCU; a carefully chosen Cortex-M4 or the like might be adequate. Otherwise, FPGA's are your friend. \$\endgroup\$
    – markt
    Commented Oct 30, 2013 at 9:40

2 Answers 2

Reset to default
1
\$\begingroup\$

I doubt your processor will be able to read data and store it in each cycle (given that the 16.368 MHz is more than half the 32 MHz clock, some inputs will have to be processed in sequential processor cycles.

A more powerful processor (e.g. Teensy 3.2) can run at 96 MHz, and with DMA may be able to process the inputs fast enough.

\$\endgroup\$
0
\$\begingroup\$

Before You Even Think About hardware capacity or something like that, Did you remember the Nyquist theorem?

Only with that You would have to sample the signal at least twice its highest frequency, but we know that even twice is still not enough. Perhaps based on this argument you'll see that faster hardware is required.

\$\endgroup\$
1
  • \$\begingroup\$ Good to remember Nyquist theory, but its probably not the over-riding issue here - we don't have any information about how fast the signal that the GPS is reporting is changing, but it's probably not that fast, the real issue seems to be simply the data rate out of the GPS. \$\endgroup\$
    – Icy
    Commented Nov 9, 2015 at 8:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.