Here is a list of all the postings Allan Bennett has made in our forums. Click on a thread name to jump to the thread.
|Thread: Which version of S8R v2.1.0 firmware?|
Keep taking the pills
Clarity? I've followed up again on the other forum, asking why have two versions if the regular one (non _vtail) works for existing v-tails and doesn't require re-configuring after the update. It'll be interesting to see the reply.
I asked a follow-up question on the other forum:-
"Does this mean that the regular version of v2.1.0 can also be used to upgrade existing v-tail models, to avoid having to re-configure them?"
And FrSky have replied, "Yes.".
So it seems that the two versions would better be named as "no reconfiguration required" and "reconfiguration required" since they can both handle v-tail models So what's the advantage of the _vtail version, I wonder? I used it yesterday on a new S8R setup, and the configuration process using Freelink on my laptop was basically the same as it had been when the receiver was flashed with the regular version the day before, though I did notice that all the default gains were zero, and all the directions were set at reverse. I think previously they'd been 50% and normal respectively.
Edited By Allan Bennett on 10/07/2020 08:13:48
Actually I was quite impressed with the support -- my original post was yesterday evening in the FrSky sub-forum of RCG, and the reply from FrSky was there this morning.
Yes, for ACCST LBT there's two versions of SxR v2.1.0 firmware -- one has the suffix _vtail, the other doesn't. As I understand it now the _vtail version can be used with all types of models, but in existing installations it will probably need a reconfiguration. The non-vtail version won't need reconfiguring when updating an existing model, but I infer from FrSky's reply that it can't be used for v-tail models. I've already updated an S8R in my TwinStar with the non-vtail version, and in ground checks (bad weather prevented flight tests) it's working correctly without any reconfiguration.
Edited By Allan Bennett on 09/07/2020 13:28:37
When setting up my Avro Vulcan model with an S8R receiver on v.2.1.0 firmware I was confused by a comment in the information tab of the Freelink configuration software which suggested that flying wing and v-tail models are configured the same. I had assumed that the _vtail version of S8R firmware was only for v-tail aircraft, so I asked FrSky in another forum. Here's their answer in full:-
"For users who intend to make a new model building and configuration, the firmware with added "_vtail" is recommended, this firmware fits all model types, not "vtail" model only.
I hope this is helpful to other users, though it does beg the question whether or not the regular version will work on already-installed v-tail models which are being upgraded to v.2.1.0.
Edited By Allan Bennett on 09/07/2020 10:46:20
|Thread: LiPo over-voltage|
There's obviously many different makes/types of chargers being considered here. Mine displays individual cell voltages throughout the charge, and I've never seen any cell go above 4.20v -- if it did, the charger would have stopped and given an 'over voltage' error message. If a pack is out of balance it holds the first cell to reach 4.20v while the other cells catch up. Like Chris, I don't understand how any charger can display a cell voltage over 4.20v and not figure out that something's wrong.
I've been following this thread, and wondering how a balance-charger could let one cell get so far beyond 4.20v. I understand that a bad connection in the balance lead could perhaps fool a cheap charger, but surely the added resistance would have less effect on the cell voltage seen by the charger when it gets to the reduced-current CV stage of the charge? In fact, if one were able to read the voltage without drawing any current, the voltage should be the same with or without extra resistance in the connection. Modern electronics should be almost able to achieve that, in which case the charger should have been able to do something about it -- either an error message and charging stopped, or discharging the cell to balance with the others.
I know that my PL-8 charger is quite annoying at times for stopping the charge within a minute or so of starting, if it detects any fault in the connections. I shall continue to balance-charge every time.
|Thread: Updated my Taranis to 2.1.0|
I've been thinking more about the oddities I mentioned yesterday: They're both on functions that I've never used since I first configured and set up the models, and hence wouldn't have noticed any problem with the programming if it changed after the maiden flights. That was in the days of .eepe files with OTX Companion 2.1, and I'm wondering if the corruption (added/changed offsets etc.) came about in OTX Companion's conversion from .eepe to .otx files.
Also, I seem unable to edit my previous post, so should point out that I'm on OTX Companion 2.3.9 at the moment, not 2.3.7.
FrSky came out with an offical v.2.1.0 firmware for my S8R receivers this week, so I've updated them now. The first one I've done (but not test-flown yet due to the weather) is in my TwinStar, and seems to have been successful without me having to extricate the receiver from the fuselage to recalibrate it. All surfaces move in the correct direction in response to stick inputs and also in response to automatic stabilisation and recovery mode when I waggle the model.
I have noticed a couple of oddities though in the .otx files which were originally created when the receiver was v.1.x, and which have been copied over from my laptop to my new v.2. trannie: All four main controls are correct, but some of the switches programming in the Inputs tab have been altered -- two of them had offset of 8 or 9 percent added where there was none before, one of them had offset of 4 percent when it had been 50 percent before, and one of them had Curve50 added where there is no such curve specified and there shouldn't have been any curve on the control anyway. Correcting the offsets was no problem, but in OTXCompanion 2.3.7 trying to edit the 'Curve 50' to 'Diff' wasn't accepted. Instead I had to change it to 'Curve ------' to remove the Curve from the switch.
Another oddity is in the simulator mode in OTX Companion 2.3.7: My spring-loaded switch SH is programmed to put the S8R receiver into recovery mode for as long as I hold it, and to voice 'Recovery mode' at 5-second intervals, and 'Panic over' when I release it. On the actual transmitter it works like that, but in OTX Companion it starts voicing 'Recovery mode' as soon as I activate simulator mode, even though SH is 'off' by default. Switching SH 'on' and returning it to 'off' stops the voice, and after that it then works as intended. In the simulator display SH also has a little padlock symbol against it -- I haven't seen that before.
As I mentioned, I've transferred to a new transmitter at the same time as updating to v.2 firmware, but you need to watch out that similar anomolies don't occur when you're doing the update on the same transmitter.
|Thread: Prop advice please.....|
Adding to what Roger has said, you surely won't be using full throttle for normal flying anyway and, since you've tested it for 30 seconds that should cover your initial take-off and climb-out, during which you may be using full throttle.
|Thread: Unable to save settings for S8R|
I know that all sorts of things can be tweaked on the trannie, but I don't like doing any of that at the field because (a) the screen is difficult to see in bright light and (b) the screen is difficult to see because I don't carry my reading glasses with me
Using LUA script to configure my S8R was a revelation, but I much prefer OTX Companion and FreeLink on my laptop in the workshop. If any tweaking is needed after a flight, I just make a mental note of it and do it later at home.
Steve, I'm not sure exactly what was going on, but some Windows diagnostics popped up after I first tried to run FreeLink a couple of times, so I clicked on the 'Fix it' button and it did fix it. Some messages about compatibility with Windows XP, 7, and 8, but no mention of 10. Frustrating for someone who's not au fait with modern Windows, but at least it's working now. I agree with you that it shouldn't be like that, but at least it can be made to work
Thanks Andy48 and Mike. I first tried the LUA script on my trannie and, as you said, it was easy to calibrate and set up the receiver using it.
I then got out my laptop and checked FrSky's Freelink. I'd been to your linked page before Mike, but I was looking for a newer version of the SxRConfig app, so discounted Freelink when I saw it. After installing I had to use a troubleshooting utility to get it to work with Windows 10 (do they not have that in China?), but after that had been sorted it worked with my S8R and wrote the setup correctly.
Just read, and printed, your link Andy48. I'll give that a go tomorrow. I did update my SD card when I updated the transmitter to v2.1, so hopefully everything will be there. If not, I think I know where to find it.
I'm using FrSky's SxRConfig 1.8.4, which has done the job for me in the past when setting up several S8R receivers with v1 firmware. I've just had a look at FrSky's introduction to the Freelink app, but it seems to need to be run from a smartphone, rather than my laptop. I'll look a bit deeper into it, though I doubt if my phone has any memory left to install another app. Mike's Sport Set app on my laptop (it does work with Windows 10, doesn't it?) might be what I need instead.
My transmitter and receiver are both v.2, and the receiver is bound to the transmitter. Interestingly, on the workbench I was able to get the transmitter to within about 2" of the receiver before I got the 'telemetry lost' message and flickering green light. Much closer than with my receivers on v.1 firmware. I'm still not au fait with Lua script; how does it get onto my transmitter? Does the transmitter's v2.1 firmware update include Lua scripts for each of FrSky's receivers?
I'll follow up all these suggestions in the 'workshop' tomorrow, and report back how I get on. Thank you.
P.S. This thread relates only to a brand-new S8R. I've already updated an existing one, in a model, to the just-released v.2.1.0 ACCST LBT and, subject to a test flight, it seems to have gone without a hitch and without the need to go through the setup process again. Control directions are correct, and stabilisation deflection directions are also correct, so I'm going to leave well alone.
Thanks Ron, I suppose now might be the time for me to learn about lua scripts. I've seen that they come from OTX, rather than FrSky, and that I need to download them using OTX Companion. But how? I see nothing in Companion relating to lua scripts.
But the STK should work (it's worked for me in the past), so any other suggestions what I might be doing wrong, please?
I've got a new S8R receiver in which I've installed the just-released v.2.1.0 ACCST LBT firmware. I've had no problem binding it to my Taranis X9D+2019 trannie, but I'm struggling to set it up using the STK and the FrSky configuration app. Actually, what I'm unable to do is to 'Write' my settings at the end of the process. The app goes into 'Write' mode, but stays there, with the red message "Tip: Writing configuration" and the red light blinking on the S8R, until I get fed up and pull the plug -- after about 15 minutes.
I've checked the 'Read' function, and it works as it should, with the red message turning to a green 'complete' message after about 30 seconds. But that confirms that the settings are still factory default, with my new configuration not saved.
I've set up a couple of these receivers when I started using them about two years ago, but can't remember what, if anything, I did different from now. I've read the FrSky manual a few times, and still can't identify any error on my part.
Any ideas please?
|Thread: 1/24 scale modern RAF pilot bust|
Thanks guys. I did look at realmodelpilots, but they do nothing smaller than 1/16 scale for any that I checked out.
I do have a clubmate with a 3D printer, so that looks like a promising route.
I need a couple of pilot busts to go in my 1/24 (approx) scale Vulcan. I've spent quite a while hunting around the internet, and can only find WWI or WW2 models. Any ideas please?
|Thread: Updated my Taranis to 2.1.0|
I'm still persevering with v.2 firmware, and I've come across a couple of minor issues.
First was an X8R in my flybarred TRex 500 heli. After updating the firmware to v.2.1.0 LBT ACCST without any problem, I then copied the OTX file that the heli had been running with for a couple of years, across to my v.2 Taranis X9D+ 2019 transmitter. Everything seemed to work, except I had no collective so couldn't take off. Checking the OTX file I saw that collective was assigned to ch9 (don't know why, but it worked with v.1 firmware!). Since it's only an 8-channel receiver, I reprogrammed collective to ch8, and all is well.
I would have thought nothing more of it if it wasn't for the fact that I had a similar ch8/ch9 issue after converting my RXSR-FC to v.2.1.0 LBT ACCST. It's in a quadcopter running with iNav, and this time one of the modes was assigned to ch9, which should have worked because with SBUS connection to the FC it's a 16-channel receiver (isn't it?), but once again I had to reprogramme that mode to ch8 to make it work. I had already updated and flown another RXSR-FC equipped quad, but the issue hadn't come up with that one because it didn't use ch9 for anything.
My X8R is specified as 8 channels in the OTX setup screen, which begs the question why ch9 worked in the past; but my RXSR-FC is specified as 9 channels. Both the setups are the same in my v.2 transmitter as they were with v.1.
Not a big issue because things are working now, and the fault is probably mine somewhere. But I'd be interested in your thoughts about it.
|Thread: Horus rate switches ignored|
What firmware are you using, and how have you programmed your rate switches?
Want the latest issue of RCM&E? Use our magazine locator link to find your nearest stockist!