Datatxt parsing issue

[mr23]

The parsing of Datatxt in the Calculation routine makes an assumption that the serial text stream records are always intact.

I have captured events when there is a partial "R" record which ends after some number (<64) of pixel values, and then in that same buffer after the partial data another "R" record is fully intact.

This type of 'data' event can be triggered by stopping the application in the debugger, stepping around, then continuing; or by using (at least) certain GUI button functionality.

Some time after such a trigger, the Datatxt buffer gets the combination of partial+full records. Without further digging I can't say if it is the IR chip's fault, or the app sending a command that causes the chip to do that, or a bug/design issue in the app causing it to mismanage the incoming text stream.

One way to compensate for the partial+full condition is to fix the parsing to not assume just one complete intact "R" record.

More specifically, when getting the index of "I", don't assume the first "I" is the correct one. Get the "X" index first, then get the LastIndexOf "R" prior to the "X", and the "I" similarly. I also recommend assuring that R, I and X have been found, with a proper order (and separation).

[mr23]

Accidentally clicked close.

[mardaso]

If you look in the sat_NewText sub routine there's a check on the length of the data stream (=405 and >192).
When I started in June 2012 B4A hadn't a good function for this. Now I would use data with a prefix but this would require a firmware update.
I'm also not happy with the way the data is send from the sensor to the phone this could be a lot smaller.
Also the BT connection is loosing data, when I put the same data on a usb connection it's far more stable.
This could be caused by the fact that the data from the uC is 'dumbed' to the BT modules, no data control at the moment.

But you're right the parsing of the data could use some improvement.
Don't forget that when connecting to the sensor first the eeprom data is send.

Be careful when you use the debugger function it slows down the app and will give you different results!

[mr23]

On the parsing; I changed:
For xPos = 0 To ((ePos - 7) - rPos) Step 6
sPos = rPos + xPos
iAddr = iAddr + 1
irVal(iAddr) = Datatxt.Substring2(sPos + 1, sPos + 7)

to:
For sPos = rPos+1 To ePos-1 Step 6
iAddr = iAddr + 1
irVal(iAddr) = Datatxt.Substring2(sPos, sPos + 6)
Simpler, clearer, fewer variables and additions.

[mr23]

I implemented a multiple-buffer approach for the incoming text, including Lock synchronization.
Now it is rarer to have 'bad' data (which is detected and rejected or exceptioned if breaks string conversion), and I can use any function of the application and the app picks right up and keeps on going, including any break/stepping in the debugger.
0.86 apk from google play still will lock up when some button functionality is used. I haven't tried to test/reproduce.
I haven't tried the 0.86 source you sent, so I don't know how it behaves.

[mardaso]

I thought you were referring to the 0.86 version. So my first comment makes no sense for the 0.60 version.
In the 0.86 the serial data is handled by the asyncstreams in a back ground task.
The 0.60 version is polling all the data and more 'picky' with the processor speed. That's why I changed to asynstreams. But maybe we could use some code in the 0.86 version.

[mr23]

I've only worked in B4A/Debugger with the 0.60 + my changes.
AsyncSt[r]eamsText was insufficient.
If for any reason the 'Calculation' is stalled, the _NewText can come in and overwrite DataCalc. Possibly before the assignment from the global in Calculation to Datatxt.
So I improved it to use multiple buffers, Locking, and assure those things can't happen.

[mardaso]

I saw that you have published your App on Google Play!
Wanted to try it but I can´t install it on any of my (5) Android devices.
Looks like there're some great new functions you added. Can't wait to try these out.

[mr23]

FYI I've also found out from Erel that modal dialogs will cause AsyncStreams to malfunction. I thought it was corruption, such as over-writing, when I was working with IR-Blue, but in fact it is re-ordering the substrings that AsyncStreams breaks an incoming message into. If you search around enough in the forums, you can find that bit about "don't use modal with AsyncStreams". Erel would not share the source for AsyncStreams, claiming it is a messaging queue problem. The latter concerns me more, as I wonder about the integrity of any message based operation when "something isn't perfect". If he had shared, I would have modified it to avoid splitting up the message in the first place, and submitted it to him as a design improvement.

[mardaso]

I read the discussion on the B4A forum.
This would explain the behavior when saving files. After saving files there´s a message on the screen and this could cause the crash some people have after saving. Will look into that and see if it´s more stable without the messages.
It´s only weird that not all phones have this problem.
Also not all phones-Android versions have the same BT implementation, I experience IR/Blue pairing problems now on my HTC one X after updating from 4.1 to 4.2. Maybe this has to do with the HTC BT4 implementation.