Advanced Search

Sorted, not sure what I was doing wrong, set to ch6 -100 and +100 (and verified in ch monitor) when toggle'd it does indeed flip

As a humble end user with little in the way of geek to add to the project I'd like to say a massive thanks to everyone on the teams efforts and hard work on this

You guys rock my world!
Regards
Rob

Late last night I also discovered that another of my nano quads (Flying Gadgets NanoQuad Xtra) binds and flys perfectly with the LS114 protocol
It's like Christmas and all Birthdays coming at once because now my Devo 7E flys/drives/sails all the toys I own

Cereal_Killer wrote: I don't mean this in an argumentative way, I am meaning it as sincere advice but I'm not in a very good mood today so consider that if my wording seems to be instigating, that's not my intention...

If you're having range problems the solution is not to try to solder on an extension yourself. Radio frequency (rf) is a huge field in and of itself, people who go to school for years to become a high level electrical engineer still choose to outsource RF related activities to an RF-specific engineer because it's just that in-depth and detailed and over most people's heads.
For example look at the company TBS (team black sheep), they're a huge company, they probably have several high-paid electrical engineers on their payroll that know quite a bit yet even still, they hire IBcrazy as an independent contractor because they understand that RF is just so finicky and so exacting in its tolerances.


Do your range testing with the module as it came with the SMA connector right on the board, if you modify the RF side of it first and then do a range test and the range test is poor or totally fails you'll have no idea if it was a bad module to begin with or if it was your modifications.

Thanks for your input,

I think you may have misunderstoon my post, the extension was not to cure range problems, my range problems was due to the cheap board with no PA and built in antenna, which i recently found out that out in the open, bare circuit board with no case actually has a real world range of 80m at best. cover it up and put it in a case and it goes right downhill.

The extension was simply if i could not mount the module by just having its connector attached to the board through the hole in the case, which it turns out its small enough you can do that, and the extension i have coming is an SMA 30cm extension, it has ends on it to screw it it, so it could could have also been posible to just screw the extension on and leave the connector soldered to the boeard.

Removing the connector was worst case scenario, and it would have been with That cable, which has the shield connected to the board.

Anyway its working great

I don't mean this in an argumentative way, I am meaning it as sincere advice but I'm not in a very good mood today so consider that if my wording seems to be instigating, that's not my intention...

If you're having range problems the solution is not to try to solder on an extension yourself. Radio frequency (rf) is a huge field in and of itself, people who go to school for years to become a high level electrical engineer still choose to outsource RF related activities to an RF-specific engineer because it's just that in-depth and detailed and over most people's heads.
For example look at the company TBS (team black sheep), they're a huge company, they probably have several high-paid electrical engineers on their payroll that know quite a bit yet even still, they hire IBcrazy as an independent contractor because they understand that RF is just so finicky and so exacting in its tolerances.


Do your range testing with the module as it came with the SMA connector right on the board, if you modify the RF side of it first and then do a range test and the range test is poor or totally fails you'll have no idea if it was a bad module to begin with or if it was your modifications.

Hi Kamil.

I am from Poland too. If you have any question please contact on PW message or login in heli-team.pl. We will help you with your heli and configuration.

Sorry, I don't know who is on the developing team and couldn't find this information on the website. Perhaps someone who knows can PM one of them.

You should PM someone from the developing team

In recent weeks, they have formed a FPV team. Released FPV Mini X racer more like the DIY hobbyist are building. As well as a host of components... motors, ESC and FC. I think they just want to ensure Spektrum link is done right so it's reliable. So by contributing code and making pull request to Cleanflight and BetaFlight, they ensure their stuff works well. Glad to see that happening.

I'm not sure if having the folders outwith the user profile will cause issues, as long as the user has r/w access it should be fine?

when cloning the repo at the begining did you clone your own branch or the team repo? also when checking out the at9 branch did it complete successfully? it would inform you that the head is now detached and is at commit 969e9d5 (as of just now) etc?

you can add remote repo's to track, like for me if i wanted to track your repo i would launch the container and drop to the shell, cd into the deviation directory and use

then if i want to build from one of your branches called for instance fdr-branch

then exit the shell, uncheck the update from git checkbox, select which images to build and build them. then if i wanted to go back to the original team branch i would use from the shell

there's a basic git cheat sheet available here >> www.git-tower.com/blog/git-cheat-sheet/

Hello,
Test Ver. 0da, Devo8s,d8r

VoltA : ok
Volt1 : ok
RSSI: ok

