Meter data duplicated?

  • 1
  • Question
  • Updated 1 week ago
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
Photo of John G3WGV

John G3WGV

  • 187 Posts
  • 35 Reply Likes

Posted 3 months ago

  • 1
Photo of Doug - K3TZR

Doug - K3TZR

  • 89 Posts
  • 11 Reply Likes
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?
Photo of John G3WGV

John G3WGV

  • 187 Posts
  • 35 Reply Likes
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?
Photo of Doug - K3TZR

Doug - K3TZR

  • 89 Posts
  • 11 Reply Likes
My system is also 2.1.33. I'm not sure about previous versions.
Photo of John G3WGV

John G3WGV

  • 187 Posts
  • 35 Reply Likes
I'm sure Eric will be along in a bit to give us the inside track.
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 675 Posts
  • 203 Reply Likes
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.
Photo of John G3WGV

John G3WGV

  • 187 Posts
  • 35 Reply Likes
Thanks Eric.
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1027 Posts
  • 988 Reply Likes
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?
Photo of John G3WGV

John G3WGV

  • 187 Posts
  • 35 Reply Likes
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.
Photo of John G3WGV

John G3WGV

  • 187 Posts
  • 35 Reply Likes
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                                 ......

(Edited)
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1027 Posts
  • 988 Reply Likes
OK I found it ... stupid 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!
Photo of John G3WGV

John G3WGV

  • 187 Posts
  • 35 Reply Likes
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.
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1027 Posts
  • 988 Reply Likes
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.
Photo of James Whiteway

James Whiteway

  • 874 Posts
  • 193 Reply Likes
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
Photo of Doug - K3TZR

Doug - K3TZR

  • 89 Posts
  • 11 Reply Likes
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.
Photo of Doug - K3TZR

Doug - K3TZR

  • 89 Posts
  • 11 Reply Likes
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).
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 675 Posts
  • 203 Reply Likes
Note that the fix mentioned above will be in v2.4 when it is released (currently going through Alpha testing).