diff options
| -rw-r--r-- | docs/design.md | 17 | ||||
| -rw-r--r-- | docs/fat.md | 20 |
2 files changed, 33 insertions, 4 deletions
diff --git a/docs/design.md b/docs/design.md index eff342a..91e0047 100644 --- a/docs/design.md +++ b/docs/design.md @@ -78,8 +78,12 @@ binary messages with comments are provided in the source folder When messages are sent out by either side, they are prefixed with a single `0xff` byte to identify the start of a message. If a message contains a literal -`0xff` byte, it will be escaped by the send function by sending the `0xff` byte -twice. +`0xff` byte, it will be escaped by sending the `0xff` byte twice. When the +parser is done receiving a message, it goes into "idle mode". In this mode, all +data is ignored (including double `0xff` bytes), until a single `0xff` byte +followed by any other byte is received, which will cause the parser to parse +incoming data normally again. This approach of a "idle" and "normal" mode was +chosen to make the parser more resilient to serial noise. All data that is sent starts with an opcode to represent the message type, and a message id to uniquely identify each message for the purpose of replying to a @@ -107,6 +111,11 @@ Other important details: - Messages are buffered until complete, so this protocol should be used over unbuffered serial connections only. +A complete list of commands and the additional data they send is located in the +`shared/protocol.h` source file, and is well documented using Doxygen comments. +The protocol implementation is written in portable C, and is used by both the +client and server side to send and receive data. + # Asynchronous QT Serial port The serial data communication is done in an asynchronous manner, which allows the program to efficiently handle data that is arriving on a serial port. @@ -129,11 +138,11 @@ Every node has a total of three elements which consist of one button and two lig ## Provisioning -The provisioner uses the PB-ADV instead of the PB-GATT provisioning protocol. This might change in the future depending on the beacon information and if there is enough time to switch from PB-ADV to PB-GATT. +The provisioner uses the PB-ADV instead of the PB-GATT provisioning protocol. This is because the PB-ADV is the standard protocol. Also, the PB-GATT provisioning method cost to much time to make it work. ## Semaphore -For now, there are two semaphores created in the provisioner software. The first one is created for an unprovisioned beacon signal from the provisionee. Also, the second semaphore is used for adding a node to the network. All these semaphores are to make sure there is only one signal at a time. +There are two semaphores created in the provisioner software. The first one is created for an unprovisioned beacon signal from the provisionee. Also, the second semaphore is used for adding a node to the network. All these semaphores are to make sure there is only one signal at a time for processing on the background. # Used software and library versions diff --git a/docs/fat.md b/docs/fat.md new file mode 100644 index 0000000..e7f6ab5 --- /dev/null +++ b/docs/fat.md @@ -0,0 +1,20 @@ +## Functional requirements +1. [] The network has atleast three nodes in a network +2. [] A node in a network has one button and one led +9. [] Nodes are in a bluetooth mesh network +10. [] Client is connected to the mesh network and internet +13. [] Nodes contain one sensor element and one actuator element +14. [] Nodes send and receive bluetooth messages + +## Technical requirements +3. [] Nodes can control multiple LEDs +4. [] Client application can control atleast 1 button and LED +5. [] The simulated node can interect and be interacted with physical nodes +6. [] Nodes can dynamically be registered during runtime +7. [] Nodes can be provisioned by the border router + +11. [] Client can monitor and control mesh network +12. [] Nodes (inputs/outputs) can be bound to eachother +15. [] Nodes can signed out/in via client +21. [] Client can connect to other nodes + |