Jump to content

Mike Blandford

Members
  • Posts

    793
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Mike Blandford

  1. How is your Tx antenna oriented? If it points almost straight at the 'plane, then it is having the minimum possible signal being sent. From some testing that was done on the universal ACCST firmware for FrSky receivers, a VFR of 60% is considered a low level, anything above that indicates a good performance. Control was, however, maintained even at a VFR of 10% ! Mike
  2. Don't plug the Rx in until the updater screen is showing "finding receiver". The Rx only looks for an update for a very short time after it is powered on. Another way is to only connect ground and signal from the Rx to the STK, then power the Rx from a battery, get to the "finding receiver" stage, then connect the battery to the Rx. Mike
  3. I'd use the sub-trim setting to set the middle position, then the min and max to set the endpoints. Mike
  4. A "Universal" ACCST firmware is available for some FrSky receivers, see here: Universal ACCST Firmware Mike
  5. It says it is a BLheli ESC with Dshot. If it is BLheli, then it is fully programmable with many settable parameters (the same as FrSky Neuron ESCs), but you need the BLheli app to run on your computer to set it up, and a special connection to "talk" to it. As it has Dshot, it may not support normal PWM input, Dshot is, I understand, a high speed method of sending the throttle information to the ESC. Mike
  6. I've only just received my BMFA news and haven't read the article fully. Many transmitters are now storing radio and model data on a SD card. Since many 'phones allow a SD card to be used in them, I would be very surprised if using a 'phone near a Tx would corrupt the SD card contents. I would think the 'phone would corrupt its own SD card if that was likely to happen! Mike
  7. I haven't got the internal module available yet, only external modules. Currently supported are XJT-lite, MPM-lite and crossfire/ELRS (yes to the IRX one). The way the dualboot works is to power up into the last used OS unless you hold the RTN button pressed at power on when it swaps to the "other" OS. Instructions are here: https://openrcforums.com/forum/viewtopic.php?f=7&t=13679 Mike
  8. Potentially, the MPM (Multi-Protocol Module) will be supported by ETHOS at some in the future. However, NOW, you may include erskyTx on the X20 and get MPM support. I have arranged this so you have a dual-boot system, choosing between ETHOS and erskyTx. I don't have a X18 at present so this is only on the X20. With these radios you should not need to look at the screen while flying, just set up voice output. Mike
  9. Mike Blandford

    Taranis X9D+

    The Taranis (and plus) has a "soft power switch" that keeps power on after you switch off to make sure the EEPROM is completely written. What is happening is power is getting to the processor so it starts up, then detects the power switch is off, so just turns the soft power off. If you turn the power switch on, does the Tx operate normally? My guess is the resistor that holds the soft power switch off is not connecting to ground. This would allow leakage current to turn the power switch on. The processor would then start up and turn the power switch off, but would only hold it off while the processor was receiving some power. According to the schematic (rev 0.2 main board) I have, the resistor is R53 (100K), and pulls he gate of Q2 to 0V. As a first step, perhaps inspect the soldering of that resistor. Warning: The X9D+ has two, flat ribbon cables that connect to the main board. One of these includes full battery voltage. If, for any reason you need to disconnect these, unplug the battery. It is possible, while plugging these cables back in to connect full battery voltage to the processor, which will destroy the processor. This happened to me on a prototype X9D+. I replaced the processor and it then worked again. Mike
  10. This is for testing the dual receiver setup only. When the Tx is using the receiver number of the main Rx, that Rx provides the servo control. When the Tx uses the receiver number of the "backup" Rx, the main Rx loses signal and so should use the SBUS data from the "backup" Rx and still provide servo control. This tests that both receivers are working and the main receiver is getting the SBUS signal from the "backup" receiver. For flying, you would bind both receivers using the same receiver number, with the "backup" receiver bound with no telemetry. Mike
  11. There is a point of view that if the shaft needs to be cut off then you are mounting the motor the wrong way round! If you mount the motor with the fixed part on the firewall so the whole of the motor, prop and spinner are in front, then any imbalance in the prop and spinner will cause large forces where the motor is mounted to the firewall. I had trouble with a long motor (a 2832) mounted this way in my WOT4. No matter how well I tried to get the prop/spinner balanced I had significant vibration at high throttle. The solution was to build a ply box so the motor mounted with the fixed part forwards, so the motor body was behind the firewall and the prop/spinner were in front. This then means all the rotating parts are much closer to the mounting, and in my case completely cured the vibration problem. Mike
  12. I have a model based on Wolfgang Matt's Superstar that I built and flew before 1982 with a HP61 for power. It is now electric powered and I still fly it. I have a "Unique Models" spitfire that I built in 1974. I never managed to fly it then I was trying to do it electric but an Astro Flight 25 (Ferrite) with 16 NiCd cells was too heavy. I have now flown it with a brushless/lipo setup. As I didn't like the foam wings with a straight leading edge (it just didn't look right), it now has a correct shape, built up wing, but the fuselage and tail is original. My WOT4 pre-dates 1997, first flown with an OS40 4-stroke (when I returned to model flying after a break), it is now electric and is still flown. I also have a scratch built model of 52" span, based on the Superstar design, that is regularly flown, I have pictures dated 2002 of that, and a scratch built electric glider, also with pictures dated 2002, that is airworthy, although I haven't flown it for a couple of years. Also an even smaller Superstar based scratch built model dated 2005. I had to build that one to replace a similar model that suffered a mid-air with a Laser powered Corsair. The collision was almost head on and the Laser just chopped my model up until the prop hit the NiCd power pack. Curiously the current model also suffered a mid-air, although this time it only lost half a wing panel and I managed to repair it. Mike
  13. If you have two transmitters, bind each Rx to a different Tx, then if you turn the Tx bound to the RX8R off, the other Tx should then provide the control. If only one Tx available, bind the two receivers using different receiver numbers. If you then swap the receiver number on the Tx between the two, you should see one Rx lose signal and the other gain signal, but keep control of the servos. I believe the RX8R will use the data from the SBUS in if it misses a small number of packets (sent every 9mS), it may do so if only a single packet is lost. Given only 8 channels are sent in a single packet, and SBUS passes all 16 channels, it probably waits for a couple of packets to be missed. Mike
  14. Even with a steerable tailwheel my BH mosquito was difficult to steer while taxiing (with larger wheels than in the kit as well). Because there is little airflow over the rudder, it isn't in the prop wash of either motor, I use separate channels for the two motors and have asymmetric thrust configured, enabled by a switch, so that while taxiing moving the rudder channel causes the motor on the inside of the required turn to slow down. Now it is very easy to turn on the ground. Mike
  15. From things I've read, CH12 has to change much quicker than over 2 seconds, and CH3 (throttle) must be at -100%. Mike
  16. What do you need help with for updating your D8 receivers? If I can improve the instructions I will do so. Mike
  17. I've been using FrSky modules, radios and receivers for over 10 years, and all have been reliable, so I'm not sure why you don't trust them. My main Tx I use for flying is a Taranis X9D+. I've been using that for over 7 years and still working fine. Some 'planes are using D8 receivers that are quite a bit older than that. I have about 11 FrSky transmitters (I do firmware development for them and get sent them!). All are working. I would still recommend FrSky, particularly if bought from the UK FrSky dealer (T9HobbySport), as you get the full dealer backup if there are any problems (all radios might have a problem whatever the make). Telemetry sensors are relatively low cost, if required, and are easy to connect. While the RM TX16S uses the multi-protocol module, such modules are available for FrSky radios (even for the X20 if you add erskyTx as a "dual boot" alternative to ETHOS). One important thing about the multi-protocol module (MPM) is there is no manufacturer control of the "unique Identifier" for the Tx. This means more than one MPM could be using the same ID, and any ID used could also clash with the original manufacturer of any protocol being used (except Spektrum as that uses an ID from the RF chip). From my experience with the MPM (I have 7 I think), the output power when using the CC2500 RF chip (used by FrSky amongst others) is lower than original manufacturers. Mike
  18. It seems that something changed between my X20 (pre-production I believe) and current production ones (possibly in the bootloader). This means erskyTx didn't work on all X20 radios. I've found the problem and fixed it so there is a new "r3" version posted here: https://openrcforums.com/forum/viewt...hp?f=7&t=13679. It is still a "work in progress", but support is in for external modules XJT-lite and MPM. This version also has some limited touch screen functionality (information for this on the above post). Because of the "Dual boot" capability, you may easily add this, but still use Ethos as before. Mike
  19. The multi-protocol module can "map" your radio channels to other channels for transmission. This is done so you may use a "standard" channel order for your models, but then match specific requirements for different protocols. DSM, for example, does use TAER I believe. If you use something different (say AETR), then the MPM may be set to change the channel mapping when DSM is selected as the protocol. There is also a control bit that may be set in the data sent to the MPM that enables/disables this channel mapping. I don't know how openTx controls this bit. This function may well have been added since the version you had and the update, and be defaulting to allowing channel mapping (it is a "disable" mapping function so a default of 0 would allow mapping). Mike
  20. I've had a report that erskyTx "doesn't work" on a X20S, unfortunately without any further detail. I only have a X20, is there anyone who could test on a X20S and report what "doesn't work"? Mike
  21. Unfortunately no. As openTx has moved through updates, it has changed the structure of the model data. So trying to maintain a conversion to erskyTx hasn't been practical. Mike
  22. If anyone wants to try it, I've posted an initial version of erskyTx for the X20 here: erskyTx for X20. Lots still to do, but it is functional using the external module bay including support for the multiprotocol module. What is neat, I think, is you may install erskyTx alongside Ethos as a "dual boot" system, so you may continue to use Ethos, but switch to erskyTx to use the multiprotocol module. FrSky are OK with me doing this as long as I don't publish the parts of the source code that would reveal the hardware design, which is fair enough. I haven't had any technical data on the X20, so things take a while to work out. I'm doing this by reading a disassembly listing of Ethos to work out the connections. I've just found out how to access the touch screen hardware, but adding touch processing may take a while. Mike
  23. As I understand it: 1. You use electrical energy from a renewable source (wind, tide solar, as mentioned in the article). 2. This energy is then used to extract CO2 from the atmosphere and combine it with water to produce a hydro-carbon fuel, releasing Oxygen to the atmosphere. 3. This fuel is then burnt in an engine, combining with the Oxygen released in (2) to produce CO2 and water. Result: The renewable energy used in (2) was converted to fuel, then mechanical energy in the engine. The water and CO2 used in (2) ends up being released in (3). It is a "closed loop", the amount of CO2 remains unchanged, so this is referred to as "carbon neutral". Mike
  24. For general information, this thread may be of interest: https://forum.alofthobbies.com/index.php?threads/universal-accst-firmware-is-coming.2252/ T9 are one of the Dealers included. With this firmware, you can forget about "is the Tx V1 or V2"? It just binds while also offering some extra features (like dual bind). Mike
  25. The example I posted is for erskyTx (not openTx). For erskyTx, there is also a PC program (called eepskye) that may also help when looking at erskyTx (companion was forked from this). Both eepskye and erskyTx are available at http://www.er9x.com/ Mike
×
×
  • Create New...