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.

VITA49 questions

John G3WGVJohn G3WGV Member ✭✭
edited November 2018 in SmartSDR API
One for Eric, I suspect:

One of the things I discover when I try to write about a subject is how little I actually know about it! I'm trying to better understand VITA49 and how FlexRadio uses it. VITA49 documentation on t'Internet is in very short supply!

I see that you use different stream identifiers for Discovery and Meter packets:

0x00 00 08 00      for Discovery packets
0x00 00 07 00      for Meter packets


and that you also have different class identifiers

0x00 00 1C 2D 53 4C FF FF   for Discovery packets
0x00 00 1C 2D 53 4C 80 02    for Meter packets

From VitaFlex.cs in FlexLib I can also see the other classes - FFT, waterfall, etc.

First Q: does every different type of data have its own stream identifier? If so, why do we need a separate class identifier? Is it legitimate to identify the packet type using the stream identifier?

Second Q: Do the Discovery and meter packets follow some defined VITA49 protocol specification? For example, are the scaling values applied to meter data defined in VITA49 or is it just something that Flex has devised?

Third Q: Flex doesn't populate the time fields in the VITA49 header, but the fields are present as 00s. Is there any plan to use these fields?

Last Q: Is the Count field of header word 1 updated as each packet is sent? If so, is this on a class and/or stream basis or does the next packet sent get the next incremental number regardless of class/stream?

Thanks, as always!

Completed · Last Updated

Answers

  • Walt - KZ1FWalt - KZ1F Member
    edited November 2016
    @John - Most of your questions could be answered by reviewing, specifically Discovery.cs, API.cs *specifically init(), Meter.cs specifically updateValue(), and radio.cs, specifically UDPDataReceivedCallback().

    Specifically, in Radio.cs data is processed from the FFT packets. This data, depending on its type is placed into blocking queues to help level out the workload to different threads, which may or may not execute concurrently. Discovery is coming from a different port and is handled differently. What happens in VitaSocket is the process invoking the discover/process creates a UDP port and passes that port to the radio. In that manner the 'client' app is, in fact, the service provider from a tcp/ip perspective. So in the discovery process the radio is the service provider and the user app the client.

    I am guessing you are doing this on Windows? It would help if you could trace through rather than trying to glean the flow from desk checking. But, maybe you are.

    Why am I even bother to answer your question? About two years ago I finished creating a portable support library (different and portable language) and went through the process you are going through now. If you'd rather just wait on Eric, that works too. Obviously, I cannot answer 'why did you do it this way' type questions but I could provide insight into how things work..in the absence of Eric's answers.
  • Walt - KZ1FWalt - KZ1F Member
    edited November 2016
    John, you can find a draft of the current vita-49 spec online, rather than pay the $100 for the final version (or whatever it is). The draft will be fine for your purposes.
  • John G3WGVJohn G3WGV Member ✭✭
    edited November 2018
    Thanks Walt. I have, of course, been reviewing the FlexAPI code extensively and it has provided many answers. I just wanted to gain a better understanding of how FlexRadio uses the VITA49 protocol - obviously I can see the actual data by Wiresharking and I have been doing that too but that doesn't give me the thinking behind it, nor can I be sure I have the full picture.

    I've since found (from the draft VITA49 specifications, thanks for the heads-up) that extension packet content is implementer-defined, so I've answered that question. Yes, I am writing my code in a Windows environment, although that isn't really relevant to the discussion.

    Mostly this is for me to get a better understanding so I don't end up inadvertently writing nonsense in my API Primer document.
  • Walt - KZ1FWalt - KZ1F Member
    edited November 2016
    It, Windows environment, is relevant from the perspective of walking thru the code as it executes. I did not know if you knew that or knee how to accomplish that and I didn't want to say anything that would be taken incorrectly. Where you need to be careful is some of the api is synchronous and some of it is asynchronous. The difference is between where there are calls to sendCommand vs SendReplyCommand. In some cases the 'anticipated' result gets set on the request side of an asynchronous request. Additionally, some responses get set via parsing status messages. Generally, before I engage in a conversation like this with someone I vet their depth of knowledge in software development but, where you are in London, I couldnt do that.
  • John G3WGVJohn G3WGV Member ✭✭
    edited December 2016
    Well... yes I am aware of the concept of stepping through code at run time. I can do it in my current Delphi XE7 environment and I was doing it 45 years ago in IBM/360 assembler code. In a multi-threaded environment it sometimes doesn't give the results you were expecting.

    I just write hobby code, having moved on from programming professionally in the mid 70s, so I probably wouldn't pass muster in your vetting process :)
  • Eric-KE5DTOEric-KE5DTO Administrator, FlexRadio Employee admin
    edited November 2018
    First Q: does every different type of data have its own stream identifier? If so, why do we need a separate class identifier? Is it legitimate to identify the packet type using the stream identifier?
    The VITA 49 spec talks about these parts in detail (more detail than anyone would probably want to know!).  But in general, I think the stream ID is for a particular stream and a class ID is more of a type of stream.  Kind of like classes and objects in OO programming.  The stream ID would be an instance of the object while the class ID would be like a class definition.
    Second Q: Do the Discovery and meter packets follow some defined VITA49 protocol specification? For example, are the scaling values applied to meter data defined in VITA49 or is it just something that Flex has devised?
    The meter packets are done with extended data packets which are mostly defined in VITA 49 (with payload details left up to the developer).

    Discovery is a completely different animal very similar to our communication protocol (not VITA 49).  It is probably worth noting that I have heard that VITA 49 is coming out with a command and control protocol.
    Third Q: Flex doesn't populate the time fields in the VITA49 header, but the fields are present as 00s. Is there any plan to use these fields? 
    We may use these at some point.
    Last Q: Is the Count field of header word 1 updated as each packet is sent? If so, is this on a class and/or stream basis or does the next packet sent get the next incremental number regardless of class/stream?
    Yes -- updated each packet, unique per stream (not class).  As mentioned above, think of the Stream IDs as individual stream objects while the Class ID defines the type.  The packet count is one way that you can tell when packets are dropped when this count doesn't match what you expected for a particular stream.
  • John G3WGVJohn G3WGV Member ✭✭
    edited December 2016
    That's really helpful Eric, thank you.

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.