FrSky telemetry app for Android phones - Page 11 - RC Groups
Shop our Airplanes Products Drone Products Sales
Thread Tools
Aug 17, 2012, 09:24 AM
Registered User
Trevor_G's Avatar
I was after a quick fix so I just passed the data across in public instance variables and used the handler to trigger the transfer. That way I could use the counter as a flag. I have put the relevant code in the attachment. Not the most elegant code I have written but it works!

I don't know if this is your current problem but sooner or later it is going to cause problems.

Trevor
Last edited by Trevor_G; Aug 17, 2012 at 09:31 AM.
Sign up now
to remove ads between posts
Aug 17, 2012, 10:37 AM
Registered User
Takilara's Avatar
Quote:
Originally Posted by Trevor_G
I don't know if this is your current problem but sooner or later it is going to cause problems.

Trevor
Thanks.
When running with only analog sensors, we have very little corrupt frames. At least on my own testing (slowest device HTC desire). When running with hub, I have had some strange behaviors that could be related to such a race condition. In theory this issue should not cause more problems than a few corrupt frames, and not problems connecting though. If this happens in frsky dashboard, evidence should be in the log that sh4nce mentioned as all corrupt frames are logged.

I have some experience with certain phones having a buggy Bluetooth implementation like HaPe mentions, and find this more likely to cause the connection problems.
Last edited by Takilara; Aug 17, 2012 at 10:38 AM. Reason: mention logging
Aug 17, 2012, 11:24 AM
Registered User
Quote:
Originally Posted by Takilara
Thanks!
we are indeed using unaltered version of that method from BlueTerm/BluetoothChat.

We will see about how we can change this. Building the buffer synchronous while processing frames asynchronous should be possible. (running the frame processing synchronous has had too many performance challenges in the past on older phones)


I am not 100% sure that this is related to the current bug that Clivew is seeing though?
FRS_Logger does synchrone frame processing and uses a global array to forward the result to other routines rather to use a handler. This works without processing problems - even with older mobile phones, But this has nothing to do with clive's problem
Aug 17, 2012, 05:27 PM
Registered User
Takilara's Avatar
Quote:
Originally Posted by Takilara
(running the frame processing synchronous has had too many performance challenges in the past on older phones)
Oops, I described this wrong. We had performance problems when using broadcasts and running synchronous. Our current frame processing is still synchronous but work ok as long as we no longer use broadcasts
Aug 17, 2012, 06:21 PM
Registered User
sh4nce: Could you pm me your email please?
The file is too big for a private message on here.

Thanks,

Clive
Last edited by clivew; Aug 17, 2012 at 06:39 PM.
Aug 18, 2012, 01:06 AM
Registered User
sh4nce's Avatar
Done.
Aug 18, 2012, 05:20 AM
Registered User
Done! I sent you the file Hans

Thanks,

Clive
Last edited by clivew; Aug 18, 2012 at 06:05 PM.
Aug 19, 2012, 10:17 AM
Registered User
sh4nce's Avatar
Quote:
Originally Posted by clivew
Done! I sent you the file Hans

Thanks,

Clive
Hi Clive


Well received thank you. I'll let you know if I find something.
Aug 24, 2012, 03:48 PM
Registered User
An update Hans.

I gave up with the Neon, and got one of these instead http://www.amazon.co.uk/gp/product/B...ls_o01_s00_i00
It appears to work perfectly so far.
Thanks for your help,

Clive



Quote:
Originally Posted by sh4nce
Hi Clive


Well received thank you. I'll let you know if I find something.
Aug 29, 2012, 03:46 AM
Registered User

FRS Logger Basic now on Google Play


