MAP 65 adaptive polarity?

Bob N7ZO

Hello all,  I am considering the purchase of a Flex-6700.  Now that you have DAX-IQ, is it possible to run a pair of coherent two meter (144 MHz) slices, each connected to their own antenna (one vertical and one horizontal polarity), and output both their IQ channels to a program like MAP65 to achieve adaptive polarity reception?  Easy choice of either of the two antennas for transmit would be a bonus.    73,Bob, N7ZO

Steve-N5AC

Today, you can have two 2m receivers tuned to the same frequency and they will be synchronous, but not coherent.  In other words, the two channels will provide a constant phase separation between the two outputs that will be random, but constant and stable after each tune.  Changing this to a coherent tune has always been in our playbook and not hard to do -- the chief challenge is how to represent that you want this from the GUI.  We have also had this request from the HF side.

Can MAP-65 handle two synchronous channels that are not coherent or is this something we need to do sooner?

Steve

Bob N7ZO

Steve,  MAP65 has a calibration procedure to correct for phase differences between the H and V channels, but this is not something you would want to do every time you tune.  It involves finding strong EME signals and measuring them. This procedure is meant to correct for constant phase and delay differences in the feed lines, external preamps, etc.

Steve-N5AC

OK, got it.  I've put this on our list and I'll look into it and get back to you (here).  US2111

Paul RN3A

It is not this simple with MAP65 and 2 IQ streams support. If you select a sound device in MAP65 menu, it will support only 1 IQ stream.
It works very good with DAXIQ single channel with 96000 settings. My EME setup for 2m includes X-pol antenna stack, with separate feed lines to H-pol and V-pol sections. I can create 2 pans with 2 DAXIQ streams, but I can see only 1 at a time - MAP65 sees only 1 DAXIQ stream. 
Most of the folks use MAP65 with Linrad. It has superb filtering capabilities and allows working with many SDR receivers which support 2 channel synchronous reception. MAP65 is connected to Linrad via network, using assigned network port. This is the most common configuration. 
So either Flex needs to create additional sound card interface, which will carry 2 IQ streams from 2 pans, supporting synchronous RX, or Joe needs to add second RX IQ channel to support X-pol this way.

73, Paul RN3A

Paul RN3A

It is not this simple with MAP65 and 2 IQ streams support. If you select a sound device in MAP65 menu, it will support only 1 IQ stream.
It works very good with DAXIQ single channel with 96000 settings. My EME setup for 2m includes X-pol antenna stack, with separate feed lines to H-pol and V-pol sections. I can create 2 pans with 2 DAXIQ streams, but I can see only 1 at a time - MAP65 sees only 1 DAXIQ stream. 
Most of the folks use MAP65 with Linrad. It has superb filtering capabilities and allows working with many SDR receivers which support 2 channel synchronous reception. MAP65 is connected to Linrad via network, using assigned network port. This is the most common configuration. 
So either Flex needs to create additional sound card interface, which will carry 2 IQ streams from 2 pans, supporting synchronous RX, or Joe needs to add second RX IQ channel to support X-pol this way.

73, Paul RN3A

Steve-N5AC

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.

[Deleted User]

Hi All

Any new development to get MAP65 to work whit SmartSDR ????

73" OZ1CT Ben

Bob N7ZO

Hi All,

Joe Taylor, K1JT, is now polling the Moon-Net mail group for information regarding their usage of MAP65 and of the new Q65 mode. There have been recent rumblings about an updated version of MAP65 to support Q65. This is the first indication of any new work on MAP65 in many years.

With the possibility of new work being done on MAP65, I am interested in resurrecting the idea of connecting Flex's IQ data output to MAP65.

Stephen Hicks, N5AC and FlexRadio CTO, gave a good analysis of the effort involved (see above), not I have not heard anything else lately. Although some of the work can be done externally, the problem of inter-slice phase alignment must be corrected inside of the radio.

How much interest is there in this from other Flex users and from FlexRadio itself?

73, Bob, N7ZO

Amos Sobel

Hi All

Joe Tailor just told me that: "MAP65 requires receiving hardware that can produce I/Q data at 96000 Hz sample rate. For adaptive polarization you need two independent channels of such information, and samples in the two channels must be synchronized. Flex receivers do not provide such data" Meaning that there is no hope of MA65 and Flex becoming compatible in the near future.

What do you think of the following solution for 2m EME and maybe suggest alternative solutions:

Take Cross Pol Long Yagi Antenna, Dual Transverter, Flex 6xxx and run 2 instances of WSJT-X/Q65 on your computer. The quality of the received Q65 message will alternate between the 2 instances following the polarity rotation of the EME signal. The user will use his intelligence to choose and call back.

An alternative solution can be:

Take Cross Pol Long Yagi Antenna, Single Transverter, Flex 6xxx and run 1 instance of WSJT-X/Q65 on your computer. Add a relay/switching network which will choose between H-Yagi, V-Yagi, Shorted H-V-Yagi or the 2 yagies connected through a quarter wave coax balun on one side . The user will have to choose the switching state according to the changing position.

73's Amos 4X4MF