Waterfall and tile data #2

Walt - KZ1F

Here is my data:
Waterfall {streamId=0x42000000, bandwidth=0.016, centerFreq=18.0780006, size=1500,800}

WaterfallTile{FirstPixelFreq=18058301, BinBandwidth=11.0, LineDurationMS=80, _width=3360, _height=1, Timecode=5, AutoBlackLevel=11570, DateTime=Tue Jun 16 10:35:17 EDT 2015}


Waterfall {streamId=0x42000000, bandwidth=0.016, centerFreq=18.0780006, size=1500,800}

WaterfallTile{FirstPixelFreq=18058301, BinBandwidth=11.0, LineDurationMS=80, _width=3360, _height=1, Timecode=6, AutoBlackLevel=11570, DateTime=Tue Jun 16 10:35:17 EDT 2015}


Waterfall {streamId=0x42000000, bandwidth=0.016, centerFreq=18.0780006, size=1500,800}

WaterfallTile{FirstPixelFreq=18068150, BinBandwidth=5.0, LineDurationMS=80, _width=3360, _height=1, Timecode=7, AutoBlackLevel=12070, DateTime=Tue Jun 16 10:35:17 EDT 2015}


Waterfall {streamId=0x42000000, bandwidth=0.016, centerFreq=18.0780006, size=1500,800}

WaterfallTile{FirstPixelFreq=18068150, BinBandwidth=5.0, LineDurationMS=80, _width=3360, _height=1, Timecode=8, AutoBlackLevel=12070, DateTime=Tue Jun 16 10:35:18 EDT 2015}


Question 2) There was a post Steve made on the second page of Williams Android app thread, where he talked about waterfall stuff.
The first pixel in the batch of data is 18.0583 MHz yep got it
There are 3360 data points, the shorts shown above
Each datapoint represents 11 Hz.

I interpret this to  mean - the OnDataReceived event is sending data that starts at
18.0583MHz for 36.960KHz. As Steve pointed out, this data spans the pan window size to represent frequencies below that shown in the pan as well as frequencies above that shown in the pan. Am I interpreting this correctly to say the bandspread for that row of the waterfall goes from 18.0583 to 18.0952 MHz? The pan, goes from 18.070 to 18.086. This seems to support what Steve said the waterfall is wider than the pan. I am concluding therefore, that not only is my math correct so is the interpretation of the data headers. Correct?

Where my problem starts is interpreting that last tile and, worse, one from yesterday.
The last tile above would equate to representing a bandwidth from 18.068 to 18.084. This high end seems wrong as it is within the spread of the pan, on the upper side. If a subsequent packet had a starting pixel frequency of 18.085, I'd feel much better. However, the previous one has the same range so something seems to be incorrect. Would you weigh in on this please?

Yesterday, with the identical pan values I was getting tile values such as
WaterfallTile{FirstPixelFreq=17847188, BinBandwidth=187.0, LineDurationMS=40, _width=2460, _height=1, Timecode=4, AutoBlackLevel=0, DateTime=Mon Jun 15 20:06:55 EDT 2015}
Total bandwidth of waterfall line = 17.847 to 18.307 which seems completely...wrong?

Stu Phillips - K6TU

Please see my post at 

https://community.flexradio.com/flexradio/topics/generating-a-pan-adaptor-and-waterfall-display

for calculating the frequency of incremental bins in the WaterfallTile.

To render the Waterfall, you need to retain a list of tiles that is at least as long as its height in pixels.

Each tile may have a different start frequency is you have caused the pan adaptor center frequency to change.

Each tile may have a different binBandwidth if you have changed the bandwidth of the pan adaptor.

Its up to you (the client) to figure this out and render the waterfall from the data you already have. This may require interpolation or chucking in the towel and starting to accumulate a new list of tiles rendering the bottom of the waterfall black until you have enough data.


Stu K6TU

PS: Don't forget the like... ;-)

Walt - KZ1F

My point is there seems to be bad data. Yes, I understand if I reposition the center frequency that will change the two ends. I did NOT do that. Your last 4 paragraphs I disagree with. Principally because the data I am presenting is with no external management like altering center frequency or dbm or size. I would also argue, no, you do not save the data, you may, however, save the image the row of data represents.

Iteratively it will work like this,

for each raised event
   build an image
   scroll the viewport down 1 tile depth (generally 1 pixel)
   display that image at 0,0 (offsetting for the overlap so the translation will involve an X shift
   at some point when the array of images exceeds the max waterfall depth, delete the bottom image, store them in a DEQUE. (double ended queue) in that way scrolling is far easier as is the time machine function. The more advanced way is to have them be in a much larger queue and simply reorient the viewport which would make scrolling more efficient still.

  

Stu Phillips - K6TU

It depends on the client.

If the client wants to...

• Scroll the pan adaptor and retain a valid waterfall
• Alter the pan adaptor zoom level (bandwidth) and render an updated waterfall
• Allow the user to select a different color gradient and render an updated waterfall
• ...

you need to recompute the color mapped waterfall as the old bitmap is now stale.

You could chose to generate a bitmap for the whole waterfall and then change the portion of it that is mapped to the view(port) but that's even more data to have to store and move every time you scroll down a line.  This only helps you on the scroll case.

FWIW, with a 1024 wide panafall, I see Waterfall tiles of width 2460 - so roughly 2.4x the number of bins.  The main pan adaptor has 1024 pixels over a bandwidth of 100 KHz (97 Hz/pixel), the Waterfall binBandwidth conveniently is the same.

However... the bins in the WaterFall tile don't line up on the same boundaries as the pan adaptor pixels...  so you need to interpolate in order to get the pan display and the waterfall to line up (pixel wise).

If the zoom level, gradient, black level etc are changed and you have stored a list of previous tiles, you can interpolate a new waterfall which is still valid.  You can't do this if you store a bitmap alone.

In the normal (optimized) case where the panafall has not been scrolled, you are spot on - scroll the memory backing up the bitmap down a line, draw in the new line at the top of the bitmap.  This is a fast operation on most devices now and can be done without having to descend into OpenGL or METAL (although then you can render the bitmap as a shader gradient and I'm told it would be even faster).

If you experiment with SmartSDR, you can see that there are cases where the waterfall history is interpolated to draw a new waterfall for the user.  Without keeping the history around, you wouldn't be able to do that.

The choice of how to render the waterfall is (IM-ever-so-HO) up to the client.  The client can then trade off what kinds of cycles it want to burn and how much complexity to dump upon the software guys having to do the SMOP :-)

Anyway, you will have to excuse me but I'm out of time.

Stu K6TU

Jon_KF2E

I'm going to like this even though I don't completely understand it. I think it is great that Stu donates his time to help developers here on the forum.

Jon...kf2e

Walt - KZ1F

@Stu, SMOP?

I am not a real big fan of the Waterfall. I think it has a near instantaneous value, but scrolling back and redrawing it, I don't know. However, just because I don't doesn't mean a customer of mine wont. The nice thing about what I am doing is if the framework sees a GPU, it'll dive into OpenGL or OpenGL-es. My framework will easily do 60fps, now that is high def.

Walt - KZ1F

@Jon, gee thanks.

Jon_KF2E

Walt,

I like what you are doing as well. I hope your project results in an IOS app that I can use to access my radio...keep at it:)

Jon...kf2e

Walt - KZ1F

As I've told Stu, running on an iPad required running the source thru a conversion program, do able but I haven't done it. Mac is out of the box.