fancy T-Deck / SenseCAP Indicator / unPhone / PICOmputer-S3 TFT screen

[mverch67]

nothing to see here, yet. Work in progress

[CLAassistant]

All committers have signed the CLA.

[bobricius]

Is possible to test on PICOmputer S3 ? I can send sample hardware.

[mverch67]

Is possible to test on PICOmputer S3 ? I can send sample hardware.

To Germany? Good. I can support it when I have the actual hardware available.
Currently (as of right now) it won't function as there is no cardKB-like keyboard input driver implemented which would be the precondition for any interaction, as the PICOmputer does not have a touch screen (or does the display have a GT911 or other touch controller??).

[bobricius]

Is possible to test on PICOmputer S3 ? I can send sample hardware.

To Germany? Good. I can support it when I have the actual hardware available. Currently (as of right now) it won't function as there is no cardKB-like keyboard input driver implemented which would be the precondition for any interaction, as the PICOmputer does not have a touch screen.

worldwide, Germany is almost a neighbor, I'm from Slovakia. Picomputer use direct gpio matrix keyboard implemented by @caveman99 cpu is bpi-PicoW-S3 + RFM95 send my your postage address to bobricius@gmail.com

[caveman99]

I am on the road right now but iirc the picomputer does only have 4MB flash. May be a tight fit. The TFT tracksenger may be a better fit. 8 MB is the min for an integrated device I would think.

@mverch I have a picomputer prototype I can send you. Assuming @bobricius doesn't have a newer revision :-)

[bobricius]

I ma not sure but on product page is:
ESP32-S3R2
2MB Quad SPI PSRAM
8MB Quad SPI Flash
Also I have Picomputer based on Wroom module which is more flexible with flash/psram options

[mverch67]

I ma not sure but on product page is: ESP32-S3R2 2MB Quad SPI PSRAM 8MB Quad SPI Flash Also I have Picomputer based on Wroom module which is more flexible with flash/psram options

That's also what I read on the ALI-Express page for the Banana-Pi. Should be fine.

https://github.com/meshtastic/firmware/blob/tft-gui-work/boards/bpi_picow_esp32_s3.json#L28

[mverch67]

[mariotti]

@mverch67 , by the way, I am flashing this PR to a t-deck weekly.
The last commit about few hours ago, it did not brick it :)

Please let me know (weekly ;) ) if I can support, sadly it is a pretty common device.

[ndoo]

lib/device-ui/source/ViewController.cpp: In member function 'virtual bool ViewController::send(uint32_t, uint8_t, uint8_t, uint32_t, meshtastic_PortNum, bool, const unsigned char*, size_t)':
lib/device-ui/source/ViewController.cpp:497:35: error: too many initializers for 'pb_byte_t [233]' {aka 'unsigned char [233]'}
             .want_ack = (to != 0)}});
                                   ^
*** [.pio/build/t-deck-tft/lib/device-ui/source/ViewController.cpp.o] Error 1

Issue probably related to this change in protobufs: meshtastic/protobufs#627

Edit: I think it's just a matter of pointing the dependencies to a newer commit of device-ui

[mverch67]

Please let me know (weekly ;) ) if I can support, sadly it is a pretty common device.

Hi Mariotti, your support is very welcome, thanks a lot ;-)

Hope, you enjoy the latest updates.
Cheers

[ndoo]

Feature request: Show distance in the node list environment telemetry.

If distance is >0. Thank you for your consideration :)

I had a look at the code for 320x480 but didn't know if it was straightforward as to add a _tm3 variable.

[mverch67]

Feature request: Show distance in the node list environment telemetry.

The distance to other nodes is already shown in the node list once the own position is known and updated.

[ndoo]

Feature request: Show distance in the node list environment telemetry.

The distance to other nodes is already shown in the node list once the own position is known and updated.

Hi there,

This is referring to the distance value in Environment telemetry protobuf, not distance between nodes - i.e. the distance measured by an ultrasonic sensor (usually a water level)

