Eachine E010 inductrix clone data captures
- planger
- Offline
I've looked only at the 2 bytes ID and not when there is a 3rd byte (2 dumps so far out of 16).
So on a total of 14 entries, I'm generating:
- 12 pairs of frequencies correctly
- 2 pairs with the good values but swapped, example ID 0x41 0x22 is supposed to give the freq 0x34 0x2F but my algo is giving 0x2F 0x34...
Strangely the computation of the frequencies is fully logic.So I might just miss one small part of the puzzle.
It has to be noted that the E010 accepts incoming packets on frequencies which are base_freq + x * 0x10 where x can be fairly large. As an example, if the frequency in the dump is 0x2E then if you send packets only on 0x3E or 0x4E or 0x5E or 0x6E or ... they will be all accepted. I'm wondering if this is a feature of the rf chip or the E010 is scanning.
In the current state, the algo works and is implemented in my TX but there is a chance that only 2 frequencies are good among the 4 in use depending on the ID...
If someone is interrested I can give more details.
Pascal
Please Log in or Create an account to join the conversation.
- planger
- Offline
It happened to me as well. It was in fact a bad antenna...FabioKastro wrote: My Devo only binds to the E010 at 10mW and it has a bad delay. Is that because of the 3in1 not being able to simulate whatever you guys said above?
Weird thing is that the bad antenna worked with all other models but not the e010 where the response was really bad=lag,sometimes lost connection, sometimes not binding.
I've changed the antenna and now all models including E010 are working. The same happened with someone else on rcgroups and has been solved the same way.
Pascal
Please Log in or Create an account to join the conversation.
- planger
- Offline
Only 2 have the values swapped. Someone wants to have a look and help?
Pascal
Please Log in or Create an account to join the conversation.
- planger
- Offline
Pascal
Please Log in or Create an account to join the conversation.
- SodaAnt
- Offline
- Posts: 4
Please Log in or Create an account to join the conversation.
- goebish
- Offline
- I Void Warranties
- Posts: 2631
planger wrote: Ok now on the 14 2 bytes TXIDs, I'm able to generate 12 good pairs of frequencies.
Only 2 have the values swapped. Someone wants to have a look and help?
Pascal
I think I had the same results than you then I double checked the captures (I think I've 7 or 8 of them ...) to make sure I didn't swap channels.
Please Log in or Create an account to join the conversation.
- goebish
- Offline
- I Void Warranties
- Posts: 2631
planger wrote: It has to be noted that the E010 accepts incoming packets on frequencies which are base_freq + x * 0x10 where x can be fairly large. As an example, if the frequency in the dump is 0x2E then if you send packets only on 0x3E or 0x4E or 0x5E or 0x6E or ... they will be all accepted. I'm wondering if this is a feature of the rf chip or the E010 is scanning.
interesting, I suppose it's scanning because I doubt the RF chip has 100 MHz bandwidth
Please Log in or Create an account to join the conversation.
- planger
- Offline
Agreed on scanning but the why is strange... I haven't tried to send everything with +0x10 I've only done 1 channel trial.goebish wrote:
planger wrote: It has to be noted that the E010 accepts incoming packets on frequencies which are base_freq + x * 0x10 where x can be fairly large. As an example, if the frequency in the dump is 0x2E then if you send packets only on 0x3E or 0x4E or 0x5E or 0x6E or ... they will be all accepted. I'm wondering if this is a feature of the rf chip or the E010 is scanning.
interesting, I suppose it's scanning because I doubt the RF chip has 100 MHz bandwidth
Please Log in or Create an account to join the conversation.
- planger
- Offline
The 2 IDs with swapped channels are 41 22 and 4F 1C. All the 12 others are good (14 x 2 bytes ID in total).goebish wrote: I think I had the same results than you then I double checked the captures (I think I've 7 or 8 of them ...) to make sure I didn't swap channels.
1 ID is one you provided in your table and the other ID is one I've provided... I think I know where it comes from but I haven't kept the file... I need to dump it again but that would have to wait this WE that I can borrow it again.
Are you getting the same result?
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.
- victzh
- Offline
- Posts: 1386
It is much easier when you can generate arbitrary id and see at what frequency the receiver expects you to transmit. It's not the case here - receiver is integrated with MCU. But what really can be done, if there is an indication of successful binding you can build a rig which tries all 65536 sequences for every id automatically. It will take some time, but not your time, but automaton's.
Please Log in or Create an account to join the conversation.
- planger
- Offline
int main(void)
{
uint8_t TX_ID[][2] = {
{ 0x90, 0x1C },
{ 0x9A, 0xB2 },
{ 0xC0, 0x44 },
{ 0x2A, 0xFE },
{ 0x7A, 0x40 },
{ 0x61, 0x31 },
{ 0x24, 0x36 },
{ 0x5D, 0x37 },
{ 0xFD, 0x4F },
{ 0x41, 0x22 },
{ 0x86, 0x3C },
{ 0xEE, 0xB3 },
{ 0x4F, 0x1C },
{ 0xD7, 0x6E } };
uint8_t E010_rf_map[8][4]={
{ 0x03, 0x57, 0x07, 0x00 },
{ 0x68, 0x18, 0x11, 0x14 },
{ 0x09, 0x02, 0x05, 0x79 },
{ 0x33, 0x36, 0x8A, 0x3A },
{ 0x47, 0x9B, 0x4B, 0x44 },
{ 0xAC, 0x5C, 0x55, 0x58 },
{ 0x6B, 0x66, 0x69, 0xBB },
{ 0x77, 0x7A, 0xCE, 0x7E } };
uint8_t Freq1;
uint8_t Freq2;
uint8_t i=0;
for(i=0;i<14;i++)
{
uint8_t Low=(TX_ID[i][0]&7);
uint8_t High=(TX_ID[i][1]&3);
Freq1=E010_rf_map[Low][High];
Freq2=(Freq1&0x0F)+0x33;
Freq1=(Freq1>>4)+0x2E;
printf("TX_ID[0]=%2X TX_ID[1]=%2X Freq1=%2X Freq2=%2X\n", TX_ID[i][0], TX_ID[i][1], Freq1, Freq2);
}
}
E010_rf_map is the table I've computed based on my findings. I could replace the table by the actual calculation if you want as I think it's more meaningful but you can get the idea by looking at the values in the table.
If you run the code above, you'll see the 2 entries which are not matching:
TX_ID[0]=90 TX_ID[1]=1C Freq1=2E Freq2=36
TX_ID[0]=9A TX_ID[1]=B2 Freq1=2E Freq2=38
TX_ID[0]=C0 TX_ID[1]=44 Freq1=2E Freq2=36
TX_ID[0]=2A TX_ID[1]=FE Freq1=2E Freq2=38
TX_ID[0]=7A TX_ID[1]=40 Freq1=2E Freq2=3C
TX_ID[0]=61 TX_ID[1]=31 Freq1=2F Freq2=3B
TX_ID[0]=24 TX_ID[1]=36 Freq1=32 Freq2=3E
TX_ID[0]=5D TX_ID[1]=37 Freq1=33 Freq2=3B
TX_ID[0]=FD TX_ID[1]=4F Freq1=33 Freq2=3B
****TX_ID[0]=41 TX_ID[1]=22 Freq1=2F Freq2=34
TX_ID[0]=86 TX_ID[1]=3C Freq1=34 Freq2=3E
TX_ID[0]=EE TX_ID[1]=B3 Freq1=39 Freq2=3E
****TX_ID[0]=4F TX_ID[1]=1C Freq1=35 Freq2=3A
TX_ID[0]=D7 TX_ID[1]=6E Freq1=3A Freq2=41
The problem is that the E010 is binding and works with any IDs if you apply my code above to compute the associated frequencies. Simply because it can run on only 1 good frequency received on the 4. And since in the cases above you have even 2 frequencies correct on 4, the one presented here and the one +0x10, it will work and you simply don't know that it works with only 2 frequencies or at least I don't know how to see that...
Pascal
Please Log in or Create an account to join the conversation.
- planger
- Offline
Then you'll see the same pattern on each table: each line increments with a rotation to the left. The value 2 is not allowed, I don't really know why but each time you have 2 in the last 4 bits it is replaced by 0. To fully understand the second table=lower 4 bits you need to add 5 and you'll see the value 2 "not" appearing as stated before.
As you'll see the table looks clean to me. Which means you can determine each row by just doing a rotate and an addition of the intial row. There is no jump or missing values (except the 2 replaced by 0).
Pascal
Please Log in or Create an account to join the conversation.
- planger
- Offline
I've done this for a number of IDs and I'm getting the correct frequencies each time. The problem is that I don't see the way to see the order... And the only 2 examples are a too smal sample to find anything.
But I'm still wondering if the real values we have are correct or if it's not just a bad reading from the dumps...
Pascal
Please Log in or Create an account to join the conversation.
- victzh
- Offline
- Posts: 1386
We probably need more statistics, when time permits I will trace my 2 Eachines as well. If it matches more real results, we can declare your algorithm good enough, if not - maybe we'll have more material for analysis.
Please Log in or Create an account to join the conversation.
- TinuZ
- Offline
- Posts: 6
Please Log in or Create an account to join the conversation.
- TinuZ
- Offline
- Posts: 6
At 100mw nothing but trouble, so I found this thread and lowering the power setting to 30mw makes it bind every time- Yeah! (not!)
BUT: If I leave the E010 stationary and bound to the TX for let's say 5-10 minutes it has the laggy/stuck control problem again.
Power cycling is not solving it immediately, a extended time in the off stated is needed to bring it back to normal controllable mode. This leads me to believe this is not a logic/datarate error but power/heat related.
Any thoughts about the above, does something make sense to you based on the above or some new insight?
I will report back if the same occurs/can be reproduced using my Taranis/Multi-Module. That would be interesting as they share the same 4-in-1 RF module.
@Pascal: As to the 250kbps/100mw issue: Why don't we see this happening on multi-module as evidently as on deviation with 4-in-1?
Please Log in or Create an account to join the conversation.
- Cereal_Killer
- Offline
TinuZ wrote:
At 100mw nothing but trouble, so I found this thread and lowering the power setting to 30mw makes it bind every time- Yeah! (not!)
BUT: If I leave the E010 stationary and bound to the TX for let's say 5-10 minutes it has the laggy/stuck control problem again.
Power cycling is not solving it immediately, a extended time in the off stated is needed to bring it back to normal controllable mode.
Any time I see anything like this my first thought is a swamped RF front end... Where are you flying? Next to a high power WiFi source? Do you have an SDR? If you don't have an SDR have you watched any RF relayed spectrum graph videos on YouTube? When you're looking at a spectrum and you're watching a specific frequency set (channels) and you switch channels / switch the tx off the spectrum doesn't immediately drop to zero on that band, because it averages it takes a while to die down.
Just seems like such a strangely manifesting issue to me...
Taranis X9E | DEVO 10 | Devo U7E | Taranis Q7
What I do in real life: rivergoequestrian.com/
Please Log in or Create an account to join the conversation.
- goebish
- Offline
- I Void Warranties
- Posts: 2631
www.deviationtx.com/forum/protocol-devel...-q303?start=80#56734
www.deviationtx.com/forum/protocol-devel...q303?start=100#56818
Also, Pascal stated that using a better tuned antenna has fixed the issue for him for the E010, but that sounds less scientific to me
Please Log in or Create an account to join the conversation.
- Fernandez
- Offline
- Posts: 983
Would it be possible to add a frequency offset shift into the protocol option? Like the Deviation Frsky protocol has option for that, as some cc2500 were off and unusable.
By trial and error the offset to be estimated? Put Tx at low power, Change to min bind, change to max bind, enter value in the middle?
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Protocol Development
- Eachine E010 inductrix clone data captures