- Posts: 230
CC2500 Tx Power test - Skyartec & Frsky Protocols
- Indigo
- Topic Author
- Offline
Changing The tx power has no effect on Range when using the Skyartec protocol. Range is always very long even at 100uw.
NOTE: This would also apply to Frsky protocols
As I am unable to test this myself, I have created a test version. If you're able to assist, please try the test version and check range at various low power levels and report back.
Test Builds
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- Indigo
- Topic Author
- Offline
- Posts: 230
The patable must be loaded onto CC2500, then table is then used to ramp up the power level when powered on and ramped down when powered off. The power level is changed by 3 bits within register FREND0.
SkyArtec.patch
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- Indigo
- Topic Author
- Offline
- Posts: 230
In this particular case u8 or u32 makes no difference to firmware size because the input parameter Model.TxPower is u8. From memory there are 5 of these ?_SetPower() functions, the other 4 all use u8 so I chose u8.
- u8 involves no data type conversion.
- u32 involves a data type conversion that will have no cost on little endian.
I changed it because int is signed. Changing int to u8 removes an unnecessary conversion between signed and unsigned types.
uint_least8_t would be better but I've found that using it makes code less readable.
uint_fast8_t is good for iterator variable in loops when iterator is used in arithmetic with u8. eg. protocol code with u8 data arrays. I suggest adding to common.c
typedef uint_fast8_t uf8;
BTW: I converted dsm protocol to u16 and u32 versions but the result in both cases is an increase in firmware size so I haven't used either. I believe the increase comes from the extra bit arithmetic required to calculate the crc.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
The code was written over a significant time frame, and when I started I didn't know much about cortex programming, so early code uses u8/u16 in a lot of places it shouldn't.
Please Log in or Create an account to join the conversation.
- Indigo
- Topic Author
- Offline
- Posts: 230
Or has anyone tried the test version?
Please Log in or Create an account to join the conversation.
- IMback!
- Offline
- Posts: 84
Please Log in or Create an account to join the conversation.
- Indigo
- Topic Author
- Offline
- Posts: 230
This time I set power level first before enabling TX mode. So the order of these 2 commands is now reversed. The order would be important because when you enable TX mode the PA powers up (ramps up) to the pre-set level. Setting that level after powering up would have no effect.
SkyArtec_v2.patch
I hope you or someone can test this new version and report back, thanks.
Test Builds
Please Log in or Create an account to join the conversation.
- IMback!
- Offline
- Posts: 84
I did a quick range check indoors, and I cant see a difference. That is the skyartec reciver dosent loose reception on 100uw long after a cyrf or a7105 reciver dose at 100uw.
Ill try to get a real range check compearing CC2500 @ 150mw to CC2500 @ 100uw in tomorrow
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- Indigo
- Topic Author
- Offline
- Posts: 230
I have spotted the problem and have uploaded new Test Builds .
The lowest TX power table value was being overwritten by another piece of code.
Source code
SkyArtec_v3.patch
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- Indigo
- Topic Author
- Offline
- Posts: 230
Could someone with Skyartec please test this and report back?
See: first post
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
The original code that is in the trunk DOES change the Tx power, is just no one can tell because the range is so much more limited. Is there some other feature of your code that warrants changing the trunk version?
Please Log in or Create an account to join the conversation.
- Indigo
- Topic Author
- Offline
- Posts: 230
Search that document for PA_POWER to read about how PA_TABLE is used to ramp PA_POWER up/down and decide which source you like best.
I was only trying to fix a reported bug . If the bug report is wrong then I'll just update its status.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Offline
- Posts: 4402
It may be worthwhile to actually have a power-range per module, since they do not lal have the same range. That might help users better choose the proper power.
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Protocol Development
- CC2500 Tx Power test - Skyartec & Frsky Protocols