SmartSDR TCP/IP - Trying to use metering protocol

IW7DMH, Enzo

Hello,

here is the meter list of my 6300 with two slices enabled.



I would like to implement a monitor for the following values:

1- S-Meter for each slice (20 & 24)
2- RF Power (15)
3- SWR (17)
4- Real-time audio input level (??)
5- Real-time compression level (??)
6- Power amp temperature (18)
7- Operating Voltage (13)

As I am not familiar with this part of the protocol I would like your help to identify the correct meter id. In brackets I wrote the number I suppose it is correct while I have really no idea about real-time audio input and compression meters (I am refferring to meter bars you can see when you select SSB mode in SSDR).
I am wondering if id numbers are fixed or if they can be changed when the rig is restarted.

Also, using the command protocol, I can't start the meter updates stream. When I send se command C12|meter updates on I get sistematically the following response error R12|50001000|.
What is wrong here?

Last but not least I would be glad if you could give me a link (docs or previous posts) that can help me to parse Vita packets.

Thank you very much
73' Enzo
iw7dmh

Steve-N5AC

Enzo, I'm at Hamvention and don't have ready access to all the information you are requesting.  Here's what I can get at the moment --  Here's a random link to the VITA-49 standard: http://www.wdv.com/Electronics/Reference/SDROoverWEB-VITA.pdf

The draft standard is just fine.  For audio input level, you can use meter 1 in your list.  I believe this will be the rapid moving mic level input you see today.  For compression level, I'm not certain.  Try looking at some and if you can't decide from decoding the meters and comparing to our display, I'll go find out what we're doing.

The command response 0x50001000 is a response from the command processor in the radio that says essentially "I called the function you asked me to and I got a good return value, but the function did not prepare a result value for the client so I will substitute 0x50001000."  This really means that the programmer that coded the function neglected to follow the rules and provide a response for the client.  This is a bug in our software and we'd always like to know when you see these.  But as a developer, you should treat this as a "radio not certain if your command is OK" and you should double check your work, but it may be OK also.

I did not look up your command to see if the command format is correct.  If it is the same command we send out from SmartSDR and you see us get that result, then you are fine.

You may not rely on the meter numbers.  If you do, you are much more likely to break in the future if we move things around.  You SHOULD rely on the src, num, nam tuple.

IW7DMH, Enzo

Hello Steve!

many thanks for your help.
It seems that I have to send the following two commands to get the udp stream:

C6|sub meter all
C24|client udpport 4990

There is no trace of " meter updates on " command in the "sniffed" ssdr command list.
Now I'll study the Vita document but before let me see again your video about Maestro presentation in Dayton.
Really great!!!

Regards
Enzo

Walt - KZ1F

Enzo, did you notice, or did you get, by simply issuing those commands, ONLY meter traffic, specifically for a meter with a units value of 'none'?

Walt - kz1f

IW7DMH, Enzo

Walt, I started from two days to look in depth at the Metering Protocol.
I saw your other post about this issue, but, so far, I didn't get that unusual  messages.
My experience about inconsistent messages is that they usually come out when a client find and connect the rig but doesn't initialize it in a correct way.

73', iw7dmh
Enzo

Walt - KZ1F

No, I am initializing it correctly. If it's spitting out garbage, that is not the fault of the client.

IW7DMH, Enzo

Hello,

I have another question about the way to start the metering data stream.

If my client is the only program that is connected to the rig it has to set the udpport by itself and listening to that port.
The doubt is when my client is running next to SSDR. When SSDR is running it has already started an udp data stream, so I could listen to that stream avoiding also network overhead.
So the question is what is the correct way to identify an already used udp port for metering protocol.

73'
Enzo

IW7DMH, Enzo

Well, now I am at the maximum of the entropy ...
In the picture below there are some metering packets. Following the wiki I think I have fixed some of the most important bytes and I highlighted them with different colors.
But I have some issues with the packet size bytes (they should be the green ones) and I can't identify the expected bytes related to the Meter identifiers - Meter Value couples.
It seems that packet size isn't coherent with actual packet size. What am I missing?

My parser is going to go crazy like me

Any help will be appreciated.

73' Enzo
iw7dmh

 

Walt - KZ1F

Enzo, you will still have to bind to the port. While there is no connection, per se, between the radio and SSDR, the radio is not broadcasting UDP datagrams. What you are saved is the 'overhead' of maintaining a connection. This is what I do, so I am seeing the same data but not the same bits, if that makes sense.

