GW12 Network Details
RPM Radio Driver
The RPM Radio requires a form of handshaking/communication control between the radio module and the MCU so that no data is lost between the probe and radio module ([See manual]). The driver should not push more than ~4kbit/s average or it will fill its buffers.
The driver should also ensure that during a transmission sequence, it enters a low-power mode while waiting for other nodes to finish their transmission sequence.
STANDBY with Wake/DTR pin - if we do hopping, some radios could be put into standby (faster startup than poweroff).
SIGNAL - pin10 says "preamble detected" - so we should not try transmitting if its set (need to Scope and record its behavour)
CTS - may be simplest way to not over-fill radio rather than driver techniques? it hoes high when buffer is 66% full and low again once its < 33% full. Buffer is 96 bytes.
GW12 Star Network
The star network to be used with the GW12 Nodes requires several features to ensure the sensing tasks are fulfilled. These include:
- Network discovery
- Time synchronisation
GW12 Hopping Network
- Routing table
- Ping nodes
- Network discovery
a simple hopping network was implemented - with no auto-route discovery. We built in a simple routing table in each node which can be setup by the base station - and make sure we can cope with longer latencies etc (RPM will probably add > 20ms to forward a packet).
The route table also specifies the port to route to - so nodes can route from serial to radio, etc. Where the channels are numbered as follows:
NO_ROUTE 0 RS485 1 RADIO_868 2 RADIO_173 3 USB 4 RADIO_151 5 RADIO_RPM 5
probes have a default route table (once you run "deploy" on them). Wired probes need to route radio-serial for all packets not destined for them. The ID of probes should only be 30-39 as that has been defined for this deployment.
routeget ID - prints the route table of a node
routeadd ID routeforID Channel - sets a route on node ID to route packets to Channel (eg 5 for RPM radio)
ping ID - pings a node - used for checking it is awake
GW12 Data/Instruction Packets
Should the communication between the devices include data and instruction/command packets? Should there be only one kind of packet or multiple different types?
I think there should be two kinds of packets: Short fixed-length command packets and longer data-packets.
Packets are thus of size between 12 bytes for command packets and 8 to 264 bytes (256+8) for data packets.
* 8-bits PACKET_START_CHAR * 8-bits PACKET_CHECK_CHAR * 8-bits SOURCE_ID * 8-bits DESTINATION_ID * 1-bit COMMAND_ID * 7-bits COMMAND * 5-bytes data * 16-bits CRC
* 8-bits PACKET_START_CHAR * 8-bits PACKET_CHECK_CHAR * 8-bits SOURCE_ID * 8-bits DESTINATION_ID * 1-bit DATA_ID * 7-bits DATA_PKT_NUMBER * 8-bits DATA_LENGTH * PAYLOAD * 16-bits CRC
Command Packet Types
- Time synchronisation/Set Time
- Device identification
- Change sampling rates
- Change wake-up times
- Request sample
- Set LEDs/ID/Debug Parameter
- List files on uSD - could be tricky as its a long list
- Send file (or send new files?)
- GW12 network commands / first draft of ideas