Startting WinSSDR with a slice already running

John G3WGV

Work continues apace with my homebrew Mk II controller. Here's a curiosity that I'd be grateful for view on:

Starting point: No client apps, no slices active in radio.

I now start my Mk II controller and, finding no slices in existence, it starts one (slice 0) and sets the associated frequency, panadapter average (70), FPS (15) and Weighted average (false). It also sets the waterfall gain (30). These are values that give a nice display for me. All this works as expected.

Now, I start WinSSDR. WinSSDR detects the existence of slice 0, sets frequency, bandwidth, etc. accordingly. However, the panadapter/waterfall parameters are not retained. Instead, WinSSDR starts up with pan average=0, FPS=25, waterfall gain=50.

This seems to be odd behaviour. It's also a nuisance, as this results in a display that is not nice for me! I wondered if WinSSDR was starting another pan/waterfall but it isn't - it's still slice 0's in each case.

So I am officially perplexed. I suspect a bug (feature?) in WinSSDR start-up, as I can't see how my code could have this effect. It seems to be inconsistent behaviour. Does anyone have any thoughts?

Thanks

John.

John G3WGV

An update:

I think the issue is that I'm not able to create panadapters in my home brew controller. In the wiki I see "Only the GUI client may create a Panadapter successfully today. Issue #2323 has been added to address this bug." And indeed, it seems that the panadapter is not being started by my controller now I look more closely at the API response messages.

So it seems I am trying to do something that isn't supported. That's not really a problem but I am still perplexed as to why WinSSDR would start up with "silly" display values when it finds an in use slice whereas it does not do so if it starts with no slices running.

All good fun...

73, John 'WGV

Eric-KE5DTO

John,

It sounds like you have already figured out that creating Panadapters on different clients concurrently is not something that support (yet).  I would expect that the values that would be used on SmartSDR for Windows would be the last ones used in a GUI (due to how these settings are saved in band persistence).

At some point, I expect we will implement multi-client capabilities that will remove the single GUI client restriction.  Let us know if you have additional questions about the API and congrats on getting things going to this point.  It is indeed good fun.  

John G3WGV

Thanks for the comments, Eric. Yes, I was aware that concurrent panadapters on different clients was not possible but I had hoped that I could set the starting parameters for a panadapter when it is started. I can see from the return codes that this isn't working, which is perhaps not surprising - the pan/waterfall has to exist before its parameters can be set.

The starting values when WinSSDR is started is the focus of my investigation now. If I start WinSSDR with no other clients already connected to the radio then it starts with the last-saved pan/waterfall settings. But if I have my client running first, even though it has not attempted to start a pan or waterfall, then SSDR starts with the odd display settings I mentioned in my original posting.

It was this that set me on the course of trying to pre-set the FPS/Average/Gain figures. I see now that I can't do that but the oddity remains that WinSSDR starts with those odd settings.

It's hardly a big issue, more a matter of intellectual inquisitiveness than a concern, but it would be good to understand what is going on. Perhaps I have found an unexpected "feature"!

My home brew Delphi-based API middleware is now working very nicely and I'm using it as the interface to my Mk II controller. I'm a bit ahead of myself on the software though - still need to get the new PCB design completed and into fab. More here for anyone who is interested.

Eric-KE5DTO

An existing (or detached, as we call it -- as in it is not associated with a Panadapter) Slice affects the startup persistence behavior as you have observed.  If one is found, a Panadapter with default parameters is created and associated with the Slice.  I'm fairly certain that this is the behavior that you are observing.

Note that while you can't have multiple GUI clients running, it is possible to control many of the Panadapter parameters in SmartSDR for Windows from another client once the Panadapter is associated with the Slice.

John G3WGV

Ah, now that's very interesting. I was starting to come to the conclusion that my "detached" slice might have a hidden panadapter. But in that case, I should be able to set its parameters, as you suggest in your second paragraph. That I don't seem to be able to do, although it is possible I am malforming the command in some way.

Anyway, I've got some useful new knowledge now, thank you Eric. I'll see where that takes me next. It's all rather fascinating to me as someone who cut his programming milk teeth 45+ years ago on PDP8 and IBM /360 assembler code!

Edit... just read this bit properly... "once the Panadapter is associated with the Slice". Do I have to do this or is the association managed by the radio? How do I determine the slice/panadapter mapping? I think this might be germane to the problem.

Edit 2... And then I find the answer in the raw data stream. The slice data from the radio includes "pan=0x40000000" and the Pan data points to the associated the waterfall. Seek, and ye shall find...

John G3WGV

OK, time for a new post.

I started my controller with no slices in use. After subscribing to all the usual things, my controller then created a slice.

>> *** new slice start up completed ***
>> SLICE PAN 00000000
[RAW] S49EAC399|slice 0 in_use=1 RF_frequency=50.087055 rit_on=0 rit_freq=0 xit_on=0 xit_freq=0 rxant=ANT1 mode=CW wide=0 filter_lo=-200 filter_hi=200 step=5 step_list=1,5,10,50,100,200,400 agc_mode=med agc_threshold=70 agc_off_level=10 pan=0x00000000 txant=ANT1 loopa=0...

Key: Lines starting ">>" are messages that I've coded so I can what's happening. [RAW] means it's raw data from the radio.

pan=0x00000000 is interesting! Normally panadapters have an address of 0x40000000. I think, therefore that pan=0x00000000 means that no panadapter is assigned. This is reinforced by the fact that I get no "display pan" message.

Now I start WinSSDR.

Among other things I now see

[RAW] S9C7A9F94|slice 0 pan=0x40000000 mode=CW qsk=1 tx=1

The panadapter has now been created. Oddly, the radio doesn't send any details of Average, FPS, gain to the API but by inspection in WinSSDR they are set to 0, 25 and 50 respectively, resulting in a rather horrible display.

Now I use WinSSDR to change the Average, FPS and Gain and see messages like this, as expected:

[RAW] S9C7A9F94|display pan 0x40000000 fps=25 average=3 weighted_average=0

[RAW] S9C7A9F94|display pan 0x40000000 fps=17 average=8 weighted_average=0

[RAW] S9C7A9F94|display waterfall 0x42000000 x_pixels=1187 center=50.087055 bandwidth=0.2 line_duration=80 rfgain=0 rxant=ANT1 wide=0 loopa=0 loopb=0 band=6 daxiq=0 daxiq_rate=0 capacity=16 available=16 panadapter=40000000 color_gain=35 auto_black=1 black_level=0 gradient_index=1 xvtr=

So now I am not so sure about the hidden Panadapter idea. If the radio is creating one then it's not telling the API about it. There is more to this than meets the eye!

Eric - I know you'll have more important things to be doing that following my rambling voyage of discovery. Please don't feel obliged to spend time on this unless you want to.

Eric-KE5DTO

It is possible that we are missing a status message on the creation of the default panadapter on a detached Slice.  However, I'm not sure how this would work for SmartSDR to show the Panadapter if that were the case.  It may be that it only sends it to the GUI client though or something like that.  We will look into that.  Thanks for the info!  For reference, this is issue #4232.

John G3WGV

Thanks Eric. I'm still revelling in the amazing opportunities that the Flex API provides to create one's own radio interfaces. The occasional unexpected "feature" just spices things up a bit! I appreciate your time.

73, John.