Old R900 reader addon hooked up to 5/8" Neptune Aquity t-10 - readings

[stazeo]

Hello - hope this message finds you well.

I am reading data from 5/8" Neptune Aquity t-10 meters, set up as sub-meters in a multi unit building, hooked up to old R900
transmitters (FCC ID: P2SNTGSRFW1 SURF Part No 12215-000:). The old transmitters are manufactured in 2002 but are still alive and reporting the data. They are wired to Aquity meter terminal screws. The meters are measuring in US Gallons

The data for these meters appear to be reported in BCD. The consumption value that I get for a meter in R900 message type is:
13684. This value appears to be in BCD. and when translated via hex function (that I dug up through code+discussions here)
is 3574 - which is a decimal representation. However the visible reading on the meter has 2 extra digits (see attached image)
so the actual read here is 35,744.0. The last digit is most likely 1/10 of a gallon, but the next significant digit is gallons. So the reading I get of 3574 has to be multiplied by 10 to be comparable with the actual reading. But its accuracy varies and can be off by as much as 9.9 gallons in the worst case.

I am looking for a discrepancy in readings between my main meter and the sum of all sub-meters and 9.9 gallons x numbers of meters adds up to quite a bit.

Question - is the data reported coming from the reader itself? Is there a way to get the last significant gallon digit read somehow?

Thank you in advance for the help!

[stazeo]

update on my own question. I found a ProCoder FAQ document online (attached), that states the following:

ProCoder is compatible in 8-digit mode with Itron 100W, Sensus RadioRead and FlexNet, Aclara
MTUs, and Elster Energy Axis (as long as these companies continue to follow the published
E-CODER specifications).
Any other third-party radio endpoints that have ProRead compatibility will also read ProCoder; however, this is
limited to a 6-digit remote reading.
Like the E-CODER, only Neptune ® R900, R450, or celluar endpoints can activate/interrogate the PLUS features
of the ProCoder.

So it looks like to read the full 8-digit there's some type of activation/interrogation that has to happen, which doesn't in rtlamr.

So the question is changing to:

given your knowledge in developing this package/code - do you have any ideas on how to active/interrogate ProCoder to recive
two more digits for complete 8-digit reading?

faq-procoder-09.21.pdf

[kb1ca]

The documentation for the Neptune meters has become increasingly confusing as there are various models of registers, meter indicating units (MIUs) and all-in-one meter heads that bear similar and/or overlapping product names. Also, the E-Coder bus protocol is supported by other manufacturers' MIUs and remote reading hardware. So, in your case it looks like you have a Neptune Aquity mechanical meter which is equipped with a built-in ProCoder electronic register. That register is connected to an optional R900 external MIU, and the two communicate using the proprietary Neptune E-Coder protocol. From there the R900 MIU transmits periodic real-time readings over the air, which rtlamr receives and decodes. The referenced Neptune FAQ is a bit fuzzy in the way it is written but, essentially, those various third party transmitters support 8 digit resolution unlike the now-obsolete R900 which only supports six digit transmissions. The R900 MIU has been superseded by the R900i which does support transmission of 8 digits. Also worth knowing; for very large meters (eg. 8"+ mag meters) which routinely need more than 8 digits to prevent rollovers between reads there are dual-transmission R900i MIUs available which can transmit a 16 digit register by sending the lower 8 digits using one ID and the upper 8 digits using another ID, all within the same physical transmitter. For reference here's some raw data that was collected using actual Neptune hardware and software showing readings being received from both R900 and R900i MIUs: Timestamp,MIU,Protocol,Read,Count,ReadFormat,IsSurf,LeakCurrent,Leak35,ContBackflow,NoFlow35 02/12/2024 11:02:31,1545286226,R900i,02699791,0,3,1,0,1,0,0 02/12/2024 11:02:32,1471379634,R900,010950,0,1,1,3,7,3,7 02/12/2024 11:02:32,1576684024,R900i,00023337,0,3,1,0,0,0,2 02/12/2024 11:02:35,1471401218,R900,054175,0,1,1,3,7,3,7 As to why the over-the-air transmission truncates digits vs. the face of the meter, it's simply to save energy over the long term for the battery powered models. The R900i all-in-one pit meter, for example, has a projected 20 year maintenance-free lifespan. If, for example, the utility collecting the readings charges you for 12340 this month when the physical meter reads 12349 it's not meaningfully impactful so long as they commit to come read the current meter value on the precise date when you close out your account (eg. when you sell your property). The inaccuracy of the lost least-significant digits from the register usually isn't financially consequential compared to their labour cost to do a high-precision read of the value shown on the physical meter face. So, in your case what is your ultimate goal? If it's to bill all the individual customers with maximum precision then the same approach should work; do an accurate read of the meter face at account termination and the charges will all work out. As for 'interrogating' a meter, for the early models of R900i it requires shining a Neptune-provided 'flashlight' on the face of the meter itself. The flashlight emits a special pattern using an IR led which causes the meter to dump an internal buffer that contains readings for the past 96 days days captured at 15 minute intervals. Although the readings contain the same data as the normal periodic transmission rtlamr does not currently decode diagnostic transmissions as far as I'm aware. For the newer models of R900i there is also an RF-based trigger that involves transmitting a specially formatted payload containing the MIU of the unit you want to dump and then, same as the IR flashlight, the meter will promptly spill its entire internal 96 day buffer. The diagnostic readings have the same digit resolution and flags as normal real-time readings. Again, the main purpose of dumping the diagnostic buffer is primarily for billing - if your field staff can't get out to read a meter until, say, two weeks after the account was scheduled to be closed then they can still retrieve a meter reading that was buffered on a specific moment in the past and report that as the 'final billing read'. Diagnostic dumps also serve a secondary purpose to clearly demonstrate the presence of customer-side leaks when they make high bill complaints, but that's more of a bonus in the event a utility provider feels like being nice to their customers. Hope all that helps a bit.

