Reading S Meter with FlexLib API

Mark Erbaugh

I'm having trouble getting a reliable SMeterDataReady callback in FlexLib API on a Slice receiver on my 6300. I have a callback routine. It will be called reliably for several hundred times, then will pause for several tens of seconds. Some times when I start my program from scratch, the callback doesn't seem to be called at all. I restart the program and it may work again, although it will pause.

I have successfully written callback routines to handle other callbacks from FlexLib API, is there something different with callbacks for S Meter?

Mark Erbaugh

I've revised the synchronization between the callback and the main program loop and the delays are gone, but it doesn't look like my external S Meter agrees with the S Meter on SSDR. I still have some work to do.

Peter K1PGV

I haven't observed the behaviors you're seeing... if that's any help. 

Soooo, based the change in behavior resulting from your changes in serialization, I'd suspect a local bug not a FlexLib one at this point, at least.

Mark Erbaugh

Could you outline the steps you use to set things up?  It might point out what I'm doing wrong.

Peter K1PGV

I'm happy to.  But if you're getting ANY events, you must be doing it right.

When the slice is added, I add then event processing routine:

           _theSlice.SMeterDataReady += OnSMeterDataReady;

And in the callback:

       private void OnSMeterDataReady(float data)        {
            data = (float)Math.Round(data);

            ...

            int valToDisplay = (int)data;
            SMeterTextBox.Text = valToDisplay.ToString(CultureInfo.InvariantCulture);
        }

I'm currently not concerned about serializing access to the main form, so I just slam the data from the callback, because I'm using the FlexAPI for fun not for work.  But this is not an acceptable strategy for production code.

If I were doing this for real, I do the usual checking "<control-name>.InvokeRequired" blah blah blah.  You probably know this, but for the archives: You can NOT do your own serialization or locking to protect from this cross-thread update.  They way I understand it, that'll fix your code's synchronization issue, but won't address issues the CLR might have.

Hope that helps,

Peter
K1PGV

Mark Erbaugh

I'm doing this with Python and not doing anything special re serialization as far as CLR is concerned. Python has a thread safe Queue that I use to pass data among threads, but I hadn't considered issue with the CLR

James Whiteway

Peter, I just wanted to say thank you for posting the code sample above. (and all the others that you have go generously shared) My little testbed program (appropriately
named K1PGV's Test program since a lot of it has come from you) now has a working S Meter Display! And amazingly enough, I have not yet started using v1.4 of the Flexlib and still, (so far) everything I have been working on still works!
 It seems since I started working harder on using Threading that things are starting to click. So, code snippets like yours really help.
james
WD5GWY

  Oh, and this is with v1.4 of SmartSDR running. Just not using v1.4 of Flexlib yet.

Peter K1PGV

My pleasure, James.  I honored by your naming your test app after me.  Feel free to request examples of various things.

Mark Erbaugh

After further testing, I believe my S-Meter readings agree with those in SSDR

Peter K1PGV

Bravo!  It's really pretty simple once you get the hang of it, isn't it!

de K1PGV

Vern

One more time....  Found something new today. Started a new project, (using C# VS 2012), add 'csproj's' Vita,Util, UiWpfFramework & FlexLib. It does NOT compile. Now, if I remove Vita & FlexLib the project compiles!! Anyone with a clue, pse? Using K1PGV's example.

Vern

James Whiteway

Vern, there is a particular order in which the individual projects need to be compiled. Some of the Flexlib projects depend on the other projects being compiled first. I'm on the road (again) or I would look up what the order is for you. Mark, posted a video that gives another way to compile all the projects together. But, even then, you'll see some error messages until all are compiled correctly. It is a hassle doing it this way. What I do most of the time when a new version of SSDR comes out is, after installing SSDR. , I make a folder on my C: drive with a name like SSDR dlls v1.6.17, and then I go to PROGRAM FILES on my C: drive and find where Windows installed the latest version of SSDR. I then COPY all of the dll's you mentioned, and paste them into the new folder I made for them earlier. Then, I load my test project and unreference the old dll files I had been using and once that is done, I add a Reference to each New dll file in the new folder I created earlier. Then, in the BUILD MENU, I select REBUILD PROJECT. It should build with no errors. Also be sure to put a copy of inoic.zip.dll in the new folder as well and reference it before Rebuilding your project. Hope this helps. James WD5GWY