Banner Image

Dane Kouttron

This project / write up is in progress, check back for more soon!

Project Started: 09/2024

Can a modern GoPro mascarade as a multichannel data logger?

Modern action cameras are amazing and also feature the ability to connect to external hardware over Bluetooth.

The goal here is to connect sensors to an external micro controller [esp32], pair it with a gopro and data-log those variables to the files that are recorded onboard.

How hard could adding *wireless* multichannel data recording to a closed source camera really be?

Here is the rough plan:

a quick project overview

An Intro to GPMF

yada

An Intro to GPMF

Following the GoPro Hero 4, camera's support the GPMF format or the GoPro Metadata Format, described here: [link] and also here [link]. This is a data layer added to a video file to store sensor data, like GPS coordinates, accelerometer data, etc. This data can be logged synchronously with the video source which makes adding an overlay incredibly convienient. This also is super helpful if you're recording some instrument data, that can be extract-able afterwards in software.

We're going to start by evaluating GPMF, learn how it works and learn how we can sneak some external sensor data into a camera.

What is Key Length Value?

Key length value [KLV] is a generic term for a process of encoding data into video, Key identifies the data, Length defines the length of the data, and Value is the actual raw data. Some more information is available on wikipedia [link]

KLV Diagram

For GPMF the Key, Length and Value are all 32 bit Big Endian. All GPMF data is 32-bit aligned and stored as big-endian. For data types that are not 32-bit, they are packed in their native byte or short or complex structure storage size, and only padded at the very end to meet how standard KLV alignment works. Lets start with Key, which for whatever reason GPMF renamed Key as FourCC

We get our first clue

We get our first clue, this note from here [link] clues us in that third party BlueTooth sensors can add GPMF data . This is excellent, as it confirms that some variables may be writable from external data sources. I've never heard of third party gadgets that actually do this but let's do some digging.

KLV Diagram

It looks like this may have existed early on for adding GPS to GPMF video, or maybe adding accelerometer data. Maybe there was a bluetooth heart rate monitor that could overlay data. Anything's possible but let's do some digging to find out. Comically, to find anything I had to boundary my goog searches from 2012->2017. I found this [Youtube Link]. It's a really curious add-on that sits behind the GoPro and streams smartphone data (Accelerometer, Gyro, GPS) to the GoPro. The "GetOn Data & Music" is some really rare proof that this does indeed work, all the way back on the Hero 4. They smartly sized the Bluetooth-bridge to take up the same space as the GoPro rear display / aux battery module such that it can fit in the waterproof enclosure.

KLV Diagram KLV Diagram

Somehow this gadget is actually available for purchase from amazon in the year 2024, I wonder if we can study how this works to implement a GoPro DAQ module. For 17$, or the price of a sandwich in the peoples republic of Cambridge, I bought one. I can dust off an old Hero 5 if this actually appears. Let's continue to see if other things existed that used this feature. As it turns out the Polar V800 and M600 sports watches also had this mode. from [Link]

KLV Diagram

Things are looking up, it does look like historically this functionality existed, it's oddly not common anymore. GetDataMusic's website is no longer available,

They frigging patented embedding data into a video [Youtube Link]

Look at GoPro Labs? https://gopro.com/en/us/info/gopro-labs

Here is a list of basic FourCC Key Names

FourCC
Key Name
Definition Comment
DEVC unique device source for metadata Each connected device starts with DEVC. A GoPro camera or Karma drone would have their own DEVC for nested metadata to follow.
DVID device/track ID Auto generated unique-ID for managing a large number of connect devices, camera, karma and external BLE devices
DVNM device name Display name of the device like "Karma 1.0", this is for communicating to the user the data recorded, so it should be informative.
STRM Nested signal stream of metadata/telemetry Metadata streams are each nested with STRM
STNM Stream name Display name for a stream like "GPS RAW", this is for communicating to the user the data recorded, so it should be informative.
RMRK Comments for any stream Add more human readable information about the stream
SCAL Scaling factor (divisor) Sensor data often needs to be scaled to be presented with the correct units. SCAL is a divisor.
SIUN Standard Units (like SI) If the data can be formatted in GPMF's standard units, this is best. E.g. acceleration as "m/s²". SIUN allows for simple format conversions.
UNIT Display units While SIUN is preferred, not everything communicates well via standard units. E.g. engine speed as "RPM" is more user friendly than "rad/s".
TYPE Typedefs for complex structures Not everything has a simple repeating type. For complex structure TYPE is used to describe the data packed within each sample.
TSMP Total Samples delivered Internal field that counts all the sample delivered since record start, and is automatically computed.
TIMO Time Offset Rare. An internal field that indicates the data is delayed by ‘x’ seconds.
EMPT Empty payload count Internal field that reports the number of payloads that contain no new data. TSMP and EMPT simplify the extraction of clock.

More interesting FOURCC variables

There isnt really a fully defined table of all of the FOURCC key names, but here are a few that are interesting that we may be able to adopt . The supported FOURCC variables also change with the vintage of the camera, some are only implemented on recent versions, while others trace back to the HERO 4 series. Of these FACE seems interesting as it, in itself, is a structured data format and probably unused for the most part. We do find a list of FOURCC variables from exiftool[link]. We need to determine if these are writeable from an external source next.

FourCC
Key Name
Property approximate frequency (Hz) SIUN or UNIT Comment
ACCL 3-axis accelerometer 200 m/s² Data order Z,X,Y
GYRO 3-axis gyroscope 400 rad/s Data order Z,X,Y
ISOG Image sensor gain 24, 25 or 30 (based video frame rate) n/a HERO5 v2 or greater firmware
SHUT Exposure time 24, 25 or 30 (based video frame rate) s HERO5 v2 or greater firmware
FACE Face detection boundaring boxes 12, 12.5 or 15 (based video frame rate) n/a struct ID,x,y,w,h
HERO6 or greater firmware
FCNM Faces counted per frame 12, 12.5 or 15 (based video frame rate) n/a struct ID,x,y,w,h
HERO6 or greater firmware

So we have two FOURCC variable we should be able to re-use, FACE and FCNM. These seem oddly specific and I somewhat doubt a Hero 6 [2017] had the computational horsepower to track faces while recording video. Of these two, FCNM seems fairly reasonable to get a single channel of 12-15hz data acquisition at 32bit depth.

Concluding Remarks:

Have you noticed that there are no advertisements or ridiculous pop ups?

No cookie banner or newsletter?

I'm trying to make a better web, feel free to support it.



Want More?

Here's a behind the scenes look at my work space and some of the images that did not make the cut to be included in the write-up:



If you have questions or comments, ask below or send an email


Post your comments!

Comment Box loading