# Trend Tool (web) Data Resolution issue with Modbus/DNP3 data with 1sample/2s rate

**URL:** <http://discussions.gridprotectionalliance.org/t/trend-tool-web-data-resolution-issue-with-modbus-dnp3-data-with-1sample-2s-rate/912>\
**Category:** openHistorian\
**Created:** [June 17, 2021, 9:25pm UTC](http://discussions.gridprotectionalliance.org/t/trend-tool-web-data-resolution-issue-with-modbus-dnp3-data-with-1sample-2s-rate/912 "2021-06-17T21:25:55Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Cesar](http://discussions.gridprotectionalliance.org/letter_avatar_proxy/v4/letter/c/e47774/32.png) [@Cesar](http://discussions.gridprotectionalliance.org/u/Cesar)\
**Post date:** [June 17, 2021, 9:25pm UTC](http://discussions.gridprotectionalliance.org/t/trend-tool-web-data-resolution-issue-with-modbus-dnp3-data-with-1sample-2s-rate/912/1 "2021-06-17T21:25:55Z")

</div>

I am having some issues with the Data Resolution for data with a slower sample rate like DNP3 and Modbus (1 sample every 2 seconds).

When using PMU measurements I can use the Trend/Export measurement tool with any Data Resolution without any problem. The data is displayed and retrieved very fast. However when using a signal that comes from a DNP3/Modbus connection, I can only use Data resolution as Full, otherwise nothing is displayed, or only some points when the interval is large.

It seams that the openHistorian have some trouble in aggregating the data to display in a different time resolution for DNP/Modbus.

Does anybody have any idea what could be the problem?

---

<div class="post-metadata">

**Author:** ![StephenCWills](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/stephencwills/32/20_2.png) [@StephenCWills](http://discussions.gridprotectionalliance.org/u/StephenCWills)\
**Post date:** [June 17, 2021, 11:05pm UTC](http://discussions.gridprotectionalliance.org/t/trend-tool-web-data-resolution-issue-with-modbus-dnp3-data-with-1sample-2s-rate/912/2 "2021-06-17T23:05:52Z")

</div>

This is an unfortunate limitation of the way that downsampling is designed in openHistorian. Because the archive was designed for synchrophasor data, which is evenly sampled at a high sampling rate, the downsampling algorithm actually turns the queried time range into a collection of timestamps that are aligned to the top of each sampling interval and seeks to each timestamp in the collection. Protocols like DNP3 and Modbus do not provide a timestamp along with the data so the timestamp is derived using the openHistorian’s local clock when the data is queried with no explicit alignment to any sampling interval. As a result, when the openHistorian seeks to aligned timestamps looking for DNP3/Modbus data, it nearly always finds nothing.

---

<div class="post-metadata">

**Author:** ![Cesar](http://discussions.gridprotectionalliance.org/letter_avatar_proxy/v4/letter/c/e47774/32.png) [@Cesar](http://discussions.gridprotectionalliance.org/u/Cesar)\
**Post date:** [June 18, 2021, 12:11am UTC](http://discussions.gridprotectionalliance.org/t/trend-tool-web-data-resolution-issue-with-modbus-dnp3-data-with-1sample-2s-rate/912/3 "2021-06-18T00:11:22Z")

</div>

Hi Stephen,

Thanks for the detailed explanation! It makes sense the limitation!

Appreciate the reply!

---

<div class="post-metadata">

**Author:** ![ritchiecarroll](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/ritchiecarroll/32/2_2.png) [@ritchiecarroll](http://discussions.gridprotectionalliance.org/u/ritchiecarroll)\
**Post date:** [June 18, 2021, 7:16pm UTC](http://discussions.gridprotectionalliance.org/t/trend-tool-web-data-resolution-issue-with-modbus-dnp3-data-with-1sample-2s-rate/912/4 "2021-06-18T19:16:08Z")

</div>

If you use Grafana instead, we have an option called `; includePeaks` which you can add to your query which should help:

> <https://github.com/GridProtectionAlliance/gsf/blob/master/Source/Documentation/GrafanaFunctions.md#special-commands>