[mariotti]

Hoi Manuel,

So I fleshed successfully on few t-deck. And tested a bit. Here my notes.

• First we need to pull always the submodule device-ui master, its not an issue, but we must remember it. As device-ui is basically master driven, I was checking if a submodule can alway point to master. There are solutions but I could not find any that is very clean. (this note is probably for others that wants to jump in).

• Then there is a little bug when the device is "remotely" administered.
  For example here I change the "role" in the UI for a remotely administered device, i.e. it should not be possible:

We see the rebooting... overlay but the device is not rebooting [expected], The UI is ignoring the settings changes [expected], but the overlay cannot be removed:

The device is working as expected, ignoring admin changes, as it is remotely administered, but the [rebooting...] is still on screen.

At present only on/off cycle removed the banner.

Then,

Is this the kind of thinks you expects from me? ;)

I am getting more and more into the code, but it will take me a bit more time to be able to address these issues to code lines. Working on it ;)

ahh a last note. Which I am not sure about.

The UI usability seems heavily dependent on the power. If you set this:

The usability seems laggy, odd, slow. I found it out by flashing on a t-deck plus, which was using a lot of power, but the UI was working incredibly better then my previous bare t-deck.

I guess it is a known issue. But I would put this ahead as we (you/meshtastic) will get a lot of UI usability complains if users run on very low power.

btw, I am almost done with my first project with this UI :)

Cheers
A+
F

[mverch67]

Hi, thanks for your tests. I don't know what version you are using as there are constant updates but here is a quick answer to your findings:

> We see the rebooting... overlay but the device is not rebooting [expected], The UI is ignoring the settings changes [expected], but the overlay cannot be removed:

This is probably not a UI issue. The firmware must be sending a reboot message to the UI otherwise it would not be shown.

> At present only on/off cycle removed the banner.
Long press the Home button would do a quick resync and remove it, too.

> The UI usability seems heavily dependent on the power. If you set this:
I don't quite understand what you mean. If you mean the power saving options then these should not be modified as it is set to its best values already (on initial factory reset with the UI). If you mean the battery power level then this also should also not impact the device.
The only thing that impacts the UI are CPU heavy tasks or things blocking the UI such as a high number of nodes (>200) or enabled Wifi or constant GPS auto scans when no GPS is present but the switch is turned on.

Cheers,
Manuel

[mariotti]

Hoi,

Quick answer: If I write here, the version will be the last commit. Unless we are very unlucky in timing :) .

I'll double check for the [rebooting ...], but it happens only if the device is "remotely administered", it does not happen in other cases. Just to be sure.

I'll try the long press tip.

Thanks
A+
F

