Open robustini opened 2 years ago
Even in video you can see the difference very well. Here the slave commands using MPM:
And this instead using Bluetooth, you can also see very well from the elevator that when it returns to the center given these shots it wobbles a lot:
@dlktdr can you please comment on this?
@robustini are you saying this is the same with Ethos?
@robustini are you saying this is the same with Ethos?
I have not tried with two TXs with ETHOS, but only between EdgeTX<->EdgeTX and ETHOS<->EdgeTX, same issue. Maybe between two Tandem it's okay, I don't know. It's something we carry with us from OpenTX.
@robustini I’m afraid it’s always been this way because the module firmware is basically broken (by design?). And if this is the case, there isn’t much we can do about it.
@raphaelcoeffic so the only ones who could get into it are those of FrSky, who don't give a damn, great! So the bluetooth trainer is useless.
But something they did in the module for the Tandem X20 because it has a few more options. I don't understand why they left out the PARA module on the X10S Express and the other on the X12S, maybe @bsongis he knows more than we do about that, since he developed ETHOS. Surely the firmware of the bluetooth module will be upgradeable from the tx, it would be enough to fix it.
I've actually fought with this quite a bit with HeadTracker and the ESP module (https://btwifimod.gitbook.io/untitled/) and assumed it was something on my end. I haven't actually tried a Frsky to Frsky with two radios in a long time, down to one working PARA module left.
I had looked over the code so many times and not found an actual issue other than with Bluetooth itself. The timing of the Bluetooth packets is not consistent at all. Although most of the packets make it there every connection interval there is quite a few that get delayed an interval and two packets come at the same time. Which is an inherent issue with Bluetooth. Not to mention that Bluetooth running in PHY 1M drops packets all the time. It isn't the best interface for a real time link. I have had it working so well at home, long range, lots of packets, then go to the field and I can't get 4ft away without loosing a ton of data or connection all together.
There may be an issue with the radio still I haven't been able to pin down. I would be very! curious what happens with two Ethos radios.
I had contemplated adding a buffer to stream the data into the radio at a consistent rate, but of course would add some (pretty significant) delay.
I've gone to the point of customizing the trainer interface to see how many packets are actually making it to the radio and graphing. With my interfaces getting near 80hz. The jitter isn't too bad but is still there. Here are some graphs of what the radio is seeing, notice the notches in the sine waves (not the large ones... ) https://github.com/dlktdr/HeadTracker/issues/63
Also, https://github.com/dlktdr/HeadTracker/issues/60
When I'm doing Arduino -> Arduino via Bluetooth link (same Frsky link over the air) and output via SBUS trainer or PPM to the radio which is a consistent data rate it comes in nice an smooth (if you have a good connection). So there is probably some room for improvement in the interface with a buffer. 😄
ETHOS I saw that in the bluetooth options it has a so-called "high speed" mode
I'm guessing this is enabling CODED PHY Bluetooth mode, which has a much longer range and is more reliable. If they haven't made new modules and the code on the PARA ones is the same as previously produced, If you could capture the RX line into the module and see what they are sending to make this happen. The chip used should support this mode CC2650 (as best we could tell) I have tried connecting to the module and requesting this mode, but it won't switch away from PHY 1M.
What other options do they list on ethos?
@dlktdr thanks Cliff for your detailed explanations. The Tandem X20S is from a friend, I don't have it here but I'm sure of that selectable "high speed" option. In my opinion they have changed the type of module, something perhaps more performing, and what is quite interesting even more than the trainer is the "audio" option available only on high-end tx, this proves that there is a different hardware.
This is the Tandem X20, the module looks like the usual PARA. If the firmware is the same as the module present in the X10S Express I cannot think that the trainer between two Tandem X20 can work better.
And this is the Tandem X20S with an additional module in addition, the one that gives the possibility of audio. So we are talking about another much more complex hardware.
Is there an existing issue for this problem?
What part of EdgeTX is the focus of this bug?
Transmitter firmware
Current Behavior
I had already reported this problem in OpenTX a long time ago, not solved and obviously in EdgeTX we brought it back. Yesterday I tried again between a Tandem X20S with ETHOS firmware and my X10S Express with "modded ISRM" for the "MPM Trainer" option enabled. In BT trainer mode the commands given by the slave's tx are frighteningly jerky, if instead I use MPM as RX they seem to be given by the master tx, very fluid, and the Spektrum protocol for both master and slave gives excellent and stable results. So I tried again between two X10S Express (so two "PARA" bluetooth module) and the result is the same, all jerky. ETHOS I saw that in the bluetooth options it has a so-called "high speed" mode which significantly increases the range between the two tx, but the problem remains the same, not having two Tandem here I don't know how it would behave. I can't believe it's a bandwidth issue as Bluetooth has some available so I don't understand where this limit is.
Expected Behavior
The commands given by the slave tx should be linear and not jerky.
Steps To Reproduce
Version
Nightly (Please give date/commit below)
Transmitter
FrSky X10 Express / X10S Express (ACCESS)
Anything else?
It is not that this thing is of considerable interest to me because with the Multi Trainer the slave and master tx continue to communicate with each other even over 50 meters away (tested), however it would have to be fixed anyway.