The + symbol opens a line for a second ID. I tried putting the extended ID there, also ARDU… separately, but no change in available downloads. I also tried deleting all IDs and then entering the extended one there. No change. Also tried logging out and back in again.
EDIT: Got it working now. Testing tomorrow, weather permitting, on 2 copters and 2-3 planes.
EDIT2: For weather reasons, only about 15 mins of flying one copter could be achieved today - no problems with the new version and a Nano Diversity RX. More testing tomorrow I hope.
(It’s long log of failed launch attempts of a small heavy plane into no wind at all, not enough airspeed. I don’t think there was anything wrong with the plane.)
I think the version was called 6.34 alpha, I don’t know if it’s identical to what used to be called 6.35 alpha. I haven’t checked for newer versions yet.
There should be RSSI via the oldschool method: RSSI_CHANNEL,12 and RSSI_TYPE,2
However, if I remember correctly it has been a longstanding problem that this number only drops when RSSI/LQ drops from 100 slowly. In case of FS (drop straight to zero), it remains at 100. I think I read about it in the wiki years ago.
I’m aware there’s now the newer RSSI_TYPE,3 (ReceiverProtocol) and I tried that but it gave me wildly fluctuating numbers that made me really nervous… So I’m sticking to the old method with which I can still observe RSSI declining gradually in flight.
I’ve now had many hours flying on 6.35 without any issues.
I understand there is a beta version 6.36. I haven’t tried this but some testers report problems.
I’m not sure if 6.35 is officially released yet but it certainly should be.
It would have been nice to see TBS attempting to warn customers about the loss of bind issues.
I was away for a while, has there been an update fixing the SA issue?
Hoping it will be the last time I have to gather all my craft for an update session this year…
EDIT: Looks like this time there isn’t even a new alpha yet.
As I didn’t find any mention of this new bug anywhere else - if it only occurs with SA from RX to VTX (which is what I still use), disabling SA on all RX pins (and setting the VTX by buttons) safely works around it, correct?
I’m facing a strange behavior after updating my tbs system.
I just updated my micro tx and some tbs nano rx and one nano rx pro receiver.
After the update, there is a strange behavior I mentioned. I’m using the channel 5 for flight mode and a curve generating microseconds as 1000,1295,1389,1551,1705,1807 - flight modes 1 to 6.
After the update and with the transmitter connected to the radio - a tx16s - when setting the flight mode 1, the microseconds are oscillating between the flight modes 1 and 2. If I select the flight mode 2 there is no oscillation, changing to 1 again the oscillation continue.
If I remove the transmitter, there is no oscillation - this behavior started after the upgrade. Any clue? Someone is having the same scenario ?
On the transmitter go into model settings, then “SERVO” tab and record the microseconds value for each switch position (should be oscillating if the mode is oscillating)
Provide a disarmed flight log of the behaviour (LOG_DISARMED=1)
yes, really strange - I will try later today downgrade to 6.19 - was the previous version I was using before the updade.
I will try to generate de log but I’m attachign a video from the radio debug screen - the 6 position switch is the channel 6 and it’s possible to see all the channels stable and I’m changing the values for channel 6 and always when I select the 1st switch the oscillation.
I’m attaching the log from a bench flight controller - the flight modes is changing between FBWA and LOITER.
I armed the flight controller and the behavior is the same, in all other flight modes except FBWA the oscillation is not present just in FBWA.
Strange.
I tried to attache the video but is missing in the previous post.
The channel 6 is the 6 position switch on this debug screen and the behavior is the same - oscillating.
But when I remove the transmitter the oscillation stop.
