Support for Vendors
Support for BiDiB
For the first steps with the new hardware/software, here are some hints to start a session and a few examples of protocol data.
Typically after switching on, the condition of the appropriate protocol partner is not clear. So we have to wait until a message frame character arrives, in order to begin to evaluate data. On the hosts side, we must expect that the BiDiB system is already enabled and actively sending data or data has been already sent. This data can be still in buffers at the PC or inside the BiDiB system itself.
When starting a host program we are going to send a frame character, a query message, a frame character and again a query message including the frame character: The first query provokes a response, so you get for sure a frame signs at its end and the second query is the actual protocol start.
After the successful contact with the interface (that is a valid response to MSG_GET_SYS_MAGIC) a MSG_SYS_RESET should be performed, in order to terminate all remaining communication from the previous operation, such as Secure-ACK, Nodetab-notifications and so on.
This double start must be performed with all three possible baud rates 1 Mbps, 115200 and 19200 baud (in this order). The following should be noted: If a BiDiB system going to be contacted with 1MBaud, which is already active at 115200 Baud, a zero-Bit is shown as zero-Byte! So if a request is answered with zero bytes, probably a slower baud rate is already active.
After successful contact and initialization, the NODETAB of the interface can be imported. All available nodes at this level are listed in the NODETAB. If these nodes have an interface (recognizable at the active Class-ID bit for interfaces) then there are more subnodes existing.
Example Data: BiDiB (serial)
0xFE 0x03 0x00 0x00 0x01 0xD6 0xFE, this means in detail: 0xFE Magic 0x03 MSG_LENGTH 0x00 local address 0x00 MSG_NUM 0x01 MSG_TYPE (= MSG_SYS_GET_MAGIC) 0xD6 CRC 0xFE Magic
The message starts with BIDIB_PKT_MAGIC (see note below), followed by a size of 3. The size includes the data until the CRC but CRC will be not counted.
The local address is 0, this means the message is addressed to the interface.
The message number is 0, therefore the destination node do not perform any check and also resets it's own verification.
Finally, the message type is 0x01 = MSG_SYS_GET_MAGIC, that's the query of the system identifier. This query is used to check whether if we are connected to a BiDiB system. No parameters are used here.
The response of the node looks like this:
0xFE 0x05 0x00 0x00 0x81 0xFD 0xDE 0xAF 0x89 0xFE, this means in detail: 0x05 MSG_LENGTH 0x00 local address 0x00 MSG_NUM 0x81 MSG_TYPE (= MSG_SYS_MAGIC) 0xFD escape 0xDE this is: FE 0xAF together with the value above: FEAF 0x89 CRC
The message starts with BIDIB_PKT_MAGIC too (see note below), followed by a size of 5. The size includes the data until the CRC, CRC itself plus the included Escape will be not counted.
The local address is 0, this means the message is coming from the interface.
The message number is 0, this number will be incremented on further messages.
0x01 = MSG_SYS_MAGIC announce the system identifier. This identifier consists 2 Bytes: 0xFE, 0xAF; 0xFE is similar to BIDIB_PKT_MAGIC, therefore it must be "escaped". 0xFD will be transmitted followed by 0xDE, this is calculated from 0xFE with 0x20 XOR.
Example data: BiDiBus (RS485)
An example of a client logon message looks like this:
0x0B 0x0A 0x00 0x00 0x8E 0x40 0x00 0x0D 0x67 0x00 0x01 0x00 0x4C, this means in detail: 0x0B Packet size, contains just a messages 0x0A MSG_LENGTH (message size) 0x00 local address 0x00 MSG_NUM 0x8E MSG_TYPE (= MSG_LOGON) 0x40 Class_ID 0x00 extended Class_ID 0x0D Vendor_ID (13 = DIY) 0x67 0x00 0x01 0x00 Product_ID (vendor-specific identificationh) 0x4C CRC
The message starts with the packet size, here are 11 bytes in this example (from 0x00 to 0x0A), followed by the messages (one single message in this example). This messages starts again with size (10 Byte), followed by the local address, sequence number and message type. Finally, 7 Bytes of data will be transmitted (Unique ID of the node). CRC will be calculated over the whole package.
Example Data BiDiB (system start)
Here is a slightly more detailed example of a communication between a host and a BiDiB system. After connection, the host query the software versions and the nodes submit all existing features followed by the occupancy status.
IRP_MJ_WRITE FE 03 00 00 01 D6 FE IRP_MJ_WRITE FE 03 00 00 01 D6 FE // = MSG_GET_MAGIC IRP_MJ_READ FE 05 00 01 86 02 00 46 FE // = CRC Error (from old Init's) IRP_MJ_READ 05 00 00 81 FD DE AF 89 FE // = MSG_SYS_MAGIC IRP_MJ_READ FE 05 00 00 81 FD DE AF 89 FE // = MSG_SYS_MAGIC IRP_MJ_WRITE FE 03 00 00 09 14 FE // = MSG_SYS_RESET IRP_MJ_WRITE FE 03 00 00 01 D6 FE // = MSG_SYS_GET_MAGIC IRP_MJ_WRITE FE 03 00 01 07 CF FE // = MSG_SYS_PING IRP_MJ_WRITE FE 03 00 05 02 CB FE // = MSG_SYS_GET_P_VERSION IRP_MJ_WRITE FE 03 00 02 05 26 FE // = MSG_SYS_GET_UNIQUE_ID IRP_MJ_WRITE FE 03 00 03 03 3F FE // = MSG_SYS_ENABLE IRP_MJ_READ 05 00 00 81 FD DE AF 89 FE // = MSG_SYS_MAGIC IRP_MJ_READ 03 00 01 82 7C FE // = MSG_SYS_PONG IRP_MJ_WRITE FE 03 00 04 06 6E FE // = MSG_SYS_GET_SW_VERSION IRP_MJ_WRITE FE 03 00 06 10 BF FE // = MSG_FEATURE_GETALL IRP_MJ_READ 05 00 04 83 04 00 58 FE // = MSG_SYS_P_VERSION --> 00.04 IRP_MJ_READ 0A 00 02 84 C0 00 0D 66 00 00 0A C0 FE // = MSG_SYS_UNIQUE_ID --> C000 = Interface + occupancy detector IRP_MJ_READ 06 00 03 85 02 08 01 FF FE // = MSG_SYS_SW_VERSION --> 01.08.02 IRP_MJ_READ 04 00 05 92 09 E4 FE // = MSG_FEATURE_COUNT // Features from Node 0 will be read IRP_MJ_WRITE FE 03 00 07 11 25 FE // = MSG_FEATURE_GETNEXT IRP_MJ_READ 05 00 06 90 00 18 95 FE // = feature: number of occupancy detectors = 0x18 IRP_MJ_WRITE FE 03 00 08 11 3D FE // = MSG_FEATURE_GETNEXT IRP_MJ_READ 05 00 07 90 01 01 DF FE // = feature: ocuupancy detection active // uand so on... // query of occupancy messages IRP_MJ_WRITE FE 05 00 10 20 00 18 18 FE // = MSG_BM_GET_RANGE from 0x00 until 0x18 IRP_MJ_READ 08 00 0F A2 00 18 00 00 00 09 FE // = MSG_BM_MULTIPLE // 0x00 = Start, 0x18 = Size // 3 Bytes 0x00: all empty.
Multiple node adressing
This example shows the addressing of different nodes. Assumed here is an interface (with address 00) and an connected BiDiBus node. The node bus address is assigned at login and is assumed here with 01, the node is therefore addressed with 01 00.
First, we get the current assignment of nodes to local addresses from the interface. This can be made with MSG_NODETAB_GETALL.
Now, we have a list of which node is connected (indicated by their UNIQUE_ID) and know their current local address. (00 and 01 00 in this example)
In the following, 2 examples for messages to these nodes:
Interface, node address 0:
fe 04 00 06 12 fd de d8 fe // serial messageHere is the detailed meaning of the Bytes:
fe: Magic 04: Size 00: Address 06: Sequence (this means the message number 6 to the interface) 12: MSG_FEATURE_GET fd de: Query feature 254 (including escaping) d8: CRC
Nodes, Node Address 1:
fe 05 01 00 04 12 32 c7 fe // serial message
Here is the detailed meaning of the Bytes:
fe: Magic 05: Size (incremented by one, the address is longer) 01 00: Address 04: Sequence (this means the message number 4 to this node) 12: MSG_FEATURE_GET 32: Query feature 50 c7: CRC
Addressing of a multilevel BiDiB-System, using a hub
BiDiB is hierarchical, bus levels can be nested. From the host's point of view it is like a tree structure. If a node reports to be an interface (the corresponding class bit in the UniqueID is set), the current assignment of sub-nodes to local address can be read from the NODETAB of this node.
00 → interface 04 00 → hub (the 4 is just an example here) 04 02 00 → node behind the hub (where 02 is the current local address of the target node)
This may also occur recursively:
00 → interface 04 00 → hub 04 02 00 → hub behind the hub 04 02 05 00 → final destination node behind second hub.
- 04 is the local address of the first hub, this is obtained from the NODETAB of the interface
- 02 is the local address of the second hub, this is obtained from the NODETAB of the first hub. Together with the address of the first hub the complete address stack is: 04 02 00 .
- 05 is the local address of the destination node, this is obtained from the NODETAB of the second hub.
The address stack is limited to 32 bits (= 4 levels), otherwise the interface will send an error message.