TLDR
The RockBLOCK sends and receives raw data bytes. It's up to your applications, both on the send and receive end, to encode and decode those as you see fit.
Text vs. Binary
The RockBLOCK essentially just sends and receives 1s and 0s. It really does not care what those are or what they mean. It sends these in groups of 8, which is what a byte is. You can send up to 340 bytes in one satellite transmission.
When we ran the Hello World example, we were able to use a simple text style entry:
AT+SBDWT=Hello World
This is generally fine since there is a known single byte representation for each character. But what if you wanted to send a value? Like the temperature from a sensor which is reading 23.6245198. Should you do something like this?
AT+SBDWT=Temperature is 23.6245198
You could, and it would work, but there are a couple of issues with this.
For one, sending the text "Temperature is" is unnecessary. You will most likely know the format of whatever data you are dealing with. So then this?
AT+SBDWT=23.6245198
That would also work, but sending the value as text is costly in terms of the number of bytes used in the transmission. Each character will consume a byte, so 10 bytes total. It's much better to send the value as an actual byte representation. There are different size bytes representations that can be used for values, but for example, a typical floating point value can be stored in 4 bytes (for single precision). So you could send that same temperature value for less than half the number of bytes it would take to send it as text.
Great, but how do you actually do this? It will depend on what programming language you are using. We'll discuss this a little further using Python.
Packing Data in Python
The process of turning values into raw data bytes is generally referred to as packing. The reverse process, turning the raw data bytes back into values, is referred to as unpacking. The Python module struct provides what is needed.
Let's look at a simple example. Our goal is to send the value of 23.6245198 with the RockBLOCK modem, through the Iridium satellites, to some other place on Earth. We want to do this as efficiently as possible since we burn credits on a per byte basis.
First, let's create our value
:
$ python3 Python 3.6.9 (default, Nov 7 2019, 10:44:02) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> value = 23.6245198
If we wanted to send that as text
, we would do something like:
>>> text = "{}".format(value).encode() >>> text b'23.6245198' >>> len(text) 10
Note that the text is generally readable. Also note that is takes 10 bytes.
OK, now let's use struct
to create a raw byte data
representation:
>>> import struct >>> data = struct.pack("f", value) >>> data b'\x04\xff\xbcA' >>> len(data) 4
The contents are no longer human readable. But it only requires 4 bytes.
To prove that the value is still there, we can unpack
it:
>>> struct.unpack("f", data) (23.62451934814453,)
That's what someone would do on the receiving end, after the 4 bytes went through the satellite system.
The key thing to note here is that it would take 10 bytes to send the text representation of the value vs. 4 bytes for the raw byte representation.
Integer vs Float
Note how in the previous example when we unpacked the value we got extra digits and it wasn't exactly the same value we started with. This is due to the general issue of floating point precision. There's no 100% cure for this. About the only thing that can be done is to throw more bytes at the issue. For example, using double precision, which takes 8 bytes, we get better results:
>>> value = 23.6245198 >>> data = struct.pack("d", value) >>> len(data) 8 >>> struct.unpack("d", data) (23.6245198,)
Great, but we just doubled the amount of bytes that needs to be sent.
The better solution to this problem is to use integers for everything. But how do you turn floating point numbers into integers without losing data? You generally can't. But that's not necessary.
These values will most likely have started out as integers to begin with. They originated from registers on the sensors where they were stored as a series of 1s and 0s. The datasheet would have all the information about the layout which could then be used to compute the actual values of interest. Doing this work for you is one of the main features of using a sensor library. But, for the sake of efficient satellite data transfer, instead of reading the register, computing the value of the physical property of interest, and then trying to transmit that value - just send the raw register values as integers.
The integer value can store all the 1s and 0s of the registers as they actually are. It is efficient and no information is lost. And turning those values into the engineering units of interest on the receiving end is a trivial task.
Page last edited June 14, 2024
Text editor powered by tinymce.