Problem with readout of temp data

Hello,
I am using MIT App Inventor to display the output from a temperature device via Bluetooth. The app works well with one exception. It will display the current temperature, say 84, and then the next reading will show 884 instead of just 84. 884 may display a few times and then it will show the correct temperature of 84. Following are the blocks for the App.

Can someone please explain how to correct this problem with the readout?
Thank you,
Scott

You need to use a line feed delimiter at the end of each message and to rig the AI2 side to check for that.

Here is the standard advice for that:

Please see the Delimiter article in FAQ

Be sure to use println() at the end of each message to send from the sending device, to signal end of message. 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.
BlueToothClient1_Properties
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.

Thank you for the reply and information.
I took another try at it, using a delimiter in the code and blocks on the AI2 side to check for that, as suggested. I changed the Bluetooth delimiter byte to 10 and added a block on the AI2 side for ReceivedText number of bytes -1. Unfortunately, the problem still persists. Here is what the AI2 side looks like now.

Any further thoughts would be appreciated.
Thank you,
Scott

Hello Scott - why does the input need to be split if you are only collecting one value?

You are setting input twice - should only be once, the first (number of bytes = -1) being correct, delete the other.

We would need to see your micro controller script (Arduino Sketch), but also consider the possibility that the sensor itself could deliver spurious values. What element is the sensor detecting the temperature of?

Also, how often is the temperature being read? Time intervals should be the longest practical for best results (Clock1 in your code). The App time interval should be approx 20% faster than the microcontroller send time interval.

I forgot to mention that you should ensure the heat output by your device does not influence the output of the temperature sensor. That can happen in two ways - heat dissipation across the board reaching the sensor and/or cooled air from the cooling fan being emitted across the path of the sensor. Both are common mistakes.

Hi Chris,

First, thank you for your willingness to assist. I just started working with MIT App Inventor.

As you will see below, I made some changes on the AI2 side. I now do not get a readout, only a complaint from the App about bad arguments (operation select list item cannot accept the arguments:,["778|"],[1]).

Here is what the Arduino code looks like.


// REQUIRES the following Arduino libraries:
// - DHT Sensor Library: https://github.com/adafruit/DHT-sensor-library
// - Adafruit Unified Sensor Lib: https://github.com/adafruit/Adafruit_Sensor

#include "DHT.h"
#define DHTPIN 2 // Digital pin connected to the DHT sensor
#define DHTTYPE DHT11 // DHT 11

// Connecting up the DHT11 Temperature and Humidity Sensor --
// Connect pin 1 (far right) of the sensor to Ground
// Connect pin 2 of the sensor to VCC 5 volts
// Connect pin 3 (far left) to DHTPIN

// Initialize DHT sensor.
DHT dht(DHTPIN, DHTTYPE);

void setup() {
Serial.begin(9600);
dht.begin();
}

void loop() {
// Wait a few seconds between measurements.
delay(2000);

// Read temperature as Fahrenheit (isFahrenheit = true)
float f = dht.readTemperature(true);

Serial.print((int)f);
Serial.println("|");

}


Since the time between temp readings is 2000 ms I changed the clock timer to be at 80% or 1.6 ms as per your recommendation.

I look forward to your thoughts.
Thank you,
Scott

Hi Scott

Well, you are nearly there. The reason for the error message is that you do not receive a List of values, so the data should not be handled as though it were a List.

Your Serial Output is therefore wrong too and since the sensor reading is a float, it's best to send that value to the App. If you want to round the value to an Integer you can do that in the App.

