The Telit JF2 GPS on the GPS TinyShield showed not to be able to follow rapid changes in height.
Based on the example from the GPS TinyShield Tutorial I have made a data logger with a TinyZero Processor Board with accelerometer, a GPS TinyShield and a MicroSD TinyShield. This logger is primarily meant for model rocket applications.
Using two separate buffer memories GPS NMEA strings are recorded in a .txt file and accelerometer outputs, time stamps and other administrative data like buffer usage are recorded in a .csv file.
The NMEA GPS string set consists of GGA, GSA and VTG strings at 5 Hz and GSV strings (normally 3 strings) at 1 Hz.
The 5 Hz command for the Telit JF2 GPS has been taken from the chapter ” Enable 5Hz Update NMEA” from “Telit_Jupiter_JF2_EVK_User_Manual_r0.pdf” found on internet:
"$PSRF103,00,6,00,0*23\r\n"
To enable sufficiently fast communication between Telit JF2 GPS and TinyZero the baud rate has been increased from 9600 to 19200 after first initialization of the Telit JF2. To set this baud rate at the Telit JF2 side I have used the NMEA command:
"$PSRF100,1,19200,8,1,0*38\r\n"
The functionality of this logger application has been tested under static and dynamic conditions, e.g. car trips. Overall, it works fine on standard, x-y trajectories.
A vertical oriented trajectory was tested using a medium sized low power model rocket, MER-75.
The data logger with the GPS was placed in a specially prepared payload bay in the nose cone of the model rocket. A 2nd data logger consisting of a TinyZero Processor Board, a Combo Sensor TinyShield and a MicroSD TinyShield was placed in another payload bay at the bottom of the model rocket between the model rocket motors. Accurate time synchronization of the logger recordings was done afterwards by matching the z-axis accelerations during the start ramp of the boost phase. This synchronization enables direct comparison of the altitude from the GPS TinyShield and the altitude from the barometric pressure sensor of the Combo Sensor TinyShield. Furthermore, a separate Altimeter 2 was included in the payload bay in the nose cone.
The trial was executed on July, 11 near Almere, The Netherlands, with a surface height of -6 m with respect to sea level. Readings of the Altimeter 2: Apogee: 94m, altitude at parachute ejection: 90 m above ground level.
The attached figure vertically shows the altitude (in m) derived from the barometric pressure sensor and the GPS for the time interval including model rocket launch, boost phase, ballistic phase, parachute ejection etc up to soft landing. The horizontal axis shows the time in milliseconds.
The part of the barometric sensor altitude curve during rocket motor trust (between 2.2 and 4.0 s) is not correct because the rocket motor trust influences the pressure, but after 4 s, when the motors have burnt out, it is reliable.
The GPS altitude only shows a decent increase with small steps up to 17.5 m and starts decreasing again when the rocket on the parachute is at about 10 m above ground.
It is clear that the GPS is not losing track; latitude and longitude values are not strange.
The minimum number of satellites tracked varies from 8 to 10. All GGA messages during the shown time interval show a fix.
However, it is obvious that the GPS altitude is incorrect during the most interesting parts of the model rocket trajectory. It seems to me that a very slow filter is applied on altitude data inside the GPS .
From my point of view this incorrect GPS altitude is related to the Telit JF2 functionality.
My main question: How can I get perhaps more noisy, but actual GPS altitude output?
