Search:
Site Map
Home
Left Middle
Left Bottom
Subscribe
Enter your email address and click the Subscribe button to receive updates via email.


If you are having problems subscribing, click here.
Recent Posts
Categories
Archives
 
Blog icon

ECMPS Support Blog


Mailbag: Safety in Numbers

Tuesday, December 9, 2008

Picture of a mailbagThe electronic mail carrier continues to deliver mail to the Technical Support ticketing system. For this installment of mailbag, we will do some number crunching as the focus turns to test numbers.

By the Numbers

Question

I heard that the Client Tool generates test numbers for QA certification and test data. Is this true?

-- Looking out for (Test) Number One

Answer

Dear Looking,

The Client Tool does not generate test numbers. Test numbers are data which are the responsibility of submitters to provide like any other data which must reported.

Under the new QA reporting instructions, tests must use a unique test number for each test type for each monitoring location (unit, stack, or pipe). Many of the previously submitted QA tests do not conform to this standard. In order to be able to load the data into the EPA Host System, the tests had to be renumbered. In preparing for the production release of ECMPS, the previously submitted QA data will be loaded with renumbered test numbers.

I've got your number

Question

How should I number my QA tests under the new test numbering requirements?

-- Feeling a little Outnumbered

Answer

Dear Feeling,

As sources begin to report data using ECMPS, they must apply the new unique test number requirement. The test number field has been enlarged to allow up to 18 characters. This change should assist sources in reporting unique numbers for a given location and test type, and also give sources the flexibility to develop their own numbering system for their data management needs.

There is no recommended numbering scheme, and the source or DAHS is free to employ any numbering scheme as long as it produces test numbers which are unique for the location and the test type for all time.
If you are still feeling numerically-challenged, send us an email, and we will answer your test number question. Who knows? Maybe the next installment of mailbag will be your lucky number, and your question will be featured.

Labels:

Mailbag: Stakeholder Meeting Presentations and Production & the CTP

Tuesday, November 18, 2008

Picture of a mailbagMailbag has returned from a long hiatus with a couple of new questions based on actual questions asked through technical support.

If you are not able to attend the Stakeholder Meeting

Question

I will not be able to attend the Stakeholder meeting on November 19th. Is there a way for me to find out what was covered at the meeting?

-- Not Able to Attend

Answer

Dear Not Able to Attend,

The Stakeholder meeting on November 19th will cover a variety of materials. The preliminary agenda is listed here. This agenda includes a lot of valuable material which sources and DAHS vendors should review if they are unable to attend the meeting. Fortunately, the materials will be made available after the meeting.

After the meeting, the PowerPoint presentations will be posted on the EPA Web site, and that will be announced here as well. In addition, several weeks after the meeting, we will post audiovisual presentations from the meeting which you will be able to watch online from this support Web site. You can view presentations from past Stakeholder meetings by clicking here.

When to use the CTP and when to use Production

Question

I am responsible for a large number of sources. Some of them have transitioned to ECMPS and some have not. Should I be using the CTP or the production version?

-- Confused about Versions

Answer

Dear Confused,

Let's see if I can clear up your confusion. There are indeed two versions of the ECMPS Client Tool. Currently, the most widely used version is the ECMPS Client Tool Preview (CTP). This version is for testing. By testing, we mean sources and DAHS vendors should be using it to test their XML files and become familiar with how the Client Tool works. In addition, stakeholders can use the CTP to evaluate their data in the Client Tool in order to see what corrections need to be made to their data based on new reporting requirements or old reporting requirements that were not checked previously in MDC.

It is important to keep in mind that the CTP is identical to the production version with one very important exception. The exception is that the data in the CTP is test data. The data in the CTP was originally loaded back in April 2008 based on a snapshot of official data taken at that time, but it has not been updated since then. That means that any official data which you have submitted since April 2008 is not in the CTP. The other important affect on the CTP data being test data is that changes to the data in the CTP, even if submitted through CTP, DO NOT affect official data.

The production version of the Client Tool is the version which should be used by everyone who has transitioned to ECMPS and needs to report official data using XML. In addition, anyone who is supporting the submission of official data (e.g., DAHS vendors, stack testers, consultants) should use the production version. This allows you to work with the actual data which is essential to providing support to the official submitter. If you are supporting the official submitter, but will not be making submissions, you need to be made a retrieve agent. This will allow you to view all of the official data, but you will NOT be able to submit the data. You can learn more about ECMPS agents here.

One final thought is that the CTP has been very valuable for preparing sources to make the transition to officially submitting through the production version. The sources who have used the CTP to test before submitting officially using the production version have had the least amount of difficulty in working with the production version. Since around 70% of sources will not have made the transition to ECMPS by fourth quarter 2008, there should be a lot of people using the CTP to prepare to test prior to the mandatory use of the Client Tool for first quarter 2008 submissions. If you would like to register to test, click here.

Labels:

Mailbag: Looking for Data

Monday, October 6, 2008

Picture of a mailbagMailbag has returned with a couple of new questions based on actual questions asked through technical support. In this installment, the Mailbag answers two questions from users who are looking for data in the Client Tool.

Where are the data? (Part 1)

Question

I am a production user. I do not see my previously submitted QA and emissions data. Should I retrieve it from the EPA Host System?

-- Looking for my missing data

Answer

Dear Looking,

With one exception, it is never necessary to retrieve data from the EPA Host System using the Retrieve module in the Client Tool. The Client Tool automatically obtains a summary of all of the previously submitted data which you need for evaluating and submitting data are obtained through the automatic synchronization process. No other data need to be retrieved. In fact, it can be detrimental to retrieve the data.

The one exception is when EPA has authorized the resubmission of previously submitted QA or emissions data. In that one case, it might be necessary to retrieve the data through the Retrieve module. However, even this is not necessary because in many cases users will be resubmitting data which have been provided by a DAHS vendor.

The detrimental part of retrieving data is that it fills up your database with data which you do not need and, in the case of QA data, the Client Tool will require you to evaluate all of that QA data. It would be far better to not retrieve any additional data unless it is necessary in the case of resubmission.

For more information about how to view your QA data in the Client Tool, view this previous mailbag question on "Hidden" QA Test.

Where are the data? (Part 2)

Question

I recently started to use the CTP for testing, and I am not able to retrieve my 2008 quarter 2 QA data. Where are my data?

-- Looking for my missing data again

Answer

Dear Looking,

The CTP began in May. Before the CTP was available, a snapshot of the legacy production data was taken and loaded in to the CTP environment. By snapshot, I mean that the data destined for the CTP were taken on a day in the middle of April. The snapshot of the data was then transferred into the CTP environment. The data taken were all of the monitoring plan and QA data available at that point in time. Emissions data were not transferred into the CTP environment. Although the data taken are considered a snapshot, because it so much data, the process takes some time to move the data into the CTP.

Any data which were submitted after the middle of April to the legacy production environment will not be found in the CTP. That data has not been transferred to the CTP, and currently, there are no plans to update the data in the CTP from the data which were taken in April. The reason for this include the fact that data loading and quality assuring the data loading is a time consuming process and the data are all test data.

For CTP users who are looking for data submitted after April, I would suggest contacting your DAHS vendor in order to determine if that data can be obtained as XML files which can then be imported into the CTP.

Labels:

Mailbag: Missing Files and Asking for Help

Friday, July 25, 2008

MailbagIn this installation of the mailbag, we will answer questions on how to help us help you when writing an email for technical support and what to do with missing files which are not actually missing.
How To Help Us Help You

Question
When I sent in an email for technical support, I was asked to provide more information which I gladly did. In general, what type of information should I include in my email requesting technical support?

 - What Should I Say

Answer

Dear What Should I Say,

Recently, a number of people have expressed interest in knowing what information should be included in an email requesting support. Because of this, the Mailbag writer requested that some information be provided on this topic by the Technical Support Team. In response to this request, the Technical Support team has developed its "Tips for Requesting Technical Support: How to Put Your Issue on the Fast Track to being Resolved".

Missing Files on Import

Question
On import, I am getting a message that some type of XML file cannot be found. Is there a problem with installation or the update?

 - Missing Something

Answer

Dear Missing,

A number of people have reported a similar problem. The error in the File Import Validation Report probably looks similar to the following screen shot.

Detail of File Import Validation Report with error message indicating file is missing
(Click on the image for a larger view.)

If this is the type of message you received, there is nothing wrong with your installation of the Client Tool.

Instead, the problem is that the Version tag in the file you are attempting to import is incorrect. The picture below shows the Version tag circled in a detail of an XML file.

Version Tag Number in XML File

