Meter data duplicated?

John G3WGV

For some time I've wanted to put some software damping on the S-meter to stop it bouncing around quite so wildly, so that took me into code I've not looked at for a while to check timings.

I was perplexed to discover that my API library was sending three identical S-meter events to my application within 1ms of one another and assumed I had a bug. In fact, it appears that the radio is sending multiple copies of meter data per packet.

In the following screen-scrape of a Wireshark UDP packet capture, the S-meter is meter 0x0015:



The three sets of S-meter data are highlighted. Further inspection shows that other meters are sent multiple times as well. As the meter data are always identical in a given packet I've fixed the issue by only processing the first occurrence of each meter per packet.

Is it a bug, a feature or by design?

73, John, G3WGV

Doug - K3TZR

John,

I've added some code to my API Tester to check for meter duplication in a single Vita meter packet. The code keeps track of which meters are contained in a single Vita meter packet and how many times it has seen that meter in the packet. It produces a printout whenever the count for a meter is greater than one.

Here's a portion of what got printed:

meter = 5, count = 2

meter = 1, count = 2

meter = 14, count = 2

meter = 17, count = 2

meter = 19, count = 2

meter = 2, count = 2

meter = 18, count = 2

meter = 1, count = 2

meter = 11, count = 2

meter = 12, count = 2

meter = 10, count = 2

meter = 13, count = 2

meter = 14, count = 2

meter = 5, count = 2

meter = 6, count = 2

meter = 7, count = 2

meter = 3, count = 2

meter = 1, count = 2

meter = 8, count = 2

meter = 17, count = 3

meter = 19, count = 3

meter = 22, count = 3

meter = 18, count = 3

meter = 2, count = 3

meter = 4, count = 3

meter = 9, count = 3

meter = 21, count = 3

meter = 23, count = 3

meter = 24, count = 3

meter = 1, count = 3

meter = 5, count = 3

meter = 1, count = 3

meter = 14, count = 3

meter = 17, count = 3

meter = 19, count = 3

meter = 2, count = 3

meter = 18, count = 3

meter = 1, count = 3

meter = 11, count = 2

meter = 12, count = 3

meter = 10, count = 3

meter = 13, count = 3

meter = 14, count = 3

It seems to happen constantly. As you asked, Is this by design or is it a bug?

John G3WGV

Hi Doug,

Yes, that tallies with what I am seeing on my V2.1.33 system. I'm surprised I'd not noticed it before and I wonder if it might have been introduced with V2?

Doug - K3TZR

My system is also 2.1.33. I'm not sure about previous versions.

John G3WGV

I'm sure Eric will be along in a bit to give us the inside track.

Eric-KE5DTO

Looks like a bug to me.  I wouldn't expect the same meter to show up in the same meter packet more than once.  I've captured this as #6250 for tracking.  We will let you know what we find.

John G3WGV

Thanks Eric.

Steve-N5AC

I took an initial look at this today and do not see the behavior.  I see ~16-28kbps meter data with v2.3 and no meter duplicates.  I tried adding additional receivers, panadapters, running CAT and DAX on one machine.  There is code to prevent duplicate subscriptions, but it's possible that for some situation it doesn't work.  Is there any way you are subscribing multiple times or you have something else that is different from my setup that might be causing the problem?

James Whiteway

Steve, I saw this behavior in SSDR in versions prior to 2.3. You could add meters over and over. Haven't seen it since then. Maybe you fixed it! James WD5GWY

Doug - K3TZR

The duplicates I saw in 2.1 were the same meter being listed more than once inside a single Vita meter packet. Running 2.3.9 I'm not seeing any duplicates of this type.

John G3WGV

Hi Steve,

Thanks for looking into this. I've just checked on my 6500, V2.3 and I am definitely still seeing meter duplication, just as before. This is a Wireshark of the streaming UDP port, showing a VITA49 meter packet. As highlighted, meter 0001 is sent three times in the same packet. The other meters are similarly sent three times.



Then I had a sudden wheeze! In my test configuration I have three clients connected to the 6500 that subscribe to meter data (Smart SDR, my operational controller and the test controller). Three. Hmmm. Coincidence? I knocked one of them off and guess what? There are now only two copies of each meter in the VITA49 packet!

