Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
L
LogAir_Application_XOS
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3
    • Issues 3
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Nicolas Richard Walter Boeckh
  • LogAir_Application_XOS
  • Issues
  • #4

Closed
Open
Opened Feb 07, 2020 by Nicolas Richard Walter Boeckh@Nicolas.Boeckh💬Maintainer

Modify firmware data stream

Render packets lightweight.

Data stream is ASCII, which means it interprets 2 bytes at a time to create "Text" -> Loss of data/efficiency

Implement new data model, where sent bitwise. :

8 bits n bits 32 bits 32 bits 16 bits
# specifiers =: n non-zero or -null mapping specifier type(float) specifier type(int) CRC_16

For any packet, such as the [,,,,,32.3,68.4,101154.1,,276,,279$, we would represent it as the following :

(Using CRC_16\ARC, polynomial := 0b1000000000000101, init := 0b0000000000000000)

=> [ | 12 packets | [∅, ∅, ∅, ∅, ∅, x, x, x, ∅, x, ∅, x], 32.3, 68.4, 101154.1, 276, 279 | CRC_16 | $

=> [ | 00001100 | 000001110101 | 01000010000000010011001100110011, 01000010100010001100110011001101, 01000111110001011001000100001101, 00000000000000000000000100010100, 00000000000000000000000100010111 | CRC_16 | $

=> [ | 000011000000011101010100001000000001001100110011001101000010100010001100110011001101010001111100010110010001000011010000000000000000000000010001010000000000000000000000000100010111 | CRC_16 | $

Then we 0 pad to a multiple of 8. => [ | 0000000011000000011101010100001000000001001100110011001101000010100010001100110011001101010001111100010110010001000011010000000000000000000000010001010000000000000000000000000100010111 | CRC_16 | $

Then we calculate the CRC value => [ | 00000000110000000111010101000010000000010011001100110011010000101000100011001100110011010100011111000101100100010000110100000000000000000000000100010100000000000000000000000001000101110111001100110011 | $

Then for each group of 8 bits, we convert to a ASCII character, in the end we have a string -> [\x00ÀuB\x0133B\x88ÌÍGÅ\x91\r\x00\x00\x01\x14\x00\x00\x01\x17s3$ which is 54 bytes long, compared to the 70 bytes originally, but with added integrity check.

For a full packet, we can expect floats to take (32+1 bits) opposed to (5*8 bits) in a normal packet.

We lose compressability with integer representation, but that enables fast splitting and decoding.

CRC code to get started : https://gitlab.unige.ch/Nicolas.Boeckh/ftp-server-client/blob/master/common/crc.c Attached is the C code to obtain an IEEE 756 representation of a floating point number.

float.c

Have fun.

Edited Feb 14, 2020 by Nicolas Richard Walter Boeckh
Assignee
Assign to
0.1.1
Milestone
0.1.1
Assign milestone
Time tracking
None
Due date
None
Reference: Nicolas.Boeckh/la_app_xos#4