I recently have added a couple of rangefinders and an I2C display to my Matek F405-SE flight controller and am doing some testing before I put it in the air again. I imagined I might be pushing the limits of this board with all the extra hardware, but now I’ve come up against a issue that I’m not sure if I can solve. I’ve updated Mission Planner and the FC to the latest stable releases of MP and AC respectively, and I can connect via USB to the copter and read params fairly quickly. However, when I try to read params over telemetry connection (2 mRo 915mHz) radios, it gets the connection, but then hangs forever on the “Getting Params” dialogue. I have waited at least 5-10 minutes on this screen before I gave up. In looking at some other posts here on the forums I saw something related to the FC maxing out its RAM capacity potentially causing an issue with this connection, but what I don’t know is if the telem connection is more taxing on the RAM than a USB connection. I have here three logs - one prior to installing the rangefinders where I was attempting an Autotune - to give a baseline of the FC’s PM.Load and Mem messages at that time, and then two other logs, where I have the copter logging while disarmed and then I try to connect via telemetry. I hope someone can help me sort this out. I’m also wondering if I actually get this working if it would even be safe to fly if it happens that the RAM on the flight controller is maxing out. The copter does arm, but I haven’t yet flown it. Thanks in advance!
You’ve got mavlink 2 protocol on serial0 (USB) and serial7.
Can you would use serial2?
Also it was discovered that using a RC switch to enable and disable rangefinders could affect the download of params, but you dont seem to have that set up…
Sorry for the confusion. When I added the rangefinders, I had to move the telemetry radio wires to a different UART. This board doesn’t show a serial 2 as available in the Matek documentation, which is why I disabled SERIAL2, instead configuring SERIAL7 for the telem radio. Maybe I missed something? (EOL) Flight Controller F405-SE – Matek Systems
I should clarify too, when I say it gets the connection/connects over telemetry, I at least get the flight mode to display correctly and the link indicator in the upper RH corner of the HUD to change, but then I get the “Loading Params” dialogue that doesn’t ever load. Thanks for any help with this.
I still am unable to get the parameters to load over telemetry, but have flown the copter 3-4 times now and it seems to be performing well otherwise. Rangefinder/Proximity Sensor on Matek F405-SE
When it’s loading is the green bar moving accross the top and then get stuck right at the end? I recently ran into that. Try QGC and see if it works. Also, you may need to tweak the SRn_ parameters to adjust the speed if you’re using a non-standard telemetry port.
Thanks @Allister. I just tried QGC with what I think are the same results. I’ll try the SRn_ parameters, I’ve never messed with those before.
So I tried reducing all the SRn_ params that were not a value of 0 already by half, but the issues persists the same way in QGC, and in MP It just hangs right here - I’m wondering if it is a CPU/Memory issue because the MavFTP seems to fail and it falls back to individual param fetching, which I thought could be related, but I’m not sure.
Dont do Connect, but instead go into MissionPlanner / Setup / Optional Hardware / Sik Radio
and do Load Settings
Grab a screenshot of that, or describe anything odd. The screenshot from docs is a little aged but it should be extremely similar.
@xfacta Here is the screenshot below. I’m not seeing anything odd, but I’m not very versed in all the intricacies of the telemetry connection - all I’ve really done before is update firmware on the Sik radios and change NET IDs. Do you see anything strange? The physical radios both have the solid green LED and the activity lights flash when I try to connect, etc.
It probably doesn’t matter but Net ID, 0 seems odd. Maybe try that as any other number, as long as both radios are the same. (long shot, not expecting this to make a difference)
You will only need to play with the SR values that correspond to the serial port the telemetry radio is connected to. SRn_PARAM I often find to default to 10. I’ve turned it down before to prevent overloading the bandwidth of a connection, but usually on the SiK radios the defaults work just fine.
Watch your antenna placement on the SiK Air radio. The rover I just built had the antenna >cough< very poorly placed and unsurprisingly the connection was useless. The radios connected and I had solid green lights, but that’s as far as it got. Once I smartened up and moved the radio it worked just fine.
Never have I had an issue with Net ID setting to 0 as long as they match this is not the issue! try and mess with the baud rates make sure you have that set to what it is! Sometimes these radios can just be a pain and then they magically work.
Cool! Thanks. I wasn’t expecting it to matter but sometimes 0 values just mess with the mojo.
Thanks for all the suggestions. I’ll try changing some of those things around and see if anything changes. I actually have flow this quad with these radios many times before, the only difference related to the telemetry now should be that I moved it to a different UART than it was on before, but I have updated all the params related to the UART, which is why this seems so strange.
It seems like you have missed a parameter with arducopter to set. Make sure everything is set to mavlink 2. Considering the radios are talking to each other in that one pic it seems like something is missing in ardu side. you have the correct serial protocols set properly? can you load param file?
Serial 7 is the normal RC port and you might be running into issues with the SBUS port. Try BRD_ALT_CONFIG,1.
Edit: Just found this:
the R2 pin can also be configured to be used as true UART2 RX pin for use with bi-directional systems by setting the BRD_ALT_CONFIG to “1” so it becomes the SERIAL7 port’s RX input pin.
Allister could be onto something there.
I dont think the SR params will make any difference, all mine are 0 and it all still works. These are really for sending particular information over the link even if something at the other end doesnt request it (like the old OSD boards)
mmm, the plot thickens…
That’s interesting. I’m going to have to play with that.
A lot of GCSs negotiate the SR parameters on connection.
Thanks for pointing this out! So based on the earlier suggestions, I was messing with the SiK radio settings page, and thought I’d try changing the baud rate up to 115 on that page, which was a bad idea apparently, since now the Sik radios refuse to enter command mode. I’ll have to look at that more later, I guess. With a different set of radios plugged in on both sides, I changed the BRD_ALT param to 1, and tried it, but now it doesn’t doesn’t get a connection at all - no heartbeat packets.