LT8900 support

More
26 Feb 2016 22:14 #43720 by planger
Replied by planger on topic LT8900 support
Thanks Guys.

Goebish, since you have a LT8900 rf module may be you can build on what I've done and add the scramble mode. That would be great.
On my side I don't have a module so I can't continue to implement such functions and I don't really want to break my moto tx...

Hexfet, I've followed (or I think) victzh's implementation. There are really different ways to program the RF chips and I think it's better to have specific functions called with their names. You can always only use the low level NRF functions which I did at the beginning and code from there. But for easier future development, I've implemented everything that would make your life easier to go from SPI dumps to protocol. Configure the LT8900 the same way, use the same type of address (2 to 8 bytes), change channel, switch TX<->RX,...

- Pascal

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

More
26 Feb 2016 23:09 #43723 by goebish
Replied by goebish on topic LT8900 support
No problem, I'll have a look at that.

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

More
27 Feb 2016 03:44 #43746 by hexfet
Replied by hexfet on topic LT8900 support

planger wrote: Hexfet, I've followed (or I think) victzh's implementation. There are really different ways to program the RF chips and I think it's better to have specific functions called with their names. You can always only use the low level NRF functions which I did at the beginning and code from there. But for easier future development, I've implemented everything that would make your life easier to go from SPI dumps to protocol. Configure the LT8900 the same way, use the same type of address (2 to 8 bytes), change channel, switch TX<->RX,...

- Pascal


It would be better to avoid having code like this in a bunch of protocol files.
    if (Model.proto_opts[PROTOOPTS_FORMAT] == FORMAT_HONTAI) {
        XN297_Configure(BV(NRF24L01_00_EN_CRC) | BV(NRF24L01_00_CRCO) | BV(NRF24L01_00_PWR_UP));
    } else {
        NRF24L01_SetTxRxMode(TX_EN);
    }
Four of those if statements in the Hontai protocol could be replaced by one that sets the chip type, then each of the rest by one statement that works for all emulated devices.

But if the vendors don't use the same protocols with different radios very often then it won't matter much. I'd still approve a pull request that added a new protocol using chip-specific nRF compatibility functions. :)

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

More
08 Mar 2016 21:32 #44283 by bugman72
Replied by bugman72 on topic LT8900 support
I had started a thread about this and Goebish has briefly replied to my post, but I currently have a Dromida Verso that uses the LT8910 chip. I have a total of three radios now, of which I would gladly donate and ship one of them to someone in hopes of developing a working protocol for it. As Victzh mentioned, I'm not sure if this would be compatible with the NRF for emulation.

I have no background knowledge on how to do what you all are doing for extraction of the data. I figured that this is the least I can do to contribute.

If someone would like the TX, message Mr and I'll ship it out to you. Might even be willing to send the second one out to someone else. That way there could be two different people working on it.

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

More
09 Mar 2016 14:52 #44327 by mwm
Replied by mwm on topic LT8900 support
I can do the SPI capture for you, but that requires a receiver as well as a transmitter, so unless you can donate both, it doesn't do much good. There's a tutorial here and a video on youtube - both by SebyDocky - on how to do SPI capture.

Do not ask me questions via PM. Ask in the forums, where I'll answer if I can.

My remotely piloted vehicle ("drone") is a yacht.

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

More
16 Mar 2016 13:01 #44643 by bugman72
Replied by bugman72 on topic LT8900 support
I could possibly send the quad along with the TX, but would ideally want the quad back, as I intend to use it for parts. I would be interested in capturing the SPI as well, but can't find anyone who has the USB Logic Analyzer in stock. Anyone know where I can get one?

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

More
16 Mar 2016 13:32 #44647 by planger
Replied by planger on topic LT8900 support

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

More
16 Mar 2016 13:40 #44648 by bugman72
Replied by bugman72 on topic LT8900 support
Wish I could. Excluded shipping destinations include North America.

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

