Missed readings?

[ngolf]

The sampling rate (using the influxdb command, and analysing in influxdb) for my power meter seems too low - It seems to be taken every 2s at best, sometimes with a >10s gap between measurements, during a continuous workout, e.g.

---

This is with a 1s window.

The other tools (trainer road, garmin 1040) seem to have a much higher measurement interval (as my prior)

The raw data in query seems to paint the same picture, e.g. (actually, larger gap)

Note that I did not stop pedalling during the entire workout, I had no power gaps on my fit file:

[tuna-f1sh]

I can't get too much into this - I think it's outside the scope of this project - but will give some pointers I can think of:

• A .fit file has a defined one second write period so there will be a record every second, regardless of whether the device received a value from the ANT+ device. Also bare in mind many headunits apply filters on top of the data received from the ANT+ device so it might still change between records even if their was no packet from the device.
• The openant module isn't polling anything but receiving packets from ANT USB stick on a sort of notify. A power meter is configured with a 8192 period, which calculates to a 4 Hz transmission rate.
• It doesn't mean the USB stick will consistently Rx from the radio and forward Tx to the host at 4 Hz - radio issues, multiplexing etc can change it.
• In my experience however (I used the InfluxDB import for a power meter/FE comparison) it should be better than what you experienced and not have 10s gaps. I would capture and look at the logs to confirm what you are seeing in InfluxDB.

[mannyray]

TLDR: Had a similar, but not exact issue as OP. Leaving this comment up to show debug work for help for future people experiencing lost data. I did discover three things:

• BUG: It is possible to receive a page number 9 from Garmin's heart strap ( https://github.com/mannyray/openant/commit/40a13adee1b467f1830e2647fc2afa6b4eccac51 ). I tested this in https://github.com/mannyray/HeartStrapAnalysis and discovered that the data is still of HeartData type.
• POTENTIAL BUG: README's pip install git+https://github.com/Tigge/openant#egg=openant did not work once I started using the code I ran into circular dependency issues
• INTERESTING BEHAVIOUR: openant code by default filters out repeat messages, but the heart rate strap can communicate data that is the same but still passes the message._data == self._last_data filter - see https://github.com/mannyray/HeartStrapAnalysis and beat_count for details
• PERSONAL INVESTIGATION GOAL: The repository in https://github.com/mannyray/HeartStrapAnalysis was created to investigate an issue https://forums.garmin.com/developer/connect-iq/f/discussion/404209/ant-heart-strap-failing-to-receive-some-packets-in-watch-app where my Garmin watch was receiving weird data from the heart strap - I wasn't sure if it was a watch or strap issue. By testing with a parallel, openant based, ANT+ USB receiver I determined that my strap is glitching sometimes. (Thank you openant!)

---

I have experienced a similar issue of missing readings with a heart rate monitor which has a 4Hz transmission rate.

Any ideas on settings I could modify to reduce the transmission miss rate? Would it be a setting outside of the openant library?

From the previous comment I am looking for more info on how to debug the following:

It doesn't mean the USB stick will consistently Rx from the radio and forward Tx to the host at 4 Hz - radio issues, multiplexing etc can change it.

Things I've tried:

• I took one of the sample code examples ( https://github.com/Tigge/openant/blob/master/examples/heart_rate.py ) and modified it slightly in https://github.com/mannyray/HeartStrapAnalysis to log upon each communication rate and keep track of overall transmission rates that are expected to come in at about 246 milliseconds. I discovered that over 50% of the expected transmissions were missed.
• I have also tried another code example https://github.com/Tigge/openant/blob/master/examples/raw_device_data.py where I set the channel settings manually channel.set_period(8070) but that also had a high drop rate (https://github.com/mannyray/HeartStrapAnalysis/tree/zonov_other_approach).
• Discovered a similar past issue https://github.com/Tigge/openant/issues/41 where someone experienced something similar: I do receive the correct data pages but in very unregular intervals between 1 and 15H and the individual's solution was to make a change which I also did locally https://github.com/mannyray/openant/commit/0c30f7b288fec05c1bbead872ba93beace27ad07 (README's pip install git+https://github.com/Tigge/openant#egg=openant did not work so I ran my script within the cloned repository). However, this did not improve drop rate
• From https://bikethe.world/help/i-cannot-connect-to-my-ant-device/, tried To save battery, some heart rate monitors’ signal is weaker compared to other devices. These heart rate monitors are built to connect to a sports watch or bike computer that is only 2 feet or less than a meter away. If you have connectivity problems with your heart rate monitor, try to place the ANT+ stick closer to your heart rate monitor. This can be done by using a USB extension cable.

Solution:

See https://github.com/mannyray/HeartStrapAnalysis?tab=readme-ov-file#drop-rate-investigation for details.