This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software:
i have some more information/questions about a previous post....
here's an example in which i successfully receive a small BLE packet from my "working" code, using SmartRF Studio:
and here's what i receive from an alternative version of the code:
i understand that the LAST byte seen here is the RSSI value.... what is the meaning of the PRIOR byte, which is 0 in the working version and 4 in the alternate version???
also, i'm not sure why SOME of the packets are slightly corrupted.... and even when the packet data looks "correct", the receiver reports an error... why???
here's a capture in which i further reduced the packet size:
as you can see, all of the packets transmit the "same" bytes.... what i don't understand is why SOME are successfully received while others are not???
clearly my alternative code version is "missing" something from my working baseline.... and apparently shortening the packet by 2 bytes from my earlier capture seemed to help...
what might cause the degradation after the few bytes are transmitted???
Hello bob
CRC error means something not expected was received with the packet, could you detail to me the particular settings you used when setting up the PHY? What baseline SDK example did you start from, SDK version, and rf configs (rcl_settings.c/.h) used.
An example that is somewhat similar to what you describe is the base rfPacketRx/Tx from the SDK which are configured as 1 mbps BLE proprf PHY.
Thanks,
Alex F
i found my issue -- i had not enabled HFXT tracking.... everything is working fine now.... i'll publish some power benchmarks down the road, which should show at least a 50% reduction in energy consumption versus your legacy BLE stack....