ION8650 Meter Load Profile Data Is Lagging

[cchapman_AMP]

I have an ION8650 that has a functioning and updated clock, but the Load Profile on the meter is lagging behind real time.  The data in the meter is 1.5 days behind real time.  Anyone ever seen this issue?

[Mehran_Mehrnia]

Hi @cchapman_AMP 

Are you using ION Setup to check real time and Load Profile? If yes, please check Time Zone settings in ION Setup -> right click on the meter -> Properties -> Time Zone tab

If you are using PME, and a meter with a large amount of logged data which has recently started communicating with PME, it will take time for PME to catch up with all the logged data on the meter.

You can also check the amount of memory used to store Load Profile logs which depends on the number of parameters being logged and the frequency with which these parameters are logged.

In ION Setup, the Memory tab in the Logging folder of the Setup Assistant displays the memory
allocated to each log and the meter’s total in-use and available logging memory.

Best Regards,

-Mehran

L3 Expert tech Support Specialist

[Charles_Murison]

Hello @cchapman_AMP ,

Would you be able to give a few more details? For example how are you reading the timestamp for the Load profile, local time or UTC time? How is the clock on the meter set? How do you determine that data in the meter is behind real time?

Regards,

Charles

[cchapman_AMP]

Hello, Charles,

The clock was showing the proper time.  This meter was set to DST=0 and the time on the clock was up-to-date to Eastern Time.  When checking the Load Profile log, the data showing in the meter was 27 hours behind the current time shown on the meter.  The logging memory was set to 35040 intervals.   Our PrimeRead application was calling and updating with the time and date found in the meter.

I was waiting for the owner of the meter to re-boot the meter and I was wondering what causes this issue and if there is a solution other than re-booting the meter.

On 8/18/2024, the owner re-booted the meter and it jumped the Load Profile to current date and time.   The jump in the meter skipped the 27 hours of data that we could see current the entire time in our SCADA connection to the solar field this meter resides in.

Luckily, I can use the SCADA data to correct the missing data in our PrimeRead system.

If you can share any insight into what may cause this in a meter, it would be appreciated.

Here are some details on the meter:

ION8650

Template is 8650B_V3.3.0.1.1

Revision (firmware) 004.020.001

Thank you.  Have a good day!

-Chris

[cchapman_AMP]

Hello, Mehran,

Thank you for your response.  The Load Profile memory was 0.26% and Duration 260 and Records 6240.  Everything there looks normal.  Thank you again.  Have a good day!

-Chris

[Robert_Lee]

Not knowing precisely how PrimeRead is retrieving the Load Profile, I have a few questions.

1 If using ION Setup to read the exact same data, does ION Setup show the same date/timestamp for identical readings (i.e. ION Setup reports a reading having a value of X at date/time Y and PrimeRead is reporting the identical reading and timestamp).

2. The ION meter typically receives its time updates using UTC (Universal Coordinated Time) which is the time it is in Greenwich England without DST applied.  Since the TZOffset is 0, the meter will believe it is located there and all data records will reflect that same time.  PrimeRead should account for that (and use its own timezone to adjust for EST or EDT if preferred).

Confirm what other time sync setting are configured for and determine exactly what application is periodically updating the meter's time if necessary.

3. When the meter powered down/up was there a *gap* of data as shown when viewing by ION Setup (records just skipped ahead and there is missing 27 hours) or did it fill in missing data with zero values?  Or are you saying now ION Setup (and PrimeRead) are both showing the exact same data which is now complete and nothing is actually missing at all.

[cchapman_AMP]

Hello, Robert,

For the moment, we can ignore our PrimeRead system since it was acting normal.  Here is what was happening with meter.  Here is a simple example:  Let's say right now is 12noon EST January 1.  The on-meter load profile shows the last data for 6am EST January 1.  The meter, up to when it went down a week ago, was showing the on-meter load profile in synch with the current time.  There has been no time zones or time synchs or any changes.  At 5pm EST on January 1, the on-meter load profile is showing the last data as 11am EST January 1.  We re-booted the meter and then the issue has gone away but I wondered why this would happen?  The issue has been resolved.  My SCADA team was up-in-arms until I could get the team on-site to go re-boot it.  Thank you for your help and insight.  Have a good day!

-Chris 

[Robert_Lee · Accepted solution]

I strongly suggest to do the following if/when you observe a similar drift in the device in similar fashion:

1. Immediately connect to the device using ION Setup and observe the clock settings found in the ION Setup assistant.

Pay close attention to all of the Clock settings and what they are set to.  Whether you program Timezone or not should not matter unless you using time of use functionality as the ION meter operates in UTC.

Most applications need to realize that and interpret the data as such.  If for example the Time Sync Type is set to UTC but the time sync source were to sync using localtime, this would have an adverse effect on when daily operations might occur.

2. Download the exact same log using ION Setup and view the data side by side with PrimeRead.  Are they reporting similar values for the exact same date/timestamps?  Does ION Setup show the same inability to read the data (stays 12 hours behind for example) until the device is power cycled.

[Robert_Lee]

You state in your first post:

Our PrimeRead application was calling and updating with the time and date found in the meter.

So depending on the CL1 TimeSync Type, if set to UTC, PrimeRead must properly set the time as GMT time (that in London without DST) and if the Timezone is set to Eastern Standard Time with no DST, then the CL1 LocalTime should show EST always (and never EDT).  If it is set to LocalTime, then the timezone must also be set properly as well as the ION meter will adjust the time sent via update to compute UTC.

Now, when retrieving the data log records, PrimeRead will need to interpret the date/timestamp for each record as UTC and adjust accordingly.