Open alexbrickwedde opened 2 weeks ago
Hi Alex, yes thats a known weakness, when dealing with AT-based protocols. A good workaround is to encode the data in base64. That is usually done in such situations and solves the issue. We will check, if there is another way.
Thank you for the feedback! BR Matthias
Hey Alex,
In the latest release of the driver v2.1.0 (1af314916da30fb683d34f4de8e956db2204fd51), the functions to do base64 encoding/decoding have been added to the driver in the following path WCON_SDK/WCON_Drivers/utils
This can be used to overcome the limitation of AT-based protocols.
Best Regards Wajdi
Hey Alex,
In the latest release of the driver v2.1.0 (1af3149), the functions to do base64 encoding/decoding have been added to the driver in the following path WCON_SDK/WCON_Drivers/utils
This can be used to overcome the limitation of AT-based protocols.
Best Regards Wajdi
The "Base64_Decode" does not work as expected, since it adds a 0 character. It returns binary data, which doesn't need a termination. I already patched it to my needs (correct length).
Best Regards
...Alex
PS: I experience issues with decoding an encoded string in Java. I think issues with the length calculation in Calypso_GetBase64EncBufSize. I patched mine to return (((4 * inputLength / 3) + 3) & ~3) + 1;
can you please provide me with the payload that you are trying to encode and the java code that is used to decode please?
can you please provide me with the payload that you are trying to encode and the java code that is used to decode please?
Try it with any 64 bytes of data. Length calculation returns 88, but including the termination character it should be 89.
can you please provide me with the payload that you are trying to encode and the java code that is used to decode please?
Try it with any 64 bytes of data. Length calculation returns 88, but including the termination character it should be 89.
i just tested it on my end and it is returning 89 (4 * ((64 + 2) /3)) + 1 = 89
also the function is called Base64_GetEncBufSize not Calypso_GetBase64EncBufSize but i guess you are still using the older driver, since this function can be shared between different modules it was decided to put it in the utils folder
can you please check again
Hey Alex, In the latest release of the driver v2.1.0 (1af3149), the functions to do base64 encoding/decoding have been added to the driver in the following path WCON_SDK/WCON_Drivers/utils This can be used to overcome the limitation of AT-based protocols. Best Regards Wajdi
The "Base64_Decode" does not work as expected, since it adds a 0 character. It returns binary data, which doesn't need a termination. I already patched it to my needs (correct length).
Best Regards
...Alex
regarding this issue i will take a look at it but i agree that the decoded buffer size and the returned output length should be without the termination character
also the function is called Base64_GetEncBufSize not Calypso_GetBase64EncBufSize but i guess you are still using the older driver, since this function can be shared between different modules it was decided to put it in the utils folder
I used the old one, sorry.
also the function is called Base64_GetEncBufSize not Calypso_GetBase64EncBufSize but i guess you are still using the older driver, since this function can be shared between different modules it was decided to put it in the utils folder
I used the old one, sorry.
no worries, either way internally they are similar in terms of functionality so if you can check the calculation again it would be great
Hi,
Due to "receivedByte == StephanoI_eolChar1" in StephanoI.c binary data in an StephanoI_ATEvent_BLE_Write event gets corrupted, as soon as eolChar1 is found.
Regards
...Alex