Lucky strike with missing bytes

This happened some 12 years ago. It could have happened today. The company I worked for was designing a new fire detection system. The incident I'll describe helped give the company many years lead over competitors. A fire detection building block consisted of a two-wire loop with combined power and signalling plus a controlling microcontroller. There could be several of these under a master processor. One loop could have up to 99 smoke-detectors connected. The microcontroller was an 8051 type, it should do two-way communication with detectors over the loop, it should measure and control the loop's power consumption and it should communicate with the master processor. In addition, it should run the signalling algorithm as well as figuring out what each detector had in mind. Was a fast fire or a smouldering fire developing? Was  the detector getting dusty? First back-of-the-envelope calculations revealed that we needed two bytes of RAM per detector, 2*99 = about 200 bytes - on a processor with only 64 bytes on-chip! Even worse: we had written a non-preemptive scheduler that could handle 7 software processes plus the idle process, which also needed some 20 bytes. Little, yes - but significant.

Code was written in PL/M-51 (a language reminiscence of C) and the compiler was rather effective in its assignment of RAM. The  hardware should be cheap (since then the unit has been sold in large quantities), still we could afford a serially connected RAM containing 128 bytes. This counted for at most 1 byte per detector: we needed individual alarm limit, some state bits and previous analogue value from each detector. In the product we were going to replace we had used 6 bits per analogue value but we didn't store each value between reading. We had wished to go for 7 bits this time, and we needed the previous readings from the last detector scan. 7 bits resolution is always better than 6, we though - and the world always advances state of the art, right? However, after consultation with the manager we were assured that smoke level isn't really that fine grained: four bits would probably do. Now we would be able to cram all state info into 8 bits! We now had larger smoke range per analogue "bit" - so we had to introduce hysteresis in order to minimize spurious alarms. It should be hard to get into higher score and equally hard to get into lower values.

This was at a time when they were allowed to smoke at meetings (and we didn't protest!) and prototypes could be carried under the arm to the meeting for inspection. We had made the processor signal a beeper each time a new score was entered. As smoke filled the room, we could hear beeps over the discussions. Back from the meeting and some days of cycling back and forth to work (it clears the brain) an idea appeared. Perhaps we could count the number of score changes? Would this indicate how well the smoke detector had been installed? Yes, it turned out that it did exactly this. A detector which had been mounted close to a ventilation outlet or close to a door with lots of traffic through indeed had increased count value. We let the master processor do this counting, and over days we could inform about the quality of the installation. Detectors would be moved, and the count decreased to normal level. The fire brigade could stay more at home because the final result was a substantial decrease in faulty alarms. As many times before, the scarce resources available had made us inventors by forcing us to think along alternative routes.