Use smaller files on the SD card ($1500)

[beastoin]

The larger an SD card file is, the slower the read/write access becomes, and the more battery it consumes.

The current firmware writes one large file to the SD card when the device is disconnected, which leads to significant battery consumption.

Key results:

• Firmware: When the device is disconnected, write smaller, time-based files (e.g., 5-minute audio chunks) instead of one large file. Each file name must contain a timestamp.
• App: Sync the audio files according to these smaller file chunks.

Refs:

• Related Issue: #1508

• Firmware sdcard.c, storage.c : https://github.com/BasedHardware/omi/blob/main/omi/firmware/firmware/app/src/sdcard.c , https://github.com/BasedHardware/omi/blob/main/omi/firmware/firmware/app/src/storage.c

• App's SD card's Sync: https://github.com/BasedHardware/omi/blob/main/app/lib/services/wals.dart#L148

• Writes one large file's battery consumption:

  

• Writes small files's battery consumption:

  

Timeframe: 1 week.

[kodjima33]

/bounty $1500

[algora-pbc[bot]]

💎 $1,500 bounty • omi

Steps to solve:

1. Start working: Comment /attempt #1650 with your implementation plan
2. Submit work: Create a pull request including /claim #1650 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to BasedHardware/omi!

Add a bounty • Share on socials

Attempt	Started (GMT+0)	Solution
🟢 @varshith257	Feb 9, 2025, 3:04:02 AM	WIP

[varshith257]

Can I get this assigned ? @kodjima33 @beastoin

/attempt #1650

Algora profile	Completed bounties	Tech	Active attempts	Options
@varshith257	28 bounties from 12 projects	Typescript, Rust, Go & more		Cancel attempt

[harshithsunku]

Hi @kodjima33 , @beastoin ,

I've raised a Draft PR: #1783.

🚫 No testing has been done yet as I currently don't have the OMI device.

I placed an order for the device on February 2, 2025, and I’m waiting for it to be delivered. Once I receive it, I will proceed with testing and update accordingly.

Thanks!

[andrewgazelka]

@addbounty $1500

[addbounty]

Make a Draft PR early so others can see you are working on it! To automatically create one:

# Using npx (installed if you have NodeJS/npm)
npx bountybot solve BasedHardware/omi#1650

Join Our Discord to connect with other bounty hunters and get help.

When merged, you will receive the bounty!

[varshith257]

@andrewgazelka @beastoin @kodjima33 Does we need the device to test? I think it will be great if are there any alternatives to test. I have completed the work of what intended but not sure testing. Will draft PR once I get the clear view on the testing side.

Hope your guidance will be great

Maybe @mdmohsin7 any insights here

[kodjima33]

@varshith257 you need the device, we don't assign bounties on people with no traction / previous PRs

[Aditya-Choudhry]

/request can i work on this bounty can you explain what you need

[0xkelvin]

if still open, I can work on the bounty thanks @beastoin

[beastoin]

assigned to you. dont forget to keep us updated.

[0xkelvin]

assigned to you. dont forget to keep us updated.

better way is: have a daily call if you have time, just 10 mins per day

[beastoin]

oh man, sorry for the late response. btw, you should do a course yourself first, collect good questions — or ideally create a PR. feel free to drop them here or ping me on Discord (and let me know what you need).

any update on this one ?

@0xkelvin

[0xkelvin]

not much update, getting the hardware and having look at the base source and ordered 2 of : https://www.omi.me/products/omi-dev-kit-2

[harshithsunku]

Hi @beastoin ,

Implementation Update - Issue #1650

I've successfully implemented the core functionality for this bounty! The device now writes smaller, time-based files (audio chunks) instead of one large file when disconnected, with timestamps in filenames.

Current Implementation Status:

• Time-based chunking system implemented
• Timestamp-based filenames working (Bases on UpTime)
• Configurable chunk duration (currently 5 minutes)

Note: My expertise is in firmware and system-level programming, so everything above is implemented and ready on that side.
The Android app sync side may require minor updates to handle multiple smaller files instead of one large file — I'll need to explore that part if it's required for bounty approval, as I don't have prior experience with Android application development.

Requirements Questions for Final Implementation

1. Should the chunk duration be configurable in production or fixed at 5 minutes?

2. What timestamp format should we use in filenames?

   • audio/HHMMSS.txt (uptime-based timestamp - CURRENTLY IMPLEMENTED)
   • audio/SSSS_NNN.txt (session ID + sequence number)
   • audio/chunk_NNN.txt (pure sequential)

3. Should timestamps be real-time or uptime-based?

   • Real-time requires RTC implementation
   • Uptime-based is simpler but resets on reboot

4. How to handle device reboot scenarios?

   • Preserve all existing chunks vs. start fresh session?

5. Storage management when SD card gets full?

   • stop recording or implement cyclic logic?

6. For the bounty submission, what's the minimum viable implementation?

   • Just firmware changes vs. firmware + app changes?

7. Should we include backward compatibility with existing large files or format the SD card with the new firmware?

Sample Output Preview

Below is a screenshot from the test device showing the 30-second chunk implementation in action (used here for demonstration purposes only — the final implementation will follow the agreed chunk duration).

Each .txt file represents a recorded chunk with uptime-based sequential filenames.

[beastoin]

assigned to you, looking forward to your PR @harshithsunku

---

1. Should the chunk duration be configurable in production or fixed at 5 minutes? => 5 minutes fixed.

2. What timestamp format should we use in filenames? => chunk_HHMMSS_.bin

3. Should timestamps be real-time or uptime-based? => i hope we have rtc, for now, use uptime based. pls try to find the good solution for resets/reboot scenarios.

4. How to handle device reboot scenarios? => preserve existing files.

5. Storage management when SD card gets full? => stop recording, inform users so they can take actions.

6. For the bounty submission, what's the minimum viable implementation? => firmware + app changes.

7. Should we include backward compatibility with existing large files or format the SD card with the new firmware? => no, i will help on that parts.

[beastoin]

Added timeframe, 1 week.

@harshithsunku pls note.

[harshithsunku]

Added timeframe, 1 week.

@harshithsunku pls note.

ok @beastoin

[HKTITAN]

/attempt #1650

Implementation plan:

• Added time-based chunking in firmware (5-minute chunks when disconnected)
• Automatic detection of disconnection and instantaneous mode switching
• Timestamp-based filenames (audio_.bin)
• App syncs in 5-minute chunks (300s) to align with firmware chunking
• Maintains backward compatibility with single-file mode when connected

Ready for review and testing.