MAP 65 adaptive polarity?

I just read through the MAP65 users manual and browsed the source a bit.  The best way to do digital mode programs is to always avoid sound cards if you can.  The reason we all use them is that it is a common interface that everyone understands.  But sound cards place the radio and the receiving software (where a digital radio is involved) in different clock domains which makes the reception more of a pain.  Anyway, MAP65 already has code for receiving streaming UDP packets, in the current case for Linrad.  The Linrad data structure for UDP packets is:

  struct linradBuffer {
    double cfreq;
    int msec;
    float userfreq;
    int iptr;
    quint16 iblk;
    qint8 nrx;
    char iusb;
    double d8[174];
  } b;

Currently the I/Q data from SmartSDR is in the VITA-49 standard format for IF data and the data structure looks like this (VITA-49 packets can have more/less fields, but this is the format we use for output):

typedef struct _vita_if_data
{
uint32 header;
uint32 stream_id;
uint32 class_id_h;
uint32 class_id_l;
uint32 timestamp_int;
uint32 timestamp_frac_h;
uint32 timestamp_frac_l;
uint8  payload[MAX_IF_DATA_PAYLOAD_SIZE];  // format is int32/int32 I/Q
} vita_if_data, *VitaIFData;

In VITA-49, significant amounts of data can be sent very rapidly and so primarily only the samples are sent.  The frequency data, etc. are all sent as part of a separate context packet which we do not emit today, but which we could easily emit.

Now, given that network UDP packets is the best way to move the data, there are two courses of action: 1) MAP65 could be modified to ingest VITA-49, 2) SmartSDR could be modified to emit Linrad packets.  3) The DAX control could be modified to output Linrad packets.   Some thoughts about each method:

Modify MAP65 to ingest VITA-49:

• MAP65 would gain a new data format, VITA-49, which is an open standard, but I doubt anyone would be willing to code a "universal VITA-49 parser" so only a subset of VITA-49 would be implemented.  Some modification would likely be required for subsequent VITA-49 emitters, should there be more at a future date
• MAP65 wants to ingest data in the format float/float for I/Q.  VITA-49 as emitted by SmartSDR for I/Q is in the format int32/int32 so a conversion is required.  This conversion is simply a multiply by a constant (1/2^bits of dynamic range).
• SmartSDR would need to emit VITA-49 context packets for I/Q data.  This is simple and we would do this

Modify SmartSDR to emit Linrad UDP packets:

• SmartSDR would have a new data output format.  I do not know the popularity or use for the Linrad formatted UDP packets for any other application
• SmartSDR would be required to reformat all I/Q packets before sending them out. This actually requires real CPU as every sample will have to receive two additional multiplies and a conversion to float.  This could limit the number of streams we would allow as the additional load may not be not inconsequential.  So if you go into "Linrad mode" I suspect we would have to limit the streams down to two instead of four.  We would have to profile and find out for sure.  The other option would be to process the multiply in the FPGA and the conversion to float in the processor which might be less load, but require more NRE.
• A new user control in the DAX control panel would be required that would stipulate which format of output would come from the radio.

Modify DAX Control Panel to emit Linrad UDP packets:

• This places no new load on the radio for data conversion and keeps the output formats from the radio simple
• DAX CP only runs on Windows today so this would necessitate a Windows client for re-processing the data.  Any future implementations on additional platforms for the SmartSDR client would require porting the Linrad emit code as well or foregoing this capability
• SmartSDR would effectively support an additional output data format (again I do not know the utility of this)

The best case scenario for us is someone willing to work with us to modify MAP65.  We would provide the necessary assistance, code snippets, etc. to make this possible should someone want to take this work on.  Alternately, we could potentially be sold on the benefits of modifying SmartSDR or the DAX CP.  Ultimately, something like this gets prioritized along with all the other things we need to do in SmartSDR and that we have already promised as much as we'd like to just go do it.