So in my code, for instance (and you can see FRS code in VitaSocket.cs) I create a DatagramChannel then bind it to the endpoint addr:port.  So long as the endpoints are unique you're fine. Right now I have neither SSDR nor my facsimile of it running so I can not sure you the connection info.

The other thing you can do that may actually help is use the code from the flexlib source to parse the inbound data. Otherwise it gets very messy very quickly.

Walt - KZ1F

also look at VitaMeterPacket.cs

IW7DMH, Enzo

Ok VitaMeterPacket.cs has the whole parsing logic. I'll study it.
About the question of getting the correct metering packets I am doing in the following way:

I start Wireshark and I set a filters for udp.port==4990. The filter window is initially empty. Then I start a telnet client, connect the 6300, and send the following commands:

C1|sub meter all
C2|client udpport 4990

At this point the wireshark filter window start to get out the udp packets. I suppose these are the packets I have to parse using a code similar to that of VitaMeterPacket.cs. I found lot of these packets has the Class Identifier that match the Meter Extension Packet class id.

Is this assumption correct? Until now I still haven't coded anything for this task.

Thank a lot for your help

73'

Walt - KZ1F

I tried to get William to build parsers. I think he is still doing brute force. I've written parsers (codexes) for all the Vita packets, makes life ever so much easier.Rather than a slew of byteswaps, I can just say getByte(index) or getInt(index) or getShort(index).
In fact I am thinking of adding them to the codex layer of Netty.. For instance, on the TCP traffic, rather than mess with partial command lines I use the String input and output codexes and I always get a proper cmd line and what gets sent is also always proper.

After the header there is an array of payloadSize/4 individual meter entries, meter id and meter value. Where you know the payload size from the header and, hence, the number of meters represented, you iterate over this to build the separate meter entities. I added the snippet of code I use to process this in the thread William created.

IW7DMH, Enzo

Hello,

I want to complete this post publishing a simple .Net class I used to compare the result of my code with the result of the official FlexApi.
You need to create a console project using Visual Studio and add reference to Vita and Util Flex libraries.
The program works offline so you don't need to be connected to the rig when you run the tests.
You only need to get some packets from you parser and copy the bytes, in Hex format, into the myData array.

Simply copy and past the following code in the Main method and run the program.

/* ************************************** */
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Flex.Smoothlake.Vita;

namespace VitaMeterTest
{

   
    class Program
    {
        static void Main(string[] args)
        {

            byte[] myData ={
                0x38, 0xd1, 0x00, 0x17, 0x00, 0x00, 0x07, 0x00,
                0x00, 0x00, 0x1c, 0x2d, 0x53, 0x4c, 0x80, 0x02,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0xc4, 0x00,
                0x00, 0x02, 0xc4, 0x00, 0x00, 0x03, 0xc0, 0xa0,
                0x00, 0x0c, 0x00, 0x00, 0x00, 0x0f, 0x18, 0xcf,
                0x00, 0x10, 0x0e, 0xec, 0x00, 0x11, 0x00, 0x98,
                0x00, 0x15, 0x83, 0x00, 0x00, 0x01, 0xc4, 0x00,
                0x00, 0x02, 0xc4, 0x00, 0x00, 0x03, 0xc0, 0xa0,
                0x00, 0x0c, 0x00, 0x00, 0x00, 0x0f, 0x18, 0xcf,
                0x00, 0x10, 0x0e, 0xec, 0x00, 0x11, 0x00, 0x98,
                0x00, 0x15, 0x83, 0x00
                           };
                    
            Console.Write("Len data:"); Console.WriteLine(myData.Length);

            //Console.Write("Len tmp:");
            //Console.WriteLine(tmp.Length);
            //Console.WriteLine(tmp);
            //for (int i = 0; i < myData.Length; i++)
            //    Console.Write("{0:X2}", myData[i]);
            //Console.WriteLine();

            VitaMeterPacket vmp = new VitaMeterPacket(myData);
            Console.WriteLine("

");
            for (int i = 0; i < vmp.NumMeters; i++)
            {
                Console.Write("Meter id:");
                Console.Write(vmp.GetMeterID(i));
                Console.Write(" - Meter value:");
                Console.WriteLine(vmp.GetMeterValue(i));

            }


            Console.WriteLine("

Fine.
");
            Console.ReadLine();
        }
    }
}
/* ************************************** */

Results are shown in the following picture.



73' Enzo
iw7dmh