The Version tag is near the top, and it is used to identify which version of the XML schema should be used to validate the XML file. The value in that tag must match an accepted version number. Currently, the production version of the Client Tool and the CTP will accept a value of "1.0" for all three XML file types: monitoring plan, QA, and emissions. As of release 2 of the production Client Tool and CTP2, the Version value for an emissions XML file can also be "1.1".

Any other value than the accepted values will result in this file import error message. The message should really read, that the value in the Version tag is not a valid value. However, like many of the XML validation messages, this message is produced by the proprietary Microsoft software which validates the XML, and the message cannot be changed. What the message is trying to say is that an XML schema for the version indicated by the value in the Version tag could not be found.

To fix the problem, you should go back to your DAHS vendor and ask them to modify what value is put in the Version tag.

If you have a question for the ECMPS Mailbag, simply send an email to ecmps-testing@camdsupport.com.

Labels:

Mailbag: CTP 2.0 Release, Installation and MS .Net 3.5 Framwork, and the Price of the ECMPS Client Tool

Wednesday, July 9, 2008

MailbagIn this installation of the mailbag, we will answer questions on the next version of the CTP, why there are problems installing Microsoft .Net 3.5, and the price of the ECMPS Client Tool.
CTP 2.0 Release

Question
I have heard that that there is a second quarter production version of the Client Tool. Will there be a new version of the ECMPS Client Tool Preview (CTP)?

 - Asking for seconds

Answer

Dear Asking,

Yes. The next version of the CTP, or CTP 2.0, is scheduled to be released next week. This version will be virtually identical to the second quarter (Q2) production version. The only differences are that CTP 2.0 will be clearly identified as CTP 2.0, and it will access the CTP EPA Host System.

As soon as the new version of the CTP is available, an email will be sent to everyone who has registered for testing the CTP. The email will include instructions on how to update from CTP 1.0 to CTP 2.0.

The help file in CTP 2.0 will include release notes describing what has changed from CTP 1.0.

Marquee displaying the message Coming in July: ECMPS CTP 2.0


Installation and the Microsoft .Net 3.5 Framework

Question
Why did my installation fail to install the Microsoft .Net 3.5 framework?

 - Working without a .Net

Answer

Dear Working,

The Microsoft .Net (pronounced "dot net") 3.5 framework is an essential requirement for running the ECMPS Client Tool. It provides necessary features which are used in the Client Tool, and it must be installed in order for the Client Tool to run.

There are a number of reasons that the installation of the .Net 3.5 framework might fail. The reasons primarily relate to your operating system because essentially the .Net framework is part of your Microsoft operating system. It is not a separate application or really even an add-on.

If the installation of the Microsoft .Net 3.5 framework fails, the first thing to try is to install the .Net framework prior to re-running the installation. Simply click here, download the install file, and then run it on your computer. If this fails, you should contact your IT staff. The problem may be that your operating system is not up-to-date enough in order to install the .Net 3.5 framework. The .Net 3.5 framework can be installed on Windows XP and Vista. (It cannot be installed on Windows 2000 which is also not a supported operating system for the Client Tool for this reason.) However, your operating system may need a service pack, security update, hot fix, or some other patch from Microsoft which needs to be installed prior to you installing the Microsoft .Net 3.5 framework. Because this begins to get into operating system changes and how your computer is configured, our technical support would rather defer to your IT staff to handle this situtation.

ECMPS Client Tool Software Cost

Question
How much do I have to pay for the ECMPS Client Tool? Will I be able to do all I need to do with the free version?

 - Bargain Hunter

Answer

Dear Bargain Hunter,

This is your lucky day because you have found a serious bargain. The ECMPS Client Tool is absolutely free. All of the functionality which is packed into the Client Tool will not cost you a dime because the U.S. EPA provides the Client Tool without charge.

There are no free versions because every version is free. Currently, there are two versions of the Client Tool, and that is only because there is a production version and a testing version (CTP). However, both have essentially the same functionality, and both are completely free.

If you need to provide license information to prove this to someone in your company, simply select About from the Help menu in the Client Tool and you will see the information provided about licensing and cost.

If you need to provide a receipt for your accounting group, you can print out the following receipt and include it with any other documentation you need to provide.

Receipt for the ECMPS Client Tool



If you have a question for the ECMPS Mailbag, simply send an email to ecmps-testing@camdsupport.com.

Labels:

Mailbag: Test History and Database Sizing Estimates

Friday, June 20, 2008

MailbagQuestions continue to pour in from all parts of the country regarding ECMPS and the Client Tool. We have even received at least one question, addressed, "ECMPS Mailbag". The writer of the mailbag appreciates that direct appeal for the question to be included in a mailbag post on the blog.

No matter how your questions are addressed, we are happy to answer your questions about ECMPS and the Client Tool.

In this edition of the mailbag, we will answer questions about "hidden" QA tests and how to estimate the disk space you will need to store your data on a shared network database.

"Hidden" QA Test

Question
I ran an evaluation on my emissions data which indicated that there are problems with some of the RATAs, but I do not see any RATAs in the Client Tool? Where are these RATAs?

 - Looking for my Data

Answer

Dear Looking,

During the initial synchronization, the ECMPS Client Tool retrieves what is termed Test History data. These data are the essential QA/Cert data which the Client Tool needs from all previously submitted QA/Cert data. The Test History data are a subset of all of the previously submitted QA/Cert data. The Client Tool needs these data in order to perform the data evaluations in the Client Tool which require data from previously submitted QA/Cert data. For example, the bias adjustment factor (BAF). You can view these data through the Test History Report which is found in the QA/Cert Module of the Client Tool. The data which are retrieved in the initial synchronization are all of the previously submitted QA/Cert data from 2003 to the present. Going forward the Test History data will automatically be in your Client Tool because it is generated in the Client Tool every time an evaluation is run on new QA/Cert data.

If you would like to view all of the details of the previously submitted tests, use the Retrieve module to retrieve all of the data (e.g. run data, summary data) for any of the QA/Cert data which have been previously submitted.

For more information about the initial synchronization, view the previous post on initial synchronization. (This post does not use the term Test History data because it had not been adopted at that time, but Test History data is part of supplementary data.)

Network Database Disk Space Estimates

Question
What is a good estimate of how much disk space I will need to store my data on a shared network database?

 - Diligent DBA (Database Administrator)

Answer

Dear Diligent,

A number of stakeholders are trying to plan what they will need to support a shared network database installation of the ECMPS Client Tool. In this type of configuration, there is a network server which hosts the local Client Tool database. All of the users share that database by having their installation of the Client Tool point to that database.

In order to set up this type of configuration, stakeholders need a server class computer with an instance of Microsoft SQL Server 2005 installed. The question becomes how big does the disk space need to be to support the data which this local database will hold.

In the local Client Tool database, no matter whether it is the stand-alone version or the shared network version, there are four types of data which are stored that depend on who is using the database. These data are the monitoring plan, the QA and certification, the emissions, and the evaluation results data. These data will increase according to two factors. The more facilities which are added and the more data maintained in the database over time.

For the most part, all of the other data in the local Client Tool database will be the same no matter who is using the Client Tool. These so-called meta data which include data such as lookup codes and information on how the evaluation checks are run do not change. After you have installed the database, these data will not increase over time.

Of the data that will increase over time, emissions data are by far the most important in increasing the size of the database. Consequently, as time goes on, the only data that really take up any amount of space are the emissions data.

By our estimates, the emissions data for one quarter for one monitoring plan takes an average of 12 MB of disk space. In order to estimate your disk space needs you can use this number to cover all of the necessary disk space.

For example, if your database will host 50 separate monitoring plans (which is the equivalent to the number of EDRs which you currently submit), you will need approximately 600 MB of disk space per quarter. If you continue to maintain your emissions data in the local Client Tool database, you will need to plan for using an additional 600 MB of disk space each quarter.


If you have a question for the ECMPS Mailbag, simply send an email to ecmps-testing@camdsupport.com.

Labels:

Mailbag: Missing Old Probe Information and QA/Cert Data Baseline

Friday, May 30, 2008

MailbagThe ECMPS Client Tool Preview (CTP) testing session is in full swing. Each week more stakeholders are signing up to begin working with test copies of their data in order to prepare for the eventual transition to ECMPS. Along with the testing, we continue to receive a steady stream of technical support questions. Here are a couple of those questions from the mailbag.

Missing Old Probe Information

Question
If we changed out our probes, discarded the old ones, and do not have any data related to the old probes, how will get past the errors that state the probe data does not cover the entire evaluation period?

Answer
The only way to clear the error is to have an active probe component defined for the entire period that the monitoring system has been in use since January 1st of 2003. To define a valid probe component all you need is a Component ID, Manufacturer Name, and Serial Number. The purpose of having the manufacturer and serial number information is so that electronically represented components can be identified in the field. It would be much better if you can find the information, but if the probe components are not longer in use it, is less important to have the actual data.

