Metering class packet

Walt - KZ1F

Again, thanks Stu, That routine escaped my mind.

In java:
    public final void updateValue(int new_raw_value) {
        _raw_value = new_raw_value;

        switch (_units) {
            case Dbm:
            case Dbfs:
            case SWR:
                _value = _raw_value / 128.0f;
                break;
            case Volts:
            case Amps:
                _value = _raw_value / 1024.0f;
                break;
            case Degrees:
                _value = _raw_value / 64.0f;
                break;
        }

        OnDataReady(this, _value);
    }

James Whiteway

Walt, I'm the one that said the values are in dbm. I guess I wasn't clear enough and should of added "when queried thru Flexlib api". That's how I retreive them in the latest version of my test program. (Windows pgm written in C Sharp) James

Walt - KZ1F

James, for the longest time...well over a year now, I had a series of conversations with Steve. In fact, I had a conversation with Greg at Boxboro, has it been 3, years ago. The **** of my argument got refined to SmartSDR for Windows, implies SmartSDR for other platforms. The net of all that was, well, not my place to quote others, but it led me to '**** it, I'll do it myself then".  I had a conversation with Stu, that didn't turn out quite as well as I had hoped. But it was always my intention. However, I worked and looking at the exist code I realized to have the same functionality was going to be a monumental effort. Fortunately I was somewhere between retired and working March of 2014 so I then had the time to do it. I took another position shortly there after and that went to this last Feb. There were several vectors that place me right on the verge of selling the radio for a K-3 or TS-590. Ironically, it wasn't that the radio ****, quite the contrary, it was that Windows sucks. I have Windows on my laptop here for one reason only, Turbotax. Well, now it's two. In another couple of months it'll be strictly for DM-780 and cw-sweeper.  I don't really want to go into what S(er)SDR, ...I can not legally call what I am doing SSDR, it'll have more features and be directly integrated with my rotor, QRZ, my KAT-500 and KPA-500. It'll do some things that I won't telegraph now but it will also have a price tag. But even if it doesn't sell, it'll be on my Nexus 9 and my multi-monitor Linux system. Anyone remotely acclimated to SSDR will totally understand S(er)SDR. That, btw, is its working name, project name, if you will. Since it will probably offend people I don't want to offend, it'll likely have a product name in the near future. Oh, it WILL beat Maestro to the market.

I used to be huge in Windows, knew pretty much the internals, had an SDK at home. yada yada until Microsoft went one bridge too far. I love Linux as a development and execution platform, I've done really kickin web apps running under Linux, done a lot of devops stuff, Puppet, Juju, Openstack (I have a multi server OpenStack cloud in the basement, before that a multi-server Eucalyptus cloud. I did a lot of probono work with Eucalyptus, sort of Tim's position at FRS. As I've said before, on a good day I can spell .Net.

It took me the longest time to 'get' .Net events. I've got a kind of tenuous working knowledge of them now  But going through the whole of Flexlib to design it to be portable is not a trivial task. It's not 'hard' per se, it is immensely tedious. I believe Stu said that the other day, yep, he is not lying about that. I can see daylight now. There are times, however, when the question rears up, "why am I doing this?????".

One decision I made which slowed this process to a crawl, is do the entire kernel first, test it out, make sure it's working correctly, then do the GUI That way I am not debugging multiple things at once. I am now adding in the GUI. I did a you tube on the panadapter output the other day. You can barely see it but it is jumpin. I think it is faster than SSDR. This is a 2.4GHz to my laptop's 3.2GHz. Watching it live, it totally smokes. I do have a wireframe of the GUI in my head and will start building it out, slowly but surely. I am up to 87 classes so far not counting GUI classes.

That piece of code Stu mentioned, I had that. I vaguely remembered various divisors and then there was Tim's comment about DDUtil so it was all swirling around in the ether. As soon as Stu showed that snippet, it clicked.

W4WHL

I'm still lost

How do these values represent dbm?

 short -12146
 int +55670

I'm not useing the API, I'm just decoding the payload in java.

For ID 21, which in the 6300 is ;   

S7F7A2149|meter 21.src=SLC#21.num=0#21.nam=LEVEL#21.low=-150.0#21.hi=20.0#21.desc=Signal strength of signals in the filter passband#21.unit=dBm#21.fps=10#

I'm getting a short value (next 16 bits) of -12146 which cast to an int value of 55670

Walt, I used your values above, because mine are almost identical.  So I guess I missed something.

Sorry for what may be a **** question.  This is new territory for me

William

Walt - KZ1F