all other Data are looking wrong somehow .
Looks like they using some time a wrong Data from the Steam. It is better then the jumping build but something is wrong.
The Alt is now showing + and - Numbers but it looks not right , the Values are to low
the VSI is better and the Amp needs a long time to change.
I can see the updating at the boxes ( it does some blinking ) but some times it stops, and after the stop it updates to the right Number.

greetings Alex

Thank you for the advice, much as I dread it, since there is no installation manual for Linux dummies. Have used 4.0.1 up to now flying the dsmx stuff; since I am ditching it, I really need the NRF24L01. Now that there is a 3in1 rf module, there is no reason why we cannot buy DeviationTX preloaded radios with the module installed. Sorry for letting off steam. Thanks again.

I'm going to be really blunt here. Unless someone wants to step up and fix bugs, they aren't getting fixed. Sometimes that 'someone' is me, and sometimes its not. What 'should' happen and what there are resources to make actually happen are not the same. We don't have anyone paid to fix bugs here, and 'we' is a very small team of people who all do this on our free time. When you decide to choose Deviation, you are also taking that reality too.

We are basically ready to go on 5.0. There are probably one or 2 bugs I'll try to fix before the release, but I may not get there. One of the last things that is needed is a release note. We'll do them on the Wiki, and I put the framework here:
www.deviationtx.com/wiki/release_notes/5.0.0

If anyone wants to fill in the changes they know about, it will speed the process.

Richard96816 wrote: It's all such a tower of babble. I have things I'd like to try. But where do I find the information that tells me how to quickly set up the build environment? This is free software, but it doesn't quite act like it. I've built other packages from other projects and it was relatively quick and painless. Getting started with this one looks like it will take weeks.

It's hard to find, but then again, so is pretty much anything.

Click Links in the menu on the left. Click "Team repository". Read the contents of the README in the repository, which tells you how to set up a build environment. Which is the first place I look for that information on open source projects.

This is changing - we've got docker images now. But they aren't done yet, so not listed in the README.

I recently got around to swapping the stock 128k processor in the 7e to the 512k version. PhracturedBlue is recommending the 256K variant and the DeviationTX team has added devo7e-256 as a target in the official repository already but it won't show up in the nightlies yet. I'll be posting the tutorials up here.

For now the hardware part and list of things needed is ready. I'll add the bootloader flashing and building from source this weekend.

1. Upgrade the processor
2. Build environment and tools
3. Flashing the new chip with a bootloader
4. Building from source Deprecated with new Docker build container by PB

If more of us adopt this, it might make it's way to the nightlies... lol... *fingers crossed*

Test builds are available on the deviationtx site (Downloads -> Test Builds). There you'll find:

• [silpstream]Ultimate7e-v5.0.0: Test Builds - Build based on BRANCH_5.0.0 (Latest stable release with bug fix updates only).
• [HappyHarry]Ultimate7e Deviation5.0.0-xxxxxxxx - Build based on nightlies (Latest and greatest deviationtx features get tested here).

Extra switches thread: Ultimate7e tutorial: Four 3-way + two 2-way switch
Extra potentiometers thread: Ultimate7e tutorial: Four 3-way + two 2-way switch

I've taken everybody but me and PB off the bitbucket team repository. There are a couple of reasons for this, but the important one is that we don't want people committing to it thinking stuff will show up in the nightly builds.

First things, the three things I think the community - or at least developers - most desperately need.

1. A new release. The reason nightly builds are more stable than the old release is because we haven't made any major changes since trying to get a release together last year. Pretty much everything I'm looking at is liable to make things less stable. In the current state of the nightly/release system, that's not really acceptable.
2. Make the build logs for the nightly builds visible somewhere. Right now, if I push a change and don't see a build, I get no clues as to what failed.
3. Document the nightly build process. Even if I have the build, what I have to do to recreate the failure may not be clear.

