Meter packet protocol

John G3WGV

For no other reason than that it's an interesting project, I am writing my own SSDR API library in Delphi XE7. The discovery protocol and IP stuff turns out to be fairly straightforward and I am slowly conquering streaming UDP. As this topic seems not to have received much comment in recent times, this is in part a brain dump of what I've found so far and in part a request for updated information.

Initially I "Wiresharked" the UDP datagrams and this enabled me to determine that discovery packets (only) are on port 4992 and streaming data is on port 4991. The former is documented reasonably well but it was difficult to find information regarding the streaming port.

Wiresharking the streaming meter packets, I discovered that the Wiki page is out of date, in that after the Class identifier the packets now contain 4 byte time stamp and 8 byte fractional time stamp fields, although all these bytes are set to zero. Thus, payload data starts at byte 28, not 16 as shown. The discovery protocol description correctly shows this.

Next I got all confused about the packet size field at bytes 2..3. It turns out that this is the size in 4-byte words. Didn't expect that!

So I think I am more or less set to start decoding meter packets. The FFT packets will, no doubt be another ball game altogether.

And so, to my question:

The Wiki suggests that meter context packets are sent via UDP but I have not managed to capture one out in the wild yet. I do get meter context data via TCP and it seems that these are sent whenever the context changes. So... are meter context packets actually sent over UDP? If so, why would I use those data instead of the IP data?

73, John, G3WGV

Eric-KE5DTO

John,

You have made good progress.  Thanks for sharing your experience.  A couple of things:

1. The streaming UDP port can actually move around.  This is because you can have multiple clients on the same machine talking to the same radio.  Thus, we needed a way to differentiate which stream goes to which client.  As such, there is a radio command for directing the UDP streaming to the port the client has opened for listening.  This command is:

client udpport

If not specified, the radio will default to using 4991.  In FlexLib, we try sequential numbers going up from 4991.  If the port is in use, we try the next one until we find an open one to use.

2. Use the packet definitions in the Vita C# project in FlexLib to help understand the details of the vita packets we use.  This should help with the details in addition to the wiki.

3. We don't actually use any context packets in SmartSDR yet.  We may use them at some point, but for now, we use status messages over the TCP command port for this kind of data and leave the streaming data for UDP.


I hope this helps.  Please feel free to ask additional questions.

Walt - KZ1F

John, be sure you subscribe to the metering packets, i.e. sendCommand("sub meter all");  Presumably you could define predicates to the request but that would require more elaboration from Eric.

Refer to the C# source, FRS provides, VitaMeterPacket.cs as well as Radio.cs, specifically UDPDataReceivedCallback, where there is a switch on header packet type, specifically, ExtDataWithStream, which contains VitaFlex.SL_VITA_METER_CLASS.

This should set you on the right direction, maybe even more info than you were looking for.

John G3WGV

Hi Eric,

Thanks for the very useful information. Since I posted I have made a lot more progress and am now decoding streaming meter data and presenting s-meter events to my test app, which then displays it on bargraph. Along the way I've learned a lot more about the VITA49 protocol!

Thanks for the note on client udpport. I had already thought of the problems associated with multiple clients on a single PC and this seems to address the issue. I'm assuming that the single PC can have as many TCP ports open to the radio as it wants (one per app). Also, as there are possibly multiple clients issuing client udpport commands, this means that the radio is streaming  to multiple UDP ports, which must have some processing overhead. I'm guessing there is a practical limitation here. I suppose that the radio stops steaming to the port when its client closes the port or otherwise goes away.

I will play with this soon because one of the problems I was planning to attack soon was that of having my homebrew logging program use the API to pull frequency/mode info and have that running on the same PC as SSDR. In fact, it was that requirement that started me off on this coding odyssey. I just kinda got sidestepped into a rather more grandiose project.

Yes, I've been delving into the FlexLib code and it's given me some good insight, even though I don't really consider myself to be a C programmer. I'm really an old-time hardware engineer / programmer that started off way back on IBM/360 assembler writing diagnostic code. So all this modern newfangled stuff can get a bit much for the old grey matter at times!

73, and thanks again.

John G3WGV

Hi Walt,