I am now pretty confident that the number of meter copies per VITA49 packet sent to each client is equal to the number of clients that are subscribed to meters. An interestingly nuanced bug indeed!

73, John, G3WGV

John G3WGV

As an aside, I tried Wiresharking with only Smart SDR connected to the 6500 and was curious to note that I couldn't see any UDP VITA49 meter packets at all. Does Smart SDR use some other way to get meter data out of the radio?

Steve-N5AC

What version of SmartSDR are you running? I tried multiple clients and did not observe this problem.

John G3WGV

V2.3 now, problem first seen on V2.1. I can't think of anything else to try but I also cannot see that Wireshark can lie. Were the multiple clients all connected concurrently and all subscribed to meters?

Steve-N5AC

Yes I connected CAT and DAX locally and then CAT from another system thinking this was the issue. I would not suggest that the problem doesn’t exist nor that Wireshark lies. But we need to duplicate the problem to fix it so I’m just trying to make it happen so I can see what the cause is (so it can be fixed).

John G3WGV

I don't think this is anything to do with CAT or DAX, neither of which I use. It seems to be a direct consequence of multiple concurrent clients that have each subscribed to meter data. My set up is:

1. Smart SDR (the GUI client)
2. My controller (you saw it at Visalia in 2017)
3. My logging program
4. The test controller, whose UDP stream I am Wiresharking.

All are connected concurrently and all but the logging program subscribe to meter data.

John G3WGV

Update:

I modified my logging client so it too subscribes to meters. Sure enough, there are now four copies of each meter per packet. I can't really see any explanation for this other than what I advanced earlier.

0000   74 d4 35 18 df 94 00 1c 2d 02 09 c7 08 00 45 00   tÔ5.ß...-..Ç..E.
0010   00 78 00 00 40 00 40 11 b9 1a c0 a8 00 06 c0 a8   .x..@.@.1.À ̈..À ̈
0020   00 04 13 81 13 82 00 64 db ea 38 5a 00 17 00 00   .......dÛê8Z....
0030   07 00 00 00 1c 2d 53 4c 80 02 5b 5c 63 38 00 00   .....-SL..[c8..
0040   00 00 00 00 00 00 00 01 dd 35 00 04 83 00 00 0d   ........Ý5......
0050   83 00 00 0e 00 00 00 01 dd 35 00 04 83 00 00 0d   ........Ý5......
0060   83 00 00 0e 00 00 00 01 dd 35 00 04 83 00 00 0d   ........Ý5......
0070   83 00 00 0e 00 00 00 01 dd 35 00 04 83 00 00 0d   ........Ý5......
0080   83 00 00 0e 00 00                                 ......

Steve-N5AC

OK I found it ... **** thing.  Didn't clear the buffer where meters were being accumulated so it has to do with the order that clients are added to the radio.  Funny thing was that I was doing a filter in wireshark for meter data doing "vrt.sid=0x00000700" which shows just meter data -- but it restricts it to port 4991 (VITA-49) and so I only ever looked at the first client.  Once I opened it up and didn't filter by stream ID and saw the other clients I found it.  This will be fixed in v2.4.  Thanks much for providing the extra info to help me find the problem!

John G3WGV

Result, Steve, well done. I always have to figure out how to use Wireshark each time I have a problem like this and need to go back to first principles. It's very powerful but it's easy (for me at least) to get it wrong and wonder what on earth is going on!

This was never really a critical problem, as I suppose the number of people that are doing what I do with multiple clients is always going to be small. Cracking it early on a Saturday morning, TX time, is definitely going beyond the call of duty. Many thanks.

Steve-N5AC

No problem -- we want to make the data footprint as small as possible so once I heard about this it became a "oh, I need to go find and fix that."  The section of code with the defect hadn't been touched in four years so it's a long-standing issue, but pretty low impact since everything will still "work fine."  Thanks again for pointing it out.

Doug - K3TZR

I just saw the same behavior in 2.3.9 that John reported, duplicate meters in a single Vita meter packet when running two clients simultaneously (in this case my SmartSDR-like client and my xAPITester).

Eric-KE5DTO

Note that the fix mentioned above will be in v2.4 when it is released (currently going through Alpha testing).