Oh, just an idea, we refresh the display in call back (wifi and BT) and may be it’s the problem, did you noticed something strange before any scan start ?
We should refresh display in main loop I think or at least not in callbacks
Yeah, thinking about this I’m sure this is our problem, callback should be fast and not doing this kind of stuff, I’ll check if we can do this in sniffer loop
I had same idea already. But it’s difficult to change in code, looks like major changes for the display handling.
Same as for wifi+ble callbacks applies for display writes in on_event in lorawan.cpp, this is also a callback from LMiC os_runloop i assume.
A way could be to use u8g2 instead of u8x8, since u8g2 features a display buffer. This could be written to display in a separate running task.
Correct but LMIC event are less “async” and called from user space once event done.
Wifi and BLE are closer to system and really async I think.
Oh excellent the buffer, great idea, just refresh the display in main loop, nice idea 
yes, that was my primary intention. But u8g2 consumes much more ressources that u8x8. On the other hand, it would give us nice logo and graphics capabilities, so we can waste more time on UX 
could be even a separate RTos task which just continuosly writes the u8g2 buffer to display.
Task is only started if device #HAS_DISPLAY. This keeps perfomance consuming off from devices who speak only with RGB LED to user.
I already used 128x64 OLED buffering lib on ATMEga328, tricky but work so on ESP32 it should be more than okay.
128x64 = 1K RAM buffer + some overhead. Should be good
Great, this is the one I used (may be 4 years ago) you should find some issues with my name sent to Oliver
To be honest I was happy with this lib, but always thought it was complicated to do simple things until I found the new one from Squix dedicated to ESP8266 and ESP32 now which is from my point of view, so easier to use and have so much fonts.
But this one has been written for more powerfull CPU so it’s easier to make more things and things better
yes, full buffer is 1024 bytes in u8g2:
U8G2_SSD1306_128X64_NONAME_F_HW_I2C(rotation, [reset [, clock, data]]) full framebuffer, size = 1024 bytes
could be tolerance of 3d print, my case fits in this point. But does not with the display Passepartout.
@Verkehrsrot: I was printing mine with 0.2 resolution. Not sure if print service did the same. You can use a file/cutter to adjust a little.
@Charles I think that was an old bogus cached/temporary model. When I get some time I will double check the current upload. After printing I will make some detail photos.
print service (3Dhubs) offered 0,2 and 0,1. I selected 0,2
3DHubs made mine with 0.2 also
not sure how precise those crowdsourced printers work, but i’m not into 3d printing (yet), always ordering my parts from printing services. Quality often not predictible.
Guys made me some and I’m erally happy with the result, looks fine
Yours from 3dhubs look better than mine. What printing supplier did you select? i went for 3druckbar Mönchengladbach. Also your colors look better that mine!
okay, next time i will go for french supplier
What are the names of your colors?
Well, in fact on 3D hub I was unable to choose different color for top/bottom, so I asked Julien if he could change color. Just asked for Green and Blue, don’t know what he chossed.
After 1st order I added another one, he opened the 1st ready order that was ready to ship and added 2nd order in the same box, that makes me win on shipping port
He was really helpfull and for sure will order again from him
