Dropix and telemetry


#1

Hi, I borrowed a friend’s dropix to try it out before purchasing one, and to be honnest it’s not going so well.
I’ve used conventional Pixhawk since a few years, and am trying to recreate the pixhawk environment I know well with the Dropix. Right now I’m struggling with the telemetry setup. I’m using a dragonlink as radio modem, and cannot get any data to feed my rx.

One of the problem to begin is that in your documentation, there is no indication of what is telem 1 or 2 or whatever number, just a digram with the connection of an xbee style modem connected to the front middle row using CTS RTS connections (which I do not use). Is there anything special to do differently than with a 3DR pixhawk ?
BTW I tried every single telemetry port I found according to google images such to be sure (I hope that the documentation provided is much more precise when you buy the board…)


#2

Hi Clement,

The Dropix has the same functionalities and architecture than Pixhawk. You should connect your telemetry radio on the S1 port of the Dropix. (S1=Telem1)
You can find further information on the Doc https://drotek.com/en/documentation/docs-dropix/#kit-de-telemetrie-3-2
Let me know if you need more precision.


#3

Thanks for the fast response,
that’s the first port I tried, the configuration of my radio modem (which is also my rc receiver/transmitter) hasn’t changed since my last pixhawk so it must come from the dropix. Are the grounds common between telemetry ground and receiver port ground ? Right now I’m just connecting tx and rx since the radio modem is already powered from the receiver port.

UPDATE : I tried putting grounds in common but still not working, what I don’t understand is that when testing with the multimeter, each telemetry ground is not in common unlike 3DR pixhawk

UPDATE 2: I have unstable voltages on the +5v and ground of telem ports, it looks to me like signal voltages, this is a V1 dropix, is the pin layout eventually different ?


#4

Ok I found the V1 documentation.

Tried different telemetry modules (including a simple bluetooth serial link that has never failed on me)
Tried Mission Planner and Qgroundcontrol
Tried Arducopter/ArduPlane/pX4 stack.
Tried telem 1 and telem 2 with correct ports and baudrates.
Tested signal voltages coming out of the tx ports, steady 5v coming out of VCC

Nothing works, I have no idea what to try now, everything works well on my regular pixhawk.


#5

Can you send me the picture of your connection between telemetry and Dropix please?


#6

I don’t have it near me so can’t send a picture right now but I know the connection is right because I managed to connect wirh the bluetooth serial eventually on 57000 baud.
Now I’m gonna try to change the telemetry baud to 19200 and see if it works to understand if the problem is coming from my telemetry system (most plausible option at the time) or the dropix not able to communicate in 19200.
Is it possible that the board doesn’t communicate at 19200 but does at 5700 ( serial settings changed accordingly of course)


#7

Hi Clement
Pay attention to the baud rate because some telemetries work well only with certain rates
for example i tried SiK radios (sold by Drotek) with both 115200 and 57600 and it works quite ok, i did some speed testing and noticed that the mavlink2 framing (suggest you to use it instead of 1) requires about 32 kBaud more or less and it works well even with a 38k but the telemetry seems not to like it so much.
i also tried Bluetooth at 115200 but i don’t find BT a reliable option, and Xbee.
I tried Xbee @ 57600 and 115200, i think i will stick to 57600 for better compatibility.
I never used any RTS / CTS only 5V GND Tx and Rx
Remember that with MP the telemetry requires 32k only if you leave all the data rates at their factory default, if you mess with the data rates it can raise a lot, if you use QGC you have no choice because it presets the data transmission rates and it sticks to 32k approx.

I suggest you to try with a clean (factory reset) system and QGC, set up 57600 baud and be careful to set up the correct rates in all the telemetry chain, then QGC should report no mismatch and everything should work fine.

Hope to have given some help
Roberto