VITA49 questions

John G3WGV

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!

Walt - KZ1F

@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 - KZ1F

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 G3WGV

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 - KZ1F

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 G3WGV

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-KE5DTO

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 G3WGV

That's really helpful Eric, thank you.