Proposed Product for Flexradio or Third Party -- Expose Flexwire via Raspberry Pi

Comments

• Larry Loen WO7R Member ✭✭

  February 2016 edited February 2016

  The main initial decision would be whether to have it be a separate "I/O" box or incorporate the Raspberry Pi.  Simplest and quickest would be to not include the Pi, but then a nice solution would be needed to connect the I2C header pins (plus the PTT stuff and maybe the audio via standard "stereo jacks") with a clean and easy solution not requiring user soldering.  That would be less integrated, and require a little skill at assembly but enable people to deploy the "Pi" they wanted.  Conversely, if the Pi were included, then it should be basically hooking up a shielded D shell, with a 3 or 6 foot wire, to a box, and then it's Ethernet and exposed USB "for the win".
  

  0
• Larry Loen WO7R Member ✭✭

  February 2016 edited February 2016

  Oh, and while I forgot to mention it, it is important to know it is very easy to run a Pi "headless".  You don't need a full time monitor and keyboard/mouse.  You can run TightVNC for full control or, once it is set up fully, just settle for the web control.  So, a nice GUI if you need it, and all hands-free.  The integrated one could integrate TightVNC as well, so nobody would even need to hook one up in the fully integrated version.
  

  0
• Rob N4GA Member

  February 2016 edited January 2017

  Wow - big spender!

  1
• Peter K1PGV Member ✭✭

  February 2016 edited June 2020

  If you're going to use a PI2, just put Windows on it, and write an app to listen to messages from the radio via FlexLib.  Then create whatever outputs you want with it.

  That project's been on my plate for, oh, more than a year now.  Ah, some day I'll have the time...

  Wouldn't that be easier?  As a software guy, it'd be easier to ME.

  Peter
  K1PGV

  0
• Walt - KZ1F Member ✭✭

  February 2016 edited November 2016

  I had written a response echoing an email thread I started with Enzo about first moving the linear, ext tuner and rotor controls to rp2 but removed it as I thought flexwire was a pre-6000 thing. At $45 a pop I think I could afford a couple. I might move XPSSDR there as well. It's what, the size of 2 card decks stacked? I'll do a video. At that form factor, you can't beat that for portable.

  0
• KY6LA_Howard La Jolla, CA. Paris and Sablet FranceMember ✭✭✭

  February 2016 edited January 2017

  Maybe I am missing something...
  
  But why use the I2C port to kluge up an interface when there is a big **** Ethernet port already available?
  
  The issue really is that most Ham Peripheral Gear is stuck with the 1970 era RS232 Serial Port or even worse Parallel Printer Port Interfaces....  You would be more effective spending the effort to construct Ethernet to serial devices to deal with the ancient protocols...
  
  Or just wait until advanced thinkers like 4O3A deliver on their Ethernet Interfaces....
  

  1
• Larry Loen WO7R Member ✭✭

  February 2016 edited February 2016

  It's a consideration, Howard.  But, there's a lot to be said for the potential for a really independent, low-latency solution here.  As in, a dedicated processor that can monitor the lines and respond within milliseconds, maybe microseconds, to changes.
  
  If it does nothing more than export status, then yeah, maybe the Flex APIs are the better solution.  But, if you want to respond (e.g. setting external antenna arrays, for instance, based on a band change or something) that go beyond the one-and-two antenna approach built-in to the Flex radios currently, this just might be the ticket.
  
  It's certainly the sort of thing I have in mind.  What do you do when you have that third antenna on a Flex 6300?  What do you do when you want to involve more than one amplifier on a 6300?  Or even a 6500 with complex rules for what amp you want to use when?
  
  Also, I have not found the switch-over between ANT1 and ANT2 inside of SmartSDR to be trouble free.  So, maybe I would rather use one port and switch it externally based on the band selected.
  
  Not everyone will need this, but many could find it very useful.
  

  2
• KY6LA_Howard La Jolla, CA. Paris and Sablet FranceMember ✭✭✭

  February 2016 edited January 2017

  @Larry
  
  There are already Ethernet based antenna switches like the Station Genius from 4O3A which easily switch multiple antenna http://www.4o3a.com/index.php/products/station-automation/ssc-xl 
  
  AFIK there is rarely a need microsecond switching ham radio..... so the Ethernet Latency is likely much more than acceptable - especially considering that it is 1,000 x faster than RS232 Serial
  

  0
