OMP Protocol support. only need cc2500 for tx&rx. telemetry support !

[smaller09]

Telemetry works now, tested on devo10(4in1 module) & devo7e(cc2500) + omp m1. only need cc2500 to work.
this replace #1006

[pascallanger]

Thanks for finding the error which was preventing to receive a big majority of the packets: wrong BW filter value...
I've now implemented the RX method differently in Multi:

• Don't care about the header (C) 71 0F. Note that the "C" is sent if a XN297 is used but not in case of the OMP which has a XN297L.
• Consider the 55 of the XN297(L) header as a CC2500 preamble.
• Configure SYNC1 & SYNC0 & ADDR as the first 3 bytes of the XN297 address -> This way the CC2500 starts to filter packets not sent to our attention.
• Check the other address bytes based on the XN297 address len (3, 4 or 5 bytes) ie 0, 1 or 2 bytes additional check . Note: your implementation does not verify that you are receiving a packet for you...
• Decode as a standard xn297 packet in normal or enhanced mode.
  I'm getting pretty good results on the bench with a tuned frequency.

It's still not perfect since with the nrf without the motor running I get 100% of the packets with a good CRC but with the CC2500 it goes down to around 95%. I can see some bits not being received correctly. Note that the implementation you've taken from me is hidding it since even if the CRC is wrong and the payload is not too damage it will count the packet as good. So may be there is still some value tuning to apply the cc2500 config registers.

Pascal

[pascallanger]

I've just done an experiment by assigning a pot to the channel bandwith:

• 5 and above only one packet is getting in at time...
• 4 most of the packets are getting in but not 100% <- this is the limit where it starts reliabiliy to work but still on the border
• 3 or less is 100%
  So I'll recommend updating the value to 0x3D instead of 0x4D.
  Pascal

[smaller09]

Yes, I did think of using xn297 address as sync word but I warry about other protocol which using cc2500 for xnl297, because I don't have those models to test, so don't want to change code a lot. and I do agree your implementation, it will be very good. As for crc error. I did notified that. In my d7e the LQI would be around 40~70, and as you said it would not decode every packet. but in my test. the LQI may not change a lot with or without motor running. I had made some tweaks to the cc2500 config registers. but got nothing. I dont have any instruments or tools to do futher research, what I have are only a d7e with cc2500 and a arduino nano with nrf24l01 for xn297dump. I guess the problem may cause by the preamble byte. cause cc2500 suggest 4 byte of 0xAA as preamble. BTW, I amd reading the sx1280 datasheet these days. and found it can do gfsk also. and it's highly configurable. I'm thinking maybe we can use sx1280 to take place of a7105/cc2500/nrf24l01 as well as ELRS.

…

