Some issues and possible improvements

enniom

Hi Kl3m3n,

Some feedback from various tests, ideas, etc.

The new Bluetooth method and speed for connecting and reconnecting that’s been implemented works very well – thanks. That saves some frustration.
I’ve been using the Time Chart widget and found a few things to point out:
a. Code;
"|CH UID:ch22 YASC:0 VIS:1 X:65 Y:32 W:65 H:15 DRA:0 BGC:#000000 FGC:#FFFFFF CHT:0 CDTF:'HH:mm' BSZ:7200 FSZ:0.8 RAD:1.5 BTH:0 LT:0.2 XTC:8 XMA:5.0 YMA:3.0 YLO:1.5 YHI:5.0 YTC:9 VLP:1 DRAT:0.2 PZO:1 SHVL:0 CHN:'Values' SCI:1"

This chart will not show the y-axis with decimal points – only whole numbers. I don’t know if the decimal points were to be activated by VLP:1 as included in the definition?

b. If the definition is changed only by SHVL:1, then, if the y-values are greater than YHI, the graph is rescaled even though YASC:0. Maybe this override is needed to show the value at the right hand side of the Chart?

I understand from the Manual that the display properties needed to calculate the aspect ratio can be found using developer mode. It may be interesting to add a command that, after @init, the Android device can be polled to get the DPW and DPH values. This way, the uC can calculate the aspect ratio and set it to a value as part of the configuration.

[EDIT] Thinking more about this, it may be best to simply include the DPW/DPH values as part of the @init response. That is, something similar, for example, as the response to the RTC command: eg, @init 300:600. The uC can then choose to use or ignore the values in calculating the aspect ratio.

In cases where widgets are defined on each of the 5 pages (0-4), it seems that if a widget is defined for page 0 as VIS:1 SCI:0, then those widgets appear on all pages. I worked around the issue by first defining the widgets as VIS:0, then toggling them on by VIS:1 when page 0 is revisited. This does not happen for pages 1-4.

E

kl3m3n

@enniom Hi!

Thank you for the feedback, I appreciate it greatly.

I will check the issues you've pointed out and will get back to you shortly. Then we can discuss (and solve) them.

For DPW/DPH it is better to add a new command to keep the backward compatibility. I suppose users handle the @init message differently (e.g., using entire string for comparison, not just the starting characters) - I must not break this.

Best regards,
Kl3m3n

enniom

@kl3m3n Thanks Kl3m3n.

Sorry for the piecemeal approach, but I just noticed something about serial Bluetooth (not BTLE) connections.

If more than 1 device has been paired and previously used, then the "Automatically (re)connect" feature does not reconnect to the previously used one. Rather, when GUI-O is launched, the screen showing the available connection is shown with all the devices "disconnected". The user must choose one of them, then the process of connecting and initializing continues flawlessly.

E

kl3m3n

@enniom Hi,

this is by design - if you have multiple devices, the last connected device is not necessarily the device user wants to connect to when starting the app... I can make this an option though in the Bluetooth settings. It would be useful in some cases, I agree...

Best regards,
Kl3m3n

kl3m3n

@enniom said in Some issues and possible improvements:

Hi Kl3m3n,

Some feedback from various tests, ideas, etc.

The new Bluetooth method and speed for connecting and reconnecting that’s been implemented works very well – thanks. That saves some frustration.

I’ve been using the Time Chart widget and found a few things to point out:
a. Code;
"|CH UID:ch22 YASC:0 VIS:1 X:65 Y:32 W:65 H:15 DRA:0 BGC:#000000 FGC:#FFFFFF CHT:0 CDTF:'HH:mm' BSZ:7200 FSZ:0.8 RAD:1.5 BTH:0 LT:0.2 XTC:8 XMA:5.0 YMA:3.0 YLO:1.5 YHI:5.0 YTC:9 VLP:1 DRAT:0.2 PZO:1 SHVL:0 CHN:'Values' SCI:1"

This chart will not show the y-axis with decimal points – only whole numbers. I don’t know if the decimal points were to be activated by VLP:1 as included in the definition?

