V202 protocol

jason4207 wrote: Sounds like Ch7 & 8 have been implemented. The label is irrelevant, just a name.

If you have full control of all accessories then that is a good sign.

LEDs on 5, missile launcher (all) and camera on ch7, missle launcher single and video on/off on ch8 all good. I don't have the other accessories yet.
If you give the all clear on the Devo 7e hopefully it will be in the nightly builds soon.

Thanks again Victor, and Jason4207.

btw the v222, even with the camera, flies like a champ in wind, even more so now using deviation and some expo. I'm getting enough confidence to fly through apertures at speed.

note: I have found plenty of SD card file corruption, maybe something is turning the video off in a not-so-clean fashion? I end up with many folders & file names with some strange unicode characters, with file sizes up to 8GB on a 2B card. I got one playable file from two batteries.

Are you toggling the switch to start/stop the video? Don't leave it in the 1 position.

Corruption is a known problem if you crash or battery voltage sags during filming. Try starting and stopping the video more often.

I am toggling switch, doesn't start recording otherwise.
Could be battery voltage sagging, although the good video was from late in a flight.
I wonder if a crash may drop the voltage enough to cause an issue? I had a couple... Thanks.

Everything is working fine on my side ! (after getting lost between my old ddf6350 file and the new one )

Thank you so much for your hard work victzh !!

The shock of the crash itself can cause issues. SD card contact can be compromised.

Some folks take the camera apart and use ds foam tape to secure the board better and reduce the chances of SD card losing contact.

I did a little testing using the new build on my 7E.

Everything works, but the camera is acting a little funny. I can take video fine, but when trying to snap photos it takes the triple shot as usual and then just locks up. I have to unplug and replug the camera if I want to take more photos or video.

My camera has been acting up a little lately, though, so maybe someone else can test? Also might need to play w/ the switch settings.

When we first tested, Heli Pad commented about the triple shot too. Then he tried it with the stock radio. And found that it also takes triple shots. There wasn't any lock out with the older build. And he's not running the latest so we can't get his comment.

Damo wrote:

jason4207 wrote: Sounds like Ch7 & 8 have been implemented. The label is irrelevant, just a name.

If you have full control of all accessories then that is a good sign.

LEDs on 5, missile launcher (all) and camera on ch7, missle launcher single and video on/off on ch8 all good. I don't have the other accessories yet.
If you give the all clear on the Devo 7e hopefully it will be in the nightly builds soon.

Thanks again Victor, and Jason4207.

btw the v222, even with the camera, flies like a champ in wind, even more so now using deviation and some expo. I'm getting enough confidence to fly through apertures at speed.

note: I have found plenty of SD card file corruption, maybe something is turning the video off in a not-so-clean fashion? I end up with many folders & file names with some strange unicode characters, with file sizes up to 8GB on a 2B card. I got one playable file from two batteries.

Can you test the camera function on your DEVO 10 to see if you can take more than 1 triple shot?

Does anyone know the stock transmitter radio pinout? I opened mine up and it has 9 pins, 3 of which aren't labeled. I didn't take the time to probe them to see if they're even connected - if they aren't it would be fairly easy to drop into place in the 7E since it's just SPI like normal.

From the top it's:
3.3v
MOSI
SCLK
MISO
(unknown)
GND
(unknown)
CSN
(unknown)

The more I use my 7e for my nQX, the more my v222 feels left out of the fun. Yeah, it would still have some dropout issues, but it sounds like there are still things going on with the full PA modules too. And I plan on wiring it to a bit of header strip for easy replacement in the future.

Ah hah, found victzh's message on it from a few months ago on the other forum:

www.rcgroups.com/forums/showpost.php?p=24998249

...now to man up and risk having a grounded v222 until the replacement transmitter comes. I hate desoldering. At least the 7e side of it is nice and beefy when I go to put it in.

In case of forum disaster, the pinout is as follows, looking at the silkscreen side of the stock radio module:

Vcc MOSI SCK MISO CE GND IRQ CSN NC

Pull CE high, leave IRQ and NC disconnected and the other 6 are perfectly ordinary.

Thanks for all the work, victzh!

Pull request for extra channels created, watch it at bitbucket.org/PhracturedBlue/deviation/p...a-video-and-all/diff and expect it in nightly builds when (if) it's accepted.

Sorry for such slow progress - I am far from my usual setup.

Best,

Victor.

No eBay APP ID défined in Kunena configurationI read as much as i can about the Devo 8S and binding with a V202 Protocol Quad (v212 in my case).
So i ended up with this Controller .
I searched for a controller with high range without any antenna.

Can i connect this controller to my Devo 8s and fly a V212 with it?

thx for your reply

pfriedel wrote:
...now to man up and risk having a grounded v222 until the replacement transmitter comes. I hate desoldering. At least the 7e side of it is nice and beefy when I go to put it in.

Thanks for all the work, victzh!

Dear All, today I successfully bound devo 7e running deviation nightly build (20120812) with my v222 quad. I have a PA based nRF24 module with 19dB output power (79 mW) and built-in ceramic antenna. I have to say that I am amazed how much better it feels to fly my v222 with devo when compared to the stock tx. My warmest thanks go to the developers of v202 protocol and to those of deviationtx, of course!

