No real limits, it only depends on the size of the sd card.
Thanks for the support Mike!
1 Like
The GMapCatcher User Wiki shows you how to set a path and then download the area that would be included in a visual path. Shown below is a 100km path from my flying field to Niagara Falls. Buffalo, NY is just below and Toronto, Canada is on the upper left.
When you Shift+drag the map, then the area included in the visual download zone is queued for download, from the zoom level below the current view zoom level, to the visual download’s minimum zoom level as set
One main function of the tool is to allow you to download close-up maps along a path; it gives feedback of the number of tiles downloaded/requested while downloading
2 Likes
Thank you very much for this great effort! And thank you for your work in bi-directional telemetry. How can users support you?
Hi Robin,
thank you very much for your kind words!
If you’d like to support what I do you can check here
cheers,
Alex
I started experimenting with frsky bidirectional telemetry, there’s a dedicated thread in the developers section
Hi sorry for butting in
Same question really.
I am using the TBS with Bluetooth Telemetry.
It uses sbus for FC and serial Rx and tx for Mavlink. I have full Telemetry on qx7 including roll and pitch also I can Connect with mission planner via Bluetooth have all functions as per connection with USB lead including writing parameter eg servo trims.
Surely there may be a way to get your lua to work. Unless I completely don’t understand.
Thanks & sorry to but in.
Am more than willing to test out any ideas if I can.
Dave.
Hi Dave,
you can try with the MavlinkToPassthru firmware on an ESP32 board, latest versions allow to use bluetooth as an input for mavlink
You get roll and pitch but how about yaw, flightmodes and arming status? Did we already have this chat, 'cause I remember asking something similar…
Alex.
No haven’t talked before.
I have all telemetry and intact took my laptop to the field and collected full mavlink telemetry via my Bluetooth link from the TBS Crossfire. I will upload this log if you want.
So it seems the protocol in my case is talking 2 way but the lua does not as yet read the telemetry.
Thanks by the way for the great work I know people love this script.
I can have a look later at the files you mentioned and if I can help further please ask. I realise you did not actually develop this for TBS but I kind of hope it can be tweaked a bit.
Kind regards David
Alex this is the telemetry log recorded from my Bluetooth link from the Tbs Crossfire, So I Had a laptop at field and am connected to mt taranis via mavlink and tbs so this i believe shows that modes and arming data are present,
OK but this is mavlink, how do you get them on your QX7, I guess by discovering some TBS crafted sensors, bu which one because the TBS manual states that for extended info support from the flight controller is needed and ardupilot does not support CRSF!
Alex.
Here is how i Have done it pleaase see link to my folder here, hope it helps.
i am only an enthusiast so may not correctly answer your questions regarding tbs, but i believe in my setup crsf is not being used, i am using matek F4-5 Wing using sbus with ch 3 and 4 set as serial ports going to serial1 on f/c these are set to mavlink protocol.
this folder will explain in pics
Thanks.
Dave thank you, the way you have mavlink via bluetooth is the one I already knew about, what I was asking you is an explanation for this quote
How did you get full telemetry on your QX7 (non mavlink)?
Alex.
Don’t know how to answer this properly it’s coming out of serial 1 into the nano tx Ch 2 the qx7 is reading the data and telemetry shows
Ok Dave, this explains it, it’s using OpenTX sensors just like ardupilot’s “repurposed frsky” telemetry.
Your TBS system is decoding mavlink messages on the ground extracting the info you see in order to inject them as fake OpenTX sensors in your radio sport pin on the back of the radio.
This way you’re missing some ardupilot specific info like flight modes and the like.
Unfortunately my script does not work with this kind of setup, it needs a “passthrough telemetry stream”.
If you have an ESP32 board around you might try the firmware I linked in my previous post.
With ans ESP32 board you could:
- connect the esp32 via bluetooth to the TBS to receive mavlink
- produce a passthrough telemetry stream to inject in your radio to support my script
- connect to the esp32 via wifi to use mission planner
If you decide to try this road I strongly suggest you ask for support in the mavlinkToPassthrough thread
Hi Alex,
“The BMP280 sensor in the F405-Wing is nothing special, but would be sufficient if the VSpd displayed by the Mission Planner were transmitted in the same way.
With the Yaapu script come strange values. First often much too late (>1-2s), then often inaccurate (+/-0.6 m/s) and often values stay for seconds. They have nothing in common with the display in the Mission Planner.”
These are statements from users who use an F405-Wing with ArduPlane, but would like to use the vario functionality. But that’s not possible due to the problems. Is it possible to optimize something in the script here?
Hi Reinhard,
a couple important points:
- ardupilot does not send baro vspeed but the EKF fused vspeed (GPS + imu + baro) so the two values baro vs fused could differ (mavlink has baro and ahrs vspeed, sport only ahrs).
- ardupilot sends vspeed info at 2Hz so there’s a built in 500ms “potential latency”.
- the script does not manipulate the values, it simply displays what it receives from the telemetry stream so it cannot introduce latencies, the vspeed and alt sensor values at injected into OpenTX at around 3 to 5Hz depending on the radio with the Taranis being faster
How can we proceed to debug what users are reporting? we need a reliable way to reproduce the very same issue!
Hi, Alex,
that’s gonna be another problem to debug… I’m also thinking about how to do that.
I hardly use a Vario myself (I have my OSD), but in a direct comparison with an OpenXSensor Vario it is already the case that the data in your script arrive very delayed.
Of course this is not directly comparable, because the OpenXSensor uses a completely different Baro, but it would perhaps be a viable way to optimize the display if possible.
…well it really depends on what you’re trying to achieve.
If you fly auto modes or even soaring in auto you’d want to see on display what the plane is processing so you really need the same source for vspeed info (pretending there’s no delay).
If you fly manual or acro than you can benefit from an external vario source I guess.
I also think that it probably tends to result in an external vario. I will discuss that again. Thank you for your hints!