You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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)
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).
The text was updated successfully, but these errors were encountered: