Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data types for pappus library should be changed #16

Open
Trent3211 opened this issue Nov 22, 2022 · 1 comment
Open

Data types for pappus library should be changed #16

Trent3211 opened this issue Nov 22, 2022 · 1 comment
Labels
bug Something isn't working

Comments

@Trent3211
Copy link
Collaborator

Rather than saving as char data which is converted to a String, all data should be stored as uints (eg: uint8_t, uint16_t, uint32_t). The size of each data byte used for data transfer should be specified in the flags byte, specifically the last 4. These can be manipulated as pointers to arrays within code, as the length of a LoRa packet is known to be 256 bytes or less. Therefore, buffer variables can be created with the max length known (Eg uint8_t buffer8[256], unit16_t buffer16_t[128], etc).

@Trent3211 Trent3211 added the bug Something isn't working label Nov 22, 2022
@Trent3211 Trent3211 added this to the Pappus Library milestone Nov 22, 2022
@Trent3211
Copy link
Collaborator Author

Trent3211 commented Nov 22, 2022

This is a bug because the data, as its currently sent, because its automatically formatted to a String before sending and after receiving, if one of the header bytes is a 0 then the code interprets that as an end of string byte, or the NUL terminator. Thus, sending the data instead as a uint8_t array will avoid this issue. This may be acheivable by sending using the LoRa.write() operation (source code and header for LoRa library)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant