digital altimeters and jump loggers are plentiful available today. But skydivers of wing suit or canopy formation (CRW) disciplines have problems logging their jumps, since slow or short fall rate makes identifying the exit (= start of tracking) problematic.
This should be changed with this approach:
• part one is a tracking device that collects the data of many jumps in many skydiving disciplines. (current status)
• part two is feeding this data into a edge impulse project to identify distinctive patterns of the exit parameters for the disciplines
• part three is to implement the decision algorithm using tinyML into the Jumplogger tracking device.
The (part one) tracking device is finished. It uses an ESP32 DevKit V4 processor board, a 1100mAh LiPo battery, an BME280 pressure sensor, a microSD card board and Beitian BP220 GPS device. Display is a reflective DOGM 128x64 LCD with no backlight.
OLIMEX ESP32-DevKit-LiPo is a DEVKIT V4 compatible board with integrated LiPo charger
Beitian BN-220 Dual GPS Glonass Modul
small GPS unit with antenna
• Correct altimeter reading is a bit tricky. In a vacuum-chamber test the Jumplogger, an analog Barigo and the X2 showed different results: Barigo and X2 pretty close 4000m, the jumpLogger ca 4500m (baro).
This although the BOSCH BMP280 (probably the same as in the X2) is pretty precise plus temperature compensated.
Temperature seems to be the problem: the "international barometric formula" for calculating altitude from pressure refers to a temperature gradient of 0,65 K per 100m. The BMP280 library calculates altitude by measuring the temperature of the sensor, in my vacuum chamber around 20ºC - this is not a temp that you see in 4000m altitude, so it reports a wrong altitude!
Problem is, that the temp of the sensor never reflects the actual situation, since jumping out of a heated aircraft will keep it warm until you reach the ground...
I didn't use the altimeter function of the library but just measure the pressure and convert to altitude with a fixed theoretical temperature of 0ºC = 273K - this gives me results pretty close to the other altimeters (+- 50m).
• using the jumpLogger on the aisle side arm in a Cessna Caravan had problems with continuous GPS reception. Having it on the window-side arm seems to resolve this problem. Probably the same behavior as all the other GPS devices
• I added a video of a test jump with the jumpLogger on YouTube:
(Oct, 23. 2021) - unfortunately end of season in most of Europe. more work on the software and waiting for next year!
On the display of the device ist shown the current altitude (meters), rounded to 10m increments (logged is full precision).
The coordinates of the DZ (or landing point) are stored with a push button before the jump.
The display shows the distance and relative bearing to this point. So for jumps in unknown areas or sudden clouds your way back to the drop zone is shown with direction to go and distance.
currently, the unit logs a trackpoint every second, containing LAT, LON, ALT (baro), ALT (GPS) and speed in GPX format. The ALT sensor measures every 125ms (8 per second). For analysis of exit point its probably better to store all 8 altitude measurements per second. this will be done outside the GPX format, since its XML and very verbose. files get easily several MBytes. I believe a line of cdv values ist sufficient, since this data is necessary only for the ML training phase.