H377 protocol

Dear All,
I have implemented the H377 protocol.
I have tested it on DEVO7E.
Could anyone help me to test it more and fine-tune the model6.ini.
Any question, please contact to me.

Thanks.
PS.
1. This protocol requires the addition of a ‘NRF24L01’ hardware
module to function.
2. DEVO10 please use devo7e`s protocol directory

Dear All,
Because DEVO10 has more memory, need not the protocol directory.
Thanks...

Hi PhracturedBlue,
I modified the code base on 4.0.1
Hopping frequency is fixed.
Because i don`t know the algorithm of h377 like the function "calc_fh_channels(u32 seed)"
Hopping frequency is according to the SPI log from H377 transmitter.
Do you have any advance about the algorithm of h377??
Thanks...

Hi ansheng,
Thanks for great job on H377 protocol.
Is it possible to provide Devo8S version F/W for test?

Thanks for your reply..
I think there are 3 important Variable:
binding_adr_rf : it is fixed
rf_adr_buf : according to lfsr
hopping_frequency : Randomization (in function calc_fh_channels(u32 seed)) , according to lfsr

If I use the those algorithm to calculate the rf_adr_buf & hopping_frequency,
DEVO can`t bind h377.

Fixed rf_adr_buf & hopping_frequency is the only way to success.
And according the SPI log from h377 transmitter, rf_adr_buf & hopping_frequency is fixed every time.
I don`t use any code about lfsr. Thit is the reason I marked the function update_lfsr.
I am afraid that those rf_adr_buf & hopping_frequency just bind my h377.
It can`t work on other h377.

Do you understand what i mean??
My English is not very good, sorry about that...

I don`t see any compile condition about devo8s.
I upload the F/W of devo8.
Thanks.

Thanks ansheng.
I will report result after testing on Devo8s.

Thanks

update model file...

Dear PB,
In bind_buf_arry, I just use the bind_buf_arry[0].
bind_buf_arry is used to send information about hopping table.
According to the log of SPI, transmitter just send 10 bytes to H377.
So I just use the bind_buf_arry[0].
Hopping-table has 20 bytes.
It has regular. That is why the information about hopping table just need 10 bytes.

Just as you say, rf_adr_buf and hopping_frequency are not fixed.
rf_adr_buf : according to lfsr
hopping_frequency : Randomization, according to lfsr
bind_buf_arry: according rf_adr_buf and hopping_frequency

I have only one h377 transmitter .
I just get a set munbers of rf_adr_buf , hopping_frequency and bind_buf_arry from SPI log.
If i have more transmitter, I could get more relationship between them.

I send the fixed number from transmitter to h377.
This is why that maybe I just could control only one H377 at the same time.

RX seems to be using nRF24LE1, so tracing it can be problematic.

www.rcgroups.com/forums/showpost.php?p=26510850&postcount=9

Second TX is the best chance, but in general it's discouraging.

Great effort on reverse engineering it, if you allow me some notes on the code and further direction.

I don't understand why do you initialize 4 copies of binding buffer. In the original HiSky code it makes sense - they are all different, so the frequency hopping is passed in several packets. In your case you pass the same binding buffer every time.

Frequency hopping sequence is pretty simple - it consists of channel monotonically raising with step 3. So there is probably only one dependent parameter - the beginning of the sequence.

Also there is unclear contents of the binding packet - the first 5 bytes is the address (which better be clearly reflected in the code), and then 5 bytes more. I would try modifying these bytes first to figure are they important or just random filler.

May be the perspective is not so glum, but the protocol is less interesting and interference proof than it could be with minimal efforts of its creators.

As a benefit one should note 10-bit precision of all 8 channels.

Good News!
I tried this protocol on DEVO8S,it worked well!
Thanks for great job ansheng !

dear victzh,
I just use one copy of bind buffer
I modified the code from hisky. It original initialize 4copies.
"the beginning of the sequence" is 0x1c at bind_buf_arry[0][5] and [0][7].
just as you say, bind_buf_arry[0][0]~[0][4] is the address
But I don't know bind_buf_arry[0][6],[0][8], [0][9] how to calcular.
If i can get 2nd Tx, may i could know how to get them.

Dear all,
Does anyone know who lmplement the hisky protocol in deviation?
Thanks!