Chris Bott - Moderator

I've had mine a year or two but do seem to remember having to get the microswitch lower than it would obviously go, before the nozzle would go near the bed.

Hi Erfolg You'll have to obtain a (or draw and generate your own) .STL file of an object. Then import it into a slicer program that's set up specifically for your printer. Here you can change dozens of print parameters such as nozzle temperature to suit the filament you're using. Often needing to experiment and tweak parameters to get a print you're happy with. Next, save the sliced object onto the SD card as a .gcode file. Place the SD card into the printer and print from there. To download ready made .STL files, have a look at thingiverse.com For slicing software I can heartily recommend prusaslicer for use with the ender 3 as it has a ready made "profile" for that printer. Download from https://www.prusa3d.com/prusaslicer/ For tutorials I'd suggest spending plenty of time on YouTube. Chris

Many thanks Mike. Its suddenly quite low on my priority list but this gives me something to look at when I get back to it.

I believe that an electric motor should be running for a failsafe test, certainly with some makes of radio, because one of the failsafe options is for the receiver to stop sending pulses on loss of signal. I have ESCs which, in this scenario, will carry on driving the motor at whatever speed they were running when pulses disappeared. So rather than identify which combinations of RX and ESC fall into this trap, it's much easier to test every setup. Restrain model, open the throttle a little then switch off the Tx. For me, only then do I have confidence that the complete setup will do as I expect.

On my Android phone I use an app called Lit Photo to shrink file sizes. I'm sure there are many alternatives too.

Lovely session last night. Such a shame that there was no Fury Maiden but it was the right decision. Here's a few seconds of video, turn up your sound. VID_20210423_185925.mp4

4S LiFeP04 sounds ideal for this application, Don. I've used 4S A123 flight packs to start small cars with flat batteries. Voltages are spot on. How about something like this, there are plenty of different makes/sizes show up from a quick web search. Self contained in a nice case and designed to be charged from a car battery charger etc. This is just a random example:- https://www.tayna.co.uk/jump-packs/noco/noco-gb20/

Haha, spookily my first one is in a WotsWot and I've had the bottom wing off numerous times in the last couple of days. Mainly due to telemetry issues but the last time 'cos I hadn't mounted the stab firmly enough ?.

Beware that the Archer/ACCESS stabilisers appear to have a very slightly different self check procedure. Handbook(leaflet) says, for this step, "Different from the SXR/R9 Stab OTA/RB series". So is this different? For these, self check is still initiated with a few switches of Ch12. Stab goes into 8-9 seconds of checking it's attitude and centres, servos won't move during this period but you shouldn't move the sticks Blue LED stays steady ON. Then there's a similar period with Blue LED flashing where you need to hit the gimbal extremes on highest rates for A,E &R. Finally the surfaces do the waggle dance to signify self check complete. PS It's not ideal if you can't see the blue LED, which is likely in the majority of models. You just have to guess the timings.

Thanks Bob. I have an FrSky S.Port 150A current sensor plugged in and that was discovered straight away. So the S.Port on the Rx is working fine. It's just the homebrew ones that are an issue at present. Prob best if I ask on their own forum.

Resurrecting an old thread, I have a question for other sensor builders and an update on the openXsensor software. 1). Has anyone has success with any openXsensor based telemetry with FrSky Archer / Access receivers? I'm really struggling with one unit working (but sometimes not) and 4 others that don't work at all. 2). I've downloaded the latest version of openXsensor, to find that it now includes a 'configurator' program that really simplifies the setting up. If you're still interested then this looks well worth investigating.

Looking good Bob. I'm sure those issues are simply 'cos it's way days. I'm having a play with Access protocol on my X12 and today found that my home brew (openXsensor) telemetry sensors don't work with the Access Rx I've bought. Well one does and 4 others don't, go-figure. Let's not take this thread away from Ethos though. I'll post my issue in another thread.

Peter you could follow John's useful link to the classifieds section. Or to help find your way around, click the word "Home" top left. This will take you to the main index of the site, very much like the old one. In the main index you'll find all the forum sections, starting with:- USING THIS FORUM MAIN TOPICS GOING PLACES MARKETPLACE Marketplace has sections called FOR SALE WANTED

I absolutely agree and was as disappointed as you when no extra telemetry appeared from the redundancy Rx.

Matty, to answer your question, I have tried connecting S.Port connections of both Rxs together. This didn't bring up any redundancy Rx data, even with a new 'Discover new sensors' attempt.

Using Access, I tested that the redundancy Rx was providing redundancy by creating an original model with main and redundancy Rxs bound. Then a copy of the model and then binding only the redundancy Rx in the copy model. Starting with the original model selected and green LEDs on both Rxs, switching to the copy model made the main Rx go red while redundancy Rx stayed green. At this point the servos still responded fine unless the S.Bus redundancy line was disconnected. The Tx was still reporting RSSI, RxBt and VFR. I can only assume that these were now from the only bound Rx, the redundancy one. The (single Rx at a time) telemetry had switched to the redundancy Rx.

Another question. Do I need to be particularly bothered by software versions? I can't imagine different versions will affect using a S.Bus signal for redundancy. But might be worth keeping up to date if leaving telemetry on from both receivers? I see that only telemetry from the 'in use' Rx gets through. So I'm intending to connect on board sensors, only to the main Rx. That way I get an obvious warning if the redundancy Rx gets used. Is that a sensible way to go?

Thanks both, that's really useful information. I do wish FrSky would produce instructions that actually helped. Reg ID:- So if I had more than one Access Tx, I assume I could make the Reg ID the same on both or all of them and I'd only need to register a Rx to one of them for it to be registered with all?

I'm just dipping my toe into the ACCESS protocol. Does anyone know of any decent documentation? I have everything I have - working fine. I'm just wondering the significance of the registration fields "Reg ID" and "UID" on top of Rx number. Also, I've set up a Pro Rx with a signal redundancy input on "S.Port In". Again, working fine, and I found a protracted way to test redundancy, but is there a way to get some indication of the redundancy signal by telemetry?

I think it depends entirely how the input circuitry of the servo or retract unit detects the pulse width of the signal. A digital circuit is likely to detect the start of a pulse and count time intervals until the end of it. It's unlikely to matter how fast the pulses turn up one after another. An analog circuit though, could be very different. I'm imagining a simplistic resistor feeding a capacitor. The capacitor charges for the duration of the pulse. The longer the pulse, the higher the voltage goes. Then that voltage is used to position the servo. In between pulses the capacitor is discharged and it might expect 16 mS to do so before the cycle starts again. If a new pulse comes along after only 9mS, everything is upset. It's very probably nothing like this in reality, but you can see how a signal that isn't what the unit was designed for, might mean the circuit doesn't perform as expected.

The FrSky 4 channel S.Bus decoder follows the frame rate of the S.Bus signal and we have no control over that at all. It's always 9mS I think. I have had an analog servo burn out in flight when using one. As luck would have it, it was an aileron and it stuck near neutral. Servo was way too hot to touch after landing. That was after a good number of flights where I'd obviously thought everything was OK. There's a good discussion about different decoders and frame rates here (and earlier pages in that thread). There are a good few different ones that will drive analog servos safely.

Brilliant, thanks for the reply.

A quick question about retracts if you don't mind me popping into this thread? I have one of these kits squirreled away while I re-configure the workshop. I bought the motor with it but no retracts. I have some JP 90deg electric ones that look the perfect size. Will 90deg do the job or do I need something else?

Maurice go back to Ron's first post in this thread and keep reading. ?

A nice padded envelope just turned up with my 10m in. Many thanks again Ron for all your efforts. At first glance it seems finer (lighter which is good) than expected. Can you remind us of the specs of this one so we know what we have?