• Larry Loen WO7R Member ✭✭

  February 2016 edited February 2016

  The other consideration, Howard, is precisely all that old Ham Gear stuck in the '50s.  I feel like I should do a short writeup for CQ or something and say "stop making everything RS232, skip USB and go straight to the internet" for interfacing.  I'm with you on that one.
  
  But, that's years off.  Meanwhile, there's still all this old gear out there, some of it not so old (e.g. my Green Heron controllers).  THAT gear needs USB or USB-to-RS232 to control it.  May as well monitor Flexwire directly and deal with it directly.  The Pi would put all that gear "on the internet".  Now, some _software_ would struggle to manage it, but that's another problem for another day.  "My" software would not struggle.  And, if I could get the Flexwire on board, it would be cheap, easy, and right now.

  0
• Larry Loen WO7R Member ✭✭

  February 2016 edited February 2016

  If you say so. But we are then relying on a solution for a Windows machine that is already running SmartSDR and whatever else one attempts to do. The Pi is only a fifty buck box if I can figure out the interfacing for a reasonable fee. And, it's an under-utilized resource. I'm finding that in my remote solution, things cannot be dumbed down enough or simple enough. It's not just the average ethernet latency, but the outlier cases. I've seen some stuff that has amazed me on that score. I would think that even if it was a bit slower, Flexwire-to-USB in the context of a decicated quad core ARM at 750 MHz would be pretty fast and pretty predictable even without an RTOS involved. More predictable than ethernet.

  0
• Walt - KZ1F Member ✭✭

  February 2016 edited November 2016

  Larry, there are non-Windows solutions out there, for iPad, Mac, and xpssdr runs anywhere. Since it will use OpenGL-ES which the RP2b supports I am going to put it up on that. I am hopeful it will work adequately. If not I will use it as an ethernet-com port bridge to my amp, tuner, and rotor. That much I know it will do. Oh, I don't run Windows except for SmartSDR digital modes and turbotax. RP2b is 900MHz. I think only the initial was 750MHz. I suspect Station Genius costs significantly more than $45.

  1
• Larry Loen WO7R Member ✭✭

  February 2016 edited February 2016

  Xpssdr is something to look into.  Beware about comparing ARM to Intel as far as performance goes. They are getting closer, but on the whole, I still expect ARM at the same clock rate to be slower than the corresponding Intel parts.
  
  It would still be fun to run the Flex on a dedicated, headless box though.  That would be fun.  I'm kind of doing that with Windows now.  But, I still think I would want to take any antenna switching or other low latency function and put it in its own dedicated box.  It also has the secondary effect of making the devices "behind it" visible to any box on the network.

  0
