Closed smaller09 closed 3 years ago
Why are you not using the NRF (if installed) to receive the telemetry like I've done on Multi?
Why are you not using the NRF (if installed) to receive the telemetry like I've done on Multi?
It's just because my d7e only has cc2500 installed. and I want to use it to control my OMP M1, a little heli. My devo10 has a 4in1 module installed. I can try to port.
But I do want to use single cc2500 to make it work, but cc2500 wants a packet start with 0xAA(n byte) and then sync word (0x71 0x0f) and then a rx address (0x05). If I disable sync word detect, it will only receive garbage. If I enable address check, it will receive nothing. If I enable sync word detect and disable address check, it will receive packets but can't decode. So maybe it's a mission impossible. As for the protocol itself, I found your code has always same hopping_frequency_table, so I add some randomisation base of tx_fixid. But I has little knowledge of LFSR, so the code is just work, hopes you can do it better.
As for the protocol itself, I found your code has always same hopping_frequency_table
This is wrong...
As for the protocol itself, I found your code has always same hopping_frequency_table
This is wrong...
the hopping_frequency_table was send in BIND phase. I had changed it to different one, and it works.
the hopping_frequency_table was send in BIND phase. I had changed it to different one, and it works.
???? What you are saying is none sense... The hopping table is different for every module and even change with the RX number... The hopping table is sent during bind and can be anything which is what I'm doing by spreading it randomely. You are just moving the start within 8 which means that you have plenty of frequencies overlap between radios...
On the receiving side, you prefer no telemetry rather than telemetry for people having 4in1 which is a strange choice in my eyes. The way you are trying to receive the packets with the CC2500 is not going to work. I'm able to receive some packets with it but they are so sparse that they are useless. I might give it a try again to see if I can get some improvement.
the hopping_frequency_table was send in BIND phase. I had changed it to different one, and it works.
???? What you are saying is none sense... The hopping table is different for every module and even change with the RX number... The hopping table is sent during bind and can be anything which is what I'm doing by spreading it randomely. You are just moving the start within 8 which means that you have plenty of frequencies overlap between radios...
On the receiving side, you prefer no telemetry rather than telemetry for people having 4in1 which is a strange choice in my eyes. The way you are trying to receive the packets with the CC2500 is not going to work. I'm able to receive some packets with it but they are so sparse that they are useless. I might give it a try again to see if I can get some improvement.
Oh sorry I make a big mistake, casue the code don't have packets detail, I use information from the omp protocol issue in your repository, so I always remember hopping table=(i+3)*5, and didn't notice that #define FORCE_OMP_ORIGINAL_ID was commented out, I will improve the code. thanks for your reminder.
I have switch to jumper T16 and not using the devo10 for long time. and just want my d7e can control omp m1, that's why I want to use single cc2500. but as what you said, it's not going to work. ok, I will try to port to nrf2401.
Telemetry works now, tested on devo10(4in1 module) + omp m1. need nrf24l01 to work. but compile fail on devo6&devo8, both two run out of rom space. may need to cut down the codes. btw I had also compiled the current master branch. those two would also run out of rom space. so the problem maybe in my own toolchain.
Porting from DIY-Multiprotocol-TX-Module, need cc2500 installed. tested on devo7e & devo10. no telemetry now. (maybe never, cause cc2500 has different preamble as xn297l)