Advanced Search

Hi Team,

I'm looking for a config file for this 3 Channel FlySky Airplane from WLToys.

www.banggood.com/buy/wltoys-f959.html

I would appreciate any help.

Best Regards

Scav

No, the YD-829 is just a test version as there are still (hardware ?) issues with it.

I'll team up with Durete soon© to make more tests and hopefully fix it ...

Thomas.Heiss wrote: I once had opened a request thread to re-implement some of the cool features of the standard curve menus to the advanced mixer GUI but IMHO there was not that much interest (complex and time consuming topic).

As far as I know, none of the developers in the deviation team use the standard GUI. Which means the best person to work on it is probably you, at least if you have any programming experience at all. If you're interested but not sure about how to get started, just ask. Having a developer actually paying attention to the standard GUI would be a great thing!

I'm also curious as to whether you think my advice on avoiding the standard GUI for flybarless heli's is correct. I know it creates headaches for non-heli things (which was part of why I added the "multi" aircraft type), but I wasn't sure about if how useful it was for FBL helis. Nuts, if you want to propose improved language for the manual, I'd be more than happy to add that.

You can't. It is the latest revision of PhracturedBlue's old default/trunk repository: bitbucket.org/PhracturedBlue/deviation/commits/all

Download link changed for deviationTX team repository: www.deviationtx.com/downloads-new/category/13-nightly-builds

Hi mwm,

I always thought that shared repository was better for small teams.

At the moment i have here my repo bitbucket.org/lyndros/deviation-lyndros-bugfixing is a clone of the bitbucket.org/PhracturedBlue/deviation .

Is that still the official repo for developers?

Cheers

People are no longer doing direct commits to the team repository, except for PB. Even if we have a commit bit, we're generating pull requests from our clones.

So that's the approach to take now. Clone the team repository, create branches for your features, as working on the default branch will require a clone for each feature. Then add pull requests for them to the team repository.

BTW: What firmware version is on your Devo 10?
Have you had a test with DeviationTX nightly-build from downloads section (from new team repository)?
There have been some DSMx telemetry monitor improvements as well as.


Why don't you get a genuine Spektrum receiver with DataPort and use TM1100/TM1000 or Spektrum FlightLog box.

You can then use DSMx (or DSM2) protocol and do range tests on 100uw/300uw/1mw output power and test how far you get.

By checking
- FrameLosses (best 0, 10-20/30, >40)
- Hold (0)

numbers you will be able to really range test your HF module.

e.g Spektrum AR6210 up to ~62m distance on 1mw with
- Fades A/B or L < 80 / <40 (just an indicator on DSMx how each receiver antenna has best reception)
- FrameLosses <20-30
- Holds 0

There are some informations written down by Spektrum/HorizonHobby on TM1000 / FlightLog manuals.


Have you tried replacing your Devo 10 antenna yet?

Maybe the cable in the middle of the antenna is corrupted?
I had to replace on my Ex-DX8 the antenna multiple times.

Changing the Devo8s module (with telemetry) might be another option / try.

Thomas

what did you do to Devo to fix it? Should i brake it apart and check if some wires etc. are damaged? or try that control module as suggested?

I thought that the possible failure is the antenna, because there is stretch join , unlike in devo 7e where it is solid?

