Introduction

The "picnet" is the network that connects the IMP to the various smart cards on the layout, which typically have a "PIC" microcontroller on them. The name "picnet" used here is from the source code to the server software, where the files are under "~tmrc/sys3/server/tmrc/railserver/picnet".

Physically, the picnet is implemented with RJ45 connectors with cable with 4 twisted pairs. Each card has two RJ45 jacks, one for the incoming bus, and one for the outgoing bus to the next card. The last card is connected to a terminator. Needless to say, physical interruptions of the bus are a bad thing.

The most common nodes are the block cards. Also on the picnet are the turntable controller, the F-Yard touch-screen controller, and the "protocob" portable cabs.

Each node has an address between 0 and 255 (one hex byte). Address 0 is the IMP. The addresses are programmed into the PIC microcontroller in each device. The definitive list of the node addresses and types is in "~tmrc/sys3/server/real.lay", in the "Card:" lines.

No idea if there is a catalog of the cards with physical location information.

Connector Pinout

Needs to be added. Presumably the same pairing as in Ethernet cables.

Packets

Communications over the picnet are in the form of very small packets. The format is:

      +---------------------------+
      | Start byte = 0xFF         |
      +---------------------------+
      | Packet type               |
      +---------------------------+
      | cardid                    |
      +---------------------------+
      | number of bytes to follow |
      +---------------------------+
      | 0-n data bytes            |
      +---------------------------+
      | checksum                  |
      +---------------------------+

This is a "character stuff" protocol, if a byte is 0xFF, it is repeated to avoid confusion with the start byte.

In packets sent by the server through the IMP, the cardid is the ID of the destination card, in packets sent by the cards through the IMP to the server, the cardid is the ID of the sending card.

There are two packet types every card is expected to respond to:

GOT_RESET: type 240, no data bytes: Request the card to reset, this is typically done by the PIC processor going into an infinite loop and being rebooted by a watchdog timeout.
GOT_STATUSREQ: type 243, no data bytes: Request for the card to send back a STATUSINFO packet

The first 7 data bytes of the STATUSINFO response packet are standard across all cards:

      +---------------------------+
      | card type                 |
      +---------------------------+
      | uptime[0] (in 60 Hz ticks)|
      +---------------------------+
      | uptime[1]                 |
      +---------------------------+
      | uptime[2]                 |
      +---------------------------+
      | uptime[3]                 |
      +---------------------------+
      | reset type                |
      +---------------------------+
      | overflows                 |
      +---------------------------+

These are the card types that the Java server software knows:

Type Number	Card Type
1	imp
2	block
3	protocab
4	turn table
5	bkcontrol
6	wireless cab
7	lcdcab
8	fycontrol
9	lcdcab2

The reset types are power (1), brownout (2), watchdog (3), unknown (4). The overflows counter is the number of communications overflow errors that occurred.

There are also other packet types shared between cards:

GOT_NOP: type 0: Does nothing.
GOT_GETMEM/GOT_MEMDUMP: type 241: Purpose unknown, maybe programming
GOT_SETMEM: type 242: Purpose unknown, maybe programming
GOT_DATETIME: type 245: Purpose unknown
GOT_PROGRAMRES: type 246: Purpose unknown