Thread Tools
Apr 19, 2019, 11:34 AM
Registered User
Quote:
Originally Posted by hpnuts
I can make a test protocol to listen and display whatever the radio is sending. But I'm leaving on vacation in a couple of hours for 2 weeks and I don't think I'll have the time to work with you on it... It will have to wait that I'm back if you will still be available.
- Pascal
No problem, we can pick it up again when you return. Have a great vacation!
Sign up now
to remove ads between posts
Apr 19, 2019, 01:38 PM
Up! Up! And Away!
GottaZoom's Avatar
Quote:
Originally Posted by theraw
Hi Pascal. There is a button on the stock controller to switch between altitude hold and angle mode as per the picture attached. You can switch modes during flight but it would make more sense to me for that to only work on bind or when the motors are disarmed. I do have the stock controller but what's involved in "listening" to what it sends when this button is switched?
That button/switch looks to be in a typical throttle trim position ... does it also change throttle behavior? (Typically AH quads use centered throttle while others do not use centered throttle.)
Apr 19, 2019, 03:56 PM
Registered User
geileraupe's Avatar
All Flysky and Turnigy sensors are working perfect Only the "pressure" sensor TGY-CAT01 Altitude Sensor does not work. In this sensor are a Tempratur and airpressure .. On the Flysky Transmitter Display it shows 2 informations temp and mbar https://hobbyking.com/de_de/attitude...r-for-i10.html
Apr 19, 2019, 04:26 PM
Registered User

Afhds 2a Issues


Hi hpnuts,

I decided to spend some time trying to figure out what is causing the intermittent link with the AFHDS 2A receiver. I studied your code in order to understad the frequency hopping mechanism of this protocol. As I understand it, a sequence of 16 channels for frequency hopping is generated at the TX module and this sequence is written to the receiver during binding.

To minimize the chance of interference with other users, the generated sequence varies with the TX module master ID and RX number. The problem I was experiencing seems to be the receiver getting out of sync with the channel hopping sequence, only getting a few hits per second, resulting in poor intermittent link.

In normal opeation the current channel index (hopping_frequency_no) is not transmitted in the packet, right? So if the RX is able to pick up a valid packed when it's listening on a different channel than the TX is sending (can a strong signal do this?), it will think it is synchronized with the hopping sequence while it is really not. It seems a fragility of the AFHDS 2A protocol, in which there is not much to do to fix it. Please correct me if this statement is wrong.

As seen earlier, changing the module's global ID has influenced the operation by allocating different channels. Now I understood and verified that changing the RX number (which is much easier) has the same effect as playing with the global ID, since MProtocol_id = RX_num + MProtocol_id_master and MProtocol_id is used to initialize the random channel generator AFHDS2A_calc_channels().

I've made a few attempts to modify AFHDS2A_calc_channels(), increasing channel spacing and limiting channel range from 1 to 160 but unfortunately it did no better than changing the RX ID by trial and error until it resulted in a good link. I do not know what sets a good chan sequence apart from a bad sequence for those receivers. Maybe some funny constraint other than chan spacing >=2 needs to be applied there... Or I have a bad receiver and I'm just taking the time to learn how these things (should) work.
Apr 19, 2019, 08:56 PM
Registered User
ripper-911's Avatar
Hello. I just purchased the iRange X module for my X10S to be used with DSMX receivers. Could you direct me to a source of information to set it up successfully for DSMx?
Apr 20, 2019, 02:35 AM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by geileraupe
All Flysky and Turnigy sensors are working perfect Only the "pressure" sensor TGY-CAT01 Altitude Sensor does not work. In this sensor are a Tempratur and airpressure .. On the Flysky Transmitter Display it shows 2 informations temp and mbar https://hobbyking.com/de_de/attitude...r-for-i10.html
All the processing of the telemetry is done through opentx. Nothing that I can do in multi. We could help the opentx/ersky9x team by dumping the telemetry packets and point out where the sensor data is and its format. Let me know if you are willing to help.
Pascal
Apr 20, 2019, 03:19 AM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by AndreL
Hi hpnuts,

I decided to spend some time trying to figure out what is causing the intermittent link with the AFHDS 2A receiver. I studied your code in order to understad the frequency hopping mechanism of this protocol. As I understand it, a sequence of 16 channels for frequency hopping is generated at the TX module and this sequence is written to the receiver during binding.

To minimize the chance of interference with other users, the generated sequence varies with the TX module master ID and RX number. The problem I was experiencing seems to be the receiver getting out of sync with the channel hopping sequence, only getting a few hits per second, resulting in poor intermittent link.

