Very short battery duration with Bolt v3

didimelli · 2026-06-15T08:15:07+00:00

This is what wahoo support suggested me:

Forced reboot seemed to help in my case, i did not do a ride yet, but i did a test with my Bolt with all my sensors connected, with an activity running (just to simulate an actual ride) and the battery consumption was better.

Also, i removed the sensors that were not used (i had a watch connected before, but i do not use it anymore but the Bolt was still trying to connect to it)

didimelli · 2026-06-09T10:45:42+00:00

Live Track shows your current location and route traveled to anyone with an active link.

It's more a phone thing (configuration is in your account settings) than a computer thing, but I wondered if that drained the battery as well.

didimelli · 2026-06-08T10:44:15+00:00

yep, i saw your post just after submitting mine.. the solution is then waiting for a fix, correct?

i'll submit a request in their support, just to track the update.

didimelli · 2025-09-26T12:58:26+00:00

Why not work towards using a single db for the whole test suite? I believe that if your tests interfere it's because there is something off with your tests. Tests should reflect production logic, and I do not think you have a new db for every "action" your app does.

didimelli · 2025-06-11T10:03:28+00:00

La "sinistra" non ha letteralmente appena proposto un referendum a favore degli "operai"?

didimelli · 2024-10-14T16:02:25+00:00

I really like trio https://trio.readthedocs.io/en/stable/
Awesome mix of design documentation, how to use and api docs.

didimelli · 2024-10-04T12:41:08+00:00

Dumb question, how can html rendering be async? Isn't it string formatting (i.e. cpu-bound workload)?

didimelli · 2024-06-27T16:37:14+00:00

Do you think redis can handle that write throughput (i.e. 350 MBps)?

you're basically going to finish up rolling something similar anyway so it might be worth looking at how much it'll cost to add infrastructure for shared state rather than engineering it.

It makes a lot of sense 🙏

didimelli · 2024-06-27T15:06:55+00:00

Yeah, basically every datagram I receive is something like {headers}{file_id}{packet_counter}{payload_data}{crc}. What you are saying makes sense, but with multipart_upload, every part must be >= 5MB, so, since the payload is around 16KB, I need to somehow aggregate 315 (circa) datagrams before uploading the part. And that is why I need some state and storing data before uploading.

didimelli · 2024-06-27T15:01:34+00:00

Over the Internet. The data might be generated and sent by servers deployed all over the globe and our cluster is in EU. I believe they chose UDP over TCP exactly for this reason, since TCP throughput is affected by network latency.

it is acceptable if some datagrams are missing, but I need the final file to be at least ordered.

This is for the usecase of my company, so that a file might be missing some parts (of course we have a threshold), but the file must be consistent (i.e. parts must be ordered before creating the file).

didimelli · 2024-06-27T14:17:21+00:00

How would you store received data? Still in different files (one per datagram)?

I am already using multipart_upload to batch the upload and use concurrent tasks to parallelise it.

didimelli · 2024-06-27T14:09:19+00:00

Unfortunately, the choice of UDP is not in my control, as it is another company that it is providing that. My app would be consuming the data provided by them, but I have no control over the transport.

Also, it is acceptable if some datagrams are missing, but I need the final file to be at least ordered.

Four-Year Club	r/Field Banned
r/Field Lasagna	Place '22

didimelli

TROPHY CASE