• Larry Loen WO7R Member ✭✭

  February 2016 edited February 2016

  Well, this is a little embarrassing.  I thought I knew some stuff and now I am not so sure after digging around some more.  This whole thing may be a dry hole, at least currently.
  
  1.  The 6xxx series isn't identical to the 5xxx series.  The manuals are careful to call it an "accessory connector" not Flexwire.  But, a lot of the same functionality might be there.
  
  2.  The manual has some curious omissions about these lines.  It states that all _input_ lines are 3.3v.  I does _not_ say anything about output lines except individually for some.  Moreover, while I am a novice about these things, it is my understanding that the I2C interface is _bidirectional_.  So, here's what I think I know and don't know about voltages (I don't have my rig handy and am not sure a DVM is the right way to measure some of these anyhow).
  
  a.  Pin 1 (Line in).  Says "consumer level -10dBV" which I assume is published somewhere.  Not sure what the unit is here (1 volt?)
  b.  Pin 2(Line out).  Says is the "buffered output" of the Powered Speakers left channel (1 volt?)
  c.  Pin 3(Line out).  Says is the "buffered output" of the Powered Speakers right channel (1 volt?)
  d. Pin 4 is KEY/FSK/INT in.  Keying for CW or FSK.  Presumably, this is 3.3v and is "keyed to ground".
  e. Pin 5 RESERVED (6300) GROUND (other 6xxx).
  f.  Pins 6, 7, 8, and 10 are GROUND.
  g. Pin 9 is +5v DC. 500 mA max, fused.
  h. Pin 11 is Accessory TX.  Buffered PTT output similar to RCA connectors TX1, TX2, TX3,  Software configurable.
  h.  Pin 12 SDA I/O.  For I2C serial channel.  SmartSDR to document further.  VOLTAGE NOT REALLY GIVEN.
  i.  Pin 13 Accessory TX REQ.  Additional transmit interlock.  Smart SDR software manual shows how to configure.  VOLTAGE NOT REALLY GIVEN (it's an output).
  j.  Pin 14.  PTT in.  Ground pin 14 to engage transmit.  Based on "all inputs are 3.3v" then this is 3.3v but you ground it, so in some circuits, voltage is presumably not critical.  Amperage limits on what can be sunk are not given.
  k. Pin 15.  SCL I/O.  For I2C serial channel clock.  As with pin 12, VOLTAGE IS NOT REALLY GIVEN.  One might presume it is 3.3 v, but it is (I believe)  bidirectional line.  SmartSDR to document further.
  
  Smart SDR (as of the latest manual download, a few days old) has no further documentation of Pins 12 and 15.  I've seen hints and discussions elsewhere that I2C is not actually implemented, which kind of makes most of this discussion pointless.  But, at least it would "probably" be 3.3v if it was, easing interface to the Raspberry Pi.
  
  Pity, I had really hoped for an independent, low-latency channel to tell my Pi how to operate various accessories I would need now or in the future.  I suppose I can, as Howard suggests, simply get it from the Ethernet interfaces (indeed, I could probably get it directly into the Pi), but I do worry a bit about worst case latencies and it would be a polled interface as well.  Presumably, the "small bit of code" (hints elsewhere) that hasn't been standardized or formalized yet for SmartSDR's I2C interface would have its own question of latency, but I would presume it to be more reliable and predictable than what we have.  What we have would presumably use ethernet, whose load cannot be easily isolated or controlled.
  
  So, if I2C isn't implemented, then there isn't a lot to discuss.  I could still  "break out" some of these input and outputs and take them back to the Pi (especially if everything is 3.3v), but I was most interested in the band switching potential.
  
  
  
  

  0
• KY6LA_Howard La Jolla, CA. Paris and Sablet FranceMember ✭✭✭

  February 2016 edited March 2017

  IIRC Flex originally include I2C in the 5000 in the hope that the ham radio community would develop I2C PERIPHERALS. However this never materialized and I2C did not gain any traction When the 6000 series came about, it now included Ethernet with a brief mention of I2C in documentation albeit I do not recall it ever being implemented Remember this is a SDR so I2C would need to be programmed and would have its own processing latency. Today, however there re lots of Ethernet devices.

  0
• Al_NN4ZZ Loganville GAMember ✭✭✭

  February 2016 edited December 2016

  There was a bit of discussion about I2C and band data here a few years ago.   A search on "I2C" will provide some background, here is one post for example:
  
  https://community.flexradio.com/flexradio/topics/looking_all_over_for_band_data
  
  Even a few years ago, moving to a "network" attached peripheral controller was discussed as a more forward looking option to bridge the gap to the legacy peripherals. 
  
  FRS has had some sort of "band data" output on the radar for years as noted in the various posts. .  In the mean time DDUtil works great and it's success is probably one reason alternatives haven't been a priority.
  
  I expect more network attached peripherals are coming but until all the vendors catch up it may be a while before it is universal. 
  
  Regards, Al / NN4ZZ  
  al (at) nn4zz (dot) com
  6700 - HW.................... V 1.6.21.77
  SSDR / DAX / CAT...... V 1.6.21.159
  Win10
  
  
  
  
  

  0
• KY6LA_Howard La Jolla, CA. Paris and Sablet FranceMember ✭✭✭

  February 2016 edited January 2017

  I might note that I use DDUTIL to interface all my peripherals. And it provides a Telnet to various apps.

  0
• IW7DMH, Enzo Member ✭✭

  February 2016 edited June 2020

  For devices integration without the PC, the best option is a "**** box" being able to read the Flexradio ethernet protocol, implementing the FRS CAT protocol and commanding devices like switches and stepper/dc motors.
  I did some tests with the Arduino DUE Platform and it could be a perfect solution from this point of view.
  But, if you need a device both for device integration and for remote operations without the PC, you (we) need to solve a problem about the RS232 protocol used by the other devices.
  For example, if you use a SPE amplifier, you need a Cat port for band data coming from the Flex rig and an additional serial port for the amplifier internal data.
  For the second one serial communication you have two options:
  - rewrite from scratch the serial protocol and send it over the network using another (not standard) network protocol;
  - use a "Serial over IP" (RFC2217) solution like this (just for example http://tibbo.com/store/soi/multiport.html) and send the serial stream data to the other end of the link.
  
  Raspberry PI is the perfect box because it can be programmed like a true PC and it can be used like a **** box. Assuming you have a similar code like the official FRS .Net library, you can command the Flex 6x00 rig in all its features, and you can use one of the wire solutions to control the PI GPIO ports. in addition you can have, out of the box, the ser2net daemon the solves the RS232 over Ip problem. It is part of every Linux distribution.
  
  It is what I realized working on my little remote control system using the Arduino platform. Most of all I realized that the real gap is the missing of a official multiplatform FRS library similar to the .Net one.
  
  73' Enzo
  iw7dmh
  
  
  Edit: I2C, SPI and Cat protocols should only be used for legacy devices integration.

  1
• Walt - KZ1F Member ✭✭

  February 2016 edited November 2016

  Not exactly missing Enzo. We'll discuss more.

  0
• Larry Loen WO7R Member ✭✭

  February 2016 edited February 2016

  If we are down to the discussion of attaching existing RS232 peripherals, the most obvious approach is indeed a fairly dumb box.  It could be an Arduino, but I've found the Raspberry Pi far more cost effective in these cases.
  
  1.  Raspbian, the Debian variant for Raspberry Pi, easily supports a lot of useful software.
  2.  Quad core processors offer a surprising amount of heft.  Way more than Arduino.  The raw power may not be a big deal, but latency is always nice to minimize.
  3.  Ethernet adds a lot of cost to Arduino, wiping out any cost advantages over the Pi, usually for less performance.
  4.  Four USB ports on the Pi allows one dumb box to solve more than one problem.  It's mostly a question of which legacy devices go best together logically.
  5.  USB-to-RS232 is basically a solved problem regardless.  There is an FTxxx chip (can't remember the exact name) that every OS you care about already has a driver for.  Get the right USB-to-RS232 and you are in business with anything, be it Arduino, Pi, Windows or (I presume) even Mac.  Just scan the Raspberry Pi literature and they will tell you what brands work.  I presume you can do the same for Arduino.
  
  The real issue becomes "how well is the RS232 protocol documented."  For my Green Heron controllers, it seems to use an industry standard (I pointed N1MM+ rotor control at it, named the standard (some HyGain controller or other) and it worked without fuss).  My Alpha 9500, by contrast, seems to be proprietary and not all that well documented.  Moving that one to the Pi may prove difficult.  But, as long as there is the equivalent of a documented CAT protocol, then we are usually going to be in business and (easily in the case of Pi anyway) with a http front end at that.
  
  So, abandoning my I2C implementation dream, taking the slice frequencies off of ethernet would enable the same kinds of solutions I was looking for as far as taking band data and running switches.
  
  But, there is a remaining problem.  If you want it automatic and idiot proof (and I do), you must now have your Pi box poll the Flex to see if somebody changed the frequency.  How often you do that is the real latency discussion.  Ten times a second?  Twenty?  If you are really trying to switch antennas and amplifiers, it becomes a serious discussion point in a network carrying a lot of traffic.
  
  Twenty times a second is 50 milliseconds of total mismatch before you even try and change the antenna (and with live circuitry at that).  So, maybe you need to take the PTT line and turn it into an interrupt?  That would potentially require some real driver work.
  
  By contrast, a dedicated I2C line, if we had it, could be polled as fast as the interface could deliver data with no potential for interference.  I was assuming that could be fast enough. If not, I suppose we'd need PTT to generate an interrupt on any scenario.
  
  In my case, since the Alpha already does a **** up job of auto switching, I don't personally have that problem, but not everyone has that luxury.  And, there could still be some wicked antenna mismatches regardless.  These would need fast action.
  
  The remaining case for SPI and I2C is probably not ham gear but things like voltage and temperature sensing, which will continue to be of some interest indefinitely.  But that has nothing to do with the Flex of course.  It can be an extremely cost-effective way to do such things.  Some of those I2C sensors are in the five dollar range, often for a couple of "ports".

  0
• Peter K1PGV Member ✭✭

  February 2016 edited December 2016

  That's not how the Flex API works. No polling is required. As I said in my first reply, the RPI cam just LISTEN for messages from the radio for frequency changes, etc, Then you can create whatever outputs you want, like I said before. Peter K1PGV

  1
• Steve - K5FR Member ✭✭

  February 2016 edited April 2019

  This is a great philosophical discussion, but according to Eric at FRS I2C is not implemented yet in the F6K radios.

  73, Steve K5FR

  1
• Walt - KZ1F Member ✭✭

  February 2016 edited November 2016

  Isn't I2C implemented at a layer much lower than FlexLib, or even .NET or C#? I am confused as to why that is even relevant.
  
  I agree with Peter, the Microsoft version of flexlib and the java version of XPSLib use callbacks/delegates. The user program registers interest in a given event, i.e. dataReady on a panadapter or waterfall or meter, and the supplied method is invoked automatically. No polling involved whatsoever. Simlarly, the UI control binds to the data item set when xpslib (I probably shouldn't discuss how Flexlib works as I did not write it) receives a status message and after parsing the name/value pairs updates the internal attribute. When that happens the relevant display control automatically is updated to reflect the new value. Again, no polling involved.
  

  0
• Larry Loen WO7R Member ✭✭

  February 2016 edited February 2016

  If this pans out, you could at least (with some suitable buffer chip to 3.3v and whatever current limiting is needed) send PTT as an interrupt to a Raspberry Pi and process it in Python:
  
  http://raspi.tv/2013/how-to-use-interrupts-with-python-on-the-raspberry-pi-and-rpi-gpio
  
  That would basically take latency down to the microsecond range.  It would all be about the actual delay in any physical relays accessed by the Pi via USB and before that, how fast you could fetch the current Slice transmitter's frequency over ethernet.  At that point, we already have configurable delays in the SmartSDR as per normal to handle the physical relay delay.  We still have an ultimate problem in that there could be fairly arbitrary ethernet delays to get the new VFO value, though.
  
  An I2C solution might still be the best way to externalize any sort of automated switching that doesn't rely on sensing the antenna input directly.  But, this is what we have.
  
  (edit) Unless, of course, I wise up and figure out how to make the call-back stuff work for frequency changes.

  0
• Larry Loen WO7R Member ✭✭

  February 2016 edited February 2016

  Can you point me at the documentation for this stuff, particularly the Java version?  I know I can make the Java version work in the Pi and even perform decently.  I have a lot of difficulty parsing the API docs here or even finding it.

  1
• James Whiteway Member

  February 2016 edited February 2016

  Me too! I'm looking forward to seeing XPSDR too!

  0
• Walt - KZ1F Member ✭✭

  February 2016 edited November 2016

  XPSLib and XPSSDR are both mine. Disclaimer: I am not, nor have I ever been, affiliated with FRS. Writing class and method level doc is a pita. I started to do that but then tired of it. There are several reasons I have not done public displays of XPSSDR, principal among them is I will not make it available until I've incorporated a license server. I am, however, leaning towards making XPSLib avail in binary form, with common function samples. I may make an exception if it performs adequately on a raspberry pi. I believe it will, so a brief YouTube may be in the offing. I will set a rp2 up as softether server in the access area and another on up as a local endpoint to control peripherals via javax.comm or ser2net. Right now that's in XPSSDR which tethers it to the shack. Larry, jpython runs in a virtual machine so it could directly make native java invocations to use java lambdas, which are the functional equivalent of delegates. I don't recall if native python can.

  0
• Larry Loen WO7R Member ✭✭

  February 2016 edited February 2016

  Pretty fantastic. I can do Java just fine, so if your stuff works better with that, we can dispense with Python. A few decent codelets should be enough here. Since it would be very limited function in this example, I think performance should be no problem. It's not like we're going to decode the audio with ffts in this case. The key is reliable latency more than absolute performance. I have just about figured out the Ethernet api, but that would be a polled solution which would of course not be what is best. Unless there are hidden callbacks in the Ethernet api I have missed.

  0
• Steve - KD8QWT Member

  February 2016 edited February 2016

  I actually prefer the Arduino Due over a pi for these types of controllers.  The Due can do serial over ethernet and has 4 on board serial ports.  The pi has an operating system that must be maintained and it runs off an SD card that can become corrupt, especially if the pi isn't shut down properly.  A power failure would do it.  Quad cores aren't needed to interface between a serial port controlled hardware device and the Flex radio.  The Due has plenty of power, and much more than the more popular Uno or Mega.  Being ethernet based, it's possible to mount the controller closer to the device being controlled.  If using a pi you'd best have it in an easily accessible location for those times it fails to boot.  I've had an Arduino Uno sitting in a box outside for the last few years in Michigan weather.  I've NEVER had to do anything with it unless I was updating it's code.  Soon I'll have a Due controlling a satellite rotator using PID and DC motors strictly over ethernet.  Even SATPC32 can control it, and it can only use serial ports. 
  

  1
• Walt - KZ1F Member ✭✭

  February 2016 edited November 2016

  /*
  * Capture Radio Added
  */
      private boolean launchDiscovery() {
          RadioAddedEventHandler onRadioAdded = (Radio radio) -> onRadioAdded(radio);
          RadioRemovedEventHandler onRadioRemoved = (Radio radio) -> onRadioRemoved(radio);
          api.addRadioAddedListener(onRadioAdded);
          API.setProgramName("CrossPlatformSDR");
          api.setGUI(true);
          api.init();
  
          return true;
      }
  
  /*
     In the method onRadioAdded
     Wire slice added logic
  */
              SliceEventHandler sliceAdded = (Slice slc) -> onSliceAdded(slc);
              SliceEventHandler sliceRemoved = (Slice slc) -> onSliceRemoved(slc);
              activeRadio.addSliceAddedEventListener(sliceAdded);
              activeRadio.addSliceRemovedEventListener(sliceRemoved);
  
  /*
     process slice added event
  */
      private void onSliceAdded(Slice slc) {
          if (log.isDebugEnabled()) {
             log.debug("Entering onSliceAdded " + slc.toString());
          }
          slc.setActive(true);
          CharSentEventHandler onCharSent = (int index) -> onCharSent(index);
  
          activeSlice = slc;
          slc.setActive(true);
          slc.setTransmit(true);
          slc.setFreq(activePan.getCenterFreq());
          slc.setDemodMode("CW");
          cwx = activeRadio.getCWX();
          cwx.setSpeed(30);
          cwx.addOnCharSentEventHandler(onCharSent);
          cwx.send("kz1f");
  
      }
  
  There are two ways to capture the slice frequency changing
  
  1) you, as the client can ask for notification when slice attributes change
     your client class needs to implement Observer interface
     register yourself as an observer of the slice
     currentSlice.addObserver(this);
     // then process the events
  
      public void update(Observable o, Object arg) {
          if (arg instanceof String) {
              String temp = (String) arg;
              if (temp.equalsIgnoreCase("Freq") == true) {
                  slice.getFreq(); // and do whatever
              }
              if (log.isDebugEnabled()) {
                  log.debug("Received notification of " + temp);
              }
  
          }
  
  2) Directly bind to the Freq attribute of that slice
  
     mySlice.getDAO().getFreqProperty().addListener((observable, oldfreq, newFreq) -> { /* process freq change in newFreq */);

  });

  A DAO is a data access object. These add a level of indirection between a class and the persistent data it includes.
  

  0
• Larry Loen WO7R Member ✭✭

  February 2016 edited June 2020

  I am finding the Ethernet API a little tough to work with for _general_ work, but it may be sufficient (at least in 1.6.17) to do _this_ function.  Maybe.  There is a function called "sub" (subscription) that will enable changes to all slices to be monitored.  This can send over a couple of kilobytes of ASCII state, worst case, but the parsing appears straightforward (Java or Python "split" on a trivial regex will do) and it most definitely sends over the frequency when it changes.  It also sends over changes in the TX flag, and it looks reasonable to know which transmitter is _supposed_ to own the transmitter.  Fully processing the interlock state looks like a big job, but maybe not that needful.  If I have the frequency and know who owns the transmitter, I have most of it without futher ado, all on a "call back" sort of basis (well, I monitor a stream that reports changes).
  
  What's not 100 per cent clear is how I know which ANTENNA is used for send and receive.  The functionality of the API here appears odd generally.  First off, you can only attach the "receive" antenna to a slice you create with the API (so far as I know).  And, I have seen nothing in the API set to set,change. or even associate the transmit antenna with a slice.  It is whatever you last did in the regular interface.  So, i don't know how you find out.  Kind of important.
  
  Still, this is a long ways towards "home" with just base functionality.  It will help me understand Walt's code if he's nice enough to send it my way.
  

  1