PS: ok, by flashing few devices, I might forget one in the tests :(

[mariotti]

Hoi, yes, the rebooting might be a firmware issue.

But in the sense that the UI gets no feedback. I will check first in the old UI how this is handled.

In practice this UI assumes, for all events, after reboot notification, that the device will actually reboot.
If the device is remotely administered the reboot is not done.

I am really poor in C++ code but for example:

``

            THIS->controller->sendConfig(meshtastic_Config_DeviceConfig{device}, THIS->ownNode);

            THIS->notifyReboot(true);

``

Assumes that a reboot will happen. Or?

[j6k4m8]

Suggested change

	url = https://github.com/meshtastic/device-ui.git
	url = https://github.com/meshtastic/device-ui.git
	branch = master

[j6k4m8]

@mariotti:

As device-ui is basically master driven, I was checking if a submodule can alway point to master. [comment]

I believe this solves this particular complaint! But as far as I know you cannot specify a commit hash or tag, so this is good for keeping the HEAD of master but not going deeper.
@mverch67 I will make a PR — you are welcome to use or reject!

[mverch67]

I don't think this is a good idea in general as it won't be possible to ever re-build old versions of the software. The branch tag is currently not maintened as there are no automatic builds but will be as soon as the last needed feature is implemented and running.

[mariotti]

Nice! But sadly it will work for a short time :(

If tomorrow we will start versioning the device-ui, which will be the idea, then we have an issue.

I think it is best to leave this to the developers until it is merged.

[mverch67]

Assumes that a reboot will happen. Or?

Yes, exactly. This is to notify the user that the device will restart in a few seconds. UI and firmware have implemented the same kind of knowledge which command leads to a restart.

The reboot notification that is issued by the firmware indicates to the UI/App that the device is going to reboot. If it sends this message but doesn't reboot then this is clearly a bug in the firmware. Some remote administration will lead to a reboot, some does not. There is no general rule, but only a case-by-case decision.

[mariotti]

Got what you mean, then it is a FW issue.

[mariotti]

Ok, then I will test the behaviour for the latest alpha in the standard UI, and start a ticket/issue on that.
cheers

[mariotti]

@mverch67 Hoi, I kept flashing t-deck's :) But I have some issues with the touchscreen that got very laggy. I am not sure it actually depends on this PR, yet it seems unresponsive only with the device-ui. It can even be hardware, but I got 2 t-deck with the issue, so I am really confused. I flashed also old commits.

Do you mind if I open a discussion under: https://github.com/meshtastic/firmware/discussions for my issue and maybe generally for other flashers? Or: do you prefer less noise while developing? Or the opposite, I should report here?

Cheers
A+
F

[mariotti]

Hoi Manuel,

Indeed about the "rebooting...", ( #3259 (comment) ) I had a look at the code and it looks like that all is passing by the AdminModule.

In the admin module you have something like this:

    if (messageIsResponse(r)) {
        LOG_DEBUG("Allow admin response message");
    } else if (mp.from == 0) {
        if (config.security.is_managed) {
            LOG_INFO("Ignore local admin payload because is_managed");
            return handled;
        }

Now at: https://github.com/meshtastic/firmware/blob/master/src/modules/AdminModule.cpp#L79

So it bails you out immediately if the node is managed. "if (config.security.is_managed)"

I assume that the UI goes also via the AdminModule too, which is auspicabile.

In that case a reboot is not going to take place.

We might need to import some security settings and apply the same behaviour.

If I got it right, of course.

A+
F

PS:
Actually for the future I would refactor the security struct into a class.
like:

if (!config.security.allowed(mp, r)) {
    LOG_INFO("Ignore local admin payload because not allowed");
    return handled;
}

You could add some fingerprint sensors :)

[ndoo]

@mverch67 Hoi, I kept flashing t-deck's :) But I have some issues with the touchscreen that got very laggy. I am not sure it actually depends on this PR, yet it seems unresponsive only with the device-ui. It can even be hardware, but I got 2 t-deck with the issue, so I am really confused. I flashed also old commits.

Do you mind if I open a discussion under: https://github.com/meshtastic/firmware/discussions for my issue and maybe generally for other flashers? Or: do you prefer less noise while developing? Or the opposite, I should report here?

Cheers A+ F

Early T-Deck Plus units have a known issue of an almost unresponsive touchscreen due to incorrect programming of the GT911 touchscreen IC at the factory. Flashing it with the UnitTest firmware and then back to the TFT GUI firmware will fix it.

[mariotti]

Thanks both, the t-Deck-plus is back in track :)

JIC, It was not that obvious, as I knew that repo, but not the actual issue so initially I did not try too hard.
In addition from a Mac a simple esptool.py was not working :(
What worked was flashing from https://espressif.github.io/esptool-js/ and using this .bin https://github.com/Xinyuan-LilyGO/T-Deck/blob/master/firmware/T-Deck-Plus-TouchFix_241025.bin (not sure the UnitTest, as building it did not work).
I will try next week to reproduce it on my second t-Deck-Plus and create a discussion to describe the steps.

Flashed successfully, basic usage working. This on the last commit with both: current pointer to device-ui and device-ui updated to the last current master commit.

Going to flash the other t-decks :)

Thanks again
A+
F