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.
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.
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".
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:
Recommendation to leave Clock1 Timer disabled until it is needed:
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".
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. http://www.brokking.net/yabr_main.html 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.