In normal opeation the current channel index (hopping_frequency_no) is not transmitted in the packet, right? So if the RX is able to pick up a valid packed when it's listening on a different channel than the TX is sending (can a strong signal do this?), it will think it is synchronized with the hopping sequence while it is really not. It seems a fragility of the AFHDS 2A protocol, in which there is not much to do to fix it. Please correct me if this statement is wrong.

As seen earlier, changing the module's global ID has influenced the operation by allocating different channels. Now I understood and verified that changing the RX number (which is much easier) has the same effect as playing with the global ID, since MProtocol_id = RX_num + MProtocol_id_master and MProtocol_id is used to initialize the random channel generator AFHDS2A_calc_channels().

I've made a few attempts to modify AFHDS2A_calc_channels(), increasing channel spacing and limiting channel range from 1 to 160 but unfortunately it did no better than changing the RX ID by trial and error until it resulted in a good link. I do not know what sets a good chan sequence apart from a bad sequence for those receivers. Maybe some funny constraint other than chan spacing >=2 needs to be applied there... Or I have a bad receiver and I'm just taking the time to learn how these things (should) work.
This issue appears only with a few RX.
RX_num is changing some bytes of the ID not all which is why I asked you to force the id in the first place. To make sure the id has no role in the issue, you could force the hopping to be always the same and play with the ID. If it works whatever ID is used then we can exclude it.
Once we know only the channels are the issue, you could try multiple id and see what channels are being used when good and bad which could give us a clue.
But the only way to really get to the bottom of it, is to dump what the RX is doing. Someone having one of these weird RX should solder 4 wires (sdio, cs,call, gnd) on the a7105 SPI bus and plug it to a logic analyzer (5$). This way we can see what the RX is looking for and not finding when this weird behavior appears.
Pascal
Apr 20, 2019, 03:24 AM
Registered User
Quote:
Originally Posted by hpnuts
Try different sub protocols PWMIBUS and such (even if the desired output is PPM). Also don't bind with the radio to close to the RX.
Hello again,

I try all the sub protocols. Diferent distances to the RX and nothing work.

What can it be?
Apr 20, 2019, 03:36 AM
Pascal
hpnuts's Avatar
Quote:
Originally Posted by HTeixeira
Hello again,

I try all the sub protocols. Diferent distances to the RX and nothing work.

What can it be?
No idea of the cause... Try different rx_num.
Apr 20, 2019, 02:06 PM
Registered User
Quote:
Originally Posted by GottaZoom
That button/switch looks to be in a typical throttle trim position ... does it also change throttle behavior? (Typically AH quads use centered throttle while others do not use centered throttle.)
Yes, sorry, I should have mentioned that. When switched to altitude hold it engages a spring which holds the throttle in the centre. So when the motors are armed the throttle is centre, pushing up lifts the quad in to the air and then letting the throttle return to centre allows the quad to hold its altitude automatically. Pulling the throttle down lowers the quad to the ground and once it's on the ground continuing to hold the throttle all the way down disarms the motors after a few seconds. When switched to angle mode the spring is disengaged from the throttle and the controller and quad behave like any other quad in angle mode.
Apr 20, 2019, 02:44 PM
Up! Up! And Away!
GottaZoom's Avatar
That's a cool TX feature! By angle mode you mean self-level (not acro), correct?

So you don't have to recalibrate the throttle or bind after changing? I wonder if the TX or TX and flight controller are handling the change. Be interesting to see whether/when the switch send out out what command.
Apr 20, 2019, 03:18 PM
Registered User
Quote:
Originally Posted by GottaZoom
That's a cool TX feature! By angle mode you mean self-level (not acro), correct?

So you don't have to recalibrate the throttle or bind after changing? I wonder if the TX or TX and flight controller are handling the change. Be interesting to see whether/when the switch send out out what command.
It is clever! That said, even without altitude hold, it's much easier to fly with the Taranis QX7S. And yes, there's no need to recalibrate the throttle or rebind when switching modes. I don't know whether the TX throttle sends out different commands when in altitude hold mode or whether the flight controller handles everything, it will be interesting to find out.
Apr 20, 2019, 03:19 PM
Registered User
Quote:
Originally Posted by GottaZoom
By angle mode you mean self-level (not acro), correct?
Oh yeah, I mean self-level.
Apr 22, 2019, 05:39 AM
Registered User

Binding Esky 4 in 1


Sorry for the newbie question, I've searched the thread but no luck. I have a Banggood IrangeX and a HoneyBee V2 but I can't get them to bind. Should it work? At the moment I'm using the pre-installed firmware in the IrangeX, doI need to update it?


Quick Reply
Message:

Thread Tools