VLP applies to last value label (currently makes sense only with SHVL:1), not the axis. I could extend this so that VLP also applies to Y axis labels.

b. If the definition is changed only by SHVL:1, then, if the y-values are greater than YHI, the graph is rescaled even though YASC:0. Maybe this override is needed to show the value at the right hand side of the Chart?

I cannot reproduce this issue. If I create a chart:

"|CH UID:ch0 X:50 Y:50 YASC:0 SHVL:0\r\n"

then add a few points:

@ch0 YP:"1"\r\n
@ch0 YP:"5"\r\n
@ch0 YP:"20"\r\n

and set SHVL:1, the chart does not rescale.

I understand from the Manual that the display properties needed to calculate the aspect ratio can be found using developer mode. It may be interesting to add a command that, after @init, the Android device can be polled to get the DPW and DPH values. This way, the uC can calculate the aspect ratio and set it to a value as part of the configuration.

[EDIT] Thinking more about this, it may be best to simply include the DPW/DPH values as part of the @init response. That is, something similar, for example, as the response to the RTC command: eg, @init 300:600. The uC can then choose to use or ignore the values in calculating the aspect ratio.

The ASR ration needs to be set to the value of the device, where the GUI is developed (only once). This ensures that the widgets will retain their correct aspect ratio even on different devices. If you always use the ASR of the current device, you negate this feature and the widgets will be scaled wrong (ASR should not be used in this a way). So, adding the option to retrieve this would probably introduce more issues by confusing the user.

In cases where widgets are defined on each of the 5 pages (0-4), it seems that if a widget is defined for page 0 as VIS:1 SCI:0, then those widgets appear on all pages. I worked around the issue by first defining the widgets as VIS:0, then toggling them on by VIS:1 when page 0 is revisited. This does not happen for pages 1-4.

If I send the following commands, everything seems ok - each widget is on its own page (i can then navigate through pages using @sci SCI:<index>):

"|TG UID:tg0 X:50 Y:50\r\n"
"|SL UID:sl0 X:50 Y:50 SCI:1\r\n"
"|CB UID:cb0 X:50 Y:50 SCI:2\r\n"
"|NI UID:ni0 X:50 Y:50 SCI:3\r\n"
"|TI UID:ti0 X:50 Y:50 SCI:4\r\n"

Can you please post the commands to reproduce your issue?

E

enniom

@kl3m3n Thank-you kl3m3n for taking the time to reply.

#2 === I will review and prepare a reply

#3 === The screen aspect ratio is set by:

@guis BGC:#FFFFFF ASR:0.5

The following screenshots were from a Plimpton Tablet and from a Samsung Galaxy - both initialized with the same set of GUIO commands.
GUIO_SamsungGalaxy_AspectRatio_0.5.jpg GUIO_Tablet_AspectRatio_0.5.jpg

The page displays perfectly on the Tablet, but when viewed on the Galaxy, one can see remnants of widgets from the prior page (on the left), and the next page on the right.

I would appreciate any suggestions.

#4 === I was setting up each of the 5 pages with an image, then scrolling through them as the widgets were being created for each of the 5 pages. However, the page was not being scrolled using the SCI:x command. This is why the symptoms appeared as I described. It is NOT an issue with GUIO.

|IML UID:pfds ACT:0 X:50 Y:50 W:90 H:100 HAW:0.0 LI:0 IPS:'image1.jpg,image2.jpg,image3.jpg,image4.jpg,image5.jpg'

@pfds LI:" ; var

Thanks
Enniom

kl3m3n

@enniom Hi!

#4 - screen aspect ratio... This is definitely GUI-O problem. I will check this ASAP.
Can you please tell me if the widgets (the remnants that are shown on your screenshot) are displayed in their entirety on the screens to the left and right? Or are they trimmed?

Thanks.
Best regards,
Kl3m3n

enniom

@kl3m3n thanks for looking into this issue.

Yes, each page has "remnants" - more specifically it is generally those defined - for example - at position X:90 W:20 or X:10 W:20. In the case of this application, the goal was to squeeze 4-6 charts per page and put them at the left or right page boundary so that the image and real-time data can be shown in the center.

