Old R900 reader addon hooked up to 5/8" Neptune Aquity t-10 - readings #296
Comments
|
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 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 |
|
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: ***@***.***>
|
|
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. Aquity spec says that is it compatible with R900i (spec attached), so I presume that if I get a better transmitter, I can read 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! |
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!
The text was updated successfully, but these errors were encountered: