The challenge with the satpack project is to fit as much functionality into the 32kB of the ATMega328 without resorting to taking the main functions out of libraries or other hard-to-read things. The current version has some precompiler conditionals that provide a good idea of the cost of some of the functionality:
Using internal EEPROM and no GPS: 27964 bytes
Using internal EEPROM and GPS (with software serial port): 30498 bytes
Using external EEPROM and no GPS: 28144 bytes
Using both external EEPROM and GPS (with software serial port): 30678
So, GPS costs 2534 bytes (much of this in the software serial port, of course) and external EEPROM costs only 180 bytes! The latter is because we've already initialized the I2C line for the realtime clock.
We still have a bit of work to do, even for minimal functionality. 1. The location has to be stored in EEPROM and accessed from there. This shouldn't take too much memory to do. 2. Clearly, then the target application for the ATMega328 is the first scenario.
I wonder if we could win back much of the GPS losses by using the GPS for time as well as location, leaving the realtime clock and I2C EEPROM out of the picture. This would be especially practical on the '644p chip, where memory concerns are not a concern (it has twice the EEPROM, up to about 20 satellites), and we have access to a hardware serial port for the GPS.
DARK SIDE TO THE MAX: WA7HRG's Android Tablet SDR (with a question) - Jim's experience with the Android tablet SDR was very similar to mine. But he used a "Ham It Up" up converter ahead of the RTL-SDR while I used an RTL-SDR...
2 days ago