- Posts: 610
HontaiTec Quadcopters (HT F801, HT F803,...)
- Durete
- Topic Author
- Offline
I started to capture from the receiver, using my stock TX.
Here the captures:
dl.dropboxusercontent.com/u/14941708/RX%...res%20Stock%20TX.zip
I didn't capture trims because I have some problems with the motors since the full quadcopter is disassembly. Hexfet, if you need the trim captures, let me know and I will desolder the motors to capture. No problem.
I will try to capture using the Devo ASAP.
@Greenfly, everytime I update the build I overwrite my Dropbox's file with the new one. So maybe when you tried to use another previous build, if you don't have saved locally and simply click at my link, you are downloading always the last version. That could be the reason you can't bind using "my previous" build, really you are trying with the last version always.
Please Log in or Create an account to join the conversation.
- greenfly
- Offline
Please Log in or Create an account to join the conversation.
- Durete
- Topic Author
- Offline
- Posts: 610
Please, try with our captured TX id as Fixed Id (61956 and 31242). I have not any problem binding with my Devo using this 2 Fixed Id's.
Remember to reset quadcopter and TX every time you change your fixed Id. I have some problems to bind if not restart both.
I need to start to test fixed id's ...
Please Log in or Create an account to join the conversation.
- greenfly
- Offline
Please Log in or Create an account to join the conversation.
- greenfly
- Offline
Please Log in or Create an account to join the conversation.
- Durete
- Topic Author
- Offline
- Posts: 610
I can only bind with my TX id. using 61956 as Fixed Id.
Please Log in or Create an account to join the conversation.
- hexfet
- Offline
- Posts: 1891
Durete's data looks just like greenfly's as far as the strangeness. After staring at it a while I realized the "bad" packets are just left-shifted one bit at some point (not always the same) after the first byte. Maybe the logic analyzer is loading the signals so much that they barely exceed levels for detection? Or causing a clock pulse to be missed? Still strange that it's so consistent. From the timing in the captures it seems the clock rate is about 2MHz. Are y'all capturing at 4MHz sample rate or faster?
greenfly, on the devo rudder capture it looks like the min value only goes down to 0a and the max up to 2f. Is that due to a mix with less than 100% scale? The rudder channel and trim values look correct, as best I can see through the sometimes shifted data.
Please Log in or Create an account to join the conversation.
- Durete
- Topic Author
- Offline
- Posts: 610
Please Log in or Create an account to join the conversation.
- greenfly
- Offline
@Hexfet, yes I was testing in 'low' mode. I forgot to switch to 100% before testing.
Please Log in or Create an account to join the conversation.
- greenfly
- Offline
Could it be that the packets are 'good' and we are just interpreting them wrong in the software?
Could you tell me what to look for if I was to try some of the other analysis options?
Thanks.
Please Log in or Create an account to join the conversation.
- hexfet
- Offline
- Posts: 1891
The SPI parameters are correct or we wouldn't get so much good data. Inspecting the SPI data onscreen might show a missed clock pulse or something. Best way I've found to correlate the export file to screen display is by timestamp. Search the decoded (--full) txt file for RX_PAYLOAD and 40 16 on the same line (that's a shifted packet) and look for that timestamp onscreen.
The bind packets I've looked at have all been un-shifted, so we can collect some bind data. I'm out tomorrow so here's what to look for. I'll use greenfly's 05-devo-bind-fail.txt file as an example.
1) Starting from the top search for RX_PAYLOAD. This is reception of the bind packet. The fifth and sixth miso bytes (right of arrow) should be the fixed id set in deviation.
2) Search down from there for RX_ADDR_P0, then again because the first match seems like a programming error. The next match should have six mosi bytes - the last five are the rx/tx address.
3) Search down from there for RX_CH. The value after 25 is the channel being set.
4) Keep searching for RF_CH until the channel sequence repeats. So far it's been 5, 0x19, 0x28.
The RX enters data phase after 2 so we can see the channel sequence, but it goes into bind again if it doesn't receive any data packets (which doesn't happen till the tx stops sending them). So it binds a bunch of times each power-up.
You might start with the stock tx and see if it randomizes the txid each time - greenfly's captured both 7a0a and 7a14 as the last bytes. Easier than changing the fixed id every test. Hopefully a pattern will emerge quickly
2.190433 > RX_PAYLOAD 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 => 42 4c 4b 3a 7a 0a 00 00 00 4f 07 25 6a 80 0a c0 91
2.190541 > RX_ADDR_P0 2a 55 65 92 4a => 4e 00 00 00 00
2.190573 > EN_RXADDR 22 01 => 4e 00
2.190586 = FLUSH_RX e2 => 4e
2.190594 > STATUS 27 70 => 4e 00
2.190606 = SETUP_RETR e4 => 0c
2.190618 > STATUS 27 42 => 0e 00
2.190632 > RX_ADDR_P0 2a 54 b2 c9 25 24 => 0e 00 00 00 00 00
2.190664 > EN_RXADDR 22 => 0e
2.190676 > RF_CH 25 19 => 0e 00
Please Log in or Create an account to join the conversation.
- greenfly
- Offline
I will get started in the morning and post my results as I find them.
I guess the quad is on the operating table for the duration... oh well at least I have a few others I can fly.
Maybe I will find a way to bring the five lines out such that I can still re-assemble it. Like giving my quad a DIY debug port!
Please Log in or Create an account to join the conversation.
- Durete
- Topic Author
- Offline
- Posts: 610
Since I'm working with windows, I can't find where is the interpreted CSV SPI file (stdout ? ).
The perl script appears to be working, but the GNU windows is very small to look for anything. I suppose this output will print to any txt file or something similar.
Sorry for this noob question
Please Log in or Create an account to join the conversation.
- greenfly
- Offline
You can use the '>' (greater than) character at the end of the command to pipe stdout to a file.
perl format_spi.pl <filetoanalyze> -full > output.txt
HTH
Please Log in or Create an account to join the conversation.
- Durete
- Topic Author
- Offline
- Posts: 610
Please Log in or Create an account to join the conversation.
- Durete
- Topic Author
- Offline
- Posts: 610
Data channels always 5, 19, 28.
I will continue capturing binding sequences for a while looking for any change.
Please Log in or Create an account to join the conversation.
- Durete
- Topic Author
- Offline
- Posts: 610
hexfet wrote: 2) Search down from there for RX_ADDR_P0, then again because the first match seems like a programming error. The next match should have six mosi bytes - the last five are the rx/tx address.
My captures at 16mhz don't show this programming error. I can see always 6 mosi bytes with the same address.
2.374596 > RX_PAYLOAD 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 => 42 4c 4b 3a f2 04 00 00 00 78 79 25 6a 80 00 28 31
2.400224 > RX_ADDR_P0 2a 2a da a5 25 24 => 42 00 00 00 00 00
2.400256 > EN_RXADDR 22 01 => 42 00
2.400269 = FLUSH_RX e2 => 42
2.400277 > STATUS 27 70 => 4e 00
2.400290 = FLUSH_RX e2 00 => 0e 00
2.400302 > STATUS 27 42 => 0e 00
2.400315 > RX_ADDR_P0 2a 2a da a5 25 24 => 0e 00 00 00 00 00
2.400347 > EN_RXADDR 22 01 => 0e 00
2.400360 > RF_CH 25 19 => 0e 00
Please Log in or Create an account to join the conversation.
- greenfly
- Offline
2.467853 > RX_PAYLOAD 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 => 42 4c 4b 3a 7a 0a 00 00 00 4f 07 25 6a 80 0a c1 91
2.467962 > RX_ADDR_P0 2a 54 b2 c9 25 24 => 4e 00 00 00 00 00
2.467994 > EN_RXADDR 22 01 => 4e 00
2.468006 = FLUSH_RX e2 => 4e
2.468015 > STATUS 27 70 => 4e 00
2.468027 = FLUSH_RX e2 00 => 0e 00
2.468039 > STATUS 27 42 => 0e 00
2.468052 > RX_ADDR_P0 2a 54 b2 c9 25 24 => 0e 00 00 00 00 00
2.468085 > EN_RXADDR 22 01 => 0e 00
2.468097 > RF_CH 25 19 => 0e 00
Channels all seem to be 5, 19 and 28.
My TX id always seems to be [7A][0A].
Please Log in or Create an account to join the conversation.
- hexfet
- Offline
- Posts: 1891
Excellent. And looks like y'all have the hang of getting the bind information The 7A14 bind address must've been a capture anomaly - 0x14 is 0x0a shifted left one bit.Durete wrote: My captures at 16mhz don't show this programming error. I can see always 6 mosi bytes with the same address.
Have you made any captures with the devo fixed id? Maybe one start at 0 and the other at 256, and just increment by one each time. It's tedious so stop before it becomes too aggravating I'm hopeful they've done something very simple, but usually it's necessary to build a test jig to automate these captures. We'll see.
Please Log in or Create an account to join the conversation.
- greenfly
- Offline
You want me to make captures of the bind process when I use a specific fixed ID on the Devo. 1..2..3..4..
I can do that... but what are we looking for?
Do you want all those capture files?
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Protocol Development
- HontaiTec Quadcopters (HT F801, HT F803,...)