1.7 Beta 2 feedback
CrazyDude1994 opened this issue · 22 comments
Hi guys. This issue is created to collect some feedback about 1.7 BETA 2 build.
You can apply for a beta at https://play.google.com/apps/testing/crazydude.com.telemetry
In this beta release:
- Added serial USB connection. You can now connect your transmitter using a FTDI adapter, OTG cable and inverter.
Connect it as follows:
Transmitter -> Inverter -> FTDI (only need to connect GND and FTDI RX line to Inverter signal wire) -> OTG -> Phone
I've used this library for serial communication https://github.com/mik3y/usb-serial-for-android. You can find supported devices and other info there.
- Added CrossFire protocol support (inverter and external bluetooth or usb connection is still needed)
- Added LTM protocol
Please test these feature and give me the feedback!
I think you have noticed that beta APK was crashing. I have fixed the issue and uploaded a new APK.
I was able to make one flight with the beta version, but still using the BT option since my USB cable hadn't arrived yet. That worked fine, I think, more later on that. I then did get my cable, made a new inverter, hooked it up, and it worked, at least in the house and for a short walk around the yard. Weather moved in so no more testing at the moment.
One thing I noticed, and this may be due to my GPS going bad and not the app, in the beta version I would get momentary GPS location blips thousands of miles away, in both the BT and USB modes. I don't remember seeing that in the public version, and now I've deleted all those old tracks so I can't go back and verify. Again this may be my gps, but I will do more flights with the beta, and may even load back up the public version temporarily to test.
Otherwise, this is AWESOME. I know most people will want and use BT, but I'm already using 2.4ghz frequency for FPV, so exactly what I needed to confidently fly....and retrieve, downed planes.
I use a Frsky Taranis X9D with a R9M module.
I can load the flight logs and view them on my phone, GPS blips and all.
I've made a couple of flights with v17b2 via a Crossfire and external Bluetooth connection.
It connects fine and tracks the drone GPS, but I've noticed the following issues:
-
There are a lot of sporadic GPS location blips. I've use your app previously (possibly v15???) with Frsky in the extact setup (minus the crossfire) and had the occassional blip (at most one per flight) but in 17b2 via crossfire there are a lot of blips. At one point I could see the satalite count go a bit crazy too.
-
The app crashes when I attempt to load any of the logs from my flight.
Other than that I agree with @KFNCOLO the App is truely awesome.
I've made a couple of flights with v17b2 via a Crossfire and external Bluetooth connection.
It connects fine and tracks the drone GPS, but I've noticed the following issues:
- There are a lot of sporadic GPS location blips. I've use your app previously (possibly v15???) with Frsky in the extact setup (minus the crossfire) and had the occassional blip (at most one per flight) but in 17b2 via crossfire there are a lot of blips. At one point I could see the satalite count go a bit crazy too.
- The app crashes when I attempt to load any of the logs from my flight.
Other than that I agree with @KFNCOLO the App is truely awesome.
Can you send me a log which crashes for you?
Yeah sure, I've emailed them to the address you have registered on google play.
I did a little more testing this morning, one flight, but mostly walking on the ground. The results seem a bit random and puzzling to me. I'll try to summarize what I'm seeing. This is with an R9M module.
-Both BT and serial connections work, however I never got a track to save using the serial connection. I used the serial connection on the one actual flight I did, and while a track was visible while I was flying, no file was saved.
-Plane Heading line - two things, 1) when I initially connect, the heading line will show. If I disconnect and reconnect without shutting down the app, the heading line does not show. 2) the direction of the heading line is 90 degrees off, most times. If when I start my flight/track and the heading is correct, the track will save and I can bring it back up after the flight. If when I start my flight/track and the heading is 90 degrees off, no visible track line is saved. There is a file saved with something in it, no visible track, and almost like random points along where the track should have been.
-I did not get the gps location blips thousands of miles away like on my first test, but at times when I'm doing my flight/track walk, the location on the screen went to that spot off the coast of Africa (must be a zero/zero coordinates?) and I must use the recenter button to resume where I am located.
-The gps is showing 16 to 19 satellites during the tests, so good connection with no trees or other nearby connection problems. I don't know if just walking instead of moving more quickly in flight introduces that 90 degree error, but the direction heading line responds very quickly and accurately (90 degrees) off when I pivot the plane, so I don't think so
Here are two log files, both using BT connection, one showing a track and the other no visible track, don't know if that will tell you anything.
I'm ready and willing to do some specific tests if you'd like, since right now I don't know if I'm doing much good.
Thanks again,
I can confirm USB works fine using a FrSky STK USB dongle connected to the bottom s.port on a Q X7. I was hoping the app would include a dashboard screen of all the sensors, maybe I can come up with something.
@andwright hi. I finally managed to start again to work on application. I fixed crossfire telemetry, and I will push new changes soon. As for crashing when playing log file, it seems like there is an bug in OpenTX. It didn't sent all the battery data. opentx/opentx#7371
So I've released a new beta version. It will be available at google play for beta testers. Mainly this updated is focused for the crossfire users. I would like to have your feedback about this update. It should be working much more better now.
Hi @CrazyDude1994 I’ll give it a go and let you know as soon as I can.
I also started to have a look at this one and was hoping to submit a pull request (but you beat me to it). For what it’s worth I’ve attached a copy of CrsfProtocol.kt as far as I got with it. I added the CRC check (as you have) and I think the crash was due to a buffer overrun due to the packet buffer including the length field (as well as the packet data), so I moved the length field out of the packet buffer.
My change has the problem that it bins potentially valid packets as it assumes the length field for any packet is correct and always bins packets based on the length field. So if a packet was truncated I would bin part of the next packet.
I started an implementation in python for what I wanted to achieve (attached). As far as I can tell, from a quick scan over your latest commit, this is along the lines of what you’ve implemented.
I was also planning on adding some sort of sanity check to the GPS latitude and longitude values (though I didn’t get as far as implementing anything). Even with my CRC check I was still getting the very occasional blip (maybe this is due to the OpenTx bug you mentioned). I figured there was still a 0.4% chance an erroneous packet could get through. So I thought about adding some sort of GPS filtering. Maybe storing the last 2 latitude/longitude values (a rolling buffer of the last two values) and then only output the GPS if it is within some sensible limit of either of the buffered values. Something like this pseudo code:
rollingGpsBuffer.push(currentGpsValue)
if (rollingGpsBuffer.length()) > 2:
rollingGpsBuffer.pop(0)
if (gpsIsWithinSensibleLimit(currentGpsValue, rollingGpsBuffer[0]) OR
gpsIsWithinSensibleLimit(currentGpsValue, rollingGpsBuffer[1])):
output(currentGpsValue)
Anyway, I’ve attached the files for your information.
I’ll give your latest change a go and let you know how I get on.
Cheers
Andy
crsf-files.zip
Hi @CrazyDude1994, Apologies I haven't been able to get out and test the new version (17b3) of the app in the field (flying around and stuff).
However, I have been able to test it with some logs I captured previously with version 17b2 (I don’t know if this is a valid test or not). Most of the logs I tested look much better; No GPS blips, heading appears to be correct now, all looks good. However there are logs which I have seen crash the app on loading. Like these two:
2020-01-06 12-48-10.log
2020-01-10 12-52-34.log
I tried running it in the debugger and saw something about “unexpected EOF” but I did look into any further than that.
@andwright I believe you're used beta version code 21, I have already saw a crash reported, and uploaded a new version 1.7b3 code 22
Sergey, any progress there in releasing further version with more bugs fixed?
@DiscoMan18 It's almost finished, but because I feel sick for a past few weeks, there was no much progress. Today I'm feeling better so maybe there will be a new release soon. Also because of quarantine I can't go and test a new version too often.
1.7 has been released. Create a new ticket if found a problem with a new version
Hi guys. This issue is created to collect some feedback about 1.7 BETA 2 build.
You can apply for a beta at https://play.google.com/apps/testing/crazydude.com.telemetry
In this beta release:
- Added serial USB connection. You can now connect your transmitter using a FTDI adapter, OTG cable and inverter.
Connect it as follows:
Transmitter -> Inverter -> FTDI (only need to connect GND and FTDI RX line to Inverter signal wire) -> OTG -> Phone
I've used this library for serial communication https://github.com/mik3y/usb-serial-for-android. You can find supported devices and other info there.
- Added CrossFire protocol support (inverter and external bluetooth or usb connection is still needed)
- Added LTM protocol
Please test these feature and give me the feedback!
Hello, I have some question to ask. is it ok to use frsky r9m module to have this apk connected with cellphone by bluetooth. I have install the apk to my cell and it runs. but I can't get the map since i am in china. is it possible I can get other map available on it? thanks alot for your nice apk.
Hey,
Trying LTM support but I can't make it work.
I know that in terms or sending > receiving is fine because I can get the data when using another app.
One possible issue I can see is that there is no way to select the baud rate, and for this I'd need to be able to set it to 2400. Does the app does the auto-detection or is set at a given rate?
Thanks
My x-lite pro with build in bluetooth .
I can connect but sometime i cannot connect. at this time i need to go to main screen, kill the task of app. then open it and try to connect again. sometime it works, sometime not.
Feel like i need luck to connect with app.
My TX bluetooth only have 40000 and 112000. it doesnt have 570000 baud rate.
Hello,
With FTDI converter you don't need to have inverter.
Connect it as follows:
Transmitter -> FTDI (only need to connect GND and FTDI RX line to Inverter signal wire) -> OTG -> Phone
But, you only need to invert RX/TX on FTDI by FTDI configuration software (FT_PROG).
My x-lite pro with build in bluetooth .
I can connect but sometime i cannot connect. at this time i need to go to main screen, kill the task of app. then open it and try to connect again. sometime it works, sometime not.
Feel like i need luck to connect with app.
My TX bluetooth only have 40000 and 112000. it doesnt have 570000 baud rate.
Try deleting your BT device from paired BT devices on Android phone
Lenovo Yoga Smart Tab YT-X705F. Android 10.
Application stops.
I've got an MLT-BT05
I'm unable to get it to connect, ive tried a few different AT commands
any ideas?