Question: Contributing to FlySight 2 firmware - dev testing workflow?

[profff]

Hi Michael,

I'm interested in contributing to the FlySight 2 firmware. I've been looking at the codebase and have a few features I'd like to help implement:

Features I could work on

1. Low power mode via switch - Allow users to put the device in deep sleep using the physical switch, for better battery life during transport/storage.

2. BLE streaming for additional sensors - Extend the current GNSS streaming to include IMU/Baro/Mag data for real-time applications.

Question about development workflow

Before diving in, I wanted to understand how external contributors can test their changes on actual hardware.

With secure boot enabled, I assume custom builds won't run without proper signing. What's the recommended workflow for contributors?

• Is there a way to disable secure boot for development purposes (via SWD/JTAG)?
• Do you build and sign test firmwares for active contributors?
• Or is there another approach I'm missing?

Happy to start with smaller PRs to build trust before tackling bigger features.

Thanks!

[crwper]

Regarding the proposed features:

1. FlySight 2 already goes into sleep mode (about 60 uA current draw) when the unit is turned off. Most of the remaining current comes from the backup supply for the GNSS module (maintains almanac and ephemeris in memory). What did you have in mind for this change?

2. This one will need a little discussion, I think. Streaming GNSS is fairly easy because the maximum sample rate is 25 Hz. However, other sensors like the IMU can easily output at a rate that's too high for BLE notifications. So we'll need to separate notification rate from measurement rate somehow. Any ideas?

Regarding development questions:

1. Debug is disabled on production units in order to protect private keys. With production units, it's still possible to use LPUART1 for debug output, as this is output on PB10 and PB11 pads on the bottom of the PCB. Otherwise, we do offer developer units where the bootloader hasn't been written at all. These can't be updated in the usual way--they need to be programmed using SWD--but they do leave the full debug interface open.

2. Custom firmwares can be built and signed using the deployment scripts (currently only in the develop branch). These use the public key to sign the firmware. This key is different for each production run, and is published in flysight.txt on each unit. Keys up to B6 are also included in the Deploy folder (I need to update this for more recent production runs).

[profff]

Thanks for the detailed explanations!

After digging deeper into the codebase, I now understand things much better.

LP Advertising Mode - Validating my understanding

From what I see in the code, after the 30s fast advertising period (80-100ms
interval), the device switches to LP advertising (1-2.5s interval) and stays
connectable indefinitely. So when the device appears "off" (LED off), it's
actually in Stop2 mode but still advertising and accepting BLE connections.

Did I get this right? If so, is there a way to fully power off the device
with no BLE advertising at all?

Contribution Proposals

1. Start/Stop recording via BLE

   Add commands to DS_CONTROL_POINT to switch from Sleep to Active mode
   directly from LP advertising state. This would allow a companion app to
   wake the device and start logging without physical button press.

   → Is this redundant with the Starter Pistol service? I understand SP is
   for synchronized multi-device starts, whereas this would be for individual
   on-demand control.

2. IMU/MAG/BARO streaming

   Add sensor streaming characteristics similar to GNSS, with notification
   rate decoupled from sensor acquisition (e.g., 25-50Hz notifications).

3. External timestamp for BLE-initiated recordings

   When recording starts via BLE, allow passing an external timestamp for
   the log header - useful for post syncing with other devices (video).

---

I'm on batch B6 and will use the deploy scripts for testing. Should I work on
a feature branch for PRs?

[crwper]

At the moment, the only way to turn of BLE advertising completely is to disable BLE using Enable_BLE: 0 in flysight.txt. Is there a specific use case you have in mind?

For mode control, this is something I've given a bit of thought to in the past, and I think it's a little more complicated than it may at first seem. The challenge is that it's not necessarily possible to jump straight from one mode to another--there are specific transitions which are followed, most of which have some side effects, so I think it will be necessary essentially to automate the existing transitions, as opposed to automating directly as a modifiable characteristic.

I'd love to see streaming for the other sensors integrated into the current Sensor Data Service. Ideally, I think, a new characteristic will be added for each distinct sensor, and SD_Control_Point will be used to enable/disable/configure these characteristics. Is that what you have in mind?

Can you elaborate on what you mean by an "external timestamp", and how this would be used?

[crwper]

I wonder if it would be easier to discuss these changes in the Developer Discord. If I have not already shared an invite with you, please email me at michael@flysight.ca and I'll share one there.