So anyway, the company is planning on buying new handheld devices for us, to replace the old Datamatic Roadrunner. I thought they were asking for volunteers to try out new devices. Back when I was first hired, I was trained on the Roadrunner by a few people, but within a few days I had already figured out how to do a lot of stuff I was never told about. It's a knack I have. So I thought it would be fun to work with some different handhelds and figure them out.
Unfortunately, I have since learned that I will also be required to attend meetings. So tomorrow I have to go to a meeting and bring some recommendations for the new device. I've spent the last hour or so writing up the following, which I offer here just in case you aren't already bored enough. You may notice a running theme which is explicitly summarized in the final point.
· Multiple trouble codes: We frequently encounter a situation in which two or more trouble codes could be used. In these situations, the meter reader is required to use the trouble code which prevents him from receiving a processing error, which is not necessarily a trouble code that would generate a work order. For example, a frequent occurrence is to have a meter that is vacant but shows consumption, and it has a service-side leak as well. In this situation, the meter reader would be forced to enter a trouble code 82 to keep from receiving a processing error and then must “write out a card” for the leak. Our current handheld device is capable of recording up to three trouble codes, but the system that receives the data is set up to catch only the first trouble code; the remainder are ignored.
· Input of new meters: When a new meter is found that is not yet on the Roadrunner, we are currently able to add the new meter in and properly sequence it, however, the system is not set up to catch these new meters. It goes ignored, and we must “write out a card” on the new meter. Adding new meters should be fully electronic.
· Straight connections: In relation to the previous point, the ability to add new meters could also be used to electronically add straight connections, rather than being required to “write out a card.”
· Special messages/instructions: Our current handheld device has the capability for the user to type in a “special message” on any given address/account. However, the system is not set up to record and remember these special messages. Such special messages would be invaluable for meter readers to leave each other specific instructions on how to approach and find difficult meters.
· Customer information: The handheld device that I used when working as a contractor for CPS had customer/account holder name available at the touch of a button. This extra information was often very useful in finding business accounts which had no address displayed on the property. Also, the Roadrunners that Alamo Heights currently uses have room on the display for the customer name to be displayed at the bottom of the screen. Therefore, our current Roadrunner device also has this capability, however the system is not set up to give us this information.
· Backlit keypad: Our new unit should have a manually switchable backlit keypad. Manually, in that there is no light sensor employed, but the user is able to turn the light on or off as conditions require. Ideally, a timer would also be used in the backlight circuitry so that it automatically switches off within a certain period of time of no keys being pressed. This would help prevent battery drain.
· Adjustable contrast: The display of our new unit should have a manually adjustable contrast that is controlled by the user. This would be very useful in increasing readability based on lighting as well as sky and weather conditions. Both the backlit keypad and adjustable contrast would help reduce input errors and improve accuracy.
· Technical support: We absolutely must have proper technical support for our new device. As shown in several previous points, our current units are capable of more than how they are now used, but the system behind the units has never been set up to exploit these capabilities. Exploring, adapting, and even changing the capabilities of the new unit should be an ongoing process as new needs arise and new situations are encountered in the future.
And here I'll just go off on a little rant. A "processing error" is an "error" in which the meter is read correctly, and there will be no error on the customer's bill. In fact, the customer will never know about it. They are put there for the sole purpose of creating additional potential for someone like myself to make an error, because they do everything they can to make sure we get as many errors as possible, even when the "error" doesn't mean $#@!. Probably the biggest offender here is the trouble code 82, which means "vacant meter shows consumption." The computer already knows that a vacant meter is showing consumption, because it makes a kerchunking error noise and forces us to re-enter the read. I'll also add here that the Alamo Heights Roadrunners don't even have a TC-82 because of why I already said. If a meter is vacant, and you enter something higher than the previous read, that can only be because a vacant meter is showing consumption. If a vacant meter shows consumption, but also has a leak, in my opinion the leak is more important, but we can't enter the trouble code for a leak because if we do, we'll get an error for not putting a TC-82 on it. So it continues to leak, and our only recourse is to "write up a card" on it and hope someone notices. Usually, they don't.
This kind of dumbassery is standard operating procedure.
No comments:
Post a Comment