I would suggest adding the old probes with a manufacturer and serial number of "Unknown". Then add the the new probes with the known manufacturer and serial number information. The old probes should be ended on the correct date and hour in the system component record, and the new probes should be begin on the correct date and hour in the system component record.

For more information about adding a probe component, view the tutorial, "ECMPS Monitoring Plan Corrections, Part 2: Adding a Probe" on the Tutorials page.

QA/Cert Data Baseline

Question
Do I need to retrieve the QA/Cert data from the EPA Host System initially to have some "base line" of previously submitted data, or can I just start by adding the QA/Cert data from this quarter going forward?

Answer
During the initial synchronization, the ECMPS Client Tool retrieves what is termed Test History data. These data are the essential QA/Cert data which the Client Tool needs from all previously submitted QA/Cert data. The Test History data are a subset of all of the previously submitted QA/Cert data. The Client Tool needs these data in order to perform the data evaluations in the Client Tool which require data from previously submitted QA/Cert data. For example, the bias adjustment factor (BAF). You can view these data through the Test History Report which is found in the QA/Cert Module of the Client Tool. The data which are retrieved in the initial synchronization are all of the previously submitted QA/Cert data from 2003 to the present. Going forward the Test History data will automatically be in your Client Tool because it is generated in the Client Tool every time an evaluation is run on new QA/Cert data.

If you would like to view all of the details of the previously submitted tests, use the Retrieve module to retrieve all of the data (e.g. run data, summary data) for any of the QA/Cert data which have been previously submitted.

For more information about the initial synchronization, view the previous post on initial synchronization. (This post does not use the term Test History data because it had not been adopted at that time, but Test History data is part of supplementary data.)

Labels: , ,

Mailbag: Production Version, Tutorials with CC, and Saving Correct MP Data

Wednesday, April 30, 2008

MailbagMailbag

It is time to open up the ECMPS mail bag and answer a few questions that have been asked in the past few weeks.

ECMPS Production Version

Question
Has the production version of the ECMPS Client Tool been released?

Answer
The production version of ECMPS Client Tool was released on April 1, 2008. The production version was only released to facilities which had elected to report first quarter 2008 emissions data using ECMPS and sources who had registered to use ECMPS to submit CAIR SO2 certification applications.

The May through September testing period is about to begin. During that testing period, testers will be able to use a version of the Client Tool which is virtually identical to the version being used by production users.

This testing version of the Client Tool, which is named ECMPS Client Tool Preview or ECMPS CTP for short, has one important difference from the production version. ECMPS CTP will only access a special testing environment at EPA rather than the official production data. To register to test during this testing session, click here.

Seeing what you are Learning

Question
Is there any way to see what is being said during the tutorials?

Answer
Yes. The tutorials all include closed captioning. To turn on closed captioning, simply click on the closed captioning button (CC button) on the right side of the Tutorial Play Bar. The closed captioning will display everything which is said during the tutorials. To turn off closed captioning, click the button a second time.

Saving Corrected Monitoring Plan Data for use in Production

Question
I have registered to test in the new testing session which begins in May. Will I be able to save my corrected monitoring plan data from testing and use it when I switch to the production version?

Answer
Yes. Once you switch to production, you will be able to use the monitoring plan corrections which you make in the ECMPS CTP version. The way to do that is to follow these steps:
  1. Correct your monitoring plan data in ECMPS CTP.

  2. Generate the monitoring plan printout report and save it as a PDF file.

  3. Export your monitoring plan data to an XML file using the Export module of the Client Tool.
After you switch to production, you will be able to import the XML file into the production version of the Client Tool. Because the data is merged during an import, you will most likely still need to make some corrections to the monitoring plan. Use your monitoring plan printout report to correct your data.

More information about this topic can be found in the previous mailbag answer entitled Transferring Monitoring Plan Data Corrections from Testing to Production.

Labels:

Mailbag: Testing Questions

Wednesday, March 19, 2008

MailbagThe next ECMPS testing session is scheduled to run from May through September 2008. As that testing period draws near, we are receiving more questions about testing. This mailbag answers questions about what version of the Client Tool will be available for testing and how to transfer monitoring plan data corrections made in testing to the production environment. The answer to the second questions is a little long, but that is because there is a great deal of information to discuss on this topic.

