Posts made by kl3m3n

@enniom said in Some issues and possible improvements:

@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

Hi,

GUI-O version 1.0.89 is being released. Additionally to the chart labels fix, this version introduces a new parameter: widgets bounding (WBE, which can be enabled / disabled via @guis WBE: command - it is disabled by default. Please see the updated manual).

Enabling this ensures the widget is never off-screen as GUI-O application internally moves the widgets in-view. This can be useful when developing for various screen sizes. Note that the widgets' sizes remain the same, only the position is updated. So, if your widgets are too close together, they might overlap.

You can try this approach on your tablet and phone.

Best regards,
Kl3m3n

@enniom Exactly

@enniom Hi.

XY chart does not support time on X axis... You can use index-based approach.

But, I would suggest that you synchronize the data using time chart. I argue that it does not matter if you send the same value multiple times.

For example, if you have three variables / values... On initialization, set all three values based on your measurements. Then send each new measured value along with two "old" values (they are actually not old, they just haven't been re-measured yet) in the same message.

This is how you synchronize the data and keep the time chart while still maintaining valid values.

Does this make sense?

Best regards,
Kl3m3n

@enniom Hi.

Generally, time chart updates should occur at predefined (fixed) interval to avoid synchronization issues. New values should be added in one operation to maintain temporal alignment. I will add this note to the manual!

If you need asynchronous plotting, switch to XY chart type. I think that should work without "flashing".

Best regards,
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 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 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 Thanks for the minimal example, I will try it.

Best regards,
Kl3m3n

@mathieu Hi!

I have sent the initialization code to your e-mail (I have included your full commands there, but not here on the forum).

Basically, the commands are sent in a non-blocking fashion one-by one:

#include <BLEDevice.h>
#include <BLEServer.h>
#include <BLEUtils.h>
#include <BLE2902.h>

#include <pgmspace.h>

const char* const commands[] PROGMEM = {   
    "|LB UID:lb0 X:20 Y:10\r\n",
    ...
    ...
    ...
};

const size_t numCommands = sizeof(commands) / sizeof(commands[0]);

namespace uuid {
  static const char *SERVICE_UUID = "6E400001-B5A3-F393-E0A9-E50E24DCCA9E";
  static const char *RX_CHARACTERISTIC_UUID = "6E400002-B5A3-F393-E0A9-E50E24DCCA9E";
  static const char *TX_CHARACTERISTIC_UUID = "6E400003-B5A3-F393-E0A9-E50E24DCCA9E";
} // namespace uuid

// forward declare parser for incoming messages
void parseGuioMsg(const String &msg);

// setup done flag
bool setupDone = false;

// init active flag
bool initActive = false;
// send command period in msec
static const unsigned long sendCommandPeriod = 50;

// custom handling of server callbacks
class CustomBLEServerCallbacks: public BLEServerCallbacks {
    void onConnect(BLEServer* pServer) {
      Serial.println("Connected!");
    };
    void onDisconnect(BLEServer* pServer) {
      Serial.println("Disconnected!");

      // fix provided by BM
      // restart advertising after disconnect, otherwise GUI-O cannot re-connect
      if(setupDone) {
        // restart advertising on disconnect
        delay(500);
        pServer->startAdvertising(); 
      }
    }
};

// custom handling of characteristic callbacks
class CustomBLECharacteristicCallbacks: public BLECharacteristicCallbacks {
  void onWrite(BLECharacteristic *pCharacteristic) {
    std::string msg = pCharacteristic->getValue();
    
    // parse message string
    parseGuioMsg(String(msg.c_str()));
  }      
};

// global ptr
BLECharacteristic *pTxCharacteristic;

void setup() {
  // debug output
  Serial.begin(115200);

  // create device
  BLEDevice::init("BasicBLE_NUS");
  // create server and register callback
  BLEServer *pServer = BLEDevice::createServer();
  pServer->setCallbacks(new CustomBLEServerCallbacks());
  // create service
  BLEService *pService = pServer->createService(uuid::SERVICE_UUID);

  // crate Tx characteristic and add descriptor
  pTxCharacteristic = pService->createCharacteristic(uuid::TX_CHARACTERISTIC_UUID, BLECharacteristic::PROPERTY_NOTIFY);
  pTxCharacteristic->addDescriptor(new BLE2902());
  
  // crate Rx characteristic and register callback
  BLECharacteristic *pRxCharacteristic = pService->createCharacteristic(uuid::RX_CHARACTERISTIC_UUID, BLECharacteristic::PROPERTY_WRITE | BLECharacteristic::PROPERTY_WRITE_NR);
  pRxCharacteristic->setCallbacks(new CustomBLECharacteristicCallbacks());

  // start the service and start advertising
  pService->start();
  pServer->getAdvertising()->start();

  // setup done flag
  setupDone = true;
}

void loop() {
    static size_t currentCommandIndex = 0;
    static unsigned long lastCommandTime = 0;

    if (initActive) {
      if (currentCommandIndex < numCommands) {
        if (millis() - lastCommandTime > sendCommandPeriod) {
            lastCommandTime = millis();

            // retrieve and send the command
            char commandBuffer[256];
            strcpy_P(commandBuffer, (char*)pgm_read_ptr(&commands[currentCommandIndex]));
            sendMsg(commandBuffer);

            Serial.print("Sending: ");
            Serial.println(commandBuffer);
            
            currentCommandIndex++;
        }
      }
      else {
        initActive = false;
        // hide loading screen
        sendMsg("@hls\r\n");
      }
    }  
}

/***************************/
/* IMPLEMENT YOUR GUI HERE */
/***************************/
void sendMsg(const String &msg) {
  pTxCharacteristic->setValue(std::string(msg.c_str()));
  pTxCharacteristic->notify();
  delay(50);
}

void parseGuioMsg(const String &msg) {
  if(msg.startsWith("@init")) {
    Serial.println("GUI-O app is requesting INITIALIZATION!");

    // clear screen and set background
    sendMsg("@cls\r\n");
    sendMsg("@guis BGC:#FFFFFF\r\n");
    sendMsg("|SORI UID:sori2 HID:sori ORI:2 SEN:0\r\n");

    // wait for orientation change (alternatively catch GUI-O screen orientation change event...)
    delay(500); 

    // show loading screen
    sendMsg("@sls\r\n");
    
    initActive = true;
  }    
}

Can you please test it and see if it works for you?

You can try extending sendCommandPeriod if you have any issues... Also you can comment out the @sls and @hls commands to see exactly what is going on...

Best regards,
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 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 said in Some issues and possible improvements:

Hi Kl3m3n,

Some feedback from various tests, ideas, etc.

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

2. 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.

3. 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.

4. 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

@mathieu Hi.

I will take a look at your initalization and see how the issue can be mitigated. I will get back to you.

Some Esp32 variants support classic bluetooth also. Here is the GUI-O example:
https://www.gui-o.com/examples/gui-o-and-boards/esp32#h.91so3s2tov2e

Best regards,
Kl3m3n

@mathieu Hi!

Is it possible for you to send me the initialization commands, so I can reproduce your issue and try to solve it? You can send them to info.guio.app@gmail.com.

Did you consider using legacy Bluetooth (not BLE, but Classic), which is more suited for such large payloads?

Best regards,
Kl3m3n

@mathieu Hi!

I can see only 29 widgets in the log, which means GUI-O did not receive commands for other widgets.
I am guessing that there is a problem with message loss (too much data in a short interval) due to limited buffer space of the BLE stack.

But, as you've said - adding a "short" delay did not help. Can you try adding a larger delay just for testing? You can add it after every 3rd command for example.

You could also try updating the connection parameters (decrease connection interval) after the connection is established (using pServer->updateConnParams method):
https://github.com/espressif/arduino-esp32/blob/master/libraries/BLE/src/BLEServer.h#L78

Also you can try more structured approach by sending a "chunk" of data (e.g., 100 bytes - without breaking the individual commands) and then waiting for a short time before sending the next chunk.

Best regards,
Kl3m3n

@mathieu Hi!

Can you try the following:

1. Open GUI-O app and navigate to "Info" from the settings menu
2. Tap the app version info 10 times - this will enable developer mode
3. Scroll to the bottom, tap on "Developer mode" and enable "Log incoming messages".

Next, try sending the widget commands then exit the app and connect your device to a PC. Navigate to com.guio.app folder (Android - > Data) and observe the contents of the incoming log. You can post the log here.

Note that the log will be truncated / cleared next time you start GUI-O app.

Best regards,
Klemen

@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

@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

Our services will have scheduled outages on Nov 5-8, from 8:00 to 13:00. We apologize for the inconvenience and appreciate your understanding.

@Fehr No problem!

I plan to write a FAQ page on GUI-O website, which will also include this explanation.

Best regards,
Kl3m3n