skyartec compatibility

blackmoon wrote: Received my 2 skyartec modules.

Now that I have them, I think that I bit off more than I could chew.

The pitch of the pads is insane... don't know how I'll solder them.

Guess we shall see if I can make it work.

Try it out and hopefully it works better than mine...

cmpang wrote: got some XL2500-D03 from the local Chinese market but the radio range is very very short. Upon contacting the seller and to my surprise, the module is different from we have here although it looks exactly the same.

I just got one and it's the same way too. I ground the RXEN though. Have you tried running yours that way? RXEN disabled (GND PAEN) and TXEN enabled (VCC RFC). It seem to me that there is no reason to enable the RX and in fact that may affect how it performs (or the RX may burn from the TX).

I need some help from the gurus here. I'm building a Skyartec TX module for my 9x. I ported the Deviation code over to an avr that I'm putting in the module (very little code changes, it's pretty much the exact same code).

The problem I have is the module works fine when I use a normal standalone atmega328p but when I try to use an Arduino Pro Mini board the SPI communication does not work correctly. I have gone over the connections 100 times and I can use SPI to program the Pro Mini using the exact same connections but it will not talk SPI to the CC2500 module for some reason.

I have a debug output in my code that prints out the partnum and vernum from the CC2500 registers. On the standalone atmega it prints 128 and 3 respectively and binding to a Skyartec RX works fine. On the Pro Mini it prints 15 and 15 and does not bind. Something is screwy with the Pro Mini's SPI when talking to the CC2500. Anyone know what could be going on here?

Can the SPI lines benefit from pull-up/down's? I don't believe I have seen that before but I don't know. I don't believe you guys with Devo's are doing that, are you?

cmpang wrote: Having installed the Skyartec XL2500-D03 module for over a week and while flying with my nanoCP get lost link every now and then..

checking with my spectrum analyser found the output power is consistently down by about 10db as compared with either the Devo or V911 protocol... what's more, the output power seemed not changed by setting from the lowest 100uW to the highest 150mW on my D10

performed a field check today and the range is only a mere 80m.. and the result doesn't change by whatever power setting on my Tx.. ( I started with the lowest 100uW, go out to the point where signal is lost, then asked my buddy to raise the power setting and to the highest but still get no signal)

Go home and perform a most basic test...

I posted the same findings in a Chinese forum and GALEE (working on a variant of Deviation on 7e) was able to track it and confirmed that there is a bug in the coding that doesn't enable the power handling routine..
GALEE has released a fix last night and I can confirm both the power output has raised by more than 10dB now and on par with the Devo and A7105 protocol. Power setting also works now..
He will post his code here later..

tx wrote:

cmpang wrote: got some XL2500-D03 from the local Chinese market but the radio range is very very short. Upon contacting the seller and to my surprise, the module is different from we have here although it looks exactly the same.

I just got one and it's the same way too. I ground the RXEN though. Have you tried running yours that way? RXEN disabled (GND PAEN) and TXEN enabled (VCC RFC). It seem to me that there is no reason to enable the RX and in fact that may affect how it performs (or the RX may burn from the TX).

no apparant effect either enabling RXEN or not..

cmpang wrote: no apparant effect either enabling RXEN or not..

Yeah, the documentation on this stuff isn't great and it's impossible to see the circuit under the shield (well, without taking it apart ).

But I assume the problem of short range will be solved with the code fixes. I'm curious to see what those changes are myself.

tx wrote: I need some help from the gurus here.

Well you guys are no help.

I think I figured out the issue(s) with my module. I believe there are a few bugs in the Deviation code with regards to how it accesses the CC2500. I want to do some more testing and research to make sure it's working 100% but I will post what I find.

It's amazing that even code I have found around of "working" CC2500 systems is not correct either. Trudging through the datasheet has been the only way I could get my module working.

tx wrote:

tx wrote: I need some help from the gurus here.

Well you guys are no help.

I think I figured out the issue(s) with my module. I believe there are a few bugs in the Deviation code with regards to how it accesses the CC2500. I want to do some more testing and research to make sure it's working 100% but I will post what I find.

It's amazing that even code I have found around of "working" CC2500 systems is not correct either. Trudging through the datasheet has been the only way I could get my module working.

Should you work on the 7e/D10 version then I am happy to do some testing

tx wrote: It's amazing that even code I have found around of "working" CC2500 systems is not correct either. Trudging through the datasheet has been the only way I could get my module working.

Hi tx, with the CC2500 module being the last one that was integrated, I think most testing to date focused on positive test cases, i.e. is it working (YES/NO) and not how good its working nor any negative test cases.

I would love like get into the testing, but both my Skyartech and aliexpress CC2500 modules are (after 5 weeks) still enroute. (real soon now, I hope )

If you could upload the documentation you have and give us a few pointers on the issues you found, we can have a few more eyes looking at the code in the mean time.

tx wrote:

tx wrote: I need some help from the gurus here.

Well you guys are no help.

I think I figured out the issue(s) with my module. I believe there are a few bugs in the Deviation code with regards to how it accesses the CC2500. I want to do some more testing and research to make sure it's working 100% but I will post what I find.

It's amazing that even code I have found around of "working" CC2500 systems is not correct either. Trudging through the datasheet has been the only way I could get my module working.

If you need help with testing the Aliexpress CC2500 (the one with the u.fl connector), I have it in my Devo 10.

I think the primary issue I had was related to using SPI mode 1 instead of the proper mode 0. I'm not sure why I thought I needed mode 1, it might not have been from the Deviation code. The CC2500 datasheet clearly shows mode 0 though.

The datasheet says to wait for MISO to go low after setting CS_LO and the current Deviation code does not do that AFAIK (unless it's a hidden feature of the ARM SPI stuff). It probably works OK like it is because the CC2500 is never in sleep mode but it's not really following the specs. On my AVR port I added this check for MISO low to all the CC2500_* functions after CS_LO().

The current CC2500 reset function doesn't really follow what the datasheet says to do for reset. Although again it probably works like it is. I changed mine to follow the recommended method (this is Arduino style code, but you get the idea ):

I eagerly await any changes for the power increase. I tested my module out to about 150 meters before I lost signal.

Looking at the Skyartec CC2500 initialization it looks like it doesn't increase the power at all from the default of -12 dBm (which is then fed in to the amplifier I assume).

The FrSky module loads 0xFF in to PATABLE which is maximum power +1 dBm. Is that all that needs to be done?

Excellent, that is just setting PATABLE like I thought. I have already been using that on my 9x Skyartec module and it works fine.

I should note the sunvsuv code has at least one bug (default -12dBm power is 0xC6 not 0xC5).

tx wrote: Excellent, that is just setting PATABLE like I thought. I have already been using that on my 9x Skyartec module and it works fine.

I should note the sunvsuv code has at least one bug (default -12dBm power is 0xC6 not 0xC5).

I have alredy tested suv's release days before and it is almost the same power output as Gale's version..

so what how much different of OxC5 instead of 0xC6?

cmPang

cmpang wrote: I have alredy tested suv's release days before and it is almost the same power output as Gale's version..

so what how much different of OxC5 instead of 0xC6?

No difference at all because it only affects the lowest power setting. Even then I'm not sure what will happen, probably the chip will reject the change and keep the default which means it might work like it's suppose to anyway.

If you have it set to use anything higher than the lowest power then no problem.

tx wrote:

cmpang wrote: I have alredy tested suv's release days before and it is almost the same power output as Gale's version..

so what how much different of OxC5 instead of 0xC6?

No difference at all because it only affects the lowest power setting. Even then I'm not sure what will happen, probably the chip will reject the change and keep the default which means it might work like it's suppose to anyway.

If you have it set to use anything higher than the lowest power then no problem.

my basic spectrum analyser is not able to differienate the lowest power anyway..but suv's work and give basically the same output on par with Devo and A7105 modules.. and of course, the supply current increases with increased power setting...
strange that it seems aside from you, no one seems to care ...

PhracturedBlue wrote: The CC250 is an incredibly frustrating chip to work with, so I've taken a break from it. Implementing proper power control is not difficult (as suvsuv has shown). I will get it implemented sooner or later, but honestly it isn't that high on my priority list. The current power output is the same as the Skyartec transmitter, which should give satisfactory output for most uses. When I get back to it, it will likely be to give frsky another try.

yes it is good sometimes to get yourselves a break rather than get buried in a particular task in programming... and priority management as well ..

thanks for your hard work and I am sure everybody here appreciate your work in the project..

cmPang