LT8900 support
- planger
- Topic Author
- Offline
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.
- goebish
- Offline
- I Void Warranties
- Posts: 2631
Please Log in or Create an account to join the conversation.
- hexfet
- Offline
- Posts: 1868
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);
}
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.
- bugman72
- Offline
- Posts: 35
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.
- mwm
- Offline
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.
- bugman72
- Offline
- Posts: 35
Please Log in or Create an account to join the conversation.
- planger
- Topic Author
- Offline
Please Log in or Create an account to join the conversation.
- bugman72
- Offline
- Posts: 35
Please Log in or Create an account to join the conversation.
- goebish
- Offline
- I Void Warranties
- Posts: 2631
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.
- victzh
- Offline
- Posts: 1386
hexfet wrote:
It would be better to avoid having code like this in a bunch of protocol files.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.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); }
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);
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.
- hexfet
- Offline
- Posts: 1868
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.
- victzh
- Offline
- Posts: 1386
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
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.
- hexfet
- Offline
- Posts: 1868
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.
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
Please Log in or Create an account to join the conversation.
- victzh
- Offline
- Posts: 1386
Please Log in or Create an account to join the conversation.
- planger
- Topic Author
- Offline
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.
- victzh
- Offline
- Posts: 1386
memcpy(LT8900_addr, address, addr_size);
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);
Please Log in or Create an account to join the conversation.
- planger
- Topic Author
- Offline
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.
- victzh
- Offline
- Posts: 1386
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.
- Home
- Forum
- Development
- Protocol Development
- LT8900 support