Is 435 better?  reported number / 128. That seems high.
If the negative was actually the proper value (although it is unsigned in C#, that would be -95DBm which sounds close to S9.

William, it is a very good question which I don't know the answer to. As I started out saying  nowhere does it say my Meter code is correct, but, it appears all the meter ids are spot on, range of 1-20-something for an id.

Stu would be a better judge of validity of the raw number than I.  I did kind of an en masse rewrite of the code without vetting it's accuracy until I had enough of the kernel done to validate. I am in the validate portion now.  I know....I don't have my Windows laptop running but if you hover over the S meter on a slice, it presents numbers that are, to my recollection, large floating point Check it against that, on the same freq in SSDR to your app. OK, now I am curious. Starting the laptop now..What SSDR starts with should be what I am displaying with shows some very loud RTTY signals.

Could that be the total of the passband and divided by the bandwidth?

W4WHL

Ok Glad its not just me   If you figure it out, please let me know. 

William

Walt - KZ1F

s 435 better?  reported number / 128. That seems high.
If the negative was actually the proper value (although it is unsigned in C#, that would be -95DBm which sounds close to S9.

William, it is a very good question which I don't know the answer to. As I started out saying  nowhere does it say my Meter code is correct, but, it appears all the meter ids are spot on, range of 1-20-something for an id.

Stu would be a better judge of validity of the raw number than I.  I did kind of an en masse rewrite of the code without vetting it's accuracy until I had enough of the kernel done to validate. I am in the validate portion now.  I know....I don't have my Windows laptop running but if you hover over the S meter on a slice, it presents numbers that are, to my recollection, large floating point Check it against that, on the same freq in SSDR to your app. OK, now I am curious. Starting the laptop now..What SSDR starts with should be what I am displaying with shows some very loud RTTY signals.

Could that be the total of the passband and divided by the bandwidth? "Signal strength of signals in the filter passband" which is the description.

I think -94 is a reasonable number. What's weird, and not to detract from your issue WIlliam, is what my app is displaying are some incredibly loud RTTY stations. Firing up my laptop (ssdr) I'd expect to see pretty much the same thing. nope, and I've tried all the bands. However, as the static crashes appear in one, they appear in the other.

I see the hover over on ssdr to be -120- -128 Dbm

Walt - KZ1F

I would also think as I changed bands on SSDR the display would change on my app. BTW, my app is markedly more lively than SSDR. It could be on 40m, yeah, I think it is 40. Lots of static crashes, no man made QRN.

Walt - KZ1F

got to shut down...boomers

W4WHL

Me too work early.  Thanks

W4WHL

Walt,

Played around this morning.  I think you are correct.  Casting to an int directly from the short, I think is the issue.  Dividing the short value by 128 before casting to in gives me what appear to be dbm.  The values for a quiet segment are around -111 or about s-2.5.   A ~s-8 birdy as measured by SSDR, gave a value of -82 on my app.

Here is a 20m shot, my noise floor on 20m is S-5 , so my test meter seems pretty accurate.  However there is a noticeable lag between the s-meter and the panadapter,  Not sure why this is!


https://www.youtube.com/watch?v=ocRKwEesA9k

W4WHL

I compared SSDR, and SmartSDR has a considerable lag also, so I guess this is just the way it is.  Never noticed this lag before,

By the way, the waterfall, does not show all that white noise as seen in the video.  Its some weird affect of the camera.

Walt - KZ1F

Not sure I know what you mean by your first sentence concerning lag.
OK, your turn. I am still not sure what band segment is displaying in my pan. This morning I added a slice, set it to 10.000 (WWV) and set that as the pan's center frequency. I was expecting to see a nice, well defined, AM signal. Nope. When I displayed the band, freq, etc about the pan prior to creating the slice, they were not populated. After creating the slice they were populated. Oh, the radio did change freq as I did hear WWV. What is your startup sequence prior to manually adjusting the freq, as far as
create pan
create slice
set set set etc?

W4WHL

The S-meter is a sec or so behind the peaks displayed on the panadapter.  I found another post on here about the S-meter delay.  But it was for v 1.38.  It seems there is still this lag.  Anyway, about the panadpter;

Here are my startup commands.

c45|display pan create x=1400 y=200

That is it.  The I adjust the bandwidth to preference

c45|display pan set 0x40000000 bandwidth=+bandwidth

Then I tune frequency;

C45|slice tune +slice+ " + newFreqA

Finally center on tuned frequency;

C45|display pan set 0x40000000 center=" + newFreqA


I just tried you exact test on 15.0 WWV and it worked as expected.


William

W4WHL

Other note - When I create the pan, it automatically creates slice 0, so I omit that step.

Other than that I do all the sub commands, prior to creating anything, this populates all my variables.

William

W4WHL

Here is my smeter progress, seems accurate enough, but just a bit laggy


https://www.youtube.com/watch?v=SYh9epwUaBs

Walt - KZ1F

I reported an issue months ago where SSDR would start with no pan, others experience this as well. I did add a warning msg in my code when the slice isn't created, I see that in my log.. The display pan ... Fails as I surmised the creat pan fails, which I've now verified.

IW7DMH, Enzo

I have two other questions:

- when in meter list I get fps=0 does it mean I'll never get that meter? or do I have to ignore fps value? It happens for both voltages and PA temperature meters.

- what about the conversion from dBm values? It seems it is not handled in Meter.cs - I think it needs a special handler, but I can't find where in flexLib api's code.

Thank you
Enzo

Walt - KZ1F

There is no meter for voltage and temp...they are just reported values. If you look at DDUtil, you can see how they are reported.
In meter.cs there is a method UpdateValue(int reportedValue) that does that conversion.

Walt - KZ1F

William, here is what I sent:

            Panadapter pan = new Panadapter(radio, new Size(1000, 500));
            PanDataReadyEventHandler tempVar = (Panadapter panx, short[] data) -> processPanData(panx, data);
            pan.addDataReadyEventListeners(tempVar);
            boolean panResult = pan.RequestPanadapterFromRadio();
            if (panResult) {
                Slice slc = new Slice(radio, 10.000, "ANT1", "AM");
                slc.RequestSliceFromRadio();
                System.out.println("Pan created");
                pan.setBandwidth(20000);
                pan.setCenterFreq(10.000);
                System.out.println(pan.getAutoCenter());
                System.out.println(pan.getBand());
                System.out.println(pan.getBandwidth());
                System.out.println(pan.getCenterFreq());
                System.out.println(Integer.toHexString(pan.getChildWaterfallStreamID()));

Here is what I received, so I have to troubleshoot why. Although it does explain why I couldn't figure out last night what it was receiving.

received status SB61421A5|display pan 0x40000000 x_pixels=1000 y_pixels=500 center=14.1 bandwidth=0.2 min_dbm=-125 max_dbm=-40 fps=25 average=0 weighted_average=0 rfgain=0 rxant=ANT1 wide=0 loopa=0 loopb=0 band=20 daxiq=0 daxiq_rate=0 capacity=16 available=16 waterfall=42000000 min_bw=0.004919999957085 max_bw=14.74560058594 xvtr= pre= ant_list=ANT1,ANT2,RX_A,XVTR

W4WHL

Hmm so something is not working there.  My code is simple in this regard, I just send the strings.  I keep a telnet up to the radio that has all the sub commands ran.  This way I can see all the radio messages.  It makes troubleshoot easy.

Are you sure that 10.000 is valid?  I thought when setting frequency you use an interger as in 10000000. My code sets the frequency like this

c45|slice tune 0 10000000

and

C45|display pan set 0x40000000 center=10000000

William

Walt - KZ1F

And, it turns out 14.1 is precisely where it was yesterday and before. Once I saw that earlier I went there and, sure enough, there was that big ole RTTY station.  There is nowhere in the code where there is a 14.1 so that likely is a FRS thing.

W4WHL

So did you figure out your issue?

Steve-N5AC

If you create a panadapter without a frequency, I believe we default the frequency to 14.1MHz

Walt - KZ1F

Yep, that is pretty much what I figured as I found no reference to 14.1 (14.088 is popular too) in any FlexLib code. From what Willam said he, doing straight telnet style commands, adds the freq on the command. FlexLib doesn't do this, in fact there is only the one ctor. I can fix that. So what perplexes me is how, given the frequency is not specified on the disp pan create blah blah, the slice is re assigned a new freq. I deduce that has to be occuring in the GUI.

One other very interesting behavior is, recall the problem I reported months ago about no panadapter generated upon SSDR startup? In looking through the code I discover, well it appeared, the only way that could happen is during the display pan create ... tcp cmd it would fail and, the only reason I could deduce it would fail is the error code "could not create a receiver". There is a notation in the current code where Eric makes the comment, to the effect, "This is happening way more than I would have thought". The place that comment exists is in the area where there is a failure of slice.... inuse=1, I am seeing that all over the place in  my log. I have yet to figure out how to enable the SSDR logging.

BTW, Steve, Eric, whoever, The panadapter display is VERY animated. It is updating visibly faster than it does on my Windows laptop, and I am displaying a window MUCH larger than possible on the 15" laptop. FWIW. I am next going to start plumbing in the final GUI environment. This will be done in a few months. Now I have a deadline.

Steve-N5AC

Walt, the guys in the office are very busy as you might imagine.  We read a lot (most/all) of the posts here in the community.  We see our job as to help unstick developers that get lost / have issues with the API / etc.  There are a lot of guys in the community that can also help and many that are doing things quite rapidly.  If you have a specific issue, it would be best to post a separate thread/topic about the issue and ask the question / provide details as concisely as possible.  The three paragraphs above dance around what may be issues, but we can't really tell from the descriptions what is going on and in the one sentence where there is a question mark, I can't tell if it is a question or a comment.

For example, your last paragraph tends to say you think that there is a bug in the panadapter update rate.  If you want us to look into this and respond, post your code and a video of what you see.

Walt - KZ1F

got it

Walt - KZ1F

William, do you have an email address we can use? You can send it to me at <my call> at arrl dot net.

Thanks,

Walt - kz1f

W4WHL

lee.hemmingsen@gmail.com