I have attached the screenshots displaying the error aswell as the blocks in which it is displayed. In that block stating " if label5>=label 10" -- label 10 is the block below the slider where i can set a specific value ; when this value will be equal to the value in label 5( which is the block below the text "SENSOR VALUE" which shows live data from sensor) then a voice command is supposed to play saying " gas leak".
Instead just after getting connecting it displays the " bad error" message
--
We need to see more blocks to diagnose this.
--
That > operation does not occur in your post.
Do a "download Blocks Image" on a blanks spot of the Blocks Editor to get them all.
For good measure, also include the .aia export,
and the sketch generating the data.
and the sketch generating the data
It looks like your transmitting side is sending multiple readings at a time.
Show us the transmission code.
See attached for my best guess without seeing the transmission code.
--
Since the incoming readings are listed vertically in the error message
I infer they are being sent with a println(), so a delimiter is needed
in the BT Client of 10.
(10 = LF in decimal.)
So I set the delimiter to 10 and asked for -1 bytes in the ReceiveText,
to get just 1 println() worth of data at a time.
Yes it is sending reading from the sensor continuosly , is there a problem in that ?
Yes it is sending reading from the sensor continuosly , is there a problem in that
That's not a problem,
as long as you use the delimiter and try to read twice as frequently as you transmit.
--
I looked at your .ino sketch.
--
You are blasting out readings as fast as posssible, with no delay between them.
See the examples in my FAQ for how to slow down the .ino transmitting side with delays.
(FYI - Ai2 has no delay capability, just clock events).
It's all in the .aia I posted a few posts ago.
--
Download attachments .aia,
Project -> import from my PC ...
See attached if you want to do it yourself.
Turning in for the night, 11 PM here.
Thank you so much . I made the changes you told and now the prior errors are gone and the app works fine now but there's new issue at hand.
1) The APP CRASHES after 3 mins of use .
2) I am using a slider to adjust the threshold value going above which the app does give the "LEAKAGE ALERT",that part is fine. Now i want my arduino to recieve the values set by the slider in the app so that when the "alert message " is given by the app , the LED would also glow at the same time.I cannot figure out how to do this.
These are the two current situations for which I need help !
For reading the value from the slider, your sketch must be able to receive it. For example, it should start with something like this:
void loop()
{
//Receives commands from remote computer:
if (serial.available())
{
int inByte = serial.read();
serial.println((char)inByte);
switch ((char)inByte)
{
//Actions:
...
For finding the cause of your crash, you should post your newest set of blocks.
-- void loop()
{
//Receives commands from remote computer:
if (serial.available())
{
int inByte = serial.read();
serial.println((char)inByte);
switch ((char)inByte)
{
//Actions:
...
For finding the cause of your crash, you should post your newest set of blocks.
I forgot to post the link to my FAQ, with its
--
Arduino and Bluetooth sample section: Arduino and Bluetooth
Also use the search facility in this board for "gas sensor".
Sorry , I had been away due to some family emergencies. I have attached my recent blocks. The crashing issue has become much more troublesome. The slider gets stuck after 2-3 times of sliding it and then the app crashes. PLEASE HELP! My project is due tomorrow!
I have two suggestions...
--
Regarding the Slider position changed event, it may need an extra layer of indirection in
its actions, to deny it any possibility of getting "stuck" trying to something that may hang.
To do that, I suggest adding an extra global variable, LastSliderPosition, initially 0.
Whenever the slider position changed event fires, do nothing.
Move the processing of a new slider position into the clock.timer event block,
guarded by an if/then test of the currrent slider.position value against LastSliderPosition.
If the slider hasn't changed position do nothing, else update LastSliderPosition and send the new value
of the slider position over the wire.
Secondly, add a speech queue to avoid asking the speech component to talk again
while it still hasn't finished saying its previous message.
Use the .AfterTalking block to service the queue.
Third, I see you are sending at a rate of 20 ms per reading, but reading at a rate of 1 reading per second.
Is the data piling up in an AI2 buffer 50 times faster than it is being processed, causing the crash?
I suggest copying the BTbytesAvailable value to a label each time it is taken, for a clue.
Does the value keep increasing, suggesting a big backlog that needs to be flushed?
"copying the BTbytesAvailable value to a label each time it is taken," - can you be a little more specific ,sir.
To test my mental model of how BlueTooth delimiter blocking works, I coded my suggestions.
--
I also speeded up the AI2 timer to 200 ms, just 10 times slower than your sensor.
But I do not have a device to test them, so I leave that to you.
Let me know what happens?
See attached blocks image and .aia file.
I just came up with another hypothesis for your slider crash.
--
What if the same antenna circuitry is being used to receive and send BlueTooth data
and it needs time to switch between receiving and sending?
Is that a consideration?
Sir, I dont think the circuitary will be an issue as we use bluetooth to send and much more data than this. As far as sendind and receiving is concerned ,i think it is internally designed to use seperate channels for it.
--
I have attached a video. The app isnt crashing anymore but s new problem has been added. It is saying "gasleak" even when the current reading is below threshold , this problem wasn;t there earlier.
Sir, I'm really stuck up.Waiting for your response .
In the video you uploaded I saw (since the values were not clear,I guessed them. So correct me if I'm wrong) that it showed GAS LEAK alert only when the sensor reading was above the threshold level . It showed gas alert only when you set the level to 101 (I guessed this since it was not clear) and the sensor reading at that time was around 109,110.
Yes sir, that is the idea but if you see the video till the end you will find that when I set threshold to 246 and the sensor reading shows 109 ,although it displays "System secure" it still keeps on saying the message " Gas Leak". That is the current problem.
I neglected to have the clock timer clear the speech queue
--
when it detected a normal condition.
To clear the speech queue variable, set it to empty list.
I see my backlog label shows 2000 bytes of unread messages piled up
--
in the BlueTooth Client.
You may notice I added a Click event to your unused Button1,
to clear both the speech queue and maybe the BlueTooth Client backlog.
I suggest adding the .Text "Reset" to that button
and trying it.
From the video, your app still suffers from an ever increasing backlog
in the BlueTooth Client that needs to be addressed.
you said "I also speeded up the AI2 timer to 200 ms, just 10 times slower than your sensor." Can you explain it to me why am I slowing it down, my sensors already displaying values fast enough, shouldnt I speed the AI2 timer to get par with the sensor? The concept is not really clear to me.
--
you said "I also speeded up the AI2 timer to 200 ms, just 10 times slower than your sensor." Can you explain it to me why am I slowing it down, my sensors already displaying values fast enough, shouldnt I speed the AI2 timer to get par with the sensor? The concept isnot really clear to me.
When I received your .aia file, it had the clock timer set to 1000 ms per cycle.
Your .ino had an inner loop of 20 ms, so that was a sending to receiving
ratio of 1000/20 = 50 transmissions to 1 reception.
I sped up the .aia timer to 200 ms, to give it a chance to run for a while, but
also for my ulterior motive of giving messages to pile up (if that mental model of
how it works) was correct. That's also why I added the extra label to show bTClient.BytesAvailable
to see if bytes piled up waiting to be read. That confirmed my hypothesis.
So it's okay to set the AI2 clock to 20 ms to match the transmitter.
But I can't guarantee the AI2 device will be fast enough to finish its work
before the next timer hits.
(In my FAQ on this board there's a section on timing with info from the
AI2 creators, more reliable than me.)
I think it would be safer to slow down the transmitter side to 40 ms,
and receive at 20 ms.
There's a data transmission law about the speed ratio,
whose name I can't remember at the moment.
So, should I set the AI2 timer to 20ms and give a delay of 40ms in my Arduino code?
So, should I set the AI2 timer to 20ms and give a delay of 40ms in my Arduino code?
Yes, try it.
But also watch that new BytesAvailable label, to see if your AI2 side is keeping up.
I used the recent .aia file. The maximum value of slider is set to 200 though the sensor shows around 300 and it doesnt speak anymore. See for yourself, I've attached a video.
The video was very short, but I managed to get a glimpse of the gas reading stuck at 200.
--
So it looks like the AI2 side has to leave its fishing net in the BlueTooth waters longer,
to get a fish before pulling it out of the water.
So try both at 20 ms, or both at 40 ms.
The final solution might be to leave the ai2 net in the water to collect a backlog,
then periodically empty the net.
Its 3 am 18th March over here .I will try it tomorrow morning.
--
--
I will be going offline for a day or two soon, so I throw this thread up
--
for whoever is available.
(self flushing added to BT buffer and single-message speech output added)
--
Going offline
I followed this discussing in the beginning, but I did not reply, because I had other things to do, I do not want to be pressured by projects due tomorrow, (that is your problem, not mine), and I do not want to be addressed as "sir".
It is however quite clear why your app keeps saying "gas leak": Your sensor transmits much faster than AI handles it, and at each timer event only one message is read. Therefore, at next timer events yopu will read "old" messages for a while and these are still saying that you have a gas leak.
For the AI side to keep up, the timer interval must be shorter than the interval the BT device is sending things, and long enough to handle incoming readings.
Then, there is another thing: what is the usefulness of sending gas readings every 20 or 40ms? It takes at least 2 seconds = 2000ms to say the message "gas leak". If this app is only meant for giving warnings to human beings, the interface could use human timings.
These two reasons would suggest to set the delay in the sensor to at least 1000ms and in AI to about 500ms.
I will take a look what effect the speach component still has.
It is however quite clear why your app keeps saying "gas leak": Your sensor transmits much faster than AI handles it, and at each timer event only one message is read. Therefore, at next timer events yopu will read "old" messages for a while and these are still saying that you have a gas leak.
For the AI side to keep up, the timer interval must be shorter than the interval the BT device is sending things, and long enough to handle incoming readings.
Then, there is another thing: what is the usefulness of sending gas readings every 20 or 40ms? It takes at least 2 seconds = 2000ms to say the message "gas leak". If this app is only meant for giving warnings to human beings, the interface could use human timings.
These two reasons would suggest to set the delay in the sensor to at least 1000ms and in AI to about 500ms.
I will take a look what effect the speach component still has.
you were right about the delay timings. The problem is solved .Thanks
Great! Cheers, Ghica
--
--
댓글 없음:
댓글 쓰기