Version of Client Tool for Testing

Question
What version of the Client Tool will be available for testing?

Answer
The Client Tool available for testing will be the same version as the one used by sources who have opted to begin reporting official data through ECMPS with one important exception. The exception is that the testing version will only allow testers to interact with test data. The test data which is available through the Client Tool is based on the most current official data, but that is where the connection ends. Any changes to the test data do not affect official data.

Transferring Monitoring Plan Data Corrections from Testing to Production

Question
I am interested in testing the Client Tool. If I correct the problems in my monitoring plan in a test version of the Client Tool, will I be able to use that corrected data once I switch over to use ECMPS for official submissions?

Answer
The answer to that question is both yes and no.

The are four reasons that the monitoring plan data corrections made during testing will not necessarily transition over to the production version. These are listed in order of increasing likelihood that the reason will make a difference.

The first reason is if the official monitoring plan changes between testing and when the source begins using ECMPS for official submissions. Right before the transition, EPA will load the official monitoring plan data into ECMPS. After the source installs the production version of ECMPS, the source will receive, through synchronization in the Client Tool, the official monitoring plan data. The data would not match any monitoring plan data which had been saved from the testing period.

The second reason is if the monitoring plan XML schema structure changes between testing and when the source begins using ECMPS for official submissions. Although there is no guarantee that this will not happen, at this point, it seems unlikely that a structural change to the XML schema will be necessary. If a structural change were to happen, any XML files saved from testing might need to be altered in order to conform to the new XML schema structure before the data in the files could be imported into the production version of the Client Tool.

The third reason is if the monitoring plan evaluations are modified between testing and when the source begins using ECMPS for official submissions. Although much testing has taken place to verify that the evaluation checks are operating correctly, there is the possibility that the evaluation checks will need to be modified because there is a bug or the evaluation specification is modified. In that case, although the monitoring plan data evaluated cleanly in the testing version, the data might have evaluation errors in the production version.

The fourth reason is that the nature of importing data is that for monitoring plan data, the imported data are merged with the existing data in the Client Tool. If one of the key fields for a particular data record is different between the imported data and the existing data in the Client Tool, there will be two records at the end of the import process for that particular data record. Typically, this happens for data for which the dates had to be corrected. There are good reasons for the data to be merged during import which necessitate that this remain the primary method for importing monitoring plan data. We have, however, begun to investigate whether there would be a way to allow the imported monitoring plan data replace the existing monitoring plan data in the Client Tool.

I would suggest using the following approach to correcting monitoring plan data. After the data have been corrected in the testing version of the Client Tool, run the monitoring plan printout report. Print it out and save it as a PDF file. This report lists all of the data in the monitoring plan, and it will be a useful reference for correcting your data in the production version. The second thing I would suggest is to export the monitoring plan data and save the XML file. Even if the file needs to be modified and the import method is not changed, the data in the file will be a good starting point for correcting the monitoring plan data in the production version. In production, after importing the data, the problems caused by the merge of data records with different key fields are fairly easy to find and correct. And in the case of data that was added and new requirements the data imported from the file should bring that in to the Client Tool without any problems.

For more information about particular monitoring plan data corrections, view the Blog series, "Preparing for ECMPS".

Labels: , ,

Mailbag: Reporting Scale Transition Points that are Different

Wednesday, March 5, 2008

MailbagMailbag

This is the first entry of a new feature on the Blog in which questions and answers from our technical support tracking system are posted. These are real questions from real users which have been answered by our technical support team.


Reporting Scale Transition Points that are Different

Question
How do you report the scale transition point if they are not the same, e.g., upscale is 95% and downscale is 90%?

Answer
The scale transition point is a new data reporting requirement for dual range analyzers. The data are reported in the non-flow span records for analyzers which have been identified as dual range analyzers in the AnalyzerData.

The scale transition point needs to be included in both the low and high span records. The data which should be reported in both records is the scale transition point for when the analyzer goes from the normal to the secondary range. Assuming low is your normal range, you should report the scale transition point for switching from the low to the high scale.

For more information, see the information about ScaleTransitionPoint under MonitoringSpanData in the Monitoring Plan Reporting instructions.

Also, more information can be found in the Blog entry on the scale transition point.

Labels: ,

 

This Web site is the property of Perrin Quarles Associates, Inc. a contractor to the U.S. Environmental Protection Agency.