GPS for Cubesats - is 8km/sec too fast for consumer chips?
I would not advise to use an integrated GPS solution (containing MCU and closed source firmware) for a satellite application. There are several reasons why this might fail to work:


The frontend frequency plan might be optimized for a limited doppler range. Typically, the RF frontend will mix down the signal to an IF lower than 10MHz (higher IF will require higher sampling rate and consume more energy). This IF is not arbitrarily choosen! The quotient IF/samplerate should be nonharmonic for the whole doppler range to avoid spurious tones from a/d-truncation errors in the sampled signal. You may observe beating effects, that make the signal unusable at some doppler rates.
The digital domain correlator needs to reproduce a replica of the carrier and the C/A code at the correct rate, including doppler effects. It uses DCOs (digital controlled oscillators) to pace carrier and code generation, that are tuned via configuration registers from the MCU. The bit-width of these registers may be constrained to the doppler range expected for a ground based receiver, making it impossible to tune the channel to the signal if you are traveling too fast.
Firmware will have to do a cold acquisition if no position/time estimate is available. It will search doppler frequency bins and code phases to find a signal. The search range will be restricted to the range expected for a ground based user.
Firmware will typically use kalman filtering for position solutions. This involves a model of receiver position/velocity/acceleration. While acceleration will not be a concern for a satellite, the model will fail for velocity, if the firmware is not adapted for in-orbit use.


All of these issues can be addressed, if you use a freely programmable frontend and correlator with a custom firmware. You may, f.e. look at Piksy.