LT8900 support

Hi Goebish,

I've seen you are going to look at the the LT8900 following a post you made earlier. I thought it was easier to open a new topic to talk about it.

This is a preliminary work only just started today.

I have a Shenqiwei 1/20 Mini Motorcycle which is using a LT8900 or LT8910. I don't know exactly since there are no markings on the RF chip (RX or TX) but from the SPI dump it's definitively a LT8900 (the new registers of the LT8910 are not used/configured).

The good news is that I've been able to read with a NRF24L01 the "air" frames.
I'm lucky since scramble is turned off and raw data is transmitted. So I've been able to guess what to expect and configure properly the NRF RX address to receive the full frames.

Air frame description:
- Preamble based on multiple 0x55 being sent, the number of bytes is configurable.
- An address configurable from 16 to 64 bits.
- Trailling bits which are alterning between 0/1 (like the preamble), the number of trailling bits is configurable.
- Payload where the 1st byte can be set as the number of bytes in the payload
- 16 bits CRC which I haven't looked at yet with an initialization value given by config
It has to be noted that bits order are reversed and bytes order in big endian,

Example of a frame 4bytes preamble, 32bits address, 8 trailling bits:
NRF configured with 5 bytes RX addr: "\x59\x59\x55\x55\x55"
Frame received by NRF: 0x59 0x59 0x55 0xC0 0x00 0x78 0xAF 0x0C 0x0C
Reconstructed frame sent by the LT8900:
- Preamble: 0xAA 0xAA 0xAA 0xAA
- 32bits address: 0x9A 0x9A 0x9A 0x9A
- trailling: 0xAA
- 1st byte of payload is number of bytes in payload: 0x03
- 3 bytes payload: 0x00, 0x1E, 0xF5
- 16bits CRC: 0x3030 (with a CRC init set to 0xAA)

Once the CRC is reversed, I should be able to send frames.

Pascal

CRC is done on the full pyload including the 1st byte which gives the payload length.
0x03, 0x00, 0x1E, 0xF5 gives a CRC of 0x3030 with a polynomial of 0x1021, initial value 0xAA, input reflected and result reflected.
So in fact the CRC is calculated with the bit reversed and written bit reversed.

Another frame:
NRF configured with 5 bytes RX addr: "\x59\x59\x55\x55\x55"
Frame received by NRF: 0xAF 0x78 0xAA 0xC0 0x00 0x6C 0x99 0x95 0x2E
Reconstructed frame sent by the LT8900:
- Preamble: 0xAA 0xAA 0xAA 0xAA
- 32bits address: 0x1E 0xF5 0x9A 0x9A
- trailling: 0x55 (note trailling is different from previous frame which was 0xAA so there is a relation with previous value surely ending bit being 0 or 1)
- 1st byte of payload is number of bytes in payload: 0x03
- 3 bytes payload: 0x00, 0x36, 0x99
- 16bits CRC: 0x74A9 (with a CRC init set to 0xAA)
So the CRC is calculated on 0x03, 0x00, 0x36, 0x99.
CRC on bit reversed: 0xC0 0x00 0x6C 0x99 with polynomial: 0x1021, initial value: 0xAA, final xor: 0x00 gives 0x952E which is exactly what's the NRF has received

- Pascal

I need to write a parser for the LT8900 SPI to figure out the protocol. Freq hopping does not looks simple at a first look but I've only looked at a limited number since I'm doing it manually right now...

Update: the LT8900 does the same thing than the NRF for the preamble, meaning switching from 0x55 to 0xAA depending of what's being transmitted right after.
I think I know enough now to write a basic LT8900 emulator.
I still need to figure out this protocol freq hopping... But I should be able to send anyway data to complete the binding procedure which is the next thing on my list.

Thanks man keep up the good work, I am impressed !

I'm now able to send full packets to the motorcycle.
Bind is going ok.
I'm able to control speed and steering but ony time to time... The motorcycle looses connection which can be seen on the internal blinking led. I don't know what I'm doing wrong... Still checking...
I haven't been able to find how the hopping table is calculated so I currently have a 60 bytes table.

You mean you wrote another emulator running LT8900 on nRF24L01? That's impressive! I know it's hard

Yes this is exactly it, I'm emulating LT8900 with a NRF24L01.
Like what you did with the XN297 but only for unscrambled mode right now.

Ok job done
Proof of concept of the emulation of a LT8900 using a NRF24L01 is completed. I can drive the Shenqiwei 1/20 Mini Motorcycle with my TX now
Not sure why but I have to send the same packet 2 times in a row (back to back) for it to work flawlessly otherwise the motorcycle is loosing connection... If someone has an idea. It's not due to the channel hopping or timing since they are the same as the original. May be the frequency of the NRF is not 100% aligned with the LT8900 and a retransmit helps.
I haven't written an emulation layer but coded inline for now. I'm planning to do it in the next few days.

- Pascal

Congrats!

I wish LT8910 (in contrast to LT8900) would not have data rates not supported by nRF24L01, but some models use LT8910 and actually use these rates! But may be your work will allow us to use more flexible CC2500 to emulate LT8910!

Thanks victzh.
You are right, the LT8910 supports 1M, 250K, 125K and 62K. The 2 last ones are not supported by the NRF24L01... I haven't looked at the CC2500 datasheet so I can't tell. The NRF looked to me as a good candidate since it's used by most of the latest models.
This motorcycle is the only model I have with a LT8900 (or LT8910 since there is no marking...).
- Pascal

Stupid question but why we can't emulate these lower datarate by duplicating values ?

You could duplicate the bits but the nrf payload is soon going to be too small to store all the data... But worse a try.

LT8900 emulation layer based on a NRF24L01 is completed.
A working implementation for the Shenqiwei 1/20 Mini Motorcycle is available as well. It uses all the functions including the read and write payloads.

You can find all this on DIY-Multiprotocol-TX-Module .
Check "NRF24l01_SPI.ino" for the emulation layer and "SHENQI_nrf24l01.ino" for the new Shenqi protocol.

The emulation layer currently supports:
- variable preamble length (1 to 8 bytes)
- variable address length (2 to 8 bytes)
- variable trailer (4 to 18 bits)
- optional presence of a payload length byte
- optional presence of a 16 bits CRC
- write and read payload

Get it to work with Deviation should be nearly a simple copy/paste.

Let me know if you have questions.

Regards, Pascal

Well done Pascal !

Great!

PMs broken now - they don't send notifications to email.

Great work!

For bringing these emulations into deviation I suggest we extend the work victzh has already done on the xn297 emulation. It should be possible to hide everything (or nearly) under the current NRF* functions with no to little API change. There is one protocol already and another pending that are used on two different devices. It would be nice to have just one new NRF* function to set the target device. The is_xn297 flag in the victzh's xn297 code reflects the idea I'm describing (though I think its intended use is to indicate the device in the tx).