Similar project and might be some useful code

[mgrouch]

I’ve done a similar project. You might find some code useful and re-usable in yours. :) UI is LVGL. and various protocol parsers. pypilot tcp, Victron MQTT, SignalK tcp, NMEA 0183. MDNS discovery.

https://github.com/bareboat-necessities/bbn-m5stack-tough

Cheers

[seandepagnier]

Thanks for bringing this up.

I will try to utilize code/design from this, but there are a few differences:

1) no touchscreen. I am not using a touchscreen... instead a keypad. 2) larger screens. I am using 5 inch displays, either monochrome or color and both daylight visible. In any case lvgl is not a good fit for monochrome, and it is also not good for 800x480 since it is too slow on the esp32. I will find out as I develop the color screen support. I also intend to work at a lower level graphics to develop more intentional displays. 3) It is my intention to configure the gauge mostly via a web interface rather than onscreen.

With all this it is very interesting and similar but different design goals. Perhaps we can mutually benefit from certain similar functions.

[mgrouch]

For me LVGL was really fast. It does need some tuning, giving proper buffer sizes, etc. But widgets quality and quality of fonts is awesome. I’d highly recommend LVGL over lower level libraries. It solves many problems which you otherwise have to solve somehow differently. Gauges are super easy to do with LVGL.

Touchscreen or buttons doesn’t make much difference from coding perspective. It’s event driven.

In my code UI, network, data parsing, and data storage are quite clearly separated. Code that parses data doesn’t know anything about UI.

Boat data model is also separate code.

So it’s easy to modify code and use it in some server type of application instead of UI.

LVGL is also possible to use over frame buffer on Linux. So the app can be ported from esp32 to Linux.

I have made a first release of BBN for CoreMP135 from m5stack. It runs pypilot and SignalK. And its plug and play device with NMEA 0183, 2000, pypilot IMU and motor controller are plug and play on it too. A bit slow on restarts. But its Debian. Has same touchscreen and 3 capacitive buttons. I have a temptation to port my LVGL app to Linux for it.

The code is here:

https://github.com/bareboat-necessities/lysmarine_gen/tree/coremp135_bookworm

About CoreMP135

https://docs.m5stack.com/en/core/M5CoreMP135

It’s $75. 2-can bus interface, i2c, uart, rs-485, 512MB ram, 2 usb 2.0, hdmi, arm based processor. Linux, small touchscreen.

[mgrouch]

I think coremp135 can be a good platform for pypilot. I’ll post more thoughts here:

https://github.com/pypilot/pypilot/issues/237

[seandepagnier]

I am supporting monochrome displays which lvgl is not really suitable. These displays have the lowest power consumption for daylight visible.

To be clear, lvgl isnt too slow it is the esp32. I have a color display with resolution of 800x480. the esp32 literally isnt fast enough to push the framebuffer at anything more than 8bpp, because the LCD clock must be 25mhz. That is using the parallel interface and 8bpp, it just doesnt have the memory to store the framebuffer in normal ram, and the psram is too slow. Technically it can work at 16bpp with octal psram but it would have issues when doing other things. Using octal ram and 8bpp seems to be the best method for this screen.

So my issue is using lvgl with low color. It can't be a palette because doing that in a hardware interrupt is also too slow. It has to be rgb232 with the last bit shared for red and blue to give 8 greys, 8 greens, 4 reds and 4 blues and so forth.

https://forum.lvgl.io/t/v9-lv-color-depth-8-l8-support/14924

They are talking about maybe supporting 256 greys, but basically lvgl doesnt work for less than 16bpp right now, and even if they make it work, it wont support rgb232 +1 color format. That is the biggest issue there are others.

As far as collaborating. We should keep checking each other's projects and understand the different intentions as the projects move along. If we could somehow share the ais code, or other bits that might be useful to avoid duplicated effort. It would be cool to somehow share data parsing for nmea, signalk, pypilot etc so that would be the starting point anyway.

[mgrouch]

I have SignalK over TCP (instead of web sockets) parser, I also have Victron MQTT parser (partial)

There is module for deriving data like wind, sunset/sunrise, going from magnetic to true based on wmm2020 for esp32. Leeway calculations.

I think those can be of interest to you too.

[mgrouch]

There is no good complete NMEA 0183 parser that I know of for esp32. I’m think of generating code for it from

https://github.com/SmartBoatInnovations/ha-smart0183tcp/blob/main/custom_components/smart0183tcp/Smart0183tcp.json

and making good test cases. I think gpsd code has plenty and some other projects too.

[mgrouch]

There is a lot of efforts done in another similar project

https://github.com/norbert-walter/esp32-nmea2000-obp60/

I think we should try to make it modular. I think protocols NMEA 0183, NMEA 2000, Victron MQTT, PyPilot TCP, SignalK TCP, SignalK WS should be made into libraries.

I think boat data can be made a shared library too. (storage of all boat sensors, etc)

In my project I tried to define it in a single structure. Then all parsers could write into that.

[mgrouch]

I propose making a separate GitHub project just for data model of ship data, with write access for me, you and someone from open boat projects.

Start version can be this:

https://github.com/bareboat-necessities/bbn-m5stack-tough/blob/main/bbn_m5tough_active_boat/ship_data_model.h

It can be header .h only library.

Then we kind of have shared data model. So all parsers would use it.

and UI components could use it.

It will improve code re-use between 3 projects.

[mgrouch]

Here is one more project which could use more unified parsers

https://github.com/philseeley/boatinstrument

related issue:

https://github.com/philseeley/boatinstrument/issues/1