Devo 8S with MultiMod: NRF based Protocol issue

I've build a multi module with A7105 and nRF Chip (no PA Versions for now) and modded my Devo 8S with it.
Deviation is custom build from source (trying MJX/UDI protocols), A7105 (Hubsan protocol) is working fine.

But my V272 and SanHuan copters (YD protocol) behave *strange*: They bind fine, but whenever it comes to controlling it, it seems to send wrong / outdated commands, throttle down happens with heavy delay.
I've let my SLH 6047 "Scorpion" Tricopter scratch the ceiling for some seconds due to that (and I initially believed it was due to protocol differences), but my new V272 behaves exactly the same. Upgraded V959 (V222 board) is also not really controllable.

Using Stock transmitters all is working fine.

I suspect something is wrong with Switch or NRF board (though I've used that before on my arduino projects).
Any clues where to start to search ?

Can you try a directly connected nRF module, so the multi-module can be ruled out as a possible issue?

With the V222 board and V272 you're using the V202 protocol? If so I'd think the first suspect is reading data from the nRF module - check the MISO connection.

If the problem is only with YD717 protocol I'd first check for a protocol difference. Maybe the SanHuan expects a checksum, which randomly matches so only it only responds to a small percentage of received YD717 packets (which have no checksum). Have you tried the SkyWalker protocol option in YD717?

I'll check with directly connected module later (Better check cables twice then ^^). Anyway, the A7105 based protocols are working fine.

Yes, using V2x2 protocol for V222 and V272.

I have sniffed some more data (finally got simple Saleae SDK based real-time SPI (+Radio Enable) output working) of San Huan, its definately the same like YD-717 besides some minor differences in bind packets - which don't matter, it seems. Also tried Sky Walker option, without any difference in (mis-)behavior.

The idea with MISO sounds reasonable - V2x2 and YD717 protocol both check for packet send / timeout conditions, thus need to read proper data back.

Is there a way to perform live-log viewing / stderr redirection / debugging on Devo via USB cable (Linux solutions preferred ) ? I've seen the comment on dbgprintf in Deviation YD717 sourcecode ...

To enable printf to UART (trainer port) 115200bps,8,n,1 :
make TARGET=devo8 TYPE=dev

Don't know if it is relevant here. But I am getting similar situation problems with the v272 using the v2x2 protocol. I am using the devo 7e without any multi module interface. Just the nrf module added directly. It binds fine... Can hover... But starts drifting like crazy to the left after a few seconds or I after I give some big stick inputs. The throttle also seems to get stuck at the times!!!... Could it be a setting issue??

bampi2k wrote: Don't know if it is relevant here. But I am getting similar situation problems with the v272 using the v2x2 protocol. I am using the devo 7e without any multi module interface. Just the nrf module added directly. It binds fine... Can hover... But starts drifting like crazy to the left after a few seconds or I after I give some big stick inputs. The throttle also seems to get stuck at the times!!!... Could it be a setting issue??

May be you have a defective board? Or motors? Do you have an original TX or another V2x2 model to compare the behavior? As long as it binds and Deviation does not freeze or reload by itself (it can happen if the contact between nRF module and the main board weakens) I doubt it is a transmitter problem.

Thanks for the reply, i dont have another v2x2 to compare!
I dont even have the original TX!
I will try to find a buddy with the original TX.

The TX is absolutely fine. I can bind fine. Never freezes or anything ODD!

Just wondering, what could be the problem with the board/motors, could i try and troubleshoot!? am feeling adventurous!

What you describe seems to be a problem with gyro - because of motor vibration gyro can drift away thus signaling wrong position to navigation software. As the design of the heli is more or less monolithic, they usually take measures in software. May be you have extremely vibrating propellers. Balancing propellers and removing vibration to the board should help.

But to exclude transmitter issues I would try to borrow a transmitter from a friend, if possible.

No vibrations in the motor or the propellers. I am searching for a tx From someone. In the meanwhile customer service has agreed to ship a replacement quad. I have told them to check thoroughly before shipping.