Btw. M5Stack is working on a new device in a bottle preform with eink display.
Maybe ttgo should create finally something useful with a good case. Everysingle board from them is so badly designed. They are not using full potential of AXP192 PMU, like why they don’t using LDO outputs for i2c display or other peripherals, why these unused pins are not pulled out to pin header (T-PCIE) or when you equip your board with a display then it is on really bad position (like T-Motion is designed to be equipped with OLED display, but when you solder it directly, then it will cover GPS antenna…). And you will hardly find a of the shelf enclosure that can be used for these devices. Sure, their boards are far away from end products, these are just devel boards probably developed without any real use case.
Recently stumbled upon this project and project owl https://www.project-owl.com/ and their ducklink. The two could possibly merge and use the same mesh backend with different User Interfaces for different situations.
Also super interested in the TTGO prototype. Haven’t bought any hardware and if it is coming soon I’d rather buy the e-ink board. Did you ever hear back from TTGO?
Yep - Linar and I were the two folks mainly working with TTGO to add support for this board. I have the same board Linar has and it is really nice. We’ve given a small amount of bug reports to TTGO and I kinda assume the next build they do will be in volume and they will sell it.
and if anyone wants to build and run the code for this board it is supported now in meshtastic btw. “pio run --environment eink”. Once there are boards people can buy we’ll add it to the standard prebuilt releases.
Is the CSI cable connecting the display and board removeable from both ends? I think I’d like to replace it for a longer one.
The buttons at the “bottom” of the board is a bit awkward so that’s why I’m thinking of reorienting the PCB 90 degrees. I also don’t like LiPo’s (they puff up with age and heat) so I would change it out for an 18650 or something similar.
Looked through the store forward plugin code am I correct that this board would be less useful for a meshtastic repeater because it doesn’t have enough memory for store forward functionality?
This seems like it would be an ideal form factor to add a keyboard for a dedicated messaging device.
I’m authoring the store and forward plugin to be used on a router built around the tbeam or other devices with external memory.
The nrf52840 has 256 KB RAM. The current memory footprint of the store and forward plugin is about 268bytes per message (I expect this to grow, but not by much). There should be some space there for S&F if the main device code doesn’t take too much RAM.
I just updated the S&F today to allow for variable external PSRAM sizes. I’ve seen some boards have just 2MB of external memory. In either case, I’m using up all the memory less 50k.
Maybe to play nice, I should just size it to use no more than 50% of available PSRAM. I’ll make that change now.
Btw @mc-hamster when we make s&f standard perhaps we just add a new message priority that is higher than “reliable” if priority is “STORE_FORWARD” it would mean that app wants this message delivered via this mechanism.
It might make a clean way to specify “text messages do get s&f but most position messages don’t”
The way I’m doing it now is only storing messages that come on the text message port. Not saving anything else. Seems like the path of least resistance for now.
Using the message priority would be novel. Something to think on.
