Discontinuities using Tap-based Filter

[snethej]

I was testing some filters out and noticed that there appear to be some discontinuities using the OpenCL Tap-based Filter. The discontinuity can be seen here:

where my flow graph is:

OpenCL_Test-FIR.grc.gz

And I am getting an interesting display on the Frequency sink, where at times (as opposed to the first attached pic), it will look like:

Does this seem like an issue? Or am I doing something incorrectly?

I'm using the following configurations:

• Ubuntu: 18.04 LTS
• gr-clenabled: maint-3.8 (11b091)
• gnuradio: v3.8.2.0-102-gcc5a816b

Thanks!

[ghostop14]

I just reran some of the validation tests for the filter and it looks fine. I'm running GR 3.9, and trying to load your flowgraph, one thing I got was a warning about the types being off between the lowpass filter taps and the filter blocks.

Maybe try with float taps to start? It's possible that low-pass filter taps block isn't creating the complex taps right and it's creating those results. (It's also possible something's up specifically with complex taps, but let's try that first). Real taps matches almost exactly:

[snethej]

I reran the flow graph and put the following taps directly into the taps field (kind'a long) and got similar results.

Here are the tap values I used:

[-0.00008815190335809532,-0.00011172578240345743,-0.00016826108201265451,-0.0002290723838676996,-0.0002863757429212003,-0.0003304465720258541,-0.00035071171115918197,-0.00033726685080957743,-0.00028266443338220996,-0.00018370156899331875,-0.00004292850332514025,0.00013045823465991982,0.00032059928707415267,0.0005059787041421145,0.0006615447024121019,0.0007617922852504638,0.0007844507416495164,0.0007143583431569862,0.0005469416376959611,0.00029065291704309356,-0.00003214117052714821,-0.00038621556762703953,-0.000726655381071635,-0.0010039326629597153,-0.0011704266777353347,-0.00118764152380716,-0.0010330837858002673,-0.0007057422654498438,-0.00022917872500656525,0.00034860859434402683,0.0009589097996284668,0.0015195248508008182,0.0019449362736513323,0.0021582042870095033,0.0021031590794902944,0.0017549164153012793,0.0011274990375286478,0.00027601808513801675,-0.0007057481262607951,-0.0016949531922210983,-0.002553408231008739,-0.003145651493431724,-0.0033588099917299555,-0.0031209623440014013,-0.0024159007521117426,-0.0012917215819165165,0.000139060138634115,0.001708572755372419,0.0032113041790392087,0.004429051197510581,0.005160396888978032,0.005250889237852777,0.004619657123533495,0.0032784269310275724,0.0013396075262042946,-0.0009888487230099133,-0.0034225081540192495,-0.0056320894952334,-0.007284479609561834,-0.008088472324864834,-0.00783940779097987,-0.00645650261342922,-0.004007136516181724,-0.0007134890982363589,0.0030610806836573056,0.006845954046253625,0.010114975641520143,0.012350902070927558,0.01311533623170451,0.012115805649096891,0.009261083849927378,0.004696818142239974,-0.0011846874229128155,-0.007763764930901115,-0.014241948573469778,-0.019715892609292185,-0.023270113762653886,-0.024078709278029093,-0.02150485800572174,-0.0151866468544699,-0.005098421638350086,0.008420421283359132,0.02467402999809288,0.04265699832568164,0.06113588664184062,0.07875768599463434,0.09417449591266337,0.10617142734159933,0.11378404764828312,0.11639278069797142,0.11378404764828312,0.10617142734159933,0.09417449591266337,0.07875768599463434,0.06113588664184062,0.04265699832568164,0.02467402999809288,0.008420421283359132,-0.005098421638350086,-0.0151866468544699,-0.02150485800572174,-0.024078709278029093,-0.023270113762653886,-0.019715892609292185,-0.014241948573469778,-0.007763764930901115,-0.0011846874229128155,0.004696818142239974,0.009261083849927378,0.012115805649096891,0.01311533623170451,0.012350902070927558,0.010114975641520143,0.006845954046253625,0.0030610806836573056,-0.0007134890982363589,-0.004007136516181724,-0.00645650261342922,-0.00783940779097987,-0.008088472324864834,-0.007284479609561834,-0.0056320894952334,-0.0034225081540192495,-0.0009888487230099133,0.0013396075262042946,0.0032784269310275724,0.004619657123533495,0.005250889237852777,0.005160396888978032,0.004429051197510581,0.0032113041790392087,0.001708572755372419,0.000139060138634115,-0.0012917215819165165,-0.0024159007521117426,-0.0031209623440014013,-0.0033588099917299555,-0.003145651493431724,-0.002553408231008739,-0.0016949531922210983,-0.0007057481262607951,0.00027601808513801675,0.0011274990375286478,0.0017549164153012793,0.0021031590794902944,0.0021582042870095033,0.0019449362736513323,0.0015195248508008182,0.0009589097996284668,0.00034860859434402683,-0.00022917872500656525,-0.0007057422654498438,-0.0010330837858002673,-0.00118764152380716,-0.0011704266777353347,-0.0010039326629597153,-0.000726655381071635,-0.00038621556762703953,-0.00003214117052714821,0.00029065291704309356,0.0005469416376959611,0.0007143583431569862,0.0007844507416495164,0.0007617922852504638,0.0006615447024121019,0.0005059787041421145,0.00032059928707415267,0.00013045823465991982,-0.00004292850332514025,-0.00018370156899331875,-0.00028266443338220996,-0.00033726685080957743,-0.00035071171115918197,-0.0003304465720258541,-0.0002863757429212003,-0.0002290723838676996,-0.00016826108201265451,-0.00011172578240345743,-0.00008815190335809532]

[ghostop14]

Thanks, I'll look into it some more with that use case.

[snethej]

Just a note: I'm seeing my problem using taps, [0.5, 0.5]. It gets really pronounced if I use [0.5, -0.5].

[snethej]

Looking at input_items and output_items, it seems like the filter calculation is starting at the current zero offset of the input value, and the last calculation is based off a zero value at [gid+1]. I'm not a filter guy, so I could be way off, but it seems like the calculations should start at input[-1] and end at input[ninput_items - 2], where input[-1] is the historical value of the previous list, input[ninput_items-1].

Good descriptions seem to be a problem of mine, so I attached an Calc spreadsheet where I attempted to show what I think the filter calculations are (using [0.5,-0.5] as taps) and the last calculated value matched the actual output value. This was from one call to the work function with ninput_items == 4088.

I am now running the flowgraph using a decimation of 1 to simplify looking at input vs. output.

OpenCL_FIR.ods.gz

[snethej]

Sorry if I'm hitting this too often, but I want to record what I find as I find it in the chance that it may help.

Something else that I'm wondering about is the history (related to me previous post). For set_history(2), the first run of input items (first call to ::work function) are:

History: 2
INPUT[1]
in[0]:0
in[1]:1
in[2]:0.999982
in[3]:0.999923
in[4]:0.999824
.
.
.
in[4091]:0.844329
in[4092]:0.840945
in[4093]:0.837528
in[4094]:0.834079
in[4095]:0.830596

The first value of zero matches what is described for set_history(). The second call to ::work() has the following input values:

History: 2
INPUT[2]
in[0]:0.82708
in[1]:0.823532
in[2]:0.819952
in[3]:0.816339
in[4]:0.812693
.
.
.
in[4083]:0.437118
in[4084]:0.431458
in[4085]:0.425782
in[4086]:0.420088
in[4087]:0.414378

It does not appear that the history is included in the new buffer. I would expect that 0.830596 would be the first value of the second input buffer. That seems odd, since history shows the correct value set.

[ghostop14]

Hi snethej, work's had me a bit unavailable so sorry for the late reply. So the history makes sure there are "old" entries included when work() is called (which you need for the FIR filter to work correctly). I won't have time to look at this in any more detail for another week or so if I don't get a chance to reply.

[ghostop14]

snethej, I had a few minutes and did actually find the bug and fixed it. I pushed to both master (gr39) and the maint-3.8 branch. Let me know if that takes care of the issue for you.

[snethej]

That's awesome! I'll have to test it after I figure out what happened to my environment. I'm getting an error like:

terminate called after throwing an instance of 'cl::Error'
  what():  OpenCL Error: Unable to get platform list.

after some updates were applied to my system.