Closed mmstac closed 2 years ago
Sounds like a good idea. I have already ordered a couple of these boards yesterday on AliExpress.
Now I have less time to work on this project, probably I will implement the core part - the code needed to share one i2c bus between the IMU and the display, maybe some basic display initialization.
I do not really want to do the porting of some drawing library or writing all the text/line/circle/fill subroutines and do all the drawing code across multiple resolutions: 128x64, 128x32, 72x40. Maybe someone could contribute that after I create some i2c sharing machinery...
Do you have any ideas about a 2d graphics library which could be used without Arduino dependency?
I don't have any experience with ESP-IDF mostly play with Arduino IDE and rely on existing libraries at that. However the below post mentions LVGL and also u8g2 apparently can be run on ESP-IDF. u8g2 is widely used on Arduino platform, good range of supported displays, documented and includes some basic drawing/bitmap and lots of fonts. https://www.esp32.com/viewtopic.php?t=18656
My coding skills are very limited, but happy to contribute if you need any grunt work done.
Getting u8g2 to work was easy enough.
icm42688 + ssd1306 on the same i2c bus:
Though the code needs to be cleaned up
Added support for 64x32 ssd1306 display. Other (higher) resolutions might work without code changes (but of course the content will not be centered, probably in the upper left corner).
More resolutions/layouts can be added here https://github.com/VladimirP1/esp-gyrologger/blob/a4687ffcffd106719d1c14d549ee9899be8704d9/main/misc/display/src/display.cpp#L183
I'd also like to support moving the oled onto different pins (other that the IMU i2c).
Probably it would be enough to add cases for U8X8_MSG_GPIO_I2C_CLOCK
, U8X8_MSG_GPIO_I2C_DATA
and U8X8_MSG_DELAY_I2C
into the switch in u8x8_gpio_and_delay_esplog
and adding two new settings for pins in kSettingDescriptor
in main/storage/settings.hpp
...
I think you can try it on ESP32-C3-0.42LCD now (but only if your IMU is on the same i2c bus as the display).
Try setting Display type
in settings to 1 and see what happens (the display is a bit different than mine (72x40 vs 64x32))
You are too fast!! I am just now trying to create a logo bitmap... but the resizing doesn't look so nice. Yes my OLED is set on the same i2c bus. I assume no need to refresh the display while logging so it won't slow the IMU communication? That board has a i2c header, makes it easy to test different gyros just by plugging. I will give it a try tomorrow.
What do you think?
I think your logo has a bit too thin lines. Resizing will never look good. How I did this was to export from inkscape with antialiasing off and then fix bad pixels in paint manually one by one.
Most IMU chips have a 1 or 2 KB buffer inside so refreshing the display won't cause problems if you do not do it too often. I wrote the IMU drivers in a way that they will deliberately crash the system in case the buffer overflows and samples are lost, so you will definitely notice it if it happens.
And the processing pipeline (the filtering and interpolation code) never stops actually, it continues to sample the IMU even if logging is stopped.
Also added gyro/accel reading display (the upper horizontal lines are gyro, lower are accel readings)
It works, but with some issues.
1) OLED is very faint, I'm not sure if there is a brightness setting that got messed up? When I run other code it is fine. This is the config qualifier for Arduino IDE
U8G2_SSD1306_72X40_ER_F_HW_I2C u8g2(U8G2_R0, / reset=/ U8X8_PIN_NONE); // EastRising 0.42" OLED
2) There is garbage characters on the left/right edges, I guess that is due to different screen resolution. If you can clear screen for a larger resolution at startup, maybe that would be enough and just use the same interface as 64x32.
Just some thoughts on the interface. Since the screens are so small (and I have old eyes), I think using a larger font and displaying less info would be more useful.
IDLE
LOGGING
SAVED
I gave another try with the logo bitmaps, feel free to use if you like them. Your logo looks fine as is :)
Try this firmware with display type set to 2: https://dropmefiles.com/yeo9m
it is asking for a password when I try to extract...
The password is "123"
(The site shows a dialog box with the password)
ok thanks, it says on the filename too (I should check more carefully). Works perfect now, brightness and borders good. Did you change how the settings are stored, it remembered all my settings after updating the firmware this time
No, the settings get reset only if I add new settings - the reset happens here: https://github.com/VladimirP1/esp-gyrologger/blob/master/main/storage/settings.hpp#L82
New UI. Pushed this on github (can be downloaded from github actions)
(the exclamation mark means wifi is on)
Estimated time remaining would be pretty inaccurate - logging bitrate varies depending on motion.
Maybe it would be a good idea to change the log naming, so when you increment the epoch by long button press the number would reset to zero.
With that and auto deletion of old logs you will never have to delete logs (but will the remaining space estimate will be useless unless you delete old logs).
One more idea - maybe I can show instead total free space the space which can be claimed by deleting all files of the older epochs.
Thank you, very nice!! How to read the bottom graphs, x - y - z? and accel on top, gyro on bottom?
When recording starts and stops, possible to flash the screen? Something like
u8g2_SetDrawColor(2) u8g2_DrawFrame(0,0,getDisplayWidth(),getDisplayHeight()) pause u8g2_DrawFrame(0,0,getDisplayWidth(),getDisplayHeight()) u8g2_SetDrawColor(1)
Also if you want to fit back the wifi, maybe can try this layout
I was new to esplog, didn't realilze you use compression as there is always plenty of storage? In that case I guess space remaining isn't really that useful, but instead a reminder if it is close to getting full but that can be with LED too.
One thing that happened once (pre display firmware), I downloaded one log and all seemed ok, but in fact the log only contained maybe 70% of the flight?! I did not delete it so I went back and downloaded again, and the full flight was there?! But I never experience this again. I do notice though when I click the filename, sometimes there is no reaction and have to reclick.
The upper bars show the gyro readings, the lower - accelerometer. Yes, X, Y, Z. Positive values are on the right, negative - on the left.
Yes, it is possible to flash the screen, will add that.
You can try fitting your layout if you want - just copy the work_64x32
function and change what you want. ESP-IDF 4.4.1 is needed for building. Or (the less convinient way to build the firmware) you can fork the repo, do the editing in browser (by pressing .
), commit and the firmware will be built automatically by GitHub actions.
My code does partial display refreshes of the last 8 rows of the display, your layout does not need this, so you can remove the code.
Thanks, yes I should learn to use ESP-IDF and github too... I've been wanting to, but it might take me quite some time...
If you have to reclick that just means that download fails. Probably you have unstable wifi connection. Truncated logs probably caused by the same thing. The JS+WASM code which does decompression just tries to decompress everything it gets, even if it is just part of the log, probably this can be improved.
Try increasing "Max wifi tx power (dbm)" to 20. The reason the default is 2 is that some of my custom PCBs have a bad antenna and do not work on high power.
Blinking done using ssd1306 hardware inversion
Many dev boards have integrated OLED displays, this tiny one for example only 2.6g with 0.42" display (including usb port, vreg, button). https://github.com/01Space/ESP32-C3-0.42LCD
Display could be used to