Hello,
The free of charge FRS Logger Basic is now also available on Google Play to allow easy installation and app testing.
https://play.google.com/store/apps/d...dlcl9iYXNpYyJd
Regards
HaPe
Aug 29, 2012, 05:43 AM
PEMAC
SleepySean's Avatar
I have received my usb-ttl adapter, so can now do some testing as to why the app runs fine for all, and for me when not receiving data, but crashes when receiving data after 20-30 seconds. Having never used one of these before, I'll be learning as I go and will post here in case others want the info.

First step will be to ensure my BT module is set to 9600bps, 8bit, No parity, 1 stopping bit. What's the best way to do this, I need a terminal program, correct?
Aug 29, 2012, 07:31 AM
Registered User
Quote:
Originally Posted by SleepySean
I have received my usb-ttl adapter, so can now do some testing as to why the app runs fine for all, and for me when not receiving data, but crashes when receiving data after 20-30 seconds. Having never used one of these before, I'll be learning as I go and will post here in case others want the info.

First step will be to ensure my BT module is set to 9600bps, 8bit, No parity, 1 stopping bit. What's the best way to do this, I need a terminal program, correct?
Hi SleepySean,
provided all connections are made correctly everything should work fine without any need to use a terminal program. With a 9600 bit/s BT module incl. UART or inverter its a kind of plug and play procedure.

Since you obviously have problems to get it running a terminal program is the easiest way to check whether the BT connection works properly. There are many free of charge programs available. I use HTerm (http://www.der-hammer.info/terminal/) on my PC or uConnect on my smartphone (https://play.google.com/store/apps/d...JfcGhvbmUiXQ..)

You need to establish a BT connection from your FrSky transmitter module (DHT) to your PC/Laptop (virtual com port) or smartphone ( BT SPP). If the serial COM settings are correct you will see the incoming FrSky data bytes.
The terminal HEX values allow you to compare the incoming data with the published FrSky telemetry protocol to see whether the hub data is send or not.
Since both the BT module and the FrSky transmitter module use 2.4 GHz its possible that the data transfer gets corrupted or interrupted if the modules are very close to each other. Some centimeters ( > 2-3 cm) should be between the BT antenna and the DHT module.
As soon as all is correctly set up you should not have crashes anymore.
Regards
HaPe
Aug 29, 2012, 08:57 AM
PEMAC
SleepySean's Avatar
Ah, I tried increasing the distance from bt to phone, but not increasing distance from bt to FrSky antenna - they are only 3cm apart. I will try that tomorrow.

I do get data on the app before crashes ( rpm, Ad1, ad2 and cell v).
Aug 29, 2012, 03:04 PM
Registered User
Quote:
Originally Posted by SleepySean
Ah, I tried increasing the distance from bt to phone, but not increasing distance from bt to FrSky antenna - they are only 3cm apart. I will try that tomorrow.

I do get data on the app before crashes ( rpm, Ad1, ad2 and cell v).
I learned that its not so much the distance to the DHT antenna but the distance and position to the DHT processor.

For me it works best if the BT module is 90 degree to the DHT module. 5 mm distance to the DHT antenna is ok. But even 3 cm distance to the DHT processor causes interruptions if the BT module is in line with the DHt module.
Aug 30, 2012, 11:29 AM
Registered User
sh4nce's Avatar
Quote:
Originally Posted by clivew
An update Hans.

I gave up with the Neon, and got one of these instead http://www.amazon.co.uk/gp/product/B...ls_o01_s00_i00
It appears to work perfectly so far.
Thanks for your help,

Clive
That's good news. Have fun!


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Cool Android Phone App - Center of Gravity Calculator pardus Modeling Science 13 Apr 09, 2015 12:42 PM
New Product Android Phone App - RCEcalc - Electric Flight Calculator pardus Electric Plane Talk 0 Jan 14, 2011 03:43 AM
Cool Android Phone App - Center of Gravity Calculator pardus The Builders Workshop 6 Oct 18, 2010 03:02 PM
Cool Android Phone App - Center of Gravity Calculator pardus Electric Plane Talk 1 Oct 16, 2010 07:07 AM