Open mryndzionek opened 2 months ago
Or maybe something like this:
That's very cool! Love it! How did you generate the .gifs?
That's very cool! Love it! How did you generate the .gifs?
Pushed the framebuffer via UART and decoded in Python.
Here is a gif with adjusted framerate:
That looks even better!! How about adding a black pixel or two above each bar in the spectrum scope, so that the spectrum scope is more distinct from the waterfall? Might be better for strong signals where the waterfall will be mostly white?
That looks even better!! How about adding a black pixel or two above each bar in the spectrum scope, so that the spectrum scope is more distinct from the waterfall? Might be better for strong signals where the waterfall will be mostly white?
very cute!
Have you optimised the ssd1306_show function? Would it help? A full update is 132*8=1056 bytes, at about 40 kByte/sec = 26ms A simple 'which pages are dirty' should get some good gains.
very cute!
Have you optimised the ssd1306_show function? Would it help? A full update is 132*8=1056 bytes, at about 40 kByte/sec = 26ms A simple 'which pages are dirty' should get some good gains.
No, no optimizations in thin regard were done. I'm not sure it's worth it. Most pages will be 'dirty' every 100ms, no? u8g2 also doesn't do this to my knowledge. LVGL does, but it's for larger and RGB displays.
The top 3 pages(of 8 vertical pixels) with frequency and voltage etc are essentially static. And as best I can tell, only the middle ~64 pixels are used in the spectrum.
Speaking of which - how much spectrum can we paint? at a guess its currently +/- 3kHz
In the current version the whole spectrum is 12.5kHz, but is captured after the filters leaving 6.125kHz. I'm working on a version in the testing branch that does the filtering in the frequency domain, with a fixed decimation of 16, this should give 31.25kHz of spectrum.
Just spotted the last gif. Looking great!
The top 3 pages(of 8 vertical pixels) with frequency and voltage etc are essentially static. And as best I can tell, only the middle ~64 pixels are used in the spectrum.
The waterfall "bitmap" height is 29 in my screenshots.
Regarding UI changes, I was thinking about putting most of the "metrics" at the top with even smaller font, making the S-meter thinner with possibly just a segmented bar. Here is a prototype:
Looks good, I like the concept. Making the s-meter.more compact/nicer is a great idea. Using a battery icon saves plenty of display real-estate and looks nicer too, the level of 'fullness' depends on the chemistry/number of cells, so some configuration might be needed. Also think it should be possible to detect whether USB power is present and modify icon accordingly. 'lightening symbol'? It might be nice to find some way of representing the filter bandwidth too, perhaps a simple horizontal bar to represent the pass band? There are probably some compromises that could be made, I know the display is a bit cluttered and it might be reasonable to leave off things like CPU temp and CPU load, but I figured it was likely to be used by people with a technical background who might like to know all the facts and figures.
Maybe move the hardware monitoring to a separate screen ? You dont need it when listening to some phat beats on broadcast AM or ringway manchester calling CQ for a YT vid
The top 3 pages(of 8 vertical pixels) with frequency and voltage etc are essentially static. And as best I can tell, only the middle ~64 pixels are used in the spectrum.
The waterfall "bitmap" height is 29 in my screenshots.
I meant the width - we dont have to write all 128 bytes horizontally
The top 3 pages(of 8 vertical pixels) with frequency and voltage etc are essentially static. And as best I can tell, only the middle ~64 pixels are used in the spectrum.
The waterfall "bitmap" height is 29 in my screenshots.
I meant the width - we dont have to write all 128 bytes horizontally
Okay, sorry. The spectrum
array is currently 128 bytes long, so I went with it.
The top 3 pages(of 8 vertical pixels) with frequency and voltage etc are essentially static. And as best I can tell, only the middle ~64 pixels are used in the spectrum.
The waterfall "bitmap" height is 29 in my screenshots.
I meant the width - we dont have to write all 128 bytes horizontally
Okay, sorry. The
spectrum
array is currently 128 bytes long, so I went with it.
Regarding UI changes, I was thinking about putting most of the "metrics" at the top with even smaller font, making the S-meter thinner with possibly just a segmented bar. Here is a prototype:
Like it! Could you push it to a branch? (Would look really good on the bigger 1.5" display as discussed on other thread)
On a related topic, the 2X font might benefit from being a "native" 10x16 font rather than a 2x scaled 5x8
Regarding UI changes, I was thinking about putting most of the "metrics" at the top with even smaller font, making the S-meter thinner with possibly just a segmented bar. Here is a prototype:
Like it! Could you push it to a branch? (Would look really good on the bigger 1.5" display as discussed on other thread)
The prototype was created using Inkscape. I made some attempts to recreate it in u8g2, but it seems too ambitious, i.e. 128x64 is a too low of a resolution to implement it. I can't make the top look similar to my prototype without significantly reducing the height of the FFT display, which is not a good thing. And in general, I don't think it will be possible ta make such changes without migrating to u8g2 first.
The prototype was created using Inkscape. I made some attempts to recreate it in u8g2, but it seems too ambitious, i.e. 128x64 is a too low of a resolution to implement it.
The best we can can do is a x5 font. Not sure the 3px win for the waterfall is worth it! :)
The prototype was created using Inkscape. I made some attempts to recreate it in u8g2, but it seems too ambitious, i.e. 128x64 is a too low of a resolution to implement it.
The best we can can do is a x5 font. Not sure the 3px win for the waterfall is worth it! :)
The main question is, do we want to integrate u8g2 (are there any licensing problems, etc)? I wouldn't attempt revamping the UI without it. The fonts support in u8g2 is fantastic: https://github.com/olikraus/u8g2/wiki/fntlistall
The prototype was created using Inkscape. I made some attempts to recreate it in u8g2, but it seems too ambitious, i.e. 128x64 is a too low of a resolution to implement it.
The best we can can do is a x5 font. Not sure the 3px win for the waterfall is worth it! :)
The main question is, do we want to integrate u8g2 (are there any licensing problems, etc)? I wouldn't attempt revamping the UI without it. The fonts support in u8g2 is fantastic: https://github.com/olikraus/u8g2/wiki/fntlistall
Here is the prototype implemented in u8g2:
I think this has a lot of potential, I would be tempted to take the best elements from this design and incorporate them into the existing UI. The waterfall is very cool, I think combining this with a graphical s-meter and battery monitor would certainly elevate the UI.
U8g2 provides a neat solution. I don't think any licensing issues would be insurmountable. Would it add much overhead in terms of memory compared to the existing library? I think I would be in favour of adopting it if it does what we need.
Would it add much overhead in terms of memory compared to the existing library?
No, I don't think so. It's designed to only compile-in the stuff that is used and regarding RAM use it also supports page-by-page drawing, so even less RAM is theoretically needed.
I'm attaching a test UF2 file with the u8g2 screen and only the frequency adjustment working. It has different IO handling - more reactive, without any inline blocking. The max. lag is then very deterministic and not bigger than ~5ms (single display page write) and no possibility of events being lost. picorx_oled_test.uf2.zip
Looks good. Except, I have some rubbish characters left column of the screen .. Sorry, could not eliminate the scan lines ..
Looks good. Except, I have some rubbish characters left column of the screen .. Sorry, could not eliminate the scan lines ..
Is this a SSD1306, or SH1106 display? Probably wrong controller. I think the binary was for SH1106.
Ahh, it was the 1306, I wasn't sure. I presume the code is for rp2040? I will try it on my ch1116 EDIT: Nope: I still have those characters on the CH1116, it is fine with the original ..
I presume the code is for rp2040?
Yes, RP2040.
Like the new look!
I'm playing with dithered waterfall. First tests: What do you think? Is it useful?