TWNMM: projects/
StampNet
What to do with a BASIC Stamp
Last Modified: Saturday, 13-Jul-2002 20:19:58 PDT [Search] [Up] [Home]
Note: this page is largely abandoned. I haven't actually been working on Stamp projects for the better part of three years. It is here for completeness only.

About the StampNet

The StampNet is a basic twisted pair network in my apartment that links a number of BASIC Stamp microcontrollers together. Eventually, the idea is that this "Stampcluster" can use data it collects to make decisions about what parts of the apartment need more heating, cooling, etc., and to generally give me something to play with. While at the moment it is primarily being used for Parallax BASIC Stamp microcontrollers, there is no reason why it couldn't be used by any suitably interfaced microcontroller (I'm going to order a 80xx-style one to play with), or even for low-speed telemetry between small computers (see notes regarding Pilot, below).

The Stamp network terminates onto the serial port of one of my Linux boxes. In this fashion, the StampNet can talk to the outside world. At the moment, a small daemon program runs on the server, and writes copies of any stamp data recieved into this file. Reading the file is simple. For each packet recieved by the Linux box, it writes something like this.

Thu Jul 23 15:14:22 PDT 1998 PKT 04 TRIG
The first part of the entry is the UNIX date and time. PKT (or, as a future version will no doubt have, PAKT) signifies that a packet was recieved (I make this distinction because there is packet framing [primitive, however] in the protocol). DATA signifies raw data was recieved, and the packet framing was broken (this happens when I'm testing new ideas, and infrequently when there is a collision or random noise on the wire). The two digit number is the byte address of the stamp reporting. The final four-six characters is the function sent, decoded. The actual function code is a byte.

On the wire, the packet looks like this.

00FF:xxYYdddd:FF00, where 00FF (start packet), xx = Stamp Address, YY = function, dddd= data, FF00 (end packet).

No effort is made to provide collision detection on the transmit side. Random delays are inserted before transmission of the data (usually around ten or so milliseconds) to prevent "collision storms" when everybody tries to talk at once. This was a design decision, sacrificing data integrity for small code sizes. In practice, I have only once experienced problems with the computer not seeing a trigger press or similar data due to a collision. However, just in case, I have implemented a "RSND" function in case I need to have 100% reliable reception of data.

I am toying around with the idea of token passing, as is apparent by the F0-FF series of codes. If I can implement a token-sharing method easily, it may actually happen. I'm going to play around with some various things first.

You will note that I tend to use the last byte of the data field as destination address. This meme should continue forever, because it's just a "nice thing to do."

Function Codes Assigned:

Hex Code OpCode Function
00 NOP
01 TRIG Trigger. Button Pressed. Data field contains BCD buttons pressed, unless only button 0 pressed, in which case no data field is reported. (Does the name of this field make it obvious what microcomputer I used to play with as a kid?) (The TRIG function has two different implementations.)
02 REG+ Increment register by one. Last byte of Data field indicates which register is being increased.
03 REG- Decrement register by one. Last byte of Data field indicates which register is being decreased.
05 REGS Put Value (first byte of DATA) in Register (last byte of Data). For REG+, REG-, REGS, and REGR, see registers discussion below.
0F RSND Resend Last.
40-4F --- SECURITY SPECIFIC FUNCTIONS. See Notes below.
40 MTN+ Motion Detected. See below.
41 MTN- Motion Not Detected. Data field contains detector numbers in BCD that have changed state. MTN+ indicates that the motion detector has opened, MTN- indicates which motion detectors have gone closed. 
42 TAMP Tamper Switch Activated
43 FIRE Fire Sensor Activated (DATA = sensor number)
44 FIRS Smoke Detector Activated (DATA=sensor number)
4E ALRM Sound Alarm
4F BEAT Heartbeat.
50 --- TELEMETRY APPLICATIONS
51 TEMP Temperature. (DATA first byte: temperature, second byte is scale {0 = Farenheight, 1=Centigrade, 2=Kelvin})
52 THOT Max. Temperature exceeded (DATA = current temperature)
53 TCLD Min. temperature exceeded (DATA = current temperature)
F0-FF --- NETWORK SYMBOLS / TOKEN SHARING
F0 TOKN Address (last byte of DATA), you have the token for (first byte of data) packets.
F1 TOK? Who has the token?
F2 TOKQ Add me to the token queue. (I'm online.)
F3 TOKD Remove me from the token queue. (I'm offline)
F4 TOKR Token Refused (I don't need it [or can't handle it?], but ask me again next time around.)
F5 TOK+ Increase my token allotment, I need to talk more.
F6 TOK- Decrease my token allotment, I need to shut up more.
F7 TOKP Forfiet my remaining packets, Pass token directly to (last byte of DATA) Address, for his normal packet allotment
FA PING Address (last byte of DATA), are you there?
FB PONG My Address (last byte of DATA), I am here. PONG is also a logical reply to TOK?, so no specific "I have the token" code has been established. (FYI: Make your network's life miserable. Build a PongerStamp, that just sends pongs over and over again whenever you push a button.)

Currently on the StampNet:

Registers

There are commands dealing with various registers. This allows the Stamp to change certain registers unique to it's self. There are 255 variables per node. Each individual node has it's own set of registers. Register 0x01 on node 0x01 isn't the same register as 0x01 on node 0x02, at least not yet.

There are two hypothetical (as of this writing) ways to allow two nodes to pass data between each other using registers. One is to have the server "mirror" certain registers between two (or many) specific nodes. The other way is to create a special set of instructions to write to a second set of 255 registers that are system-wide. Either, or both, may be implemented, depending on future needs. (Of course, there is a third way, and that's to sniff packets on the wire. I'll get to that in my discussion of listeners vs. talkers later)

stampd, the Stamp Daemon

stampd is, as of this writing, a very primitive program that just takes whatever it sees on the wire and writes it to a designated file. That being said, I'm starting to implement "server features" into stampd that will allow individual nodes on the network to change registers being kept on the server. stampd will act as a "master" process, and spawn child processes as needed to work with the data that is being sent, or would write it to specific files to be handled later by a different program, depending on the situation.

Listeners Vs. Talkers Vs. Servers

I've started to think about the overall design philosophy of the network, and I came up with this concept of "listeners" versus "talkers". The argument goes something like this: some stamps (like ones that report telemetry) are inherently talkers, while others (like the BeeperStamp) would be inherently listeners. By differentiating between these two functions, coding becomes a whole lot easier. Note, however, that this might preclude the token-passing stuff.

Servers have an additional responsibility: providing the register store for the network. Due to the design of the network, at the moment I can only see having one "server" per network (although, other complex computers could certainly be "listeners" and/or "talkers", if they desired).

Generic Design Notes

I'm in the process of getting some of the code (and schematics) for this online. In the meantime, here's some design ideas I've been banging around in my head.

Applications

ThermoStamp: How Hot Am I, Anyway?

ThermoStamp was a quick hack to get temperature data into a Linux workstation using StampNet. The stamp itself was a Rev. D Stamp with a thermister coupled to one of the pins, as described in one of the Basic Stamp Application Notes. I won't regurgitate that material here, other than to say that ThermoStamp used that basic idea, coupled with a speaker to sound an alarm if the internal temperature of the computer got over 120ºF.

Security Applications Notes

I've given a lot of thought to how StampNet could be used in a security application. Obviously, the needs of a network that will be carrying security information is a little different than transporting your refrigerator temperature. With that in mind, I've implemented a few things in my design for the Security Stamp that may be of interest.

Pilot Notes

One of the things I'm working on is a PalmPilot interface to the Stamp network. You could plug a PalmPilot in, and collect data from the Stamps, or input data into the network from a Pilot. It could also act as a keyboard or similar controller.

It will require a custom piece of software (which I haven't developed) and some kind of RS-232 conversion (which should be no trick to build). Future (or present?) versions of the program/circuit could use the Pilot III's IR function instead of hard serial. The practical upshot of this is it could provide a StampNet with an additional way of talking to it's users, and/or interacting with it's environment. More on this later.

Changes to this document

.03 (August 3, 1998):

  1. Added ThermoStamp, and commands for temperature.
  2. Reformatted discussion on Applications
  3. BeeperStamp has been moved to netaddress # 5.

.02 (July 24, 1998):

  1. Changed motion detector opcodes (MOT-/+) to MTN, because I thought MOT would make more mnemonic sense for motor control.
  2. Clarified "variable" discussion. They are now referred to as "registers" (a more accurate description), and the mnemonics have been changed to reflect this (V+, V-, VSET, VREaD are now REG+, REG-, REGS, and REGR, respectively).
  3. Added two codes for various fire sensor apparatus.
  4. Added ALRM function.
  5. Added discussion on "listeners" versus "talkers"
  6. Started adding a discussion of the stampd Linux daemon
Feedle's Homepage
© 1998 Christopher B. Sullivan (feedle@hotmail.com).
Original software covered under GNU General Public License or the Artistic License.
All Rights Reserved.
index.shtml, Updated: Saturday, 13-Jul-2002 20:19:58 PDT