The firmware is about 70% done. About 2/3 of the firmware in this project is re-used from a version that used DC servo motors instead of step motors. The system is accepting and interpretting all the required EZComm II commands to track satellites with the help of Gpredict. The biggest thing remaining to add to the firware is the NVM support to retain the system configuration long term. There are a few small features that I would like to add to the completed code, but they are in the nice to have category, not the required category.

Unfortunately, the tool chain is refusing to load more than 32K of code to flash. The executable code size is right around that boundary now. After adding a new command handler this morning, the debugger would not load the flash. I went in and cleaned out some debug code and was able to load and test the new commands. I suspect the 32K limit is a "feature" of the evaluation tools, because the data sheet on the MCU says it has 256K of flash. Believing that I had 256K to work in, I was not very thrifty with code space. If I have to, I can go in and re-do some stuff to free up extra space, but I would rather find a way around the 32K limit.

The EZComm II protocol is designed to support a 2 axis rotator (azimuth and elevation). Using a Yagi antenna to communicate with small satellites requires a 3rd axis (theta) to rotate the antenna on its centerline as the satellite rotates in orbit. Having your antenna 90 degrees out of the correct orientation can cost you 20 or 30dB of antenna gain which is a LOT. The protocol is simple enough that is easy to extend it in a consistent way to support the extra axis. The problem is that the satellite prediction packages don't know how to predict the theta position, as it is fairly random. Gpredict uses the Hamlib library to handle the hardware abstraction between the "standard rotator" and the actual one. I think I can wedge some extra code into Hamlib to give me manual control of the theta axis. This is an issue for another day.