Secondly, the widgets at these positions may not be fully shown in the page they are defined. To be more clear, in this case they are fully shown in the Tablet view but may be cut off slightly at the left or right in the Galaxy view.

Enniom

enniom

@kl3m3n Thanks for implementing the decimal point configuration on Chart axes in the latest GUIO update. Works PERFECTLY.

Ennio

kl3m3n

@enniom No problem

Thank you for the feedback. I will notify you when I solve the issue regarding the widgets on different screens.

Best regards,
Kl3m3n

enniom

@kl3m3n Hi kl3m3n,

Going back to item #2 in the initial post....

Now using the Beta version v1.0.88 downloaded on November 24, I have not been fully able to replicate the issue discussed in the first post. However, in part, some aspects of the issue remain. Specifically, this code snippet shows it:

"|CH UID:ch20 YASC:0 VIS:1 X:50 Y:78 W:94 H:19 DRA:0 BGC:#000000 FGC:#FFFFFF CHT:0 CDTF:'HH:mm' BSZ:10800 FSZ:0.8 RAD:1.5 BTH:0 LT:0.2 XTC:12 XMA:5 YMA:3.0 YLO:0 YHI:7000 YTC:7 VLP:0 DRAT:0.2 PZO:1 SHVL:1 CHN:'All Values' SCI:0"

while True:   #pseudo code
    Y = time.seconds * 100
    "@ch20 PLI:'pl1' PLC:'#FE642E' YP:'" + Str(y) + "'" 

    time.sleep(250)    # 250  milliseconds

    Y = Y + 1000
    "@ch20 PLI:'pl2' PLC:'#FACC2E' YP:'" + Str(y) + "'"

    time.sleep(250)    # 250  milliseconds
                   
    Y = Y + 1000
    "@ch20 PLI:'pl3' PLC:'#C8FE2E' YP:'" + Str(y) + "'"

Observations:
As the Chart is first populated with values, there appears to be a "flash" of the SHVL:1 values. Then, as the Chart progresses, ultimately it seems the SHVL:1 values are limited to 2 characters.

Enniom

kl3m3n

@enniom Thanks for the minimal example, I will try it.

Best regards,
Kl3m3n

kl3m3n

@enniom Hi.

I tried your example, but I am unable to see the issue? Can you please explain what does "flash" of the SHVL:1 values mean? You are talking about the values on the Y axis and the last value?

Best regards,
Kl3m3n

enniom

@kl3m3n Yes.

What I see is the SHVL:1 values written on the last value at the start of the chart and the x axis increment is large. With each new value, it seems they move forward until the x axis increment becomes small and the values are only shown at the far right. More importantly though, is that when the value is over 99 only the first 2 characters are displayed - not all 4.

enniom

I tried to take some photos that show the two issues. The flashing one is difficult to catch in a photo but can be seen while watching.

kl3m3n

@enniom Hi.

Ok, I see now. The labels are not entirely visible.

Can you try setting the YASC:1 and see if the issue persists?

BR,
Kl3m3n

enniom

@kl3m3n Yes, all digits are fully visible with YASC:1 and SHVL:1. This has been one of the issues all along since when the chart is first stated, the values are zero(0) thus creating a large scale for the Y-axis. The chart is not useful with that format.

Enniom

enniom

@kl3m3n If you can follow this link, the video will show the "flashing" issue. The video is about 40MB and takes 30 seconds or so to load.

link text

Enniom

kl3m3n

@enniom Thanks, I can see this "flashing".

Since you are using the time chart, you should send all the data points simultaneously in one message, so that the drawing of data points is synchronized.

A simple example:
@ch1 PLI:"id0,id1" PLC:"#ff0000,#0000ff" XP:"0.0,0.0" YP:"10.3,20.4"

Can you try this and see if the issue persists?

Meanwhile, I will fix the labels showing only partially...

Best regards,
Kl3mn3

enniom

@kl3m3n Thanks for the hint.

Yes, this suggestion can be adopted in this case and does eliminate the "flashing". However, waiting to plot Y values in one command compromises the purpose of "real-time" plotting and charting.

Enniom