[hpsdr] Potential Metis Bug and Protocol Ambiguity

[Bill Tracey]

I'm 99% sure separate seq numbers per endpoint is intentional - the 
thought was that it would be good for the code processing each 
endpoint track it's own sequence number.  Less coupling in that one 
endpoint's code need not be aware of the other one.

As to the wideband data being stuck on ..... think Phil may already 
be aware of the bug ... if not he is now!

Bill (kd5tfd)


At 03:39 PM 5/30/2013, Jeremy McDermond wrote:
>***** High Performance Software Defined Radio Discussion List *****
>
>While trying to prepare today for the SeaPac convention, I noticed 
>that my Atlas/Metis system was taking about 2x the bandwidth of my 
>Hermes system as I measured on my iPad.  It appears as though Metis 
>is not processing the start command correctly when you are not 
>asking for the wideband data to be sent.  Looking at a wireshark 
>trace, I'm still getting the endpoint 6 data even though I'm 
>specifically asking for it not to be sent.  Hermes seems to do this 
>correctly, but Metis does not.
>
>Additionally, there's a little bit of an ambiguity in the 
>spec.  Looking at the traces, it seems as if there is a different 
>sequence number coming across for endpoint 6 data from the endpoint 
>4 data.  I had always read the spec that the sequence number was 
>over the total packets coming out of the system.  Are separate 
>sequence numbers intended, or is this an oversight/bug?
>
>--
>Jeremy McDermond (NH6Z)
>Xenotropic Systems
>mcdermj at xenotropic.com


 1369948088.0