Model railroad fastclock master/controller based on ESP8266 with small display and nRF24 based radio
Go to file
Dirk Jahnke 91653e197f Improved failure handling, especially in radio. 2018-12-01 13:12:33 +01:00
include Initial commit. 2018-11-14 08:43:50 +01:00
lib Added new platform: Wemos ESP8266 D1 mini pro. Now radio starts but still does not send any clock information. 2018-11-14 21:34:51 +01:00
src Improved failure handling, especially in radio. 2018-12-01 13:12:33 +01:00
test Initial commit. 2018-11-14 08:43:50 +01:00
.gitignore Initial commit. 2018-11-14 08:43:50 +01:00
.travis.yml Initial commit. 2018-11-14 08:43:50 +01:00
README.md Introduced advertisement on channel 1 and clock-channel to be configurable. 2018-12-01 09:02:19 +01:00
platformio.ini Sends broadcast time message over radio. 2018-11-15 13:03:01 +01:00

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.