CC2500 Tx Power test - Skyartec & Frsky Protocols

More
09 Mar 2015 09:59 #29483 by Indigo
I have attempted to fix the following issue:

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.

More
09 Mar 2015 12:48 #29491 by PhracturedBlue
Replied by PhracturedBlue on topic CC2500 Tx Power test - Skyartec & Frsky Protocols
Can you make your code /patch available? I'd like to see what the change was.

Please Log in or Create an account to join the conversation.

More
09 Mar 2015 16:05 - 09 Mar 2015 16:07 #29499 by Indigo
The change to patable codes is not important, I just selected lower current draw equivalents.

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
Last edit: 09 Mar 2015 16:07 by Indigo.

Please Log in or Create an account to join the conversation.

More
09 Mar 2015 17:24 #29500 by PhracturedBlue
Replied by PhracturedBlue on topic CC2500 Tx Power test - Skyartec & Frsky Protocols
while this has nothing to do with the cc2500 stuff, do not change ints to u8 for parameter passing in general. It adds extra code and compute for no gain. The natural int size is 32bits, and that should be used everywhere except when storing large arrays or static variables.

Please Log in or Create an account to join the conversation.

More
10 Mar 2015 03:39 #29514 by Indigo
I agree that u8 is over used and u32 is better and often reduces firmware size...

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.

More
10 Mar 2015 04:08 #29518 by PhracturedBlue
Replied by PhracturedBlue on topic CC2500 Tx Power test - Skyartec & Frsky Protocols
I don't want to use such compiler directives if at all possible. Sticking with the normal u8,u16,u32 should be fine almost everywhere. If there is a strong reason to change, using the full type makes it more obvious there is something special going on.

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.

More
23 Mar 2015 13:24 #30106 by Indigo
Back on topic. Did the patch work?

Or has anyone tried the test version?

Please Log in or Create an account to join the conversation.

More
23 Mar 2015 13:46 #30109 by IMback!
yes I have. there ist no difference in range. :(

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 10:12 - 24 Mar 2015 10:46 #30173 by Indigo
Thanks for testing this. I have uploaded new test builds. :woohoo:

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
Last edit: 24 Mar 2015 10:46 by Indigo. Reason: Added hyperlinks

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 10:46 - 24 Mar 2015 10:47 #30174 by IMback!
Thanks for trying to resolve this bug! B)

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
Last edit: 24 Mar 2015 10:47 by IMback!.

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 14:11 #30184 by PhracturedBlue
Replied by PhracturedBlue on topic CC2500 Tx Power test - Skyartec & Frsky Protocols
during my testing of the UniversalTx, I'll use my RFExplorer to take accurate measurements of power output for all modes, and will verify that the table works properly. I expect to complete that work this week.

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 15:59 #30198 by Indigo
Thanks for testing this. :)
I have spotted the problem and have uploaded new Test Builds . :woohoo:

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.

More
25 Mar 2015 03:06 #30221 by PhracturedBlue
Replied by PhracturedBlue on topic CC2500 Tx Power test - Skyartec & Frsky Protocols
I checked the output power with my RFExplorer, and there isn't much difference between your method and mine. I see about a 10dBm spread between max and min power with both methods.

Please Log in or Create an account to join the conversation.

More
28 Mar 2015 09:44 #30354 by Indigo
Oh good, my version is now working. :)

Could someone with Skyartec please test this and report back?

See: first post

Please Log in or Create an account to join the conversation.

More
28 Mar 2015 12:39 #30359 by PhracturedBlue
Replied by PhracturedBlue on topic CC2500 Tx Power test - Skyartec & Frsky Protocols
I have a skyartec, and I can test it. But the maximum span of the CC2500 in current configuration is only 10dBm, as opposed to the CYRF which has a span of about 30dBm. That means that '150uW' on the CC2500 is actually 10mW.. So you won't notice the range difference except at extreme distances.
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.

More
28 Mar 2015 13:38 #30365 by Indigo
Mine is implemented according to CC2500 datasheet .

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.

More
28 Mar 2015 14:17 #30366 by PhracturedBlue
Replied by PhracturedBlue on topic CC2500 Tx Power test - Skyartec & Frsky Protocols
Your solution does add an additional ~1.5dBm in range (atthe low end), so it is better I think, but that may just be the tweak you did to the table. I'll let others try it, but my expectation is that the bug is actually invalid.

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.

Time to create page: 0.078 seconds
Powered by Kunena Forum