LiveCode Forums

Since BLE is not an ACK/NAK protocol, I need to "simulate" such an interface. In principle, it is quite easy and straightforward. For every time you write out from Livecode iOS to the receiving BLE device (an Arduino Adafruit Bluefruit module, in this case) via mergBLE, the Arduino "sees" the incoming data and replies with (literally) and "ACK".

The problem I am having (which is related to my experiences (of lack thereof) with mergBLE), is that the BLE card doesn't "run" in the background. in other words, the incoming ACK from the Arduino is only made available to the LC stack when the stack "goes idle" ... as good a term as I can invent for the message-passing methodology of a LC process. The incoming (to LC) ACK isn't lost... the hardware buffers it just fine, it's just that I need a way to get LC to "see" the ACK as soon as possible after the LC write... and that's just doesn't happen in "real time".

I know about putting a Group into the background... but that isn't the same sort of background I need... I need to be able to either:

- detach / fork / job (chose one depending on your big-system experience) a code segment/card/stack into the background .... I know iOS (since iOS 8, I think) can handle background processing ... BUT just how to do so in LC is unknown to me. If possible I'd run the whole BLE card in the background.

- somehow (without necessarily pushing a process into the background) trigger the current stack to READ the incoming message acquired by the mergBLE message handler "mergBLEPeripheralDidUpdateValueForCharacteristic".

The relation of this subject to my previous post regarding mergBLE is that since I cannot find a way to "use" individual aspects of the mergBLE "toolkit", I can't seem to find a way to call/invoke/trigger some other part of my LC code to fetch the incoming message.

Interestingly, if I "pause" my stack with an LC "answer" command, the incoming ACK mergBLE message gets processed by the BLE card as soon as the ANSWER window appears. I remember (I think... getting old!) reading that "ANSWER" is actually a separate stack (?sub-stack?)... I am guessing here but it seems like the act of waiting for a button push in an ANSWER invocation, it what allows the mergBLE card to run it's own message handlers and retrieve my ACK. Hopefully THAT makes sense to the reader.

So if someone could assist me in recommending a way to "simulate" what ANSWER does WITHOUT waiting for a user input/action, that would likely solve this particular problem.

ps: I know about using a looping command/function with a "send <message to myself> in <time>" as a way to produce a "semi-detached" process ... but that doesn't help unless it "allows" the BLE card to process its incoming messages. Tried it, doesn't do what I need.

Since BLE is not an ACK/NAK protocol, I need to "simulate" such an interface. In principle, it is quite easy and straightforward. For every time you write out from Livecode iOS to the receiving BLE device (an Arduino Adafruit Bluefruit module, in this case) via mergBLE, the Arduino "sees" the incoming data and replies with (literally) and "ACK".

The problem I am having (which is related to my experiences (of lack thereof) with mergBLE), is that the BLE card doesn't "run" in the background. in other words, the incoming ACK from the Arduino is only made available to the LC stack when the stack "goes idle" ... as good a term as I can invent for the message-passing methodology of a LC process. The incoming (to LC) ACK isn't lost... the hardware buffers it just fine, it's just that I need a way to get LC to "see" the ACK as soon as possible after the LC write... and that's just doesn't happen in "real time".

I know about putting a Group into the background... but that isn't the same sort of background I need... I need to be able to either:

- detach / fork / job (chose one depending on your big-system experience) a code segment/card/stack into the background .... I know iOS (since iOS 8, I think) can handle background processing ... BUT just how to do so in LC is unknown to me. If possible I'd run the whole BLE card in the background.

- somehow (without necessarily pushing a process into the background) trigger the current stack to READ the incoming message acquired by the mergBLE message handler "mergBLEPeripheralDidUpdateValueForCharacteristic".

The relation of this subject to my previous post regarding mergBLE is that since I cannot find a way to "use" individual aspects of the mergBLE "toolkit", I can't seem to find a way to call/invoke/trigger some other part of my LC code to fetch the incoming message.

Interestingly, if I "pause" my stack with an LC "answer" command, the incoming ACK mergBLE message gets processed by the BLE card as soon as the ANSWER window appears. I remember (I think... getting old!) reading that "ANSWER" is actually a separate stack (?sub-stack?)... I am guessing here but it seems like the act of waiting for a button push in an ANSWER invocation, it what allows the mergBLE card to run it's own message handlers and retrieve my ACK. Hopefully THAT makes sense to the reader.

So if someone could assist me in recommending a way to "simulate" what ANSWER does WITHOUT waiting for a user input/action, that would likely solve this particular problem.

ps: I know about using a looping command/function with a "send <message to myself> in <time>" as a way to produce a "semi-detached" process ... but that doesn't help unless it "allows" the BLE card to process its incoming messages. Tried it, doesn't do what I need.

I know little of these early 60's sitcoms of which you speak.

Sorry.

I know little of the particulars of which you speak.

But broadly, would sprinkling in a lot of: allow your app to "listen" to these other processes of which you speak?

Craig Newman

This post really should be a continuation of your original query to keep the information together. I’m not sure if a moderator can merge them though.

Can we see some of your code? It is very hard to answer your question in general terms, especially since I don’t have any experience with BLE. But, if I can see what you are doing that does/does not work I may be able to spot something. (And probably more for the more experienced around here.)

