Endianness of 'in the air' data bytes on STM32WLE5 - I asked this question before but did not get a definitive answer. So hoping someone here can answer now. I can get no response from STM online support. HOW DOES ONE GET AN ANSWER FROM STM ??

[JNoci.1]

We are evaluating if we can use the STM32WLE5, to interface to existing devices .A critical factor is the expected endianness of the data. I have seen no reference in the docs if this can be set, so I have provided an example message and would like to know if this can correctly interpreted by the STM.

The following sequence defines the values of bits 'in the air' as recorded on an oscilloscope. The most left bit is the first bit transmitted.

10101010 10101010 10101010 10101010 These are the 4 preamble bytes. Byte value is 0x55 with LSB

of each byte transmitted first

00110011 01010101 00110011 01010101 These are the 4 Sync bytes 0xCC 0xAA 0xCC 0xAA in sequence

of transmission, with LSB of each byte transmitted first

01000000 10000000 00000000 The first byte is the Variable Length : Value is 0x02, LSB

transmitted first. The data bytes are 0x01, 0x00, LSB

transmitted first

01110100 11110110 The CRC is computed on the 3 bytes above. The CRC value is 0x6F2E

The LSByte of the CRC is sent first, LSB of byte first

Can the device be set to receive this bitstream correctly. I am specifically worried as to how the data bits (specifically the message length value) are interpreted by the Receiver - as if this is not interpreted correctly (ie in the opposite order of bits), the receiver will be expecting a msg of length 0x40 instead of 0x02.

If need be, I could manage to do the CRC in software, but the above point is critical.

[TDK]

> HOW DOES ONE GET AN ANSWER FROM STM ??

This is a user forum with only casual ST presence. You can file a support request which may or may not help:

https://www.st.com/content/st_com/en/support/support-home.html

I imagine the information you're looking for is part of the bluetooth protocol and isn't anything within ST's control or ability to change. I imagine it's also more involved than just a simple bit stream. There is very likely a CRC, convolutional coding, or similar to ensure the integrity of data.

[JNoci.1]

Hi TDK.

Thanks for trying to help...

The STM32WLE5 is NOT Bluetooth - it is a basic sub-GHz multi-mode wireless transceiver with an ARM processor. It is deemed for use in many applications, LORA, simple point to point radios, etc.

So, no Bluetooth protocols, etc that is has to conform to, and since it is claimed to be is an open platform supporting LoRa®, (G)FSK, (G)MSK and BPSK modulations, etc, one would assume it should be able to be made top communicate with similar legacy transceivers as well - some of which have different endianness - but trying to get that answer from STM - we have filed and re-filed a support query, got a ticket, etc - but they just never come back with an answer - for some WEEKS now.

[TDK]

Ah, my apologies. I think I've made that mistake before as well.
Looks like you're already trying the available avenues.
Assuming you have a data path established, wouldn't it be easier to send one and retrieve the bit-order on the other end? You've probably thought of that. Good luck.

[Tesla DeLorean]

One typically works with their assigned FAE. Where are you located? What per-annum business are we talking about? Are you the Radio / RF Engineer or the SW/HW Engineer?

Like I said when you asked this the last time, I'm pretty sure it deals with a byte-stream,sent most significant bit first.

https://community.st.com/s/question/0D53W00000SZOkrSAH/endianness-of-in-the-air-data-bytes.

The radio IP is custom (SoC, not stacked-die), but a variant of the SX1262. Semtech would be the domain experts on that, functional detail might be covered by NDA.

Assuming you can't change the bit-shift direction, you might have to use a free-form encoding, and bit reverse the data coming out of the FIFO

[JNoci.1]

We are located in Namibia - so how do I get in contact with the associated FAE? Business per annum is small, but regardless I would still hope to get some support. We do both the SW/HW design.

We have worked with two other RF devices - one from Silicon Labs and the other from Axem. In both cases, the device allows you to explicitly specify the endianness of the data bytes. It thus seems that this then is not an unusual function and I would hope that the Semtech device would have the function as well - just cannot find evidence in any document thereof.

I have thought of using free-form encoding, but it is a very inelegant solution as I would have to somehow be 'polling' the fifo to see when there are sufficient bytes received. The application is critical and I cannot afford that uncertainty.

[JNoci.1]

We are located in Namibia - so how do I get in contact with the associated FAE? Business per annum is small, but regardless I would still hope to get some support. We do both the SW/HW design.
We have worked with two other RF devices - one from Silicon Labs and the other from Axem. In both cases, the device allows you to explicitly specify the endianness of the data bytes. It thus seems that this then is not an unusual function and I would hope that the Semtech device would have the function as well - just cannot find evidence in any document thereof.
I have thought of using free-form encoding, but it is a very inelegant solution as I would have to somehow be 'polling' the fifo to see when there are sufficient bytes received. The application is critical and I cannot afford that uncertainty.