Serial.print((f,2); // Send a Float value of 2 decimal places
Serial.println(); //Sends ascii character number 10 to tell App 'end-of-data'

The following snippet will hopefully be enough change to get your Project working but there is a lot more required to build a reliable App.

See this basic example Project. Many have used it as the base for their own App, it uses some tips and tricks that you will find on my website:

BT_Basic_Setup_ReceiveOne.aia (9.1 KB)

.... and a basic Sketch:
ClassicBt_Arduino_ToApp.txt (738 Bytes)

Note that updating a value every two seconds is hard for the eyes to tolerate. It is always the case that the time interval should be as long as is practical. I recall a student's App that was designed to water flowers periodically..... every second!

https://www.professorcad.co.uk/appinventortips

Hi Chris,
Thank you very much for the information and tips. It is most appreciated. I will try today to incorporate these changes today and hopefully get the app working soon.
I have a few more questions, if you con't mind.
First, do you know of an actual course I can take in order to get better at using MIT App Inventor?
Second, if you want to build an app for commercial applications, would you use MIT App Inventor or take another approach?
Thank you,
Scott

I actually would, yes. There might be some things that App Inventor could not deliver on adequately but I don't know of that many - probably the weakest part is in the area of action games, the Canvas could do with an overhaul but then there are languages dedicated to games so they are going to be the best choice most times.

I have been programming (mostly engineering software) with various languages for forty years - some you take to like a duck to water, some you really hate using.

With App Inventor you can build quickly. It's executable is reasonably lean and fast. It's learning curve is fairly smooth. It's free. Technical support is free. You get free grey hair and headaches thrown-in too. What's not to like?

Hi Chris,
Thank you for your reply. Good to know!
Best regards,
Scott

Thank you very much for all the good information! I will keep this handy for future reference.
Best regards,
Scott

Hi Chris,
I have a few questions about the blocks above that you provided, if you don't mind.
First, I am not sure where to find the "call Notifier1.ShowAlert" block. Please advise.
Also, would you please explaining what the "whenScreen1.inilization" blocks are doing?

Thank you,
Scott

You can find the notifier in the user interface category
http://ai2.appinventor.mit.edu/reference/components/userinterface.html#Notifier

It sets a few properties of the clock... alternatively you can set it in the designer

A very good way to learn App Inventor is to read the free Inventor's Manual here in the AI2 free online eBook http://www.appinventor.org/book2 ... the links are at the bottom of the Web page. The book 'teaches' users how to program with AI2 blocks.
There is a free programming course here http://www.appinventor.org/content/CourseInABox/Intro and the aia files for the projects in the book are here: http://www.appinventor.org/bookFiles
How to do a lot of basic things with App Inventor are described here: http://www.appinventor.org/content/howDoYou/eventHandling .

Also do the tutorials http://appinventor.mit.edu/explore/ai2/tutorials.html to learn the basics of App Inventor, then try something and follow the Top 5 Tips: How to learn App Inventor

Taifun


Trying to push the limits! Snippets, Tutorials and Extensions from Pura Vida Apps by icon24 Taifun.

Excellent! Thank you very much.
Scott

Hi Chris,
Following is what the App looks like now.

Unfortunately, I am still having the same problem as before. The temp readout is fluctuating and getting readings like 83.66, 882.12, 2.12, etc.

Here is the Arduino code.

// Initialize DHT sensor.
DHT dht(DHTPIN, DHTTYPE);

void setup() {
  Serial.begin(9600);
  dht.begin();
}

void loop() {
  // Wait a few seconds between measurements.
     delay(2000);

//   Read temperature as Fahrenheit (isFahrenheit = true)
     float f = dht.readTemperature(true);
      Serial.print(f,2);  // sends a float value of 2 decimal places
      Serial.println();   // Sends ascii character number 10 to tell App 'end-of-data'
}

Further ideas?
Again, thank you for your assistance.
Scott

  1. In the Sketch, initialize value f outside of the loop (at the top of the Sketch).
  2. Use the elapsed milliseconds method of timing the loop as per my example (instead of using delay())
  3. Increase the loop interval - try 5 seconds

Whether or not that fixes the output, it's a more robust control. However, ultimately you could be looking at a hardware issue as I have previously described, or the sensor is not being fed the correct voltage/amps, or the sensor is faulty.

Hi Chris,
The readouts seem to be behaving themselves now. They look very good.
Thanks so much for the assistance. It is most appreciated!
Scott

:grin: Good to know.

Hi Chris,
I have a different issue that has come up. I am not sure if the forum etiquette calls for me to set up a new post but I will start with you in case it is okay.
You just helped me get my App working well using digital temperature data from a DHT11 temperature sensor. I tried to use the same App to read digital data output (at the same 10 second rate) but sourced from a load cell. This is causing the App to freeze.
Any thoughts on why this might be happening?
Thank you.
Scott