Currently, there is one major issue with v222 quad: dropouts. My stock TX does has them just as devo 7e has them.

I read on the big v222 review thread that somebody reported to have received a new "fixed" tx which works flawlessly(!).

This lets me think that the issue is not with the FC board of the quad, but rather with the tx.

Does anyone of you have an idea what we could try with our devo tx in order to avoid dropouts?

Having asked this, I don't think that we have issues with the nRF24 modules, as many of us bought chineese modules (I did) which could not be all bad.

I would rather tend to think that the old tx had deficiencies in the protocol implementation, which would need to be traced back using the new "fixed" tx and than implemented in the deviation code.

However, as Victor wrote, change in protocol, except for retransmission rate, would need modification of the FCB. So. my above idea with the protocol could be wrong.

Another possibility is that the dropouts with devo do have a different origin than the dropouts with the stock tx.

I may easily be wrong, but please tell your thoughts!

Andre.

I too wonder if it's something fixed in the protocol.

My friend just go the new TX in yesterday. We may head over to the DO prone park to give it a test.

Can a logic analyzer help snoop the protocol?

Original TX was pretty sloppy in the timing and extra, nonsensical packets. If they fixed it, it should improve. There is no way to change the protocol only on TX side, so the protocol is basically the same. What they could change is packet repetition rate (if you triple the packet instead of doubling it as it is done now, it probably can enhance reliability), remove garbage packets, strictly observe frequency change pattern (first TXs had unexplained temporary change in this pattern which could easily be responsible for dropouts).

Logic analyzer is what helped to reverse the protocol in the first place. If I could get new TX (probably some of the distributors can be generous enough to provide it, I'll try to contact MassiveOverkill who helped me once before) I'd definitely re-analyze the new implementation - scripts are still there. It would be also interesting to look at genuine V222 TX.

Also, you should not discount RX as a cause of dropouts - antenna can be folded - it should not - or inappropriately soldered. Also, antenna length matters somewhat, makes sense to check that it's close to 31mm.

Sitting at the park. After the test session.

We have three TX.
One from the v222. One that just arrived Friday with the new v262. And then the new TX that is supposed to have resolved the drop out issue.

The result?

The drop out issue remains on both the v222 and v262 with all three TX. We are truly, truly disappointed. We want to cry. :~(

So in our experience, the issue has not been resolved...despite us wishing and praying with all our might. I don't know what's going on.

We also got to try the Devo7e with poweramp. The v262 was very smooth flying thanks to the better gimbals. However, it still experience Drop Out!

By the way, with the v202. Our first quad with the drop out issue. I did many things to try and resolve it.

I had the RX antenna horizontal. I trimmed it to 31.25mm. To 30mm. I replaced it with a new antenna wire. I tried a thin wire one that came with my Blade NanoCPX.

I also tried with three Devo7e radio, two different antenna configuration. One using a dipole up the antenna tube. One using a J-style antenna horizontally installed inside the Devo7e.

Regardless of all that test scenario, the drop out remains.

So we have three quads now. v202, v222 and v262. All with the same dropping out of the sky issue. 10ft or right in front of us sometimes. Very frustrating.

I just got a new usb logic analyzer. Now to figure out how to hook it up and peek at the signal. LOL anybody care to give me tips and get me up to speed?

Daryoon, what exactly do you want to achieve with your new logic analyzer? Protocol is reversed and nothing unknown left. Stock transmitter is very sloppily programmed indeed, it has irregularities in emitted packets which can't be explained by any logic, so they seems to be bugs in transmitter program. My code which does not produce such irregularities works perfectly for me - no dropouts on V202 and V212 so far.

The chance is that sequence recovery algorithm in receivers is lacking as well. If you don't get the packet on expected frequency on time, you can do two things - either predict the frequency from the hopping algorithm and wait for next packet there, or stay on the frequency waiting for hopping algorithm coming to the same frequency again. As far as I can tell by analyzing V202 receiver it uses the latter strategy. It takes 32*4ms = 128ms in theory to recover. May be the RX gets tired and just switches off control - I did not check this. The quality of receiver may affect the rate of defective packets and thus the dropout rate.

Summing up - if you have one model without dropouts and another with dropouts, may be the model is to blame, not transceiver.

Well, I am just gonna start learning to hook these things up. Not looking to reverse engineer protocols or anything like that...yet. I don't even know where to hook up the probes. Don't laugh too hard.

It's just that we got three TX. One of which was shipped by Banggood and IS the TX with supposed the "fixed" to prevent drop out. Thought I could hook the logic analyzer up to that or something to give you guys feedback.

But it seems like it won't matter anyways. The new TX didn't solve the drop out issue on ANY of the quads we have. Including the brand new one that we just got in the mail.

Like I said...v202, v222 and v262. All suffering drop out. And with all combination of TX we have. So it doesn't look like it's the RX or the TX that's to blame. Don't know what else to try at this point without knowing exactly what WLToys deem was the issue and solution that they implemented.

What kind of logic analyzer? If it's Saleae or clone I can send you the Python scripts for decoding the nRF24L01 protocol (as used by V202, not everything in the spec is implemented).

If I understand the situation right, the fix is both in new TX and RX, so defective receiver boards with dropouts stay defective. I asked a question in rcgroups about what specifically they fixed, but don't have serious hope of it being answered.