…

On Fri, Apr 5, 2024 at 3:30 PM stazeo ***@***.***> wrote: update on my own question. I found a ProCoder FAQ document online (attached), that states the following: ProCoder is compatible in 8-digit mode with Itron 100W, Sensus RadioRead and FlexNet, Aclara MTUs, and Elster Energy Axis (as long as these companies continue to follow the published E-CODER specifications). Any other third-party radio endpoints that have ProRead compatibility will also read ProCoder; however, this is limited to a 6-digit remote reading. Like the E-CODER, only Neptune ® R900, R450, or celluar endpoints can activate/interrogate the PLUS features of the ProCoder. So it looks like to read the full 8-digit there's some type of activation/interrogation that has to happen, which doesn't in rtlamr. So the question is changing to: given your knowledge in developing this package/code - do you have any ideas on how to active/interrogate ProCoder to recive two more digits for complete 8-digit reading? faq-procoder-09.21.pdf <https://github.com/bemasher/rtlamr/files/14891298/faq-procoder-09.21.pdf> — Reply to this email directly, view it on GitHub <#296 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC7DKCFOJ7DXEFO5H664ANTY34QXTAVCNFSM6AAAAABFZPFFTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBQG4YTCMRWGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[stazeo]

Thank you for taking the time for such a comprehensive answer!

In my set up, I have a main domestic water meter provided by the municipality. that meter is a Neptune with built in R900i transmitter measured in CF, which rtlamr reads well. And I have a set of Neptune Aquity sub-meters for each apartment that I read and bill when the bill from the City comes in. All this is a new installation as of a few years ago. I chose 5/8" Neptune Aquity because they were inexpensive, readable and brand used by the municipality. I've been doing a manual read/billing and noticed a somewhat significant difference in the total amount of water used between the City billing and my own billing resulting in the total bill deficiency. (However I didn't read the meters on the same date - so I am working to get correct data for that now.)

So I took the time to automate my reading and installed hardware/software and wired R900s to the meters. So I can collect the data automatically - I'd like to add some more functionally to my collection system to be able to compare the total usage of all sub-meters with the value reported by the main domestic meter and also create bills based on the reading dates provided by the municipality water bill.

So, I am collecting the data into a database for all these meters on daily basis, but with non-exact metering I cannot have an exact measure of accuracy without looking at the meters display.

I understand your point about the billing accuracy with the last manual read vs. energy savings. And I might have to live with that lack of accuracy.
Yet, since reading functionality lies within the transmitter (and old R900 in my case) and the meters provide magnetic connection to the transmitter, I presume that 8-digit data is available and can be read/transmitted by a better transmitter.

Aquity spec says that is it compatible with R900i (spec attached), so I presume that if I get a better transmitter, I can read
more accurate data - correct?

I see that I can buy an occasional R900 v4 on ebay - but because this is still not R900i would newer R900 provide 8-digit values in transmitted data?

If R900 (any version) would not provide 8-digit data - is there a R900i transmitter available that can be wired to the meters?

Thank you again for all the help!

ps-t10-small-23-010383-07.23.pdf