More
16 Mar 2016 14:10 #44649 by goebish
Replied by goebish on topic LT8900 support
Just go to ebay.com then search for "8ch analyzer".

Looks like they can be used with sigrok now, I'll try to make a tutorial someday so people can stop "stealing" the software from Saleae ;)

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

More
16 Mar 2016 18:32 #44657 by victzh
Replied by victzh on topic LT8900 support

hexfet wrote:
It would be better to avoid having code like this in a bunch of protocol files.

    if (Model.proto_opts[PROTOOPTS_FORMAT] == FORMAT_HONTAI) {
        XN297_Configure(BV(NRF24L01_00_EN_CRC) | BV(NRF24L01_00_CRCO) | BV(NRF24L01_00_PWR_UP));
    } else {
        NRF24L01_SetTxRxMode(TX_EN);
    }
Four of those if statements in the Hontai protocol could be replaced by one that sets the chip type, then each of the rest by one statement that works for all emulated devices.


Theoretically you're right, it would be better to write something like:
  Radio_SetChip(XN297);
  Radio_SetAddress(addr, size);
  Radio_SetDataRate(RADIO_DATARATE_1M);
  Radio_SetCRC(2, 0x1021, 0xAA, 0x00, RADIO_CRC_SRC_INVERSE, RADIO_CRC_NORMAL);
For this we need more high level and very detailed implementation of radio subsystem, it should cover many initialization strings as APIs, and probably will not fit into Devo 7E. For instance, to cover CC2500 properly it should have a lot of APIs not supported by any other chips - channel spacing, frequency deviation, intermediate frequency, filter bandwidth, oscillator frequency, CC2400 compatibility modes etc. So for now some part of really low level code is put into protocols, but considering all the circumstances I think it's OK.

Also, if someone wants to import Pascal's code to Deviation, PLEASE preface it with LT8900, not LT8910. LT8910 has incompatible data rates and may be can be emulated with CC2500, so to distinguish between the two, name it LT8900.

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

More
16 Mar 2016 18:56 #44660 by hexfet
Replied by hexfet on topic LT8900 support
You're going a step past the goal I'd like to reach :) I'm just proposing a NRF24L01_SetChip() function. For this we need only an extension of the current is_xn297 tests. (I realize that flag was probably intended to set the tx chip, but the same concept works to set the emulation to match the rx device.)

It's helpful if the same protocol is used with more than one NRF compatible rx chip.

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

More
16 Mar 2016 19:01 #44662 by victzh
Replied by victzh on topic LT8900 support
Considering I have vague plans to emulate low data rate modes of LT8910 with CC2500 it is actually a serious problem. You'll need to write for LT8900 in terms of NRF24L01_ functions and for LT8910 - in terms of CC2500_ . Dreadful, isn't it?

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

More
16 Mar 2016 20:09 #44666 by SeByDocKy
Replied by SeByDocKy on topic LT8900 support

victzh wrote: Considering I have vague plans to emulate low data rate modes of LT8910 with CC2500 it is actually a serious problem. You'll need to write for LT8900 in terms of NRF24L01_ functions and for LT8910 - in terms of CC2500_ . Dreadful, isn't it?



