Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dithered waterfall #31

Open
mryndzionek opened this issue Sep 1, 2024 · 32 comments
Open

Dithered waterfall #31

mryndzionek opened this issue Sep 1, 2024 · 32 comments

Comments

@mryndzionek
Copy link
Contributor

I'm playing with dithered waterfall. First tests:
waterfall
What do you think? Is it useful?

@mryndzionek
Copy link
Contributor Author

Or maybe something like this:
waterfall

@dawsonjon
Copy link
Owner

That's very cool! Love it! How did you generate the .gifs?

@mryndzionek
Copy link
Contributor Author

That's very cool! Love it! How did you generate the .gifs?

Pushed the framebuffer via UART and decoded in Python.

@mryndzionek
Copy link
Contributor Author

Here is a gif with adjusted framerate:
waterfall

@dawsonjon
Copy link
Owner

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?

@mryndzionek
Copy link
Contributor Author

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?

waterfall

@penfold42
Copy link
Contributor

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.

@mryndzionek
Copy link
Contributor Author

mryndzionek commented Sep 2, 2024

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.

@penfold42
Copy link
Contributor

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

@dawsonjon
Copy link
Owner

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.

@dawsonjon
Copy link
Owner

Just spotted the last gif. Looking great!

@mryndzionek
Copy link
Contributor Author

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.

@mryndzionek
Copy link
Contributor Author

mryndzionek commented Sep 2, 2024

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:
pico_rx_ui

@dawsonjon
Copy link
Owner

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.

@penfold42
Copy link
Contributor

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

@penfold42
Copy link
Contributor

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

@mryndzionek
Copy link
Contributor Author

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.

@mryndzionek
Copy link
Contributor Author

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.

See here and here

@bmentink
Copy link

bmentink commented Sep 4, 2024

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: pico_rx_ui

Like it!
Could you push it to a branch? (Would look really good on the bigger 1.5" display as discussed on other thread)

@penfold42
Copy link
Contributor

On a related topic, the 2X font might benefit from being a "native" 10x16 font rather than a 2x scaled 5x8

@mryndzionek
Copy link
Contributor Author

mryndzionek commented Sep 4, 2024

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: pico_rx_ui

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.

@penfold42
Copy link
Contributor

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! :)

@mryndzionek
Copy link
Contributor Author

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

@mryndzionek
Copy link
Contributor Author

mryndzionek commented Sep 4, 2024

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:
screen_00000

@dawsonjon
Copy link
Owner

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.

@mryndzionek
Copy link
Contributor Author

mryndzionek commented Sep 4, 2024

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.

@mryndzionek
Copy link
Contributor Author

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

@bmentink
Copy link

bmentink commented Sep 5, 2024

Looks good. Except, I have some rubbish characters left column of the screen ..
Sorry, could not eliminate the scan lines ..

IMG_20240906_100403461

@mryndzionek
Copy link
Contributor Author

Looks good. Except, I have some rubbish characters left column of the screen .. Sorry, could not eliminate the scan lines ..

IMG_20240906_100403461

Is this a SSD1306, or SH1106 display? Probably wrong controller. I think the binary was for SH1106.

@bmentink
Copy link

bmentink commented Sep 5, 2024

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 ..

@mryndzionek
Copy link
Contributor Author

I presume the code is for rp2040?

Yes, RP2040.

@dawsonjon
Copy link
Owner

Like the new look!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants