- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
10-12-2017 05:29 AM
I have discovered a critical bug with the EFR32 Radio or Radio Configurator. Changing the Manchester symbol code mapping from default to inverted breaks the radio receive frame detection.
I have a simple test project with fixed frame length, manchester coding and no crc checking. The frame detection should not be affected by the Manchester code mapping since the symbol coding only applies to the frame content. But nonetheless, the reception does not work when the mapping is changed to inverted.
I have the low level radio frame detection signal routed via PRS to a output pin and I am checking if the radio even gets the frame detection. This is the case when the mapping is on default but not the case if it is changed to inverted.
I tried to invert the sync word, thinking the mapping would be falsely also be applied to the uncoded sync word but this did not work.
The transmit operation does response as expected to the Manchester code mapping setting. I have checked the on-air data with a real time signal analyzer and see that only the payload is affected by the setting but not the preamble or sync word.
So in summary: The Manchester code mapping does work with the transmit operation but breaks the reception of data once the setting is set to "inverted".
I had previously experienced problems with the Manchester Code mapping in February and had worked around it until now. My post from then: "EFR32 Radio Configuration Missing Machester Code Mapping".
Is my current problem also a already known issue of the RAIL library?
Is there a thing I'm doing wrong or can someone confirm the problem?
Thanks and best regards
10-16-2017 08:01 AM
Did you removed the workaround (i.e. inverted preamble and sync word)?
The inverted manchester currently inverts the symbol mapping, preamble and sync word(s)
10-16-2017 09:16 AM
I removed my workaround of inverting the payload.
The inverted preamble and sync word were just to try if i could get reception with the manchester code inversion option working.
Like you said, I noticed in the radio configurator output that it changes the fsk mapping and inverts the preamble and sync word patterns. I now suspect that the fsk mapping in rx mode is at fault. I have a working system with transmitter and receiver. With both at default fsk mapping MAP0 everything works. If I only change the fsk mapping on both of the devices to MAP1 the receiver fails to detect the signal. I have a third party device to verify that the transmitter works as expected with fsk MAP1 but the receiver is not able to receive any signal when configured to the alternate mapping.
A bit of background: I have my system currently working with the standard manchester code mapping but inverting the data before transmitting and after reception with my third party device. I nonetheless want the native manchester code inversion working, because I currently can not use the RAIL hardware CRC because of the inverted data.
10-16-2017 09:41 AM - edited 10-16-2017 09:43 AM
You should set up MAP0, and sync/preamble/payload without inversion. and inverse manchester.
The generated array should look exactly the same if you would set up MAP1, sync/preamble inverted and normal manchester, but due to a bug with this setup, you will probably have 1-2 bit difference.
If that doesn't work, maybe you can send me the configs with a note what is and what isn't working with it, and describe the packet itself.
10-17-2017 05:09 AM
I did some further testing and found a possible cause for my problems with the manchester code inversion.
I started with a default radio PHY profile (868M 2GFSK 38.4Kbps 20K) for the BRD4250B Board.
Then I modified the profile by increasing the Syncword length to 32bit and choosing a good pattern, disabling the CRC and enabling Manchester Symbol coding.
This configuration worked with default AND inverted Manchester coding.
But when I changed the advanced setting "Number of Symbols in Timing Window" to smaller than 2 the configuration broke with inverted Manchester coding.
I require for my application the use of the sync word as my timing window (because my third party transmitter tx preamble is useless to the efr32). I therefore have the "Number of Symbols in Timing Window" setting set to 0. With this setting the receiver only works when I do NOT enable the Manchester code inversion (or FSK mapping inversion since they work on the same basis). See configs and test project in attachments.
It looks to me that the fsk inversion that is used by RAIL to achieve the manchester inversion might break the receiver timing when using very short preamble detection or in my case no preamble detection but timing detection with the sync word.