API RequestPanadapterFromRadio

Walt - KZ1F

I could swear this was answered by Steve but I can not find it.
Here is what I am seeing:

PanAdapter pan = new Panadapter(radio, new Size(200,100);
boolean result = pan.requestPanadapterFromRadio();

The pan object is instantiated and the panadapter is created in the radio, I can hear it and I am getting FFT data flowing from it.

However, what is happening is I can't see it as the reply to the "display pan ....." instead of coming back with 1 stream id, it comes back with 2. Consequently the reply update fails as the parse of the nnnnn,mmmmm fails. Consequently in the code when a FFT packet arrives it can't find the proper stream id, when this occurs it creates a new panadapter with a size of 0,0, consequently the FFT data is bagged because the y dimension is greater than the  height of the view.

Does this ring a bell for anybody?

Thanks,
Walt - kz1f

Stu Phillips - K6TU

Walt,

Regardless of whether you create a pan adaptor or a panafall, you get a panafall.  The two stream ids that are returned are for the pan adaptor and the waterfall respectively.

Best to do a "sub pan all" and you will get the relevant status messages as well as the stream ids.

Stu K6TU

Walt - KZ1F

Thanks Stu. That is what I assumed and I did find comments from Steve about not supporting 2 displays in connection with 4000000 and 4000001 (or was it 42000000). What was troubling was in the FlexLib source in Panadapter:UpdateStreamID it performed an Integer.TryParse(...) which the doc on it says it takes A number in string form. I would have thought the 2 comma separated numbers would have failed there as well. Again, on a good day I can spell .Net.  But the stream of commands sent to the radio are a whole series of subscribes, one of which IS sub pan all. After I changed the updateStreamID to parse off the first number in the CSV series, it appears fine, just curious about the csv as a response to the  requestPanadapterFromRadio.
Again, thanks Stu.

Walt - kz1f

Eric-KE5DTO

Walt,

It looks like at some point we changed to using a different method (Radio.RequestPanafall instead of Panadapter.RequestPanadapterFromRadio).  I don't see that we hit the UpdateStreamID code path anymore as a result.  I suspect that function would indeed need to be updated in order to comply with the new reply.  Thanks for pointing this out.

Walt - KZ1F

Thank you for your reply there Eric. A related question. Now that flexlib has 'escaped' (software isn't released, it escapes), are you considering deprecating no longer used methods? Or, put slightly differently, would you mark no longer used methods as deprecated? I don't know how C# handles this but Java uses @deprecated. I suspect C# does as well.  What that means for those that don't understand what I am talking about is @deprecate is a vehicle vendors used to mark portions of their software as potentially being removed. It gives users of their software an indication at compile time that they are using an 'old' method which may not survive the next release.  It gives users a chance to change their code before it stops working or compiling.

Eric-KE5DTO

I would need to talk to the team about this, but my personal opinion is that I don't really want to leave dead code laying around.  I would probably lean towards giving the API develops a heads up if a part of the API is going to change.  This is something we have not been particularly good about to this point as the pace of development here is fast and furious.  This will get better over time.