Advanced Search

Hi guys!!

Has anyone made by any chance an RC Buggy icon at all? Reason being a friend is sending me his never-been-unboxed Team Associated RC18B2 and I would like to control it with my Devo 7E (I just can't get used to wheel and trigger car radios)

I would design it myself, but if "Stickmen 101" existed, I would fail it miserably... so if anybody happens to have one made, it would be very much appreciated. If not, then I'll just have to see what I can make to resemble a buggy heheheh.

Thank you

Nobody has talked to PBR that I know of. And I agree - I don't want to do anything that might keep him from returning. I want to be perfectly clear that what I'm doing has no other goal than to keep deviationTx moving forward until he comes back. So if there's no community support for something, I won't push it by myself, as that wouldn't really be moving things forward.

I hope that when he comes back, he'll adopt whatever infrastructure we've set up to provide support for the project should he need to take time off again. But the project is still his no matter what. If he wants this stuff gone, it'll go away. If he wants to use it but thinks there are things we're doing but shouldn't, we'll stop. Conversely, if he thinks there are things we aren't doing but should, we'll start.

The first thing I did when I created the deviationT team was make PBR an admin. I expect to do something similar if we do set up such a foundation.

I believe you can find all the relevant sources at bitbucket.org/PhracturedBlue/universaltx . However, I've not been working on this (don't have a clue how), so I'm not positive about that.

If those are the sources, and any of you would like a shared repository to work in, let me know and we can create one and then add you to team deviationTx.

You can open a ticket with the hosting company by sending a note to the sales address. I called them to actually get some action. But they aren't very happy about customers of their customers opening tickets.

Money would be welcome, but until at least two other people volunteer to be officers (we need a president, secretary and treasurer), it won't go anywhere.

Promotion doesn't have to include selling modded radios. Stocking modules would be a big help for a lot of people. Selling neck straps, etc. would also qualify as promotion. And yeah, selling modded radios may have liability issues, as well as requiring FCC certification. Checking on such would be part of the foundations job. Actually, thinking of things they can do to promote use and then sorting through the legal issues is part of their job. But dealing with the web site and team deviationTx would be the first priority.

Comment out the has_pa-cyrf6936 line. It shouldn't make any difference to the A7105 protocols. However the best case is that it'll be ignored because the corresponding enable- line is commented out, but if not, it could seriously reduce the range for your CYRF6936 protocols.

Also try setting has_pa-A7105 to 0. I don't expect that to make any difference, but it's worth a shot. Until the * goes away, you aren't going to be able to bind things.

Have you double checked your connections against PBR's docI that I referenced earlier? In particular, make sure you've got TMS connected properly.

If so, then you might try installing the latest team nightlies . Make sure you update the file system as well (everything but the models file and tx.ini). You'll need to edit hardware.ini instead of tx.ini, but it has the same values in it. This will at least tell you the module is missing at startup.

The only one who can say which will be the future repository is PBR, and he hasn't been heard from for a while. Last time he did this, when he came back he copied RB2102's (?) repository into his.

The "team" repository is just that: an attempt to get all the people continuing development working together. The rules are pretty minimal, and designed to make it easy for PBR to evaluate when he comes back. I'm hoping PBR will adopt the code, but do it by just moving his work to it, rather than keeping the repository closed. He's already an admin on the repository.

I run the team project because I created the team & repositories. I'm inclusive about things: if you've had pull requests accepted by PBR or the team and agree to follow the rules on the team repository wiki page , you can have a commit bit.

However, I only have that authority because I created the repositories. If the team decides they want someone else to run it, or a more democratic process, or a different set of rules, I'll follow the teams wishes. And of course, PBR will always have the last say.

The other thing I'm doing to try and keep the project alive is the deviationTx foundation. That's still a proposal for a non-profit organization that would take over administering the project, among other things. But if nobody is interested, it won't happen. So if you'd like to see something set up that could accept donations to help develop deviationTx (again, among other things), make a comment on that thread .

Welcome! Always glad to have more hardware hacks here. You should be able to help with development of the all-in-one module.

First thing - tell us which version you're running! That's pretty much always useful. That's on the about page. There are at least three reasonable possibilities:

1. 4.0.1. That's the last release.
2. PBR Nightlies, from last august.
3. Team deviationTx nightlies, from the last night.

That's the preferred order, and you should only move down if there's something in the later ones you have to have. The nightlies don't distinguish themselves except by the revision checksum. If you're running one of those, you probably got the files on the Tx edited wrong, as the instructions are hard to find.

