Dirk Jahnke 06b36ed3d0 | ||
---|---|---|
include | ||
lib | ||
src | ||
test | ||
.gitignore | ||
.travis.yml | ||
README.md | ||
platformio.ini |
README.md
Model Railroad Fastclock Master/Controller
This is a controller for a model railroad fastclock. That clock looks like a normal clock, but runs at a higher speed than usual. This is used to compensate the fact, that distances on the model railroad are not properly to scale, as that would need much huger locations and setup than possible.
The tasks of the master clock / controller is:
- set the correct time
- set the speed of the clock
- start/stop the clock
- inform client clocks about the current time to be displayed
- support multiple clock systems, as we have multiple arrangements of model railroads at the same location having their own times
Principals
- all messages are sent as broadcast messages without acknowledge on device level
- all devices listen to all messages and filter out those messages addressed to them
- all messages begin with a message type, to-address, from-address
- addresses are a number in the range of 0..255
- address 0 is reserved for master/controller
- address 255 is reserved for a broadcast to all devices
- if acknowledges are necessary/wanted, then separate messages need to be defined
- after receiving a message that needs an acknowledge, no device is allowed to send a message for a TBD. period of time except the requested device, which may send an acknowledge
- after sending a message, the same device must wait a TBD. period of time before sending another message
Protocol
Message structure
Type | To | From | Message |
---|---|---|---|
P,p,A,U,a,C,T,H,E | 0..255 | 0..255 | msg type dependent |
Message definitions
Nachricht | msgType | Attribute | Status | Description |
---|---|---|---|---|
ClockAdvertisement | c | FastclockName (8) ClockChannel |
done | Using ADVERTISEMENT_CHANNEL (channel 1) to announce the clock's existence. |
PairingOffering | P | FastclockName (8) ClockChannel |
done | Announce clock master and allow immediate reply by clients (master waits with further messages for at least 20ms). |
PairingRequest | p | ClientName(10) | done | Message from client as reply to PairingOffering. |
PairingAck | A | FastclockName (8) ClientName (10) Network-Address |
done | Master acknowledges a PairingRequest. |
UnpairRequest | U | tbd. | --- | Remove a client from master's client list, initiated by client. |
UnpairAck | a | tbd. | --- | Acknowledge an UnpairRequest, sent by master. |
FastClock | C | FastclockName (8) Hour Minute Second ClockSpeed Weekday stopped |
done | Current fastclock time. |
TextMessage | T | FastclockName (8) Message |
done | Additional text sent by master may be displayed by client, if possible. |
Hello | H | tbd. | --- | Test message sent by master to receive signal quality data. |
HelloEcho | E | RSSI canRouteToMaster FastclockName(8) |
--- | Hello reply with signal quality data and the ability to route (if a client cannot receive a master but routing clients, this is the chance to get access; routing not clearly defined so far, it's just an idea) |
Quiet | Q | quietTime_ms (1) | --- | Master sends this message and asks for being quiet for some time, as the master will switch off (e.g. to the advertisement channel to send an announcement). |
The communication is done on two (!) channels. One channel is used as an advertisement channel, where all clocks shall send advertisement messages from time to time to inform interested clients, on which channel they can be found. No dialogues are allowed between clock masters and clients on the advertisement channel. The advertisement channel is currently defined as channel #1.
Each clock master may use an own channel to avoid collisions, although it is possible, that multiple clock systems communicate on the same channel. The clock's channel is announced on the advertisement channel. The master switches back to the clock's channel immediately after sending the advertisement. The same advertised message is sent on the clock's channel as well from time to time as an invitation to register as a client at the master ("Pairing"). This is an optional step and only used to be able to show at the master's display, which clients are displaying the fastclock informations.
As all clock messages from the master are sent as broadcasts, each client can read/follow the clock.
Links / References
- Digitrax Loconet PE: http://www.digitrax.com/static/apps/cms/media/documents/loconet/loconetpersonaledition.pdf
- we do not support loconet yet, but it is an option to be added later
- see page 14 ff. about FAST Clock definitions
- Rocrail with a description of the loconet interface (German): https://wiki.rocrail.net/doku.php?id=loconet:ln-pe-de
- List of loconet interfaces: http://loconetovertcp.sourceforge.net/Client/index.html, and here especially the fast clock: http://loconetovertcp.cvs.sourceforge.net/loconetovertcp/tcp/client/Clock/
- FREMO had some discussions about fast clocks, see the forum (available to members only)