Hitec protocol

I don't have my computer with me this weekend just my mobile so I did a quick review.
I see a number of issues:
- the hopping frequencies are choosen based on the current clock which is wrong it should be based on the ID since we want always the same hoping table to be generated for the same ID.
- the ID is not initialized, rx_tx_addr in multi is loaded with the content of the 32bit ID of the TX which is MProtocol_id also used to generate the hopping frequencies.
- the channels value calculation is also not quite right just use the min max of the Devo, a sizing is not required before.

@sfrench808: in the current form of the code, you should be able to bind the RX and have something kind of moving if you do not turn off the TX. This is important if you power cycle the TX or stop the bind process or do whatever with it the bind information will be lost...

Thanks Pascal!

Test build is updated (6e9c5f3).
- Use txid to choose hopping frequencies and initialize rx_tx_addr
- Calculate channel values directly from deviation channel range (-10000/10000)

ok, I updated the firmware and tried to bind. Both rx seemed to bind correctly. I didn't see any movement on the servo, so I went into the channel monitor and discovered that there is no channel one. I moved the servo over to channel two and there is movement. The movement isn't correct, as in the servo moves completely in the direction commanded within just a few percent of the total throw. When I moved the servo to channel four, even though the monitor shows movement from 60 to -60 the servo did not move. The monitor shows the same configuration on the minima rx channels two thru six, but no matter where I put the servo there is no movement. The minima bind, I believe works now, you have to select minima put the tx in bind by highlighting bind and hitting ENT, while it is binding you then need to put the rx in bind mode. You get the rapidly flashing blue LED then it goes steady and when you cycle power to the rx the blue LED comes on steady and stays steady. The servo movement on the Optima is very erratic. I as stated before the servo arm moves full throw with just a slight movement of the stick then if you keep moving the stick in the positive direction the servo arm goes full negative. In the negative direction it goes full throw very quickly and then just stays there. I also have an 8 channel minima third party rx. It binds also and has movement on both channel 2 and 4, but the movements are still very erratic. Thanks again for your efforts and quick responses.

It looks like an issue in the scaling of the channels.
The trickiest part was the bind which is working so it's nearly there.

Pascal

Test build is updated (9f60e78). Restored the scaling of deviation channel values to match DIY project values.

Wrote some test code to verify the same channel values are produced for -100%, 0, 100%, etc.

Updated with new build. Everything seems to be working properly. I can bind with all three rxs and the servo movement is smooth and looks totally normal. I haven't tried to fly anything yet but things are looking promising. This will help me immensely so I really appreciate all your work on this. I will try to update when I put it into actual application. Thanks again.

Cool!
Have you tested the telemetry with an Optima RX? At least RSSI and RXVoltage?

Pascal

No I haven't gotten that far into it yet. I will have to do some research I'm still relatively new to all of this. I'm going to try to fly this weekend, weather permitting.

I am very interested in what you are doing. I am setting models up in my Jumper and will be loading this protocol into the TX when it appears to be ready.
Keep up the good work and thank you.

Will

Can't do telemetry, all I have is an Optima 6 and they don't do telemetry. Oh well. Still haven't flown but hope to soon. I have an rx in my plane and the servos seem to move correctly. The throttle is a little off at the bottom, I have to give it about 25% before it starts the motor. It also seemed a little iffy on the staying bound, but I was pretty close to the rx with the tx. My finger are crossed that this all works well.

Every Optima RX have basic telemetry built-in, this includes the 6.
Check the telmetry screen, you should RSSI and RX voltage.

Pascal

Good day,

I have been finally able to proceed with trial of the Hitec protocol..

I have updated my Jumper T8sg V2 plus to the nightly build firmware v5-0-0-e44bf33

and have created a Crack laser aero plane model. Using 4 channels and flight modes.

I have successfully linked:-

2 x 3rd Party minima 4 channel RX’s

And also

1 Genuine Optima 7.

I have tested extensively both minima’s and appear to have the same problem as described in post 70357

Both these RX’s are having the same problem.

It appears that they are hanging momentarily during the stick waggling process.
They can be hung for random lengths of time from ½ second to 5 to 10 seconds.

I have made a short video which can be found at:



The glitches are as follows:-

At 6 secs when changed from low to high rate.
At 28 secs small one.
At 1.04 quite big one.

Hope this will help,

Cheers

Will.

Isn't it caused by the Swamping (overdrive) the RX input at close range? The cc2500 are very sensitive. So probably at few meters distance, or lower power setting it may be ok ?

Thank you very much for your reply Fernandez.

I had not even thought about swamping.

Now that I think about it, it is a real possibility.

I did have the TX power at 150mw, and was holding the TX at this point to get the sticks and model in the same picture.

I have had 600 flights with that same RX in this model aircraft using Hitec Aurora 9 without any glitches or evidence of swamping even while working on the model on the bench.

I have tried to find the Hitec output stats, it appears that the A9 could be transmitting at 100mw so the 150 would be a huge increase.

I must admit I am still nervous about this new protocol in case it is not the swamping so will perform a lot of testing with varying output power, to get the confidence I need.

Could you please tell me , what is a CC2500? Is it th TX or the RX?

Cheers
Will

It is the transceiver chipset, texas instuments, present in Transmitter and receiver.

Normally you would expect that if swamping is present, it will also do it with original TX, as it is the RX which has the problem.
Could be that due Tx power differences, you really must put antenna's close and parrell to obtain swamping with original Tx?

Another thing what you could try, is ensure you have matched the freq tune. So put tx in 100uW mode, put antenna's fixed approx. 1m distance, try find min max edges of tune value when it just can.cannot bind. Then set freq tune in middle and fly like that.. This way you have tuned out any tolerances between oscillators. Nice feature of deviation.




.

Good Day Fernandez,

Thank you so much for your advice and help.

I have extensively tested 2 X Hitec 3rd party Minima 4 channel compatible receivers, as well as the Delta 8, and Hitec optima 7 channel.

As you suggested the 4 channel RX’s were being swamped and I was able to produce the swamp affect with my Hitec A9 TX.

I entered 2 x models, a Twisted Hobbies crack laser, and a Twisted Hobbies Crack pitts, into the Jumper and written ini files for them.

Today was bite the bullet day and took the 2 models to the field.

Both models were range tested with the transmit wattage at 100. Adequate range equaling the Hitech Aurora 9 tests was achieved.

Both models had 3 flights each and no glitches were detected.

I would consider the Jumper protocol for Hitec to be good and would now have no hesitation in using it and recommending it to others.

As mentioned above I have bound and tested Delta 8 and Optima 7 but as yet have not flown them.

Cheers
Will