Go Down

Topic: Storing things in a hex string (Read 298 times) previous topic - next topic

jremington

#15
Aug 27, 2019, 10:10 pm Last Edit: Aug 27, 2019, 10:10 pm by jremington
Quote
unfortunately I'm working with a library that only accepts a hex array
It is very likely that you misunderstand how this library works, because that statement makes no sense.

All data are binary.

supersecretsecretforgot

I asked for some help in working with a closed-off library that's under NDA, and I got:
It is very likely that you misunderstand how this library works, because that statement makes no sense.
Then I suggest you pay someone to fix your problem after signing an NDA.
Which is not helpful to the current problem. Due to NDAs and such I can't push back against these statements, which is uncomfortable.

For anyone who's interested, I've temporarily solved the issue by putting the characters one by one in a hex array, and padded them with zeroes to conform to the fixed width fields, like so:
Code: [Select]
185415561500087756
Which corresponds to a message type of 1, a temperature of 8.541 degrees, a humidity of 5.615, and a light level of 87756 Lux. I'm not using the full resolution possible with hex values, and I'm looking into structs to see if I can do that at a later moment, but at least this works, and has the benefit of the resulting string (which appears on the other side of the system) being human-readable.

Anyway, thanks for your help.

ardly

Maybe it would help to use concrete examples.
Let's say your temperature can go from 0.0 - 25.5 degrees, and you only need it accurate to one decimal place.
You could multiply the temperature by 10 which would give you an integer in the range 0-255.
This range could be stored in an unsigned byte.
 
So if the actual reading is 19.3 degrees you could store it in a byte with the value 193 (base 10).
You now have a couple of choices on how to send the reading as a hex string.
You could send it as two ASCII characters C1 or three ASCII characters 193, the receiving end needs to which you are going to be doing and that the reading has been multiplied by 10, it can then reconstruct the floating point number 19.3. Because the temperature reading will always take the same number of characters to transmit you don't need a separator between it and the next reading.
A structure will contain several variables of different types for your readings but the length of each type is fixed so it is not much different to sending a single byte. You do though need to consider what would be an appropriate type for each variable given the range of the reading.
"Facts do not cease to exist because they are ignored" - Aldous Huxley

gfvalvo

For anyone who's interested, I've temporarily solved the issue by putting the characters one by one in a hex array...
Again, there's no such thing as a "hex array".
No technical questions via PM. They will be ignored. Post your questions in the forum so that all may learn.

supersecretsecretforgot

Again, there's no such thing as a "hex array".
I'm storing values in an a variable which is defined like this:
Code: [Select]
uint8_t payload[payloadLength]
Yes, this is an array of unsigned 8-bit integers. I'm not exactly treating it as an array of integers, but I'll call it whatever you want as long as it means the discussion you seem to be fond of having gets bypassed.

You could send it as two ASCII characters C1 or three ASCII characters 193, the receiving end needs to which you are going to be doing and that the reading has been multiplied by 10, it can then reconstruct the floating point number 19.3. Because the temperature reading will always take the same number of characters to transmit you don't need a separator between it and the next reading.
Sending three ascii characters was the previous implementation, now I'm sending two and having the other end reconstruct the original measurement. I've only suggested the use separators initially, and have since realized these are not needed.

A structure will contain several variables of different types for your readings but the length of each type is fixed so it is not much different to sending a single byte.
I'm reading up on the struct and how it works, and it seems like a good candidate for the next implementation, as the code would be quite a bit more concise and elegant.

ardly

I'm storing values in an a variable which is defined like this:
Code: [Select]
uint8_t payload[payloadLength]
Yes, this is an array of unsigned 8-bit integers. ...
Take things a step further. You don't need to explicitly store things in your unsigned bytes. Declare a pointer to uint8_t and then point the pointer at the variable that contains your reading or the structure that contains several readings of different types.
"Facts do not cease to exist because they are ignored" - Aldous Huxley

ardly

Here is some code that might make things clearer;
Code: [Select]
#include <iostream>

using namespace std;

int main()
{
    uint8_t* from;
    uint8_t* to;
    float fromTemp1=25.9;
    float toTemp2=0;
    int len;

   printf("Start fromTemp1=%f toTemp2=%f\n",fromTemp1,toTemp2);
   len=sizeof(float);
   from=(uint8_t*)&fromTemp1;
   to=(uint8_t*)&toTemp2;
   
   for(int i=0;i<len;++i)
   {
        printf("%X\n",*from);// transmit the byte in hex to the receiver
        *to=*from;// receive and store it
        ++from;
        ++to;
    }
   printf("End   fromTemp1=%f toTemp2=%f\n",fromTemp1,toTemp2);
   return 0;
}

Output;

$g++ -o main *.cpp
$main
Start fromTemp1=25.900000 toTemp2=0.000000
33
33
CF
41
End fromTemp1=25.900000 toTemp2=25.900000

One thing to be aware of is that if you are sending data like this the sending and the receiving end need to be storing variables in the same way e.g. same byte order.
"Facts do not cease to exist because they are ignored" - Aldous Huxley

jremington

#22
Aug 28, 2019, 04:37 pm Last Edit: Aug 28, 2019, 04:38 pm by jremington
Quote
Which is not helpful to the current problem. Due to NDAs and such I can't push back against these statements, which is uncomfortable.
This is a forum for open source software and products.

Go away.

Go Up