Here is a list of all the postings Mike Blandford has made in our forums. Click on a thread name to jump to the thread.
|Thread: Who wants a Warbird Replics Hurricane?|
Interesting, I wonder what the mechanical explanation is! Normally, I would expect the motor to speed up as the 'plane gathers speed. Since I'm looking to use 6S, my motor should be rotating quite a bit faster than yours already!
The prop washer on mine is already hatched.
I'll check to what I have the timing set anyway.
I did some power tests today. The motor I'm using is an E-max GT 4020/07, KV=620. My plan is to use 6 cells, although at that KV value, 5 may be better to give a larger prop.
I hadn't got an RPM sensor hooked up, but I'd estimate test 1 at around 11000RPM. As I was using a 4-cell and a 2-cell in series (3000mAh), I didn't have a full voltage reading either, although the 4-cell (quite old) showed between 14.6 and 14 V.
I'm tempted with the 11x7 and 800W at the moment, although a 12x6 may look better.
|Thread: C rating on Lipo's|
60% of 44Amps is 26.4Amps
|Thread: Does your club prohibit the use of after-market receivers?|
I would question whether this actually achieves the objective. I would assume the club would allow the use of an Orange Tx module with an Orange receiver. However, some of the Orange modules had a fault in their firmware, I found the fault and reported it to the firmware writer. For the Orange modules I have, I re-flashed them with the multiprotocol firmware that had the fault fixed. So, as far as it looks, I would be using an Orange module and receiver!
As it happens, I normally only use FrSky, but I have used other modules and receivers when testing them.
Another possibility could be someone has several DSM2 receivers which match the make of the Tx, but some DSMX receivers that don't. I would suggest the DSMX receivers may well perform better, particularly on a crowded flight line.
I would also wonder what that club thinks of open source Tx firmware. Personally, I'm much happier using that as I know what is in it!
|Thread: FrSky Taranis X9D Plus|
Do you mean a newer model of the X9D (or X9Dplus)?
They clearly have a range of transmitters (Xlite, X7, X9d/+, X9E, X10/X12) to suit a range of budgets and requirements. They are always working to improve performance and cost effectiveness.
I'm not aware of any replacement Tx likely to be available soon. I am aware of some of their developments (but under a NDA I can't say anything specific). By replacement I mean an updated X9D. Over time the X9D/+ has been improved internally to make it easier to produce, and may undergo further improvements, but will still be a X9D/+.
I assume you have considered the range available and have selected the X9D/+ as the most suitable for you, based on cost and features.
I actually use a X9D+ as my main transmitter.
Edited By Mike Blandford on 16/03/2019 23:20:19
|Thread: Seagull 80" DH Chipmunk|
There is a lot of information on the openXsensor here: **LINK**.
If you want something "simple" to start with, you could look at **LINK**.
I did this to replace the X8R2Analog device I designed that was available from T9Hobbysport (and Aloft in the US), but has recently been discontinued. Note it uses a 3.3V, 8MHz Arduino Pro Mini.
|Thread: Turnigy 9X range issues?|
Yes you may have both modules active, but when binding it is advisable to only have the one module operating to avoid it being "swamped" by the other module.
As I understand it, there is a known problem with the Orange module and some BNF models where the throttle never works. I don't have any BNF models so I can't test that myself, and anyway, all my Orange modules have been re-flashed to use the Multiprotocol firmware!
Did the Orange module have a flashing LED before and now doesn't?
Which module do you have internal and which external?
When binding, modules usually transmit at a very low power level, having another module powered at the same time could interfere with the bind operation.
LBT is ONE way of conforming to the regulations, but not the only way.
I believe you may still sell non-conforming equipment as long as it was placed in stock before the regulations came into force.
I'm unclear whether the 'D' protocol does conform to the regulations, without measurements of the duration and power of transmissions we cannot be sure if they meet the 10% media utilisation factor or not. Given the DFT, DJT and DHT modules are still for sale, either they should either meet the regulations or they are "old" stock. 'D' receivers should be legal as they only transmit for part of 9mS every 36mS and at, I believe, only 60mW, so meet the 10% MUF.
Even with the LBT firmware in a XJT module, the module supports 'D' protocol. You may need to update the firmware on the radio to allow the 'D' protocol to be selected. An external XJT module (JR type), has switches on the back that enable switching to 'D' protocol.
With FrSky, a data packet is sent every 9mS, so 111 times per second. With LBT, the Tx listens to see if the channel is "free". If it is it transmits. If not, then it doesn't. Probably, this has no significant effect compared with transmitting regardless as, if the channel is already in use, anything transmitted probably gets corrupted by whatever is already transmitting, so is lost anyway (and probably corrupts whatever is already transmitting!).
It is not illegal to use non-LBT equipment if it was purchased before the regulations came into effect, or was imported before then.
The DFT (and DJT/DHT) pre-date the LBT regulations and don't support LBT anyway. If the DFT module is available for purchase, it may well have been imported a long time ago.
This older type module and transmission (FrSky 'D' and 'V'" is becoming obsolete.
I note that the DFT module costs £23.40 from T9. You might consider purchasing the FrSky QX7 ('only' £103.40 from T9). This includes an internal XJT module, that fully supports LBT.
|Thread: S6R receivers|
I've just put my 'scope onto the outputs of a S8R and can confirm there are no pulses output at power on (except for a single, very short pulse of about 15uS) until the Tx signal is being received.
Not seen that before! Please confirm you are only turning off quick mode, rather than disabling stabilisation altogether.
My S6R is in a model, so I'm testing with a S8R, but that works fine.
Sounds like you haven't run the "Self Check" and set the servo limits in the receiver. You need to run the self check for the receiver to "learn" straight and level, then you move the aileron, elevator and rudder controls to their limits (don't have dual rates enabled) to "teach" the receiver the servo movement limits to avoid it over driving the servos.
Do you have the full manual? It is available here: **LINK**.
My logic says auto-level mode will be fine. The Rx uses accelerometers to detect when the model is not in the level position defined in the self check. It will apply a correction, to the current servo positions, to try to bring the model level. If you have trim applied to get the model level, then the Rx has nothing to do!
|Thread: One receiver different models|
If using ersky9x or openTx firmware, with FrSky 'X' receivers, when using "custom" failsafe settings, the settings are held in the Tx and sent to the Rx regularly, so even these are not in the Rx.
As far as plugging and unplugging connectors is concerned, it will depend on how much gold plating is on them, but typical ratings are between 100 and 600 cycles.
|Thread: Who wants a Warbird Replics Hurricane?|
It's been in the paint shop!
Insignia are hand painted!
At the moment the canopy is just placed in position.
Edited By Mike Blandford on 11/02/2019 18:50:46
|Thread: PIC Programmer|
I'd suggest going the Arduino route to start with. By getting an Arduino Nano, all you need to get started is the Arduino IDE (free download as mentioned) and a USB cable to be able to flash the program (called a sketch for Arduino).
I have used both PIC and Arduino and I think you will get started quicker using the Arduino.
While Phil is correct that assembler is more efficient for real time applications, I find the GNU C compiler (used by the Arduino IDE = "Integrated Development Environment" compiles the code and approaches pure assembler. The Atmel AVR processor (used on Arduinos) also executes code "faster". For the same clock, many PICs use 4 clock cycles for one instruction while the Atmel AVR processor only uses 1 clock cycle for most instructions.
John: Being a bit pedantic here, but assembly language is "assembled" while higher level languages (e.g. C, C++, Pascal etc) are compiled.
|Thread: Arduino project - Servo Exerciser - RCM&E Dec 2018|
Just using a 8-pin chip is not really good enough for real control functions, although fine for exerciser functions. The reason is the 8-pin device is using an internal clock generator that is not accurate enough to give reliable results as the temperature and voltage changes. You need a clock controlled by a crystal (or resonator).
When I wrote the code, I assumed you would want either the slow function of the reverse function. In each case, sub-trim is easily handled on the Tx. I have, however, added the option to reverse the slow output!
I would not recommend using an analog input, I assume controlled by a pre-set pot, to adjust the sub-trim, particularly on an IC powered model.
You could adjust the centre position of the reversed output in the code. The reversing operation is done by taking the input pulse, subtracting 1500uS, changing the sign then adding the 1500uS back on. This is actually done by just subtracting the input pulse width from 3000uS, you get the same answer.
To adjust the centre position, just add an offset to this calculation:
where offset is in uS.
It must be later already!
Github updated with a switch output on IO2 (also on the LED output to help see it operating).
There are some defines near the top of the sketch where you define the switching point and the switching level. I've also allowed for some hysteresis to prevent the switch output "jittering".
I haven't updated the wiring picture (yet).
Only one of the outputs is slowed at present.
Edited By Mike Blandford on 02/02/2019 22:32:03
Code and a picture showing the connections are now on Github here: **LINK**
I've now tested this on both a 5V, 16MHz Pro Mini and a 3.3V, 8MHz Pro Mini. A hardware timer is used for input capture and both outputs, so there should be no jitter.
No doubt we could add some enhancements later.
Edited By Mike Blandford on 02/02/2019 20:03:48
Want the latest issue of RCM&E? Use our magazine locator link to find your nearest stockist!