Lucky strike with missing bytes

This happened around 1990. When bytes were expensive and smoking was allowed at work. 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 system 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 the 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 some of the smoke detection algorithms 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 (we didn't really embrace C when it later arrived). The compiler was rather effective in its assignment of RAM. The hardware should be cheap (since then the unit were sold in large quantities), still we could afford a serially connected external RAM containing 128 bytes. This counted for at most 8 bits or one byte (not two bytes) per detector: we needed individual alarm limit, some state bits and previous analogue value from each detector. In the product which 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 I was assured that smoke level isn't really that fine grained: four bits or a half byte would probably do, for 16 levels. Less was to become more. I would be able to cram all state info into 8 bits per detector! We now had larger smoke range per analogue "bit" - so I had to introduce hysteresis in order to minimise spurious alarms. It should be hard to get into higher score and equally hard to get into lower values.

On my way to one of the meetings I carried my prototype and a battery to show it to my fellow engineers. I had made the processor signal a beeper each time a new score was entered. I placed it on the middle of the table. As the tobacco smoke filled the room, we could hear it beeping over the discussions. Back from the meeting the unit beeped again, since I never smoked myself. After some days of cycling back and forth to work (it clears the brain) an idea appeared. Perhaps I could count the number of score changes? Would this indicate how well the smoke detector had been located? 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 it, indeed had an 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 to better locations and the count values decreased to normal level. The fire brigade could stay more at home because the final result was a substantial decrease in faulty alarms. The scarce RAM resources available, taking the "less is more" aha moment in, smoking colleagues and some cycling to work had turned me into an inventor. It was just a few beeps away.

* Written 2002, here from 1.2004, updated 25Jan2020
* An edited version published in IEEE Life Members Newsletter (Dec. 2020), see here