Harg :((((( Very bad news :(

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

More
16 Mar 2016 22:26 - 16 Mar 2016 22:27 #44675 by hexfet
Replied by hexfet on topic LT8900 support
I agree that if a protocol is only used with an LT8910 rx then it makes sense to have a full LT8910_* interface (that's calling CC2500_ to do the emulation).

Seems an advantage to separate the protocol from the emulation to simplify writing protocols that are used with more than one rx radio chip. The protocol is written once using the existing NRF functions, with one new initial function call to set the chip to XN297, LT8900, or NRF depending on protocol option for the target aircraft. Since there's only two examples so far (one still unimplemented) of the same protocol being used with different rx chips it's probably not worth the effort to implement unless more examples start coming.
Last edit: 16 Mar 2016 22:27 by hexfet.

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

More
17 Mar 2016 20:14 #44748 by SeByDocKy
Replied by SeByDocKy on topic LT8900 support
I got some other model with LT8900/LT8910 for example some XinLin models (X181 for example) and many more

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

More
13 Apr 2016 05:23 #46401 by victzh
Replied by victzh on topic LT8900 support
Pascal, started adapting your code for Sky Viper. I have some mysterious observations about it - e.g. the TX configures the chip so that the first byte is length byte, but then sets it to a fixed value which does not correspond to anything. I decided to build receiver first to see what's really coming and it did not work the first time I started it - no packet received at all. Then looking at your examples earlier in the thread and your implementation of SHENQI TX I realized that you were so lucky that your address is 4 same bytes. Mine is not, and guess what - the order in which they're passed is reversed WRT nRF24L01. So I see on the wire address 0xEE, 0xFF, 0xFD, 0x07 - I need to pass it to LT8900_SetAddress as 0x07, 0xFD, 0xFF, 0xEE then it works. I will invert it in my implementation and advise you to do so in your code to confuse the user less.

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

More
13 Apr 2016 10:03 #46406 by planger
Replied by planger on topic LT8900 support
Hi Victzh,
For Shenqi, the protocol is using a boradcast address at the begining with 4 times the same byte but after that the address is composed of 2 bytes from the TX GID and 2 bytes from the RX GID.

I may have chosen the wrong convention to write the address...
In my mind and since the address is of variable length, I found it simple to do 1st byte of the address is going to addr[0], 2nd byte of the address is going to addr[1] and so on. Which in fact writes the address reversly if you want to write this way "\x00\x01\x02\x03" which is 0x03020100...

Let me know which convention was used for others and I'll rewrite this part.

- Pascal

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

More
14 Apr 2016 03:34 - 14 Apr 2016 03:36 #46465 by victzh
Replied by victzh on topic LT8900 support
In a sense it's a convention. This address is passed in up to four 2-byte registers, so it's not that important. In my code I replaced
    memcpy(LT8900_addr, address, addr_size);
with
    for (u8 i = 0; i < addr_size; ++i) LT8900_addr[i] = address[addr_size-i-1];

So my 4 byte address passed as follows:
0.2039  23 WRITE 36_SYNCWORD0 (24) DATA: FD 07 STATUS: 01 81
0.2042  24 WRITE 37_SYNCWORD1 (25) DATA: AA BB STATUS: 01 01 // These two - 37 and 38 - don't count for 4 byte address
0.2045  25 WRITE 38_SYNCWORD2 (26) DATA: CC DD STATUS: 01 01 //
0.2049  26 WRITE 39_SYNCWORD3 (27) DATA: EE FF STATUS: 01 01

and which according to datasheet is EE FF FD 07 would be passed to the code as
    LT8900_SetAddress((uint8_t *)"\xEE\xFF\xFD\x07", 4);
It looks more convenient to me - datasheet to code.
Last edit: 14 Apr 2016 03:36 by victzh. Reason: code tag added

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

More
15 Apr 2016 13:49 #46565 by planger
Replied by planger on topic LT8900 support
Victzh,
I've pushed out a new version with the address bytes written in the "correct" order.
The Shenqi protocol has also been modified accordingly.

- Pascal

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

More
15 Apr 2016 15:04 #46569 by victzh
Replied by victzh on topic LT8900 support
OK.

I faced with couple more problems - one is packet size - 27 bytes - is dangerously close to 32-byte limit of nRF. Add 2 bytes for address, 2 for CRC and one for handling "trailing" bits and you're there. Any longer packets can't be handled, and LT8900 packet limit is 256 bytes :-).

Another one - I probably deal with some variant or clone of LT8900 - it does not obey packet structure completely. Despite of having set length and CRC bits it ignores both. I captured some packets from air with the help of nRF24L01 and they just don't have length and CRC.

These chips are breeding like rabbits.

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

Time to create page: 0.095 seconds
Powered by Kunena Forum