[NLRS] RF read water meters

[Dr. Gerald N. Johnson]

On 7/22/2012 12:15 PM, Doug Reed wrote:
>
>
> Dr. Gerald N. Johnson wrote:
>> Could be. With a transmitted bandwidth of 405 kHz, the center frequency
>> doesn't have to be held to within 0.1 ppm to be found.
> .......
>> Hopping by FCC regulations requires more than three frequencies, the
>> test reports say for their bandwidth 25 are required and used.
>
> My assumption is that they are not running spread spectrum but instead
> are working under the older Part 15 low power rules. The SS rules let
> you run up to 1 watt output. The low power rules had a limit below 1mw
> continuous with more power allowed if you used a burst mode like they
> do. That is probably how they ended up at 11.5mw average TX power.

There is much interesting data in the FCC test data from FCC ID GIF-2006B.
>
> I was wondering what data rate they are using. Is the 405KHz the BW
> rating of the TX signal or the RX BW of the receiver? A 400KHz TX BW
> implies something over 400 bits of info in the TX burst, that seems
> quite excessive. If it is the RX BW then it implies closer to 100 bits
> of TX data which is still a lot but much more reasonable.

  405 Khz is the observed TX bandwith by the testing company, the data 
submitted to the FCC. I found signals noticeable from 914.15 to 915.300 
using my handheld in WFM mode. I found a signal peak at 914.4. The FCC 
submission curves show a double peak each side of the center frequency. 
I didn't notice the other peak nor did I go look for it. Of course with 
a 250 kHz receiver bandwidth, I stretched the spectrum and with the 
short burst time, I didn't get an s-meter indication.

  I figure 54 bits minimum for binary data with 8 decimal digits data 
each for meter ID and data. Plus a sync byte or two and an EOT makes at 
least 80 bits. More for BCD, more for straight ASCII. 64 bits data for 
two 8 digit strings BCD (4 bits per digit), 16 bytes, 128 bits for 8 bit 
ASCII (least power efficient but with with more error detection. It 
would make more sense to me to use straight binary data for minimum bits 
then to add some bits for error correction or at least error detection. 
The algorithms for converting binary to BCD aren't all that complex or 
slow if one realizes division is not necessary.

When my monitor was next to my counters, it displayed a couple weird 
digits though the meter reading stayed constant.

Bandwidth depends a lot on bit shaping. Half sine bits like we used for 
9600 baud packet minimum shift keying gets a minimum bandwidth, while 
less effective transmitter shaping and real frequency shift takes up 
more spectrum.

> ITI/GES was using a TX data rate that gave a TX BW of under 4KHz, but
> the crystal controlled TX-RX equipment had a RX BW of closer to 30-40KHz
> to accommodate frequency errors in the RX and TX crystals. The 434MHz
> SAW based products were allowed +-75KHz TX frequency errors and the RX
> IF was over 250KHz wide. The PLL based products were not as wide as the
> SAWs but not narrow enough to compete with the purely crystal based
> products. The extra RX BW helped reduce the RX range.

Extra RX bandwitdh always hurts receiver performance.
>
>> Since the transmitters don't have receivers to trigger them, in the
>> drive by situation they want them to transmit often so the odds of the
>> mobile receiver being in range for at least one transmission is high.
>
> That is what I hadn't considered. If they are doing drive-by data
> collection, that explains perfectly why they TX every 4 seconds. And one
> man can drive the area far faster than a man on foot can check it. And
> it eliminates data collection receivers which would cost money and
> require maintenance for something that only needs to be done once every
> few months....

That's the basis of the Badger patent.

Right here the "foot" meter reader would be driving because its a half 
mile of road minimum to the next meter. They aren't going to be reading 
50 meters a minute, hardly will do 1 a minute on gravel.
>
> Being active 2ms out of 4000ms they have a low risk of TX collision and
> as the RX gets closer to one or the other, the signal strength would
> help resolve the issue. In fact with a laptop in the car, GPS to locate
> position and GIS info showing the houses and meters, you could have the
> display turn from red to green when the signal had been received w/o
> error. It would certainly reduce the number of meters you had to
> physically check....

I'd expect the receiver data base combined with GPS would be able to 
detect missing hearing a meter and direct the driver to go back and 
pause to try again. Then if it didn't detect the meter it would prepare 
a trouble ticket for the meter man to go check and probably replace that 
meter.
>
> I've definitely enjoyed this discussion.
>
> 73, Doug Reed, N0NAS.
>
73, Jerry, K0CQ