Initial Deployment and teething troubles

Five of the six metering systems are installed – one of the laundry rooms is closed for the summer, so next week Hercules will come to move that system to another building.

But there is another problem, one more critical: bad data. The system installed and let run for a month in Goddard seems to have about a thousand good data points. Seems is the operative word there, as the software doesn’t tell you if it screwed up. Now that there’s error checking, I know something is going wrong, but all I get is errors-meaning the software isn’t working properly. I noticed that there is more complexity to the fill cycles than I thought (seemed simple enough, fill 5 times) although listening to the machine, it seemed to fill (defined by a stop in filling) more than 5 times, in a sort of ‘add some water then add some more mode’ which screws up the count. The way the system measures the cycle is to count how much water is added each time, and after a delay, count that fill cycle as complete—and after a full (two for top load, or five for front load) fills, write to the data file, indicating what temperature on the main wash fill was used. The problem becomes more difficult with the Super Cycle.

For $0.25 more, you can get an extra rinse and run the main wash longer. That sixth or third fill makes havoc for my system as it would think the next count started, thus screwing up a whole line of washes. To combat this problem I added the ability to listen for the sixth fill, not it in the data file, and therefore not kill the datafile column. And I added a rolling clear, which would clear any extraneous data if there is a cycle which ends early in the case of a power failure, someone taking their laundry out early, or a missed super cycle fill.

When simulated, everything worked out great. Once I put it in place, nothing seemed to work, either for the top or front load machines. Both detected lots of super cycles (which are rare, according to Lev, the Hercules technician, and has several resets. I have modified the timings but if the data is bad Tuesday, I’ll have to ‘listen’ to the machine more carefully and see if the software isn’t accurately measuring the cycle.

Another possible source of trouble is the wiring. Initially (and partly still) I had planned to use twisted pairs of cable. It’s simple and it’s cheap, but it doesn’t stick in the pins very well. Eric Rosenthal suggested using header pins and ribbon cable, which I’m trying but that is more susceptible to common-mode interference, which is rejected by twisted pairs. Eric recommended shielded TP cable to eliminate this possibility, but that stuff is nearly impossible to work with at scale (60 runs) and would set me back past my acceptable time limit—the unshielded twisted pair, especially with the header pins, seems to work well, if I run in to trouble there, I’ll have to make more runs of twisted pair cabling. It’s inelegant, but works, especially with the better-sticking header pins.

I can have the datalogger print out via serial communication what it’s listening to-therefore getting a handle on exactly what’s happening. If indeed the fill schedule isn’t as I think, I will have to revise the code, which is simple, provided the schedule is regular, or can be put into time blocks (multiple fills in a single time window are fine, and would be counted as one fill). Currently the software is set so that there’s a one minute timeout after filling for nothing to happen before it considers the fill cycle complete and increments the count, this may need to be adjusted.