Hola, en este momento me encuentro desarrollando una App para un proyecto en la Universidad el cual consiste en utilizar un modulo Gps conectado a Arduino y enviarle la Latitud y Longitud a la aplicación mediante el modulo Bluetooth pero cuando quiero que me salgan los valores AppInventor aproxima los numeros y la ubicación en el mapa es la incorrecta. alguna idea de como evitar la aproximación ?
Your problem needs a better description. The gps coordinates are coordinates sent by the arduino to your app but the latitude/longitude coordinates received by your app are incorrect. Please provide an example showing what you mean by 'incorrect'. Are the coordinates truncated or do not have enough decimal places or not precise enough?
The gps module sends latitude/longitude to the arduino, and those numbers have several decimals but when I send from the arduino to the application those numbers with decimals it only approximates them, for example:
I am sending from the arduino to the App: -74.10195612
and the application only shows me: -74.10
the other decimals are disappearing and it is not giving me the exact location of where the gps module is connected.
APLICATION
ARDUINO PROGRAM
Try sending from the arduino as text/string
It would really help if you provided a screenshot of your relevant blocks, so we can see what you are trying to do, and where the problem may be.
To get an image of your blocks, right click in the Blocks Editor and select "Download Blocks as Image". You might want to use an image editor to crop etc. if required. Then post it here in the community.
Taifun
Trying to push the limits! Snippets, Tutorials and Extensions from Pura Vida Apps by 
Taifun.
I understand now. 
I expect that the coordinates are being truncated in the bluetooth part of your app.
As Taifun suggests, share your Block code and arduino script and someone might find where the arduino coordinates are being truncated.
Be sure to use println() at the end of each message to send from the sending device, to signal end of message.
Only use print() in the middle of a message.
Be sure not to println() in the middle of a message, or you will break it into two short messages and mess up the item count after you split the message in AI2.
Do not rely on timing for this, which is unreliable.
In the AI2 Designer, set the Delimiter attribute of the BlueTooth Client component to 10 to recognize the End of Line character.
Also, return data is not immediately available after sending a request,
you have to start a Clock Timer repeating and watch for its arrival in the Clock Timer event. The repeat rate of the Clock Timer should be faster than the transmission rate in the sending device, to not flood the AI2 buffers.
In your Clock Timer, you should check
Is the BlueTooth Client still Connected?
Is Bytes Available > 0?
IF Bytes Available > 0 THEN
set message var to BT.ReceiveText(-1)
This takes advantage of a special case in the ReceiveText block:
ReceiveText(numberOfBytes)
Receive text from the connected Bluetooth device. If numberOfBytes is less than 0, read until a delimiter byte value is received.
If you are sending multiple data values per message separated by | or comma, have your message split into a local or global variable for inspection before trying to select list items from it. Test if (length of list(split list result) >= expected list length) before doing any select list item operations, to avoid taking a long walk on a short pier. This bulletproofing is necessary in case your sending device sneaks in some commentary messages with the data values.
Some people send temperature and humidity in separate messages with distinctive prefixes like "t:" (for temperature) and "h:" (for humidity).
(That's YAML format.)
The AI2 Charts component can recognize these and graph them. See Bluetooth Client Polling Rate - #12 by ABG
To receive YAML format messages, test if the incoming message contains ':' . If true, split it at ':' into a list variable, and find the prefix in item 1 and the value in item 2.
...
i have this test code and this shows the app, i changed the bit delimiter in bluetooth client and it is still the same
change in the arduino ide to char type and the app does not receive it.
Use Do it and show us the Do it result of Lista
EDIT: use a global variable for this
use Do it to debug your blocks, see also tip 4 here App Inventor: How to Learn | Pura Vida Apps
see also Live Development, Testing, and Debugging Tools
Taifun
Trying to push the limits! Snippets, Tutorials and Extensions from Pura Vida Apps by Taifun.
I see from your screen shot that both the lat and log are truncated.
Also, the latitude is rounded from 4.56518... to 4.57 so this is not a truncation problem, but a data type precision problem.
Check your Arduino language manual for higher precision data types than float.
From
float
[Data Types]
Description
Datatype for floating-point numbers, a number that has a decimal point. Floating-point numbers are often used to approximate analog and continuous values because they have greater resolution than integers. Floating-point numbers can be as large as 3.4028235E+38 and as low as -3.4028235E+38. They are stored as 32 bits (4 bytes) of information.
Syntax
float var = val;
Parameters
var: variable name.
val: the value you assign to that variable.
Example Code
float myfloat;
float sensorCalbrate = 1.117;
int x;
int y;
float z;
x = 1;
y = x / 2; // y now contains 0, ints can't hold fractions
z = (float)x / 2.0; // z now contains .5 (you have to use 2.0, not 2)
Notes and Warnings
If doing math with floats, you need to add a decimal point, otherwise it will be treated as an int. See the Floating point constants page for details.
The float data type has only 6-7 decimal digits of precision. That means the total number of digits, not the number to the right of the decimal point. Unlike other platforms, where you can get more precision by using a double (e.g. up to 15 digits), on the Arduino, double is the same size as float.
Floating point numbers are not exact, and may yield strange results when compared. For example 9.0 / 0.3 may not quite equal 30.0. You should instead check that the absolute value of the difference between the numbers is less than some small number.
Conversion from floating point to integer math results in truncation:
float x = 2.9; // A float type variable
int y = x; // 2
If, instead, you want to round off during the conversion process, you need to add 0.5:
float x = 2.9;
int y = x + 0.5; // 3
or use the round() function:
float x = 2.9;
int y = round(x); // 3
Floating point math is also much slower than integer math in performing calculations, so should be avoided if, for example, a loop has to run at top speed for a critical timing function. Programmers often go to some lengths to convert floating point calculations to integer math to increase speed.
@ABG It gave me the idea of how to solve it because it was simpler than I thought, arduino was sending only 2 decimals and approximating so I had to tell the program how many decimals it needed to send to the application.
you have to count how many numbers there are after the decimal point and indicate it in the serial print.
1 Like
Glad you found the problem. Be aware, it is not necessary or practical to capture more than 6 or 7 decimals of latitude or longitude.
The following is from coordinates - Measuring accuracy of latitude and longitude - Geographic Information Systems Stack Exchange
table of what each digit in a decimal degree signifies:
- The sign tells us whether we are north or south, east or west on the globe.
- A nonzero hundreds digit tells us we're using longitude, not latitude!
- The tens digit gives a position to about 1,000 kilometers. It gives us useful information about what continent or ocean we are on.
- The units digit (one decimal degree) gives a position up to 111 kilometers (60 nautical miles, about 69 miles). It can tell us roughly what large state or country we are in.
- The first decimal place is worth up to 11.1 km: it can distinguish the position of one large city from a neighboring large city.
- The second decimal place is worth up to 1.1 km: it can separate one village from the next.
- The third decimal place is worth up to 110 m: it can identify a large agricultural field or institutional campus.
- The fourth decimal place is worth up to 11 m: it can identify a parcel of land. It is comparable to the typical accuracy of an uncorrected GPS unit with no interference.
- The fifth decimal place is worth up to 1.1 m: it distinguish trees from each other. Accuracy to this level with commercial GPS units can only be achieved with differential correction.
- The sixth decimal place is worth up to 11 cm: you can use this for laying out structures in detail, for designing landscapes, building roads. It should be more than good enough for tracking movements of glaciers and rivers. This can be achieved by taking painstaking measures with GPS, such as differentially corrected GPS.
- The seventh decimal place is worth up to 1.1 cm: this is good for much surveying and is near the limit of what GPS-based techniques can achieve.
- The eighth decimal place is worth up to 1.1 mm: this is good for charting motions of tectonic plates and movements of volcanoes. Permanent, corrected, constantly-running GPS base stations might be able to achieve this level of accuracy.
- The ninth decimal place is worth up to 110 microns: we are getting into the range of microscopy. For almost any conceivable application with earth positions, this is overkill and will be more precise than the accuracy of any surveying device.
So it is not necessary to capture 13 or 16 decimal places and it might actually slow Bluetooth communication.
Thanks for posting your SerialBT.print decimal information. 
1 Like
Thanks for telling us about the Arduino print(variable, number) syntax and semantics.
Apparently, the PRINT verb has different interpretations in different languages.
My Dartmouth BASIC memories would have sent me down a different rabbit hole, expecting to see a '16' in the output stream.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.