| 3 | | 1. Issue a NMI system reset to the Radio Node: Upon receiving a “Radio Node Reset” command from the CMC, a local C drives a signal appropriately to reset the Radio Node. |
| 4 | | |
| 5 | | 1. Control the system power state of the Radio node: Upon receiving a “Power On/Off” command from the CMC, a local CM drives a signal appropriately to power up or down the Radio Node. Since the same control line is used for both power on and off, the CM must verify the assumed state of the node before issuing the command. |
| 6 | | |
| 7 | | 4) Obtain Chassis Status: The CM periodically reports node status to the CMC. This status message includes voltages, temperature and other tbd parameters. The CM reports status every 20 seconds. |
| 8 | | |
| 9 | | 5) Provide CM diagnostics: There are several diagnostic commands designed for integration and test. These include: |
| 10 | | a) Remotely identify a CM from the CMC: An “Identify” command issued from the CMC causes the CM to blink a local highly-visible “Identify LED” twice per second for approximately a 20 second period. |
| 11 | | |
| 12 | | b) Identify a node at the CMC from the CM: A momentary contact button on the Grid Node Chassis generates an IDENTIFY message to the CMC. The CMC then blinks the Identify LED at a high rate for approximately two seconds. This insists in physical verification of node placement and a quick test of end-to-end connectivity with the CMC. |
| | 3 | 1. All communication from the CM to the CMC uses the UDP_SOCK_DGRAM. |
| | 4 | 1. Issue a NMI system reset to the Radio Node: Upon receiving a “Radio Node Reset” command from the CMC, a local C drives a signal appropriately to reset the Radio Node. |
| | 5 | 1. Control the system power state of the Radio node: Upon receiving a “Power On/Off” command from the CMC, a local CM drives a signal appropriately to power up or down the Radio Node. Since the same control line is used for both power on and off, the CM must verify the assumed state of the node before issuing the command. |
| | 6 | 1. Obtain Chassis Status: The CM periodically reports node status to the CMC. This status message includes voltages, temperature and other tbd parameters. The CM reports status every 20 seconds. |
| | 7 | 1. Provide CM diagnostics: There are several diagnostic commands designed for integration and test. These include: |
| | 8 | 1. Remotely identify a CM from the CMC: An “Identify” command issued from the CMC causes the CM to blink a local highly-visible “Identify LED” twice per second for approximately a 20 second period. |
| | 9 | 1. Identify a node at the CMC from the CM: A momentary contact button on the Grid Node Chassis generates an IDENTIFY message to the CMC. The CMC then blinks the Identify LED at a high rate for approximately two seconds. This insists in physical verification of node placement and a quick test of end-to-end connectivity with the CMC. |
| | 10 | 1. Start Up: Immediately after the CM fully boots up, the CM repeatedly attempts to register with the CMC at the hardcoded IP address of 10.1.200.1, port 9030. (No polling is done by the CMC during the registration process). Upon receiving the registration ACK, the CM sets its local clock to the CMC time, and begins to report status to the CMC once every 20 seconds. If the CM does not receive an ACK for the status message for three consecutive status reports, the CM restarts its registration phase. |
| | 11 | 1. The transport protocol between the CMC and CM is shown in Table 4. |
| | 12 | 1. CM Software upgrade: Each CM periodically checks with the CMC Web Server to see if a newer version of CM software is available. If a newer version of CM software is available, the CM downloads it through the Web Server and reboots into the new version. |
| | 13 | 1. Initiate Request Detailed Status from any CM: UDP protocol exchange |
| 15 | | 6) Start Up: Immediately after the CM fully boots up, the CM repeatedly attempts to register with the CMC at the hardcoded IP address of 10.1.200.1, port 9030. (No polling is done by the CMC during the registration process). Upon receiving the registration ACK, the CM sets its local clock to the CMC time, and begins to report status to the CMC once every 20 seconds. If the CM does not receive an ACK for the status message for three consecutive status reports, the CM restarts its registration phase. |
| | 16 | == CM / CMC Packet Syntax == |
| | 17 | |
| | 18 | |
| | 19 | ||Syntax || No of bytes || Identifier || |
| | 20 | || seqId || 4 || ulmsbf || |
| | 21 | || timetag || 4 || ulmsbf || |
| | 22 | || pktFormat || 2 || usmsbf || |
| | 23 | || cmd || 2 || usmsbf || |
| | 24 | || myIp || 4 || ulmsbf || |
| | 25 | || version || 2 || usmsbf || |
| | 26 | || nodeType || 2 || usmsbf || |
| | 27 | || cmStatus || 4 || ucmsbf || |
| | 28 | || mac0 || 6 || ucmsbf || |
| | 29 | || mac1 || 6 || ucmsbf || |
| | 30 | || mac2 || 6 || ucmsbf || |
| | 31 | || mac3 || 6 || ucmsbf || |
| 19 | | Table 4 CM / CMC Packet Syntax |
| 20 | | |
| 21 | | Syntax No of bytes Identifier |
| 22 | | cm_packet() { |
| 23 | | seqId 4 ulmsbf |
| 24 | | timetag 4 ulmsbf |
| 25 | | pktFormat 2 usmsbf |
| 26 | | cmd 2 usmsbf |
| 27 | | myIp 4 ulmsbf |
| 28 | | version 2 usmsbf |
| 29 | | nodeType 2 usmsbf |
| 30 | | cmStatus 4 ucmsbf |
| 31 | | mac0 6 ucmsbf |
| 32 | | mac1 6 ucmsbf |
| 33 | | mac2 6 ucmsbf |
| 34 | | mac3 6 ucmsbf |
| 35 | | } |
| 36 | | Identifiers: |
| 37 | | ulmsbf: unsigned long, most significant bit first |
| 38 | | usmsbf: unsigned short most significant bit first |
| 39 | | ucmsbf: unsigned char, most significant bit first |
| 40 | | |
| 41 | | 8) CM Software upgrade: Each CM periodically checks with the CMC Web Server to see if a newer version of CM software is available. If a newer version of CM software is available, the CM downloads it through the Web Server and reboots into the new version. |
| 42 | | |
| 43 | | 9) Initiate Request Detailed Status from any CM: UDP protocol exchange |
