Crossfire telemetry could explain the GCS anomalies. Whilst the serial port data rate is 56kb, one source has indicated that the over-the-air rate is only 12kb. I’ve no idea how it is down-sampled by the crossfire.
I have no experience with the TBS Crossfire, but it might be worth trying a standard 915Mhz modem set to see if the problem persists. These work fine for LOS : https://hobbyking.com/en_us/hkpilot-transceiver-telemetry-radio-set-v2-915mhz.html
For longer range BLOS I’d highly recommend RFD 900x Modem (HS 8517.62.00.90) - RFDesign which also supports PPM passthrough for RC control. These are the “default” radios used by most Outback Challenge teams, are also well supported by Tridge (so they remain compatible). From memory, in the 2016 event CUAV managed to maintain a RF link ground to ground over 15km or so, whilst the quadplane was landed at the remote site. PPM wiring diagram can be found here: RFD900x Setup — Mozzie 1.0 documentation
Thanks James, Ill look into it more.
Thanks for the links Sam, I have some 3DR units I will try first. I have been planning on getting a pair of RFD900’s for a while, I was not aware that PPM passthrough is available, that’s a nice option to have considering we would like to make our own AIO GS.
I posted a request for help in Plane 3.8 sub-forum : Near crash amidst multiple “EKF yaw reset” messages. Logs inside
Please take a look if you think you can help decipher some odd behavior.
On a positive note; Completed a couple really nice looking full AUTO missions ( my first! ) I was flying alone, but I managed to capture some video of an AUTO takeoff and landing I’ll post later.
(Radio is beeping because I have not touched it for 10 min.)
By the way, the improved transition into the final landing stage on 3.8.2 is buttery smooth compared to previous versions, great job Devs. 
1 Like
JFYI with the RFD900 it’s only the “x” model that has PPM passthru, the others don’t. It also has multipoint mesh, so you can use a third radio as a relay etc.
I assume you mean “all in one ground station” with AIO GS?
For that we’re using Maverick on a pi Zero as a ground comms relay and are thinking of making some of our own PCB’s for it. With that we connect the RFD900x to the pi uart, FrSky RX and telemetry via the smart port to the RFD900x PPM (this gives telemetry back to the Taranis screen as well for the RC pilot), LTE modem to the pi USB and share the telem/LTE on the ground to the GCS’s etc, using the pi zero W wifi which routes mavlink of mavlink-router/mavproxy. Powered by 2s 18650’s this can last 4-6hours. Also has a RGB LED strip to emulate PXH LED on the ground and near the GCS, oled or eink display for showing critical messages, plus some buttons to do basic config and RTL without a GCS. The good thing is that this can go in a decent RF location, like on a mast and makes the GCS devices wireless so they can move around on the ground without needing to babysit the RF or cables. Well worth it, even if it’s just to cut down on the setup times. Just boot, connect and fly.
P.S. One more thing for LTE routing through the telco NAT, and in general, I highly recommend using https://www.zerotier.com/
1 Like
I’ve replied on the other forum post
Notes from most recent test flights:
-
Suspect compass still unhealthy despite moving GPS /MAG to very tip of wing
-
Abrupt pitch-up upon reaching ARSPD_FBW_MIN in transitions.
-
Lots of interference from IC engine? Could be contributing to multiple issues?
Sample Flight Log: 0004.BIN
OK, Compass. I moved the whole unit to the very tip of an ugly, but functional RH wing I had laying around. Routed wires in twisted pairs to the FC.
Re-calibrated compass offsets in the middle of a field, still not great numbers:
X -396
Y 148
Z -31
Observing mag level on the Mission Planner tuning page shows a relatively stable base line of around 700 (isn’t that really high?) It fluctuate between ~620 - 800 under quad power and in flight.
Visually, the telemetry suggests that the aircraft is far more aware of its magnetic orientation. Yaw commands in hover are noticeably better, and auto transitions to initial waypoint seem accurate. Still see pretty bad toilet-bowl in Q_LOITER take-off. I’m not sure how to quantify the improvement (or lack thereof) in the logs so if anyone could shed some light on the that it would be much appreciated.
Pitch-UP Issue :
This is a recurring issue that is always there but often so bad in wind that the aircraft almost goes vertical.
The log posted above and these screen shots below likely paint a better picture than I can describe with words.
As far as I can tell, the pitch is an entirely un-commanded output on channel 2 (and 10 - not shown).
That interference on the last screenshot is quite troubling and leads me to my final note:
**Gas Motor Interference and/or Ground issues?
The RH tail servo used to jitter when the gas motor started (I suspected ignition noise), but that went away with shielded servo wire.
Could noise in the long tail servo wires show itself in the RCout as seen in the logs? Or is that different issue form within the FC?
As usual, any help is appreciated, I’ll keep poking around in the meantime.
Till next time,
Ryan
Hi Sam, (@JeffBloggs) Thanks for this information. I purchased a couple RFD900x 's to experiment with.
Currently have them hooked up as peer to peer (sik) radios and they are working as expected.
I also have the PPM pass-through working on the ground. Tested via a Taranis and Spektrum Dx8 trainer port. (both 3.3v PPM) in Manual mode the latency is noticeably worse and possibly a bit “notchy” using either radio TX. I am using the default Mavlink settings per the RFD900 configuration tool with the correct GPIO boxes checked for PPM in and out.
Do you experience this latency? (sorry, no scope data) any suggestions on modem settings? I cant find much information on the RFD900x and PPM.
I like your wireless GS idea and will likely pursue something similar.
Thanks again,
Ryan
Hi there, I was looking to implement the prop alignment idea that @rallyon mentioned previously here, but I wanted to check if there’s already Arduplane 3.8-compatible code that does this?
I am an armature coder at best but I did get the prop alignment implemented on Plane 3.7 and working well.
When we moved to 3.8 it stopped working and I haven’t had time to figure out why.
Here is a Change Log for what I added to the code in 3.8 which DOES NOT currently work.
(It is basically the same code I added to 3.7)
Would love help implementing this feature correctly.
-Shane
quadplane.h
Line # 271
Added:
// timers and const for propeller alignment //***** Hybrid Project *****
uint32_t propalign_pulse_ms;
float propalign_state = 0;
float propalign_pulse_current = 1;
const float propalign_number = 5;
AP_Int16 propalign_pulse;
const float propalign_gap = 500;
Line # 287
Changed:
enum {
TRANSITION_AIRSPEED_WAIT,
TRANSITION_TIMER,
TRANSITION_ANGLE_WAIT,
TRANSITION_DONE
} transition_state;
To:
enum {
TRANSITION_AIRSPEED_WAIT,
TRANSITION_TIMER,
TRANSITION_ANGLE_WAIT,
PROPELLER_ALIGN, //***** Hybrid Project *****
TRANSITION_DONE
} transition_state;
quadplane.cpp
Line # 397
Added:
// @Param: P_ALIGN_PULSE
// @DisplayName: Propeller alignment pulse ms
// @Description: Length of alignment pulse in milliseconds.
// @Units: pulses
// @Range: 0 5000
// @Increment: 1
// @User: Standard
AP_GROUPINFO(“P_ALIGN_PULSE”, 57, QuadPlane, propalign_pulse, 750),
Line # 1216
Changed:
if (is_tailsitter()) {
if (transition_state == TRANSITION_ANGLE_WAIT &&
tailsitter_transition_complete()) {
GCS_MAVLINK::send_statustext_all(MAV_SEVERITY_INFO, “Transition done”);
transition_state = TRANSITION_DONE;
}
To:
if (is_tailsitter()) {
if (transition_state == TRANSITION_ANGLE_WAIT && /Hybrid Project
tailsitter_transition_complete()) {
transition_state = PROPELLER_ALIGN;
}
Line # 1277
Changed:
case TRANSITION_TIMER: {
motors->set_desired_spool_state(AP_Motors::DESIRED_THROTTLE_UNLIMITED);
// after airspeed is reached we degrade throttle over the
// transition time, but continue to stabilize
if (millis() - transition_start_ms > (unsigned)transition_time_ms) {
transition_state = TRANSITION_DONE;
GCS_MAVLINK::send_statustext_all(MAV_SEVERITY_INFO, “Transition done”);
}
To:
case TRANSITION_TIMER: {
motors->set_desired_spool_state(AP_Motors::DESIRED_THROTTLE_UNLIMITED);
// after airspeed is reached we degrade throttle over the
// transition time, but continue to stabilize
if (millis() - transition_start_ms > (unsigned)transition_time_ms) {
transition_state = PROPELLER_ALIGN; /Hybrid Project
}
Line # 1318
Added:
case PROPELLER_ALIGN: { /Hybrid Project
if (propalign_pulse_current > propalign_number){
transition_state = TRANSITION_DONE;
GCS_MAVLINK::send_statustext_all(MAV_SEVERITY_INFO, “Transition done”);
propalign_pulse_current = 1;
}
if (propalign_state == 0 && millis() - propalign_pulse_ms > (unsigned)propalign_gap){
propalign_pulse_ms = millis();
propalign_state = 1;
motors->set_desired_spool_state(AP_Motors::PULSE_ON);
motors->output();
GCS_MAVLINK::send_statustext_all(MAV_SEVERITY_INFO, "pulse");
}
if (propalign_state == 1 && millis() - propalign_pulse_ms > (unsigned)propalign_pulse){
propalign_pulse_ms = millis();
propalign_state = 0;
propalign_pulse_current ++;
motors->set_desired_spool_state(AP_Motors::PULSE_OFF);
motors->output();
GCS_MAVLINK::send_statustext_all(MAV_SEVERITY_INFO, "off");
}
break;
}
AP_Motors_Class.h
Line # 90
Changed:
enum spool_up_down_desired {
DESIRED_SHUT_DOWN = 0, // all motors stop
DESIRED_SPIN_WHEN_ARMED = 1, // all motors at spin when armed
DESIRED_THROTTLE_UNLIMITED = 2, // motors are no longer constrained by start up procedure
};
To:
enum spool_up_down_desired {
DESIRED_SHUT_DOWN = 0, // all motors stop
DESIRED_SPIN_WHEN_ARMED = 1, // all motors at spin when armed
DESIRED_THROTTLE_UNLIMITED = 2, // motors are no longer constrained by start up procedure
PULSE_ON = 3, // turns motors on without ramp
PULSE_OFF = 4, // turns motors off without ramp
};
AP_MotorsMulticopter.cpp
Line # 469, 502, 549, 589, 621
Added:
//Hybrid Project
if (_spool_desired == PULSE_ON) {
_spool_mode = THROTTLE_UNLIMITED;
break;
}
if (_spool_desired == PULSE_OFF) {
_spool_mode = SHUT_DOWN;
break;
}
1 Like
Thank you very much Shane, I’ll take a look at it in a couple days
When you said it doesn’t work, do you mean that the pulses don’t trigger at all?
The pulses trigger but we can no longer control their length.
It is like there is a minimum interval that the quad motors can be turned on and off in 3.8 that was not present in Plane 3.71.
-Shane
Tridge,
Last year you offered a lot of valuable advice on our hybrid VTOL project which was very much appreciated.
We have made a lot of progress on our engine management system and would like to further integrate it with Ardupilot.
It seams the best way to do this would be to connect via UART (serial 4) or MAVLINK then add a driver similar to those used for range finders to import engine and electrical system telemetry. We would like to log that information on pixhawk as well as sending it back to the GCS for monitoring.
Do you think this is the right approach?
Also, I am an armature coder so do you know of anyone that might help with the process?
-Shane
Hello, just dropping in to give a quick update of what we have been up to over the winter:
-
We switched to The RFD-900x for RC and telemetry as suggested by @JeffBloggs ( Thanks! I considered it in the past, but did not realize the “x” version supported PPM pass-through) It added a small amount of latency, haven’t measured it, but the telemetry has been rock solid so far.
-
Moved a stand-alone magnometer (HMC5983) to the nose of the aircraft and compass issues have ll but disappeared. I’m still using the internal compass as a secondary, and sometimes get a compass variance message on Q takeoff, but it auto performance is very good. We will likely make our own board combining the airspeed and the mag since they are both I2C and conveniently near each other in the nose.
-
We manufactured our own pito-static tube / main battery disconnect. Shane’s idea and design and it is awesome! The idea is that it facilitates our future water resistant goals, at time same time it is extremely convenient. You pull the tube to connect the main power bus, and push it to disconnect. This has the added benefit of a easy to hit kill switch that will auto activate on any nose first incident/accident. Safety!
Thanks for all the input. Until next time…
4 Likes
Noting the length of the i2c cable run, if you’re going to make a custom board, I’d suggest taking it a step further and making it canbus.
ProfiCNC is releasing a combined airspeed/mag board on CAN soon. (see the PH2 facebook group)
How long is your I2C cable now?
I2C currently is about 24" long (shielded wire) and no real noise issues in telemetry data (haven’t scoped it). Only airspeed and external mag on it.
Ryan,
That pitot tube idea is a brilliant idea, especially in the event of a nose down crash that could very well save a lot of components from getting burned up, great design. Also nice looking website!!
1 Like
Congratulations guys !! It is absolutely beautiful.
I just read a previous post about your ICE starter, but I wanted to know a bit more about the parts you used. Typically, I was wandering what is the power of your ICE and what is the embedded starter you used ? 
Thanks in advance for your answer !
Marc