Now, for your problem. The bind procedure for deviationTx is always the same: select the bind (or re-init, if you don't have a fixed id) button as described. If it's not selectable, then something is wrong elsewhere. For instance, not having enabled the module properly in the tx.ini or hardware.ini (nightlies) files. Or the module not being found - which should generate a warning. Is there an * in front of the protocol names?

What you have to do to your aircraft varies depending on the aircraft.

The V911 uses the FlySky protocol. Leave the fixed ID at none, as the v911 ignores it, and having the tx try and bind on power on is convenient. The procedure is to turn on the V911, then hit bind/re-init with the throttle all the way down. It's very finicky - if you hit re-init to early or to late, it won't bind, and you'll have to pull the battery and try again.

The Proto X uses the hubsan protocol. Turn on the Tx first, make sure the throttle is all the way down, then turn on the quad. It should go blinking then solid as it binds. If it doesn't bind, try hitting re-init/bind. I haven't tried the Proto X with deviationTx yet - I just got mine, and need to find an A7105 due to a comedy of errors. Try it both with and without a fixed id. If you haven't looked through the thread on it in the forums, do so - there may be detailed instructions there. I'll be checking it late tonight, I hope.

If you make a post about the team deviationTx repo and nightlies on another forum, please mention it on this thread so we can participate!

Sure. Feel free to announce it wherever you'd like. I just did a chain of updates:

team deviationTx/deviation wiki: now points to the nightly builds on the drive, and has info for developers.

team deviationTx/deviation README now points people to the wiki for nightly builds and developer info.

PhracturedBlue/deviation Wiki home page now points to the team deviationTx/deviation repository.

Those are all the things I know I can update. I don't know anyone who can update the deviationtx.com site, other than via forum posts.

Can the info about the team's repository and nightly builds address be put somewhere more visible? People at rcgroups have an impression that no development is going on.

I know that you are not an admin of this forum, but something should be done, otherwise people will lose interest to the project.

OK, you should be added now. Please PM me an email address either here or on bitbucket so I can add you to the developers mail list that will be getting jenkins reports as soon as I set it up.

General rules: please submit a pull request for a review from your own clone before committing. Get approval from at least one other team member before merging. You might also do a pull on the team repository before merging, just to see if there's a change that might break the build.

Take some time to review pull requests yourself. The idea is to avoid problems - if you spot a bug, or there's a faster or smaller way to do something, comment. But don't bikeshed: if you make a suggestion and the person explains why they don't accept it, if you can't spot a flaw in their explanation, approve the code as is. They are donating it and will be the person hg blames and presumably the first person queried if there's a problem, so let them do it their way. If it really bothers you, write your own version of the pull request so hg blames you.

These are open for discussion.

The outage that started yesterday makes me think it's time to put forward an idea I've had in the back of my mind for a while now: setting up a non-profit whose primary function would be to deal with such issues.

The idea is that the foundation would be tasked with promoting the use and development of deviationTx. It would manage the domain names and any hosted sites, and act as a project manager of sorts for deviationTx team that already exists.

Unlike PBR, it would accept donations. Those would be used to pay for the fees involved in running those sites. Other activities might be helping people get deviated Tx's: bulk orders of the modules, for instance. Finding someone to install them if people wanted to provide a Tx and donate their time.

It could also do things to promote deviationTx: people have asked about neck straps, so a bulk purchase of deviationTx might be possible. Or arranging to get a deviated Tx into the hands of a reviewer. Or anything else that falls under the title of "promoting the use of deviationTx".

It could also use that money to help developers. For instance, the universal board that PBR has been designing - it could reimburse suitable developers for the purchase of that. Possibly even PBR, though I understand why he won't take money. Even setup up a feature/bug bounty system of sorts.

Nothing beyond managing the domains and web sites is guaranteed, and other things are possible. I'm just blue-skying what such an entity could do.

Registering a non-profit usually requires three officers. PBR would of course be an officer (borrowing Guido's title of "benevolent dictator for life"), but wouldn't count as one of the three. As far as I'm concerned, each of the three would have to have at least one alternate who could deal with things if the officer was missing, because - well, we want to avoid outages like this.

So, how many people think this is a good enough idea to donate money to such an organization? How about donating time to being an officer?

Final note: the outage seems to have been caused by the deviationTx.com hosting company doing some kind of migration. I chased them down, opened a ticket and gave them a call, and was told it would get fixed. Not sure that was why it got fixed, but at least it got fixed.

I have prepared the following modification of KN-protocol. I use jimqjp-repository , but modified the protocol for backwards compatibility. Now available trimmers! Available 11 channels:

1. Throttle/Pitch
2. Aileron
3. Elevator
4. Rudder
5. DR
6. Hold
7. Flight mode Norm/3D
8. 3D/6G
9. Pitch trimmer
10. Aileron trimmer
11. Elevator trimmer

For new V977-receiver ajustable pitch work. And "Hover Debugging" in 6G-mode work also.

I compiled firmware for Devo7E, Devo8s and Devo10. I used the deviation-team repository and adapted patch for this. For sample, this is my V977 configuration .

http://mcheli.blogspot.com/2015/02/wltoys-v977-kn-protocol-mod-v2.html

Sorry, text only Russian.

For any of you using this, I've found a problem in the timer setup. I've been flying with this for months and never noticed it before, but I've updated the document to fix this.

And it turned up a bug in deviationTx as well. A pull request has been submitted to the team repository.

Hi team, evening. I've flashed the latest version tonight- fonts are back to normal, things are looking nice again. It appears that the red bits are red when they should be, although the battery voltage labels appear the wrong way round again!

I think we're pretty much there though.

Thanks in advance Indigo!!

Forgot to mention:

If you're playing with advanced mixer programming, using the team nightlies is a major win. They've rewritten the channel monitor so that instead of displaying just the channels sent to the Rx, it displays all the channels that have a mixer - including the virtual ones. So you can see those without having to route them to an unused output channel.

I'm looking forward to the pull request for this on the team nightlies!

Kernowmcrae, can you try binding the 10-channel Rx's with 7 channels? There's a known issue with the Blade/Eflite Rx's built into their small RTF & BNF aircraft if you bind them with more than 7 channels. My 350QX1 when bound with 8 channels on the Tx will chatter the ESCs even before it's initialized.

I'm wondering if this issue may be related to that.

I've got working code for this for the 7e & 10. Well, the emulators.

If you're doing your own builds, you can pull the code from the new_toggles branch of my bitbucket repo . This is a clone of the team deviationTx repo.

I've also added a description of the user interface to the team wik.

First part.


Ok, lets start from the beginning and crate some sort a crash course in R/C lingo.

1. Channel

Protocols have channels as discrete units of transmitting values (digitally nowadays) from your transmitter to the receiver. Channels are transmitted in packets, and packets have some sort of a periodicity, depending on protocol.

Now, you can simply see channels as numbers 1,2,3,4...etc or you can (and here it will depend on the protocol) see channels associated with thei use on the model.

Example, DSMX:

Channel 1 -> used for throttle
Channel 2 -> used for aileron
...
Channel 5 -> used for gear
Channel 6 -> used as AUX1
Channel 7 -> used as AUX2

What you see above are just conventions, and sometimes they not even true between different transmitter models of the same manufacturer.

Deviation is capable of mapping channels in a model configuration depending on protocol, so you get the correct channel assignment on the receiver, if you respect the labeling.

2. Switches

Switches, being binary (0/1, on/off), three position (0/1/2, low/mid/high, -1/0/1) or analogic (pots) are means of altering the channel output. You can tie a switch to a channel and modify the final value of that channel that's being sent to the receiver to you liking. See below, mixes.

Switch names don't matter, other manufacturers use identifiers such as Switch A, B, C and so on to label switches. Use the switches as you see fit, it doesn't matter.

Deviation being the flexible firmware that it is, imposes no convention on the user like 'normal' firmwares do, so as far as I care use the FMOD switch to turn on and change color of your LEDs.

3. Mixes / Mixers

These are simple programs that take an input value (a stick movement or a switch position) and output a certain value (which of course ca vary in time).

Probably this is best with an pseudocode example:

input = THR ; throttle stick
scale = 0.5 ; channel properties, scaling, 50%
output = input * scale

when SW_GEAR == 1 ;
scale = 1
output = input * scale ; mix_type = replace, current value is discarded

when SW_MIX == 0
value = 10
output = output + value ; mix_type = add, current value is altered
.
.
.
return output ; this gets sent over the air to the receiver

Now, as a programmer, this is the best way to see mixers / mixes, in the end there this state machine which has a number of input and outputs. You alter it with your own rules and that's it.

4. Channel values at receiver (PWM)

This is PWM basically, pulse width modulation. Normal bounds are between 1000us and 2000us, most transmitters and receivers will output 1150us to 1850us with 1500us as center channel. This is what basically having a scale of 100% in channel properties means.

But, of course not all protocols and receivers are created equally, so you will have center channels at 1520us, etc, etc, etc.

PWM output requires a pair of wires for each channel, and this is very common in airplanes, where you do not have any sort of flight controller.

5. Channel values at receiver (PPM)

Some (usually more expensive) receivers can output a steam called CPPM (sum PPM) which basically sequentially encodes (usually 8 yeah that's eigth) channels over a single pair of wires. Very common in multicopters or helicopters.

6. Channel values at receiver (Serial)

Well, not much to say here, values are transmitted over an UART. Needs a counterpart on the flight controller/decoder. Common on multicopters, usually with Spektrum compatible satellites.

7. Channel values over SBUS

No idea here, never used SBUS which is a Futaba thing I think but probably more similar to Serial than others.

Hi

I just purchased a Devo 7e and installed the A7105-D03 module. I used the new wriring (see here: www.rcgroups.com/forums/showpost.php?p=30651761&postcount=2702 ).

I flashed two different firmwares: the latest nightly from the download area of this side (92e1705) and the one from team deviationtx here (9085f67 from 2015-01-30.

With both firmwares I got a range of 1-3m (at 150mW) at best. I measured the voltage on the tx and rx pin (coming from the GPIOs of the A7105). TX was always on GND and RX probably floating (between 1.35V and 2V).

I changed the wriring to the old style and the PA is working fine then.

So my question is: Is this a firmware problem? Or are my GPIOs defect?

Which firmware is proven to work nicely with the new wriring?

Have I maybe done something wrong?

Thanks for any help. I am totally new to this.

Michael