________________________________ 发件人: pascallanger ***@***.***> 发送时间: 2021年3月17日 14:28 收件人: DeviationTX/deviation ***@***.***> 抄送: smaller09 ***@***.***>; Author ***@***.***> 主题: Re: [DeviationTX/deviation] OMP Protocol support. only need cc2500 for tx&rx. telemetry support ! (#1007) Thanks for finding the error which was preventing to receive packets: wrong BW filter value... I've now implemented the RX method differently in Multi: * Don't care about the header (C) 71 0F. Note that the "C" is sent if a XN297 is used but not in case of the OMP which has a XN297L. * Consider the 55 of the XN297(L) header as a CC2500 preamble. * Configure SYNC1 & SYNC0 & ADDR as the first 3 bytes of the XN297 address -> This way the CC2500 starts to filter packets not sent to our attention. * Check the other address bytes based on the XN297 address len (3, 4 or 5 bytes) ie 0, 1 or 2 bytes additional check . Note: your implementation does not verify that you are receiving a packet for you... * Decode as a standard xn297 packet in normal or enhanced mode. I'm getting pretty good results on the bench with a tuned frequency. It's still not perfect since with the nrf without the motor running I get 100% of the packets with a good CRC but with the CC2500 it goes down to around 95%. I can see some bits not being received correctly. Note that the implementation you've taken from me is hidding it since even if the CRC is wrong and the payload is not too damage it will count the packet as good. So may be there is still some value tuning to apply the cc2500 config registers. Pascal ― You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#1007 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJ3C3KAU4PCRONI7OSDIXB3TEC4ARANCNFSM4Y3KNRXA>.

[smaller09]

I've just done an experiment by assigning a pot to the channel bandwith:

• 5 and above only one packet is getting in at time...
• 4 most of the packets are getting in but not 100% <- this is the limit where it starts reliabiliy to work but still on the border
• 3 or less is 100%
  So I'll recommend updating the value to 0x3D instead of 0x4D.
  Pascal

3D = 464K BW filter. that means the received signal have a big offset from the center frequency.
but I do remember that I had changed the BW to 541K and had no different. maybe in my situation it must more bigger to see change. I will do some test to confirm.

[pascallanger]

My implementation is available on GitHub if you want to check.
The OMP protocol is now available with telemetry on CC2500 only modules, on NRF24L01 only modules and when both RF components are installed it uses the CC2500.

I forgot in my previous post to add that switching the CC2500 from TX<->RX is only 2 additonnal CC2500 commands to run so not a lot of overhead added.

[pascallanger]

BTW, I amd reading the sx1280 datasheet these days. and found it can do gfsk also. and it's highly configurable.
I'm thinking maybe we can use sx1280 to take place of a7105/cc2500/nrf24l01 as well as ELRS.

I looked at it too. I was thinking it could even do the cyrf but no way...
The cyrf is my main target right now since it is EOL and you can't buy it anymore. I haven't found an easy replacement yet... If you have an idea you rae more than welcome.
Next will be the SX1280, I have a proto to work on so I'll get that going at some point but cyrf first.

[smaller09]

BTW, I amd reading the sx1280 datasheet these days. and found it can do gfsk also. and it's highly configurable.
I'm thinking maybe we can use sx1280 to take place of a7105/cc2500/nrf24l01 as well as ELRS.

I looked at it too. I was thinking it could even do the cyrf but no way...
The cyrf is my main target right now since it is EOL and you can't buy it anymore. I haven't found an easy replacement yet... If you have an idea you rae more than welcome.
Next will be the SX1280, I have a proto to work on so I'll get that going at some point but cyrf first.

I do notified that cyrf was EOL. and also think of take place of it. for GFSK that should be ok by sx1280. but for DSSS it's more difficult. I first found A7157, but no datasheet around the internet, and then em357 or em358x. but don't have detal of the RF module.
if em358x works, I would vote for it, it has cortex-m3 core inside, and lot of gpio, and also a usb interface. we can use it for main controller.

[hazemay]

is this protocol include newest firmware?
or any steps that I need to add into newest firmware?

[smaller09]

is this protocol include newest firmware?
or any steps that I need to add into newest firmware?

it was not included in mainline.
u must clone the source then patch the code and compile it.

[hazemay]

I tried to build my docker desktop, but failed.
Would you please compile a firmware for my DEVO8S?

[smaller09]

I tried to build my docker desktop, but failed.
Would you please compile a firmware for my DEVO8S?

it's because there are too many protocol for DEVO8 to fit into it's memery.
I just commet out xnl297dump and cyrf6936_scaner to make it to be builded.
deviation-devo8-v5.0.0-dddda03.zip
please try and report back.

[hazemay]

I tried to build my docker desktop, but failed.
Would you please compile a firmware for my DEVO8S?

it's because there are too many protocol for DEVO8 to fit into it's memery.
I just commet out xnl297dump and cyrf6936_scaner to make it to be builded.
deviation-devo8-v5.0.0-dddda03.zip
please try and report back.

I already flash this firmware into my DEVO8S.
it seems like work very well.
I will try fly my M2, I will update it later.
thanks for your help.

[mrampm10]

Hi, i have t8sg v2 and same problem with memory, can you port it for me? I spend full night trying to delete something and only reasult is when i close my eyes i See docker console