Hi Doug,

unfortunately I can not help with mergBLE but maybe this can help you.

Monte is not regularly scanning the Forum. But as you might have found out already he has a web-site dedicated to the merg externals.

http://mergext.com/home/mergble/

I suggest that you contact him directly via

http://goulding.ws/consulting/about/

just point him to your forum posts.


Or another possibility is to go to the use-list where a lot of advanced Livecode developers are.

(You have to apply to gain access to the use-list)
http://lists.runrev.com/mailman/listinfo/use-livecode

Here is what a quick search of the use-list returned

https://www.mail-archive.com/search?q=m ... runrev.com

I hope this helps.

Kind regards
Bernd

Both good points Brian.

bn wrote: ↑

Sat Apr 07, 2018 9:14 am

Monte is not regularly scanning the Forum.

My bad, I know I've seen him answer here, while I didn't think he was regularly on I did figure he was at least a once in a while visitor

Thanks Bernd!

I suspect I am not understanding your problem, but is it that you are trying to "listen" for another message while a handler is running, or while LC is quiescent? I am interested in that sort of thing in general, as a matter of knowing more about how LC thinks. So if you have a button and a field on a card, and in the button script: This is basic stuff. If you click on the button, the field increments via a running handler. If you press the commandKey, you are able to insinuate another "process" into the mix. Does this have anything at all to do with your question? In other words, can you set up a case where LC either "listens" or "interrogates" itself to detect this ACK thingie?

Craig

Thanks to all (so far .. keep 'em coming!) for the replies... first to bogs and bmilby ... I kept the two threads separate because although they both relate to mergBLE, they really are two separate topics and issues. Additionally, the first thread was getting so long, I didn't want readers to nod off getting to the end. I have added an additional discovery relevant to the "disconnect and re-connect to MergBLE" thread (I can now close/stop the connection but I still cannot re-start it).

Thanks, Craig... but I've done that sort of thing in several places within my code ... to no avail. I'm beginning to think I'm discovered a Copenhagen quantum wave function collapse condition in LC. If I don't try to look for the ACK, it appears in both fields I've coded the BLE_Card to put it:
- field "debugField" of card "anycaster_card1"
and
- field "fromAnycaster" of card "anycaster_card1"
If, on the other hand, I "wait" for the ACK to appear, it does not appear... until... ("on checkFrom" is located in the main (one and only) stack to ensure it is seen in the message pathway. It is called by a "mouseUp" handler on a scrollbar object located on my main card ... "doCheck" global variable is set to "true" before the call to "checkFrom")
...until ... And to reiterate a point, when the loop fails to find the ACK, the very act of "posting" an ANSWER cause the ACK to appear in the fields... the wave function collapses. Hence my need to an "ANSWER" type "pause" WITHOUT the required user interaction.

That's HUGE assist, Bernd!! I will follow your advice. I feel like I'm on the verge of success with this code if I can only get a bit more info about how mergBLE was implemented and how it interacts with LC

I will reply once I've managed to find more in info... as I'm sure this will be valuable to others.

Cheers! ... Doug

In your second code block, you are missing with messages on the wait.

One other way to structure that loop:

Yes,

Without "with messages", that command is blocking.

Craig

I've sent to message off to Monte begging for help (I ain't proud!). In the meantime, I went through every posting you extracted for me:
" ... Or another possibility is to go to the use-list where a lot of advanced Livecode developers are.
(You have to apply to gain access to the use-list)
http://lists.runrev.com/mailman/listinfo/use-livecode
Here is what a quick search of the use-list returned
https://www.mail-archive.com/search?q=m ... runrev.com ..."

AND the bottom line is:
... a BLE for Android is greatly desired ... are ya listening LC?
... no one is that whole list has done any significant work with mergBLE that they've noted or posted about.

now, I could be wrong about these interpretations but if anyone can prove otherwise, I'd be more than happy to kowtow!

Duplicate threads merged.

Going forward please post only one thread on a given topic so everyone can find the answers in one place.

dougr wrote: ↑

Fri Apr 06, 2018 9:29 pm

Interestingly, if I "pause" my stack with an LC "answer" command, the incoming ACK mergBLE message gets processed by the BLE card as soon as the ANSWER window appears. I remember (I think... getting old!) reading that "ANSWER" is actually a separate stack (?sub-stack?)... I am guessing here but it seems like the act of waiting for a button push in an ANSWER invocation, it what allows the mergBLE card to run it's own message handlers and retrieve my ACK. Hopefully THAT makes sense to the reader.

[SNIP]

ps: I know about using a looping command/function with a "send <message to myself> in <time>" as a way to produce a "semi-detached" process ... but that doesn't help unless it "allows" the BLE card to process its incoming messages. Tried it, doesn't do what I need.

Based on these 2 statements, I still think there is a logic issue with how you are attempting to structure the code. LiveCode runs on an event loop and responds to messages. If you try to run your own event loop, you are just going to end up blocking messages (which is what your checkFrom code does). The loop you describe in your PS would just be the timeout check (which is how I rewrote your checkFrom). The actual work should be done based on events coming back from the mergBLE code (on mergBLEPeripheralDidUpdateValueForCharacteristic).