I have blamed copter bad-batteries,RX-modules, my phone in pocket while i`m steaming internet radio when flying---no logig.

and the time when copter loses control varies, 1-5 min.--Earlier copter started to go round anti clock wise..and eventually down....resently i flow toward of me and suddenly copter nose went down ...and crash....

couple months ago my dog dropped devo10 to floor, and flightswitch went broke, ,,afterward copter/TX worked same way, no change....then after few weeks i changed mix switch(that i dont feel to need at the quitxebeginning) to the flight switch place--ok---works ok----but maybe that control broblem is bigger , often than earlier....besides that TX dropping the TX has not experienced any damage at all in its history.


-Matti-

Yes, those changes should show up in the next nightly build. It has the hontai protocol, but not the baysang (there was no pull request for that).

To update your repository, do

As noted, you can add the line

to the paths section of .hg/hgrc in the top level directory, and then just do

to update your repository.

Doing a pull does not change your repository. You'll have to do an "hg update" in order to do that.

And...fixed

The answer was to update the firmware to the latest nightly
Format the drive
Put all the files on the drive
Overwrite the models and model icons and the hardware and tx ini files with my old ones
Reboot the TX and bingo bongo - one happy HCP80 V2 now able to toggle 3D and stable as a stable thing mode
Have tried the rest of the "fleet" and they all seem happy
Massive thanks to the Deviation team for making my TX the best out there

One happy camper (and a set of chibbled dented props already! - switching to 3D mode is a BIG jump)
Attached is the ini I am currently using
The idle up and throttle and pitch curves possibly needs work and the battery countdown needs setting for your model

Regards
Rob

Two comments:

While things should merge cleanly, they don't always. Watch for warnings about conflicts. Or really strange compilation errors . The "hg resolve command" will fix this.

You can edit .hg/hgrc in the top directory of your clone, and add things like:


You can then use the names "team" and "hexfet" instead of the full URLs in pull requests for those repos. I typically never pull from my bitbucket repo any more, but instead pull from team and push to it.

I found a schematic of the XN297 that might help.



It appears to me that pins 2, 3 and 4 correspond to CSN, SCK (clock), and MOSI; these should give you a good capture once you determine a ground pin. I can't tell from the photos where the 1st or 5th pin from the processor is connected, but that the processor's CE and MISO; they might not be needed to get a capture. I'm not entirely sure you've got ground and 3.3 right..the red wire to pin 5 would suggest there is Vcc on that pin? Where does that red wire go?

Here is a good example of what the team did with the CX-10 Green board. The chip pins are the same and you might be able to follow the process there. On that one the MISO wasn't connected, and it looks like just capturing CSN, SCK and MOSI got what was needed.
CX-10 Captures

Edit: found a photo with the red wire connected to the shield, which probably means that pin 5 is ground. So yea, connect 2, 3, 4 and 5 to your analyzer and let 's see the results!

Wonderful progress and team work. Great ideas.

I've got a smattering of experience in a large collection of pursuits, expert in none. Much to assimilate here. Pardon me if I mis-comprehend.

Using a multiplexer between the transceivers and antenna doesn't feel right. I've seen better solutions in the distant past, but sadly can't recall them in detail. The single package of the multiplexer is handy, but costly of performance, I think. Especially if only one transceiver is meant to be enabled at a time.

Also, adding a microprocessor to a project is a game changer. Wonderful in many ways, though not so in others. Designers often overlook the power of the processor and create potential harmful error conditions. The processor should not be able to bring harm to itself, surrounding circuitry or others through bad programming or random crash conditions. These possibilities should be surveyed at various stages of design and prototyping. Scrutinize all inputs and outputs and consider worst-case scenarios.

Allowing a processor to selectively enable and disable a bank of transceivers is handy and powerful. Allowing it to enable all simultaneously, if that is not intended, is probably a bad idea. It's easy enough to provide additional circuitry to prevent it. If you only intend to build one unit such may be excusable. Probably not if you're planning to build dozens.

Microprocessor design requires additional responsibility.

I was given a DAK bread machine as a gift, years ago. It would mix, knead, and cook loaves of bread from start to finish. Come back when it's done. Mine was the first version. Happened by the kitchen in the middle of the baking phase one time -- the whole unit was glowing bright red. Plastic parts were sagging. The heater was on runaway. The processor had crashed, perhaps due to heat. And it was in sole control of the heating element. Needless to say, the next version built in a discrete safety override. Certainly not of the same scale and impact as an r/c transmitter, but an important lesson many should learn.

Please be careful.

Thomas.Heiss wrote: There are at least 2 current FRSky / CC2500 threads.
There are >=2 pull requests in deviationtx team repository for frsky telemetry optimizations for the offical nightly-build.

For the record, three of the four FrSky telemetry pull requests deal with display issues: there are telemetry values whose names are blanks in the spinboxes, the sensor hub (which is considered obsolete and no longer sold by FrSky) voltage readout is wrong, and there's a question about whether we want to use RSSI values or the thing that's currently there), and the fourth is a bind issue that only affects some users.

CPPM (Combined PPM) combines a multiple PPM signals into a single serial line. Open standard, very popular on multi-rotor FC boards. SBUS is a similar system from futaba. I don't know if it's open or has been reverse engineered, but you also see it on FC boards. OrangeRx's newest line of Rx's - the #20X version - come in both CPPM and SBUS versions. You can also get Rx's from FrSky that support one or the other of those.

Thomas.Heiss wrote: DSmx SAT only = no Spektrum FlightLog
Do you really need PPM?
Spektrum AR6210 including SAT (supports FlightLog) is a good receiver.

There are at least 2 current FRSky / CC2500 threads.
There are >=2 pull requests in deviationtx team repository for frsky telemetry optimizations for the offical nightly-build.

Well,....... thanks for that Thomas, my mind just turned to jelly...haha. Will search out that info. and try to make some sense of it.

Do i need PPM? Buggered if i know...i am too new to know much of anything on the programming side of things....mechanical stuff fine, but i tend to stuff up big time when i try to do 'new to me' stuff on computers and don't understand the language (>+50 & approaching dinosaur status)....techy stuff makes my head hurt.

Thanks for reaching out though, it is very appreciated.

BH

DSmx SAT only = no Spektrum FlightLog
Do you really need PPM?
Spektrum AR6210 including SAT (supports FlightLog) is a good receiver.

There are at least 2 current FRSky / CC2500 threads.
There are >=2 pull requests in deviationtx team repository for frsky telemetry optimizations for the offical nightly-build.

The latest nightly builds (from download section or on deviationTX team repository) will normally not remove something which is in your V4.01-92e1705 nightly version.
Sorry, I do know nothing about "layout". May updates / news on Devo7 custom build thread?
Switches mod is supported on nightly-builds in hardware.ini as I heard it (I do not use them on Devo10).

However I believe there may be problem with the latest code not fitting anymore the Devo7E according to vlad's posting.
I do not understand it 100% if the repository checked in code fits for Devo7E, if the workaround code works to be uploaded or if it needs some more tweaking or what Devo7E features had to be disabled.
It is hard to follow all the different threads and partial news sometimes...

The deviationtx team nightly build should support 9999 values on all FlightLog values.

You probably mean those A, B, L, R, F, H?

See mantisbt and blade 200srx as well as 180cfx.

More details in Spektrum telemetry thread.

Maybe you could give some examples for as3x gain?

Hi,

yes that is known.

It is fixed in one of deviationtx team nightly-builds.

The branches / pull requests which fixed it had the name "scrollable".

Thomas

In the initialize function (file frsky2way_cc2500.c), when already binded, the state variable was initialized to FRSKY_STATE2 and counter variable was not initialized (should be to 0) where as if you start from FRSKY_BIND_DONE, the counter variable is well initialized.

I am now very happy as well with my 7E. Thank you very much to the deviation team.