Firt...let me thank you guys working very hard with all these Ardu-things (ArduPilot, ArduCopter, APM, ...). Very nice and I love it!
I have bought a set of APC220 RF sender/receivers for using as telemtry link for my ArduCopter. I could not connect with the APM Mission Planner...got a time-out for "no heartbeat sent". It did however work with HK GCS and QGroundStation so I started to dig into why it did not work with APM. Luckily, the code is available and hence I have now managed to get it to work.
The APC220 requires the RTS and DTR to be false at all times as no handshaking can be used. I also found that the version of ArduCopter (2.4.1) that I have does not send heartbeats on the telemetry port...have I set something up badly here?
To get this to work you can edit the code to change how the OpenBg() is executed in the MavLink.cs according to:
lock (objlock) // so we dont have random traffic
log.Info("Open port with " + BaseStream.PortName + " " + BaseStream.BaudRate);
// No RTS/DTR at all for this one...
BaseStream.RtsEnable = false;
BaseStream.DtrEnable = false;
I added a small "useAPC220" propery that I set to "true".
I also added/changed a setting where the code expects the heartbeats to come:
// No hearbeats coming from my 2.4.1 FW using APC220...why?
// firmware issue?
sysid = 1;
compid = 1;
mavlinkversion = 2;
aptype = 2;
// incase we are in setup mode
buffer = getHeartBeat();
// incase we are in setup mode
buffer1 = getHeartBeat();
So, I hardcoded some values (version, id's etc) that is coming from the heartbeat package normally.
Anyhow, this is a rather bad approach (but quick and dirty and works for my special case). So, now I wonder if it would be possible to add a few settings in the APM Mission Planner to handle this? Maybe one can have a setting for "use handshake" and one for "expect heartbeat". This would make the APM to be compatible with the APC220 as well.
Well...that was what I had in mind. Thanx once again for your hard work!
ive moded the connect sequence again, please give 1.1.52 a try.
the reason hk's connected is it doesnt care if it lost a param, where as i force it. this is because pid settings may not load and cause other issues.
btw the planner does have an override option for connecting. (Control-T) use at your own risk
also just a fyi.
the planner sends the request, once the apm starts sending params, all other data stops, only params are sent. so technicly flodding shouldnt happen if it has worked in the past
Just tried with v1.1.52, but still no luck with APM2 - doesn't connect, just times out.
Still connects fine to APM1, refresh params works once but not the second time - all params go blank but still get live flight data through. If I power down APM1 (and the APC220 connected to it) and then refresh the params it refreshs fine (but not a second time).
EDIT: I have now just been able to connect to APM2, (after restarting MP and APM2). Have live flight data but cannot read or write params.
MP log attached
ok something new to try.
set the telemetry rate on the apm to 19 aka serial3_baud
set your remote modem to 19200 baud as well. this will turn on the internal apm serial speed checking. and should prevent alot fo currupt packets. and now try connecting
Trying this now, using the RF Magic program linked here, I've changed the 'Series Rate' to 19200, left the 'RF TRx rate' at 19200, different 'Node ID's', did this to both modules (and changed the port speed to 19200).
No joy Michael, can't get them to connect now... APM1 too
Tried twice, no joy. Going back to 57600 I can at least connect to APM2 on most tries but changing params doesn't work (which is what I really want to do)
when you change the serial3_baud on apm did you reboot apm?
Sorry, I understood to change the baud in the Mission Planner, where do I change "serial3_baud"? EDIT: found it config.h, checking now...
No, I didn't reboot APM after, should've, but will try that now
OK, done it correctly now including changing the "serial3_baud" to 19200. Rebooted APM and still have the problem. It stalls at SR3_EXTRA3 then goes really slow from there and ends with failed connection.
Syberian posted this up @ RCG megapirates thread concerning APC220
To all the guys experiencing the problems with APC220 link:
You have to lower the update rate in the mission planner. Go to Configuration-Planner and set 'telemetry rates' to 3,1,1,0.
The Glider`s adventures was caused by flooding the APC with data stream. The telemetry data amount was too high to fit in the 19200 baud aerial speed of this module. Since the modules are semi-duplex i.e. working sequentally on the same frequency, there were no space left for incoming ground commands. Also there were massive packet drops and skips on the board side.
I dove deeply into this today when tried to connect my APCs to a new Megapirate Plane 2.24. The mavlink protocol was not designed for that low transmission rates.
I`d ended up reducing the telemetry rates as mentioned above.
Also these lines should be found and commented in the gcs_mavlink.pde (backup the original file):
Mentioned above will drastically reduce the channel loading.
Michael if you want, PM me your address and I will send you a set of APC220's .
Thanks for your time looking into this.