Yes, had a chat with Tridge, there’s a patch for DMA contention we could try
Thanks Alex,
My CRFS protocol is working but still no telemetry. I get GPS data though and the yaapu widget works. Possibly I’m not using the correct build. Would you point me toward that download to make sure I get the latest. Here is what I am using taken out of the “latest” directory.
arducopter_with_bl.hex Tue Oct 13 13:39:03 2020
Thanks
Richard Powell
@vierfuffzig how have you got WiFi setup? I can’t get anything at all out of WiFi - I am only using CRSF right now and hoping MAVEmu works, but it does not appear to. Does it work over mavproxy?
After figuring out nearly all possible permutations of
bad SD card,
broken switch on T16,
wrong setting for RC_OPTIONS,
wrong settings for the SERIAL port or
wrong unrelated custom FW on the board
I got it working with Micro-TX-V1 and the big TBS-TX on both OpenTX radios (Jumper T16 and Frsky xLite).
All running on old CRSF FW2.42 as well and FW4.03 too.
Two screen shots:
I am still curious what is the meaning of the numbers in the lower right corner?
@andyp1per imho it is workin only partially. i assumed it would be working correctly on the fullsize TX (aren’t you using a fullsize?).
on the microTX it requires using a fw version 3.80 and newer, so you’ll actually need to use a 4.0x beta as there is no release type fw above 3.78… i couldn’t spot any difference between the available 4.0x betas, using 4.05 right now.
additionally you’ll need the wifi module at fw 1.17.
i’ve set the UDP port to 14550 for convenience (why 8888 as default???).
you’ll need to manually turn the wifi’s MAVLink “on” on every power-up, it falls back to “off” on power cycle.
you can opt for both AP or STA mode, both work equally bad.
now you’ll be able to connect and see a both a vehicle’s and the radio’s IDs with a basic message set.
if you now turn on your Rx and add a telemetry feed, you’ll see some more messages pop up:
i was expecting all basic CRSF tlm items to be emulated, but right now it is the GPS data only. so you’ll only really notice with a GPS fix. attitude, batt etc messages do pop up as well, but the actual data payload is not ever populated and stays at zero. i don’t know if this is intentional to only allow feeding an antenna tracker or showing position on your mobile mavlink GCS. that’s at least how far i’ve come with this.
on a sidenote i’ve tried opening a ticket at TBS to give some beta test feedback, but the ticket system is down.
Thanks. Does it work for you if you try mavproxy? I’ve not had much luck with APM planner and cannot connect via bluetooth or wifi from my windows machine (with MP)
i haven‘t actually tried with mavproxy yet, only MP on windows (successfully) and QGC on iphone (does NOT work).
will check mavproxy now.
vierfuffzig@DESKTOP-GNQDSSL:~$ mavproxy.py --master=udp:0.0.0.0:14550
Connect udp:0.0.0.0:14550 source_system=255
Log Directory:
Telemetry log: mav.tlog
Waiting for heartbeat from 0.0.0.0:14550
MAV> online system 1
ARMED
Mode(0x000000c0)> Mode Mode(0x000000c0)
Arming checks disabled
module load console
Mode(0x000000c0)> Loaded module console
link 1 OK (56 packets, 1055 bytes, 0.00s delay, 30 lost, 53.6% loss, rate:33B/s)
Great you’ve got it working!
…and you can ignore those numbers, they are just debug info that will be removed from release versions!
1 Like
Doesn’t look very promising
i had expected WSL vs windows network issues and / or inherent crsf connection issues, so i actually went to bed pretty happily. i might be biased because i had a great day of flying yesterday.
there‘s a link, there‘s a set of messages, it‘s just some values missing…
1 Like
I can reproduce your experience now - it was the MAVLink setting getting dropped that had me confused. It looks like we get an initial message of the right types but after that only the GPS gets updated.
@andyp1per reading the CRSF manual more clesely i do come to the conclusion that GPS data only when using MAVLink emulation might be intended behaviour actually:
this would mean it’s not my individual intellectual shortcomings that keep me from getting attitude messages over MAVemu, which is great news for me again, a little less delightful with regard to our functional expectations though…
I‘m a little bit irritated… what exactly is the sense in emulating Mavlink from csfr, when a full mavlink telemetry is available? Do I miss the point?
@fingadar it was OT actually, sorry for that, just checking which of the crossfire‘s features work to what extend. afaik on the microTx, the full MAVLink option just doesn‘t work sufficiently well right now.
I updated all released files to test version 0.7:
release notes:
- Horus widget updated to show TX ppower
- CRSF native telemetry always enabled
- CRSF custom telemetry uses frame ID 0x7F as suggested by TBS
- CRSF custom telemetry in RF mode 1 uses a single big frame every couple seconds to pack all passthrough frames as an array. This leaves enough bandwidth for native CRSF telemetry, status text messages and passtrough, the only side effect is the artificial horizon is unusable while in RF mode 1 but everything else is updated every 3 seconds on average.
Rates in RF Mode 2:
- native GPS 3Hz
- native BATTERY 1Hz
- native ATTITUDE 1Hz
- native FLIGHT_MODE 0.5Hz
- native HEARTBEAT 0.2Hz
- custom STATUSTEXT 2Hz
- custom PASSTHROUGH 20 Hz
Rates in RF mode 1:
- native GPS 1Hz
- native BATTERY 1Hz
- native ATTITUDE 1Hz
- native FLIGHT_MODE 0.5Hz
- native HEARTBEAT 0.2Hz
- custom STATUS_TEXT 0.5Hz
- custom PASSTHROUGH 0.5Hz (1 frame with all passthrough packets as an array)
Downloading and testing (latest is version 0.7)
2 Likes
I got it working on the full size TX - looks great!
A few small issues I noticed:
- If you have not set RC_OPTIONS then the widget says there is no telemetry/no GPS in big flashing letters even though there is clearly GPS telemetry visible on the widget
- I get periodic “switched to RF mode 2” messages even though I am sitting right next to the RX. Maybe there is something glitchy there
- Losing the RC connection takes a few seconds to register - I’m surprised there is not a more direct way to tell since the TX already knows as soon as you unplug
Hi Andy, thanks for testing.
I noticed a periodic bouncing between mode 1 and 2 even without my patches but as soon as I put some distance between tx and rx the bouncing stops (my patches simply added the mode switch detection code to ardupilot)
The widget expects custom telemetry data i.e. passthrough telemetry data pushed from opentx to lua, so if you do not enable rc_options bit 8 the widget has no way to tell custom telemetry is enabled.
GPS is pushed as a regular sensor so having GPS data is not enough to tell telemetry is working because sensor data is cached and I can read it from lua even when telemetry is off.
Open to ideas here, the problem is I can send a passthrough packet every couple seconds only while in mode 1.
As for the last point, I need to double check, my widget uses opentx and I might be tied to a built in 2 seconds timeout for telemetry data, telemetry and RC have different timeouts in OpenTX