Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
If you are having a problem, please check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.

SmartSDR TCP/IP - Trying to use metering protocol

IW7DMH, EnzoIW7DMH, Enzo Member ✭✭
edited February 2017 in SmartSDR API
Hello,

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

image

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

Answers

  • Steve-N5ACSteve-N5AC Community Manager admin
    edited February 2017
    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, EnzoIW7DMH, Enzo Member ✭✭
    edited January 2017
    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 - KZ1FWalt - KZ1F Member
    edited November 2016
    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, EnzoIW7DMH, Enzo Member ✭✭
    edited December 2016
    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 - KZ1FWalt - KZ1F Member
    edited November 2016
    No, I am initializing it correctly. If it's spitting out garbage, that is not the fault of the client.
  • IW7DMH, EnzoIW7DMH, Enzo Member ✭✭
    edited January 2017
    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, EnzoIW7DMH, Enzo Member ✭✭
    edited January 2017
    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

    image 



  • Walt - KZ1FWalt - KZ1F Member
    edited November 2016
    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 - KZ1FWalt - KZ1F Member
    edited November 2016
    also look at VitaMeterPacket.cs
  • IW7DMH, EnzoIW7DMH, Enzo Member ✭✭
    edited December 2016
    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 - KZ1FWalt - KZ1F Member
    edited November 2016
    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, EnzoIW7DMH, Enzo Member ✭✭
    edited January 2017
    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.

    image

    73' Enzo
    iw7dmh

Leave a Comment

Rich Text Editor. To edit a paragraph's style, hit tab to get to the paragraph menu. From there you will be able to pick one style. Nothing defaults to paragraph. An inline formatting menu will show up when you select text. Hit tab to get into that menu. Some elements, such as rich link embeds, images, loading indicators, and error messages may get inserted into the editor. You may navigate to these using the arrow keys inside of the editor and delete them with the delete or backspace key.