Thanks. Yes, as you can see from above, I am subscribing to meter data (and lots of other things too). I've spent some time wrapping my non-C mind around what I see in FlexLib and it's certainly given me some ideas but often there is no substitute for Wiresharking the interface. I suppose that's the way my old timer brain works. I'll be getting the 'scope out next and perhaps trying to solder a few more bytes onto the VITA packet!

Walt - KZ1F

I've got some java code you can look at but am not sure that would be of any more help than c#, in your case. VitaMeterPacket class, be it have or c# will unmarshal the UDP packet into a meter object. Radio object can show you how to notify interested parties of any specific meter object's data.

John G3WGV

Thanks for the offer but I think I'm probably beyond that point now. I've fully cracked the meter packet/meter context data and I am already creating (and handling) events for all sorts of things, including meter data.

It's always like this - it seems to take an age to get the hang of how some new protocol is constructed but once you've cracked it for one invocation it's easy (easier!) for the rest. I can read C (more or less) but I've never got on with it very well, being very much an Algol/Pascal/Delphi aficionado ever since I was weaned off assembler.

John G3WGV

Hi Eric,

I have a few more questions: I am already decoding the meter status messages and setting up my meter data arrays accordingly. At the moment I am just subscribing to all meters and I see up to about 30 meters with the two slices on my Maestro active.

How many meters can there be? It looks like each slice creates five, so I'm guessing a 6700 might make around 60 or so. I'm a cheapskate, so I only have a 6500...

Is there any reason (performance or whatever) not to subscribe to all meters? If I am to selectively subscribe then I will need to request and then decode the meter list output, which is not for the faint hearted! (although I suppose I've almost done that already for the meter status decode)

Are all real number meter values sent to two decimal places? I can see that the S-meter ones are.

I see on the meter status message that the COMPPEAK meter description has two tab characters at the end of the text, after ...(Compression). Is that a feature, a bug, or something with a cunning purpose?

I assume the FPS is the rate at which the meter updates (10 in the case of the S-meter level meters). Can that be changed? When I'm not maxing out on the computer, I am a keen CW op and at anything other than slow CW the S-meter update rate just isn't quick enough to follow the code.

****, this is so interesting: I'm really enjoying prying the lid off the API and gazing inside. But I really ought to go do something "useful" rather than sitting in front of the computer all day pretending to be a programmer! Like eating perhaps...

Eric-KE5DTO

There can be quite a few meters.  I'd hate to give a number and then have us add one to the Slices which would make that number grow.  In short, if you are going to do "sub meter all", you need to be prepared to create meter objects dynamically.

The only reason I can think of that you wouldn't want to do a sub meter all would be if you were operating remote and wanted to really limit the bandwidth used.  Keep in mind that the meter data pales in comparison to the audio data (which pales in comparison to the display data).  So this probably isn't the first place we would look to optimize bandwidth, but it is an area where you could trim a few KB/sec.

There shouldn't be any tab characters on the meter status data.  Can you give me an example of the exact message so I can track this down and get it fixed up?

John G3WGV

S673E7423|meter 5.src=TX-#5.num=8#5.nam=COMPPEAK#5.low=-150.0#5.hi=20.0#5.desc=Signal strength of signals after the CLIPPER (Compression)        #5.unit=dBFS#5.fps=20#

After the word (Compression) there are two tab chars (showing here as a bunch of spaces). It surprised me and it's the only place I've seen it. Hardly urgent!

Thanks again.

Eric-KE5DTO

Thanks for the follow up.  I entered this as issue #3818 in our system.  We'll look into this.

Alan

I too am trying to get meter data.  I am not a programmer, so am using Node-Red.

I have been successful at subscribing to a meter (#15, Voltage) and am receiving the VITA-49 packets on port 4991.

I need help with decoding the packets.  Can anyone share your code or method on how to decode VITA-49?

I can plug the code into a Node-Red function node and use that as a decoder.  I just need help with the code.

Alan
WA9WUD

Eric-KE5DTO

For reference, this issue (#3818) was addressed in SmartSDR v1.9 back in 2016.

bobby

Google is your friend. Search "Vita-49" in the search bar you will find in the list a pdf with all the decoding information since it is a standard.