As for documentation, I'm happy with the state of the manual. But that's more a reference manual. The issue is that users can't contribute tutorials or howto's or similar things in a way that they can be found from the web site. The current bitbucket wiki (PB's not the teams) has valuable thing on it and is editable by anyone with a bitbucket account, but the only thing that isn't many links away from the deviation site is the module installation guide. In theory, such stuff can be posted to the forum, but between thread drift, the poor search facility in this forum software (I see the same issues on other sites using it) and that they are only editable by the original poster, they're not really much better than a blog post.

I don't really want to abandon the 7E, but I also don't want to have to worry about keeping things fitting during the transition phase. I had two things planned that I think would make things fit, but the first change would almost certainly break the 7E build, and those wouldn't happen until later.

Providing a desktop editor for configuration and making the config files on the transmitter binary would shrink the binary. IIUC, PB has already done some work on a desktop tool to convert the existing config files to/from binary just to save space on the 7E. That isn't my reason - I want to rework the config system for a number of reasons, the desktop config tool is something that showed up in the survey, and this is a natural place to do that. The ability to do mobile/web based configuration is a target to aim for after that, and should be kept in mind when doing it, but not a driver for it - at least not yet.

Once there's desktop software that you're interacting with on a regular basis, then something like the OpenTx build system - which lets you pick a set of features and builds a binary for that - seems like a natural next step. That would mean we no longer have some "standard build" that we have to make fit on a 7E. We could add conditional features at will, and then end users could build and install the set they wanted with little more pain than they'd have in installing a downloaded version with the desktop software. Figuring out other things to make conditional would also be worthwhile - telemetry, for instance. There are things I suspect most 7E users don't need that could save us space, like MM support (already conditional) or even individual RF module support. The audio player code is already conditional in that branch. Eventually supporting end-user builds was one of the reasons I built those docker images. They run on windows, OSX and linux as is, and provide a complete build environment for everything currently distributed.

I just read Mike's blog post and I think he is putting the finger where it hurst, he's right on spot for every point, but one, and for that one PB is right, deviation shouldn't be forked the community will suffer from this and I fear that most likely both projects won't survive.

So the only real solution would be to make diversionTX the new deviationTX, rather than go reinvent the wheel elsewhere, just make it better here.

I agree that :

1.
We are past the "benevolent dictator" type of development in this project, others should, in particular the core developers team, be allowed to edit and change things around on all project related stuff (maybe it is already the case for some things dunno).

2.
Standard GUI has to go, look at how many people use OpenTX, Er9x and all those firmware flavors, if people want it people will learn it, don't cripple development with things from "last century".

3.
Development for crippled transmitters should be froze to it's actual state, if things like standard GUI should stay.

4.
Access to and documentation editing should be made easier, I really dislike (and maybe others) having to navigate (and loosing time) the bitbucket wiki, and having to rely on reading commits and searching for new stuff in thread scattered around the forum,. This isn't going to help anyone, when it comes to know what has changed or when new stuff is added to the firmware.

5.
Nightly builds should be renamed to something less intimidating, so new people would adopt them, instead of using 4.0.1 that is far less stable than latest nightlies

6.
A soft "à la" OpentTX/Er9x companion would be a must, this would resolve point five immediately, the nighlies would be just the next firmware release like they do, and that doesn't bother anyone from the beginning of those projects.


I know all of Mike's proposed changes will mean a lot of work, I'm no programmer (so can't help) and have very limited time (my wife's health condition takes a lot of my time), but I would be more involved if things would be easier to find and edit ,especially on the documentation field.

Adding new stuff without people being aware of it existence, or not knowing how to use it, is worthless and lets it confined to an elite class of users/developers.

So am I for the fork? No!

Make it better? Definitely!

And again a big thank you, to all of those, who give their free time to this project!

How long ago have you had contact with PB?

May be it make sense to have a release from team repo, the wait for PB is indeterminate.

BTW while I can't do a real release, I can make new download pages, and probably can add the files to (but I need to check that).
I don't know if the official releases are made from the team repository, or from PB's own...

"Rudderless" is all to accurate. Our rudder - PB, the creator of the software and general project lead - has been missing more often than not over the past two years. People were even saying that the project was abandoned until I created the deviationTx team repository and started getting the active developers to commit to it and builds from that. PB reappeared briefly over the summer, and I put all my development work on hold to get the outstanding major issues fixed and the manual updated, but he vanished again before creating a release.

Unfortunately, the release process is undocumented, and as far as I can tell, the only difference between a release and the nightly build is that the release version is stagnant and has the "release" label. As you say, this means that it gets more use, so more problems get discovered. But they don't get fixed in the release, they get fixed in the nightly - which is why the current nightly build is more stable than that antiquated release. That wasn't true before our efforts this summer, and it might stop being true if there is significant work committed to the nightly build - but that doesn't seem likely in the near future.

if I could, I'd delete that old, obsolete release from the download area as the simplest solution to the current problem. But I can't. That I can't is also why there won't be a release any time soon. Sure, I could cut one and do whatever testing I deemed appropriate and put it up for download - but since I can't put it in the release download list, what would be the point?

While you may prefer the waterfall model for software development, deviation is currently using an agile development model. Whether or not it's the right choice is certainly open to debate, but it's not really something we can change in the current situation. If that makes you want to abandon deviation, that's up to you. I've never had an issue with people who insist on Spektrum (or Futaba, or whatever) at both ends for reliability reason. I do find it a bit odd if they only want to use Spektrum for one end or the other, or if they are flying aircraft they built themselves, as if hobbyist quality is good enough at one point in the chain, it ought to be good enough all the way through.