H377 protocol

Dear victzh
How do you know the sequence of bind_buf_arry and channel data(AIL ELE...)?
According to any document?
The sequence is not easy to get.
Thanks.

@ansheng,

It's not totally clear to me what you're asking, channel data you figured out and it works, right?

For binding packet there are several options:

1. Get a second transmitter and figure out the difference between the packets.

2. Experiment with existing code - try to figure out what in this binding packet is relevant and how. You'll need to do this anyway, even with the second transmitter - usually you can't buy 100s of them, you need to apply some guesswork. So you can try it early. First, try to change values in bind packet beyond the address and supposed beginning of the frequency hopping sequence. Does it influence binding? If so, they can be either fixed for any binding packet, or form some kind of a checksum. Then you probably need to automate your efforts.

Does the receiver board have clear indication of binding process? Say, LED blinking during biding and if binding succeeds, blinking differently or going steady or whatever. Also, it is good to have an automated way to induce the board into binding more.

You can connect the board's power or reset button or wire and LED to something like Arduino (I personally use it for such jobs) and put the binding part of your code to Arduino as well. Then you can program varying parameters in the binding code and watch whether the receiver binds, if not - try again. It takes time, but computer is much more persistent doing this than humans

It would also help if you make detailed photos of both sides the RX board and TX board, put it somewhere and publish a link in this forum - may be someone recognize something familiar or suggests some way of tackling it.

Dear victzh,
I need more transmitter， get more infomation about package and apply some guesswork.
Right?
hisky protocol is not easy。
How much time do you spend to implement the hisky protocol?

HiSky is not mine to reverse - I was a bit late It is done by another person (suvsuv, or sunvsuv on different forums), who lost interest in it. I picked up after him and brought it to shape.

But I did on my own V202 and Tactic SLT - they were not easy, may be even harder to crack - HiSky passes full frequency hopping sequence in binding packets and it is hard not to notice it. V202 and SLT use algorithms deriving this sequence from TX id. V202 was a gentle case - after binding packet it tried to listen to all frequencies in its sequence, so I just needed to connect logic analyzer, issue a binding packet and record response. Then my program reset the RX board, issue new binding packet etc. Then I analyzed the trace of channel switching from the logic analyzer.

Tactic SLT was worse - it did not want to listen to all frequencies before it got packet on the previous one. So I built a more complicated rig - I connected RX's SPI bus back to the code, driving TX and build a loop. My TX code issued the binding packet, then waited on SPI bus which channel RX switches to, issued packet on this channel, watched RX again - and so on.

Decoding the results is the most challenging part - I wrote several scripts trying to find a system in these dependencies between the TX id and sequence.

You're a bit more lucky - the sequence is simpler. But the binding packet unknown 5 bytes are still there.

Overall, each protocol requires 3-4 days full time (around 20-30 hours), which, considering it's not my day job, can be spread over weeks of real time

I understand.
I will continue to crack the h377 protocol.
Thanks.

Dear PB,
Here is the newest source code for H377 protocol.
Could I add the code to Deviation project??

Thanks.

Ansheng, congrats with your first protocol reverse engineered!

Victzh,
I don't. crack the protocol 100%.
I just put 9 set hopping sequences in the protocol.
The protocol just select one set of them to use by random.
It is not good enough for me.