Asking for help to send a byte using Bluetooth every 20 millis

I'm attempting to build a remote controller app. It will only send data over bluetooth and not receive. The gui will set a global byte to '00000000' when there is no control input. This byte does not need to be sent over the bluetooth connection. The gui will set the byte to something else when there is input. The gui event sets the byte and the event can be used to send the byte one time to the bluetooth connection. I am attempting to use a 'Clock timer' to repeatedly send the value to the bluetooth connection. Every 20 millis would be great. I can only get my app to send at about every 1 second. I calculate a difference between 'current_millis' and 'prior_millis' and compare the difference to a 'delay_mills' but I cannot get the bluetooth message frequency to change.
Anybody see what I'm doing wrong?

How do I provide a copy of the entire app for this group to examine.

What are your Clock1 settings in the Designer?

P.S. It is safer to wrap the BlueTooth transmission block with a test to insure you only transmit when BlueTooth is connected, to avoid 507 errors.

I set interval to '1'.

OK - I do need to do that - I'm getting a lot of the "506 errors".

You are now in the territory of AI2 block execution speed overhead.
Don't expect 1 ms intervals for the Timer, even with an empty Timer block.
Experiment to find your overhead.

It would help to see the code that changes the byte for YABR value, and its global init value.

We don't know if the fire hose starts at app startup and has continually run since then.

Is there another event type than the 'when ___ Dragged' that could be used. The bluetooth message can be sent from within it and it reliably sends an updated byte much more frequently. But if it does not see some sort of movement then no message is sent. There is a "TouchUp" that indicates that there is no input, but I'm thinking more along the lines of "StillTouched".

People use the TouchDown and TouchUp events to start and stop the Clock Timer.

Those events also are there for Buttons.

I can attach another screen grab of the app blocks. What is the best way to provide everything that would be helpful.

Please download and post each of those event block(s)/procedures here ...
(sample video)


Please export your project and post it here.
(for what the blocks images don't show).

The 'aia' file:
YABR_Controller.aia (7.3 KB)
The 'png' files:

blocks (9) blocks (8) blocks (7) blocks (6)

blocks (15) blocks (14) blocks (13)

Some observations ...

The Ball component has a flag that will set it to return its center X and Y, useful to avoid having to subtract the Ball radius for reporting its position.

If you would like to disconnect on error:
Disconnect on error

Recommendation to leave Clock1 Timer disabled until it is needed:
Clock1 Designer recommendation
also a more feasible Timer Interval

Avoiding BT errors in the Clock1 Timer:

Turning on the Clock Timer when Ball TouchUp:

(All blocks are draggable into the Blocks Editor workspace.)

I have run out of speed recommendations.

Here's one more idea on bit manipulation:

The bitwise or math block can combine bit masks without risk of collision overflow, so it is better than the math '+' block for 'or' operations.

I may not be understanding when the '.Touchup' event occurs, but I have the impression that it occurs when your finger is lifted from the screen.
I understand that this is different from "holding" your finger (without moving) on the screen and not triggering a ".Dragged" event for the object.
I'm hoping to come up with a way to send the position while not triggering a ".Dragged" and also not a ".Touchup".
The ".Touchup" will return the ball to the center and mean that there is no byte to send over the bluetooth connection.
The goal is to send the ball position after the ".Dragged" and until the ".Touchup". It should be sent every ~20 milliseconds unless it is "00000000".

You have given me some very valuable suggestions that I will add to the app.
Thank you.

I'll spend some time experimenting with a 'Clock.enable' in the '.Dragged' and a 'Clock.disable' in the '.Touchup'.

Thanks again

Hello Russell

Something you are up against with the Clock Timer is that it using the standard OS timer - low priority and therefore not entirely accurate. If your App is only for your use, you may be able to optimise it to suit your requirements, but if you intend to distribute the App, different phones could differ in performance levels.

Why does your remote control have to send a value so fast? I assume there is more than one value, for different commands. Can you tell us more about your project on the hardware side? Are you using a microcontroller?

Our colleague Anke has developed an extension to yield better timer accuracy:

The app may have a small audience. There is an Arduino robot project call "Your Arduino Balancing Robot" by Joop Brokking. I'm building on that design. It uses a second Arduino with a WII nunchuck as the controller. I'm hoping to replace the use of the nunchuck with a smart phone app.
The code on the robot Arduino expects to receive an "action byte" about every 20 milliseconds. The byte uses each of the first 4 bits for 'left','right','forward',and 'reverse'. When the bits are '0000' then the Arduino code slowly brings the robot to a standing stop. The longer any other combination of the bits is received the faster the robot goes. By 'longer' I mean that the same code is received every 20 millisec for a period of time.
Obviously the Arduino code could be redesigned to continuously act until a new byte was received from this app but it would be a big change to that code.
I hope that this provides a reasonable amount of background as to what I'm working on. The app may already have been built - but I couldn't find it.

OK, so if the signal is sent within a range of 15 to 25 milliseconds, that should be OK. You would want to hold a button down, but control the signal send with a timer, so when the button is released, the timer should be disabled. Note, "Timer Always Fires" should be permanently disabled, it's there to allow the timer to continue to work when the App is not displayed on screen, which does not fit your scenario.