Peter Zelchenko

Portfolio > Systems > Street-Cleaning Warning Light System

Street-Cleaning Warning Light System. Concept, plan, and engineering. In 2006, I appeared on local television after I'd discovered that the new permanent street-cleaning sign system was so complicated that it even baffled the Department of Revenue, causing them to issue thousands of tickets on the wrong days. Because of this discovery, the city was forced to reverse judgments and return thousands of dollars in fines to hundreds of car owners. I quickly proposed a design where flashing timer lights would be attached to these signs. They would be timed to begin flashing a day or more before sweeping day, and then the street-sweeping truck would beam a signal to reset the lights as it passed, as well as send updated time and schedule instructions to the light. I worked on the architecture with veteran Bally-Williams pinball and videogame engineer Ted Kilpin. This idea was implemented on a pilot basis by First Ward Ald. Manny Flores in 2007.

Here's a glimpse into the firmware we were developing for the PIC microcontroller that would go inside each flashing light. This was part of a document I sent to Ted. It shows the kind of thinking that needs to go into all of the interrelated workings of such a system:

Ted, your executive knows the following parameters in EEPROM:

1 pMemSource (source of schedule, EEPROM or FLASH [or even RAM?])
2 pMemAddr (location in that memory)
3 pNumInst (total items in schedule to go with)
4 pExecType (type of execution: one shot or loop)

The above parameters should be at least partially self-explanatory. We don't have a script command interpreter, per se, such as I've outlined (not yet, at least). The schedule event items are fixed-length operations with the following parameters (obviously I'm encoding this for human readability; you'd compact it and hex it and zero-base whatever you wanted, for your convenience; I can write a converter for this, too):

STATE ##: YEAR MO/DA N WKD HH:MM - II:NN +OFS CO XON XOF

STATE = Sequential item number for state change, just for our purposes (I would call this "EVENT" because it actually sets or changes state, but that might confuse us because an "event" we're talking in real life, the day of the picnic, or the street cleaning, or whatever, and we could have three state changes (e.g., rates of flashing) before the "public event" actually occurs. So let's call it state for now)

YEAR = Year of event (0000 = not used)

MO/DA = Month and day of event (00/00 = not used, 00/14 = the next 14th)

N = Week number (0 for not used, 1 for first week)

WKD = Week day (used with or without N; 2 WED = 2nd Wednesday, 0 Wed = every Wednesday)

HH:MM = Start event hour and minute

II:NN = End event hour and minute

sOFS = Offset factor in hours (s is the sign +/-)

CO = Color of lamp, or "device" to act upon (or "command")

XON = On period (hundredths of a second - Need to be able to go to 1000, really)

XOF = Off period (see XON)

Sample schedule 1, one event, pExecType is toggled to "one shot":

STATE ##: YEAR MO/DA N WKD HH:MM..II:NN sOFS CO XON XOF
STATE 01: 2007 04/05 X XXX 09:00..15:00 +000 RE 003 097
(then dies)

Means when we get to April 5, 2007 at 9 a.m., we start flashing a very short 30 ms blip every second on the red LED. Do this until 3 p.m. and then die.)

Sample schedule 2, pExecType is toggled for looping:

STATE ##: YEAR MO/DA N WKD HH:MM..II:NN sOFS CO XON XOF
STATE 01: 0000 00/00 2 WED 00:01..23:59 -048 RE 003 999
STATE 02: 0000 00/00 2 WED 00:01..23:59 -024 RE 003 300
STATE 03: 0000 00/00 2 WED 00:01..09:00 -000 RE 003 300
STATE 04: 0000 00/00 2 WED 09:00..13:00 -000 RE 003 050
(then loops)

Note that in the first three "events," the only things really changing are the hours, the offsets, and the XON/XOF values. What this schedule does is the second Wednesday street cleaning: STATE 01 fires up two days (48 hours or -048) before the street cleaning, at midnight, and flashes the red LED for 3 ms every 9.99 (i.e., 10) seconds. It stops this at the end of that day. The next day (24 hours before or -024) it flashes faster, 3 ms every 3 seconds. EVENT 03 is so that it continues after midnight the night of the street cleaning (each state is limited in range to the selected day). Finally, at 9 a.m. of the street cleaning day, it flashes very quickly, every half second. That stops at 1 p.m., where it stops that action, loads STATE 01 back in, so as to wait for the next 2nd Wednesday (the next month).

(Do we need a voltage or "intensity" parameter as well? That would be easy to build into this.)