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

  • 3
  • Idea
  • Updated 2 years ago
I would pay between 50 and 100 dollars for a clean implementation that would take the under-utilized Flexwire interface and expose it via a Raspberry Pi.  Integrate the Pi into the solution and I will pay the extra 50 bucks for the Pi.

Here's the thing:  Flexwire has an I2C interface out the back that does most of the "heavy lifting" in terms of function.  A brave few have made discrete circuits to process this.  But, it's not really as good as it might be, because it is hard to anticipate everyone's unique needs.

However, the Raspberry Pi has _direct support_ out of a couple of its own pins for I2C.  I believe the drivers are part of the standard Raspbian (Linux) distribution.  It's easy to find hundreds of projects already doing this.  You might have to do voltage shifting for 3.3v to 5v, maybe, and that would be it.  You could also monitor the other pins as well, such as the PTT lines.

See the picture below to help visualize the possibilities.

Do what I suggest and you now have something really interesting and flexible:

1.  There are several models of Raspberry Pi, but the Pi 2 is the most interesting.  That Pi has four USB ports in addition to header pins for the I2C.  It also has ethernet support.  It's easy to find USB-to-mechanical-relay devices capable of AC and DC operation at fairly high voltages and amperages.  Not very expensive either and you tend to get four or eight per USB port.  You should be able to control anything; amp selection, antenna selection, etc.  For the 6300, you could trivially manage to "switch" the single amplifier PTT for instance between a solid state 500 watt  brick and your tube amp. so you can be operational while the tubes warm up.   You can also include voltage sensors of various sorts (chained off of I2C or via USB) which might in turn actually monitor temperature or something else.  If you need more than nominal power, the correct brand of powered USB hubs will provide enough power for any reasonable or even not so reasonable USB devices.  I've hooked up a couple of hard files to my Pis and those are pretty unreasonable in terms of their power demands.  If you don't need the extra power over the modest basic Pi supplies (and you often won't), you're home free.  There is a lot of off-the-shelf stuff that runs on the other end of a USB line.  In particular, there are also workable USB-to-RS232 adapters, so you can talk easily to tons of old ham gear quite directly.

2.  This means the Pi can monitor Flexwire via I2C, notice any changes, and immediately instruct rotors, antenna switches, and much else, to change state via USB (RS232) ports.  You can control up to four devices via USB and, with the aforementioned powered hub, as many as six more.  Plenty of ports and it would all be integrated because it would all have access to the Flexwire information.  You could also manage state changes manually.

3.  So, the Pi becomes an intelligent, programmable break-out box for whatever you want to do with Flexwire.  It is also trivial to install a web server on Raspbian Linux and provide a basic, separately addressed web front end for the Pi.  I've done a little of that and the web pages involved tend to be fairly basic and trivial.  So, once you have a basic capability installed, you can surround it with a little HTML and allow yourself to control it via your own little web page if you want.  Or, however else you want to do the control.

The picture shows the v2 connector; don't know how compatible it is with older gear.  That would have to be explored.  But, for the 6x00 owners, I presume the v2 is sufficient?

The Pi itself is now very widely available.  Easily ordered off of the web -- and I can even get them at Fry's.  So, this is not a product with a very substantial risk of obsolescence.  The basic "Pi" is likely to be around in substantially the same form if not absolutely identical for at least five years.

Anyone interested in this?  I don't really have good skills in this regard, at least on the hardware side, but I would be interested in anyone who does and would be glad to work "kickstarter style" with someone if Flex isn't interested.  I could certainly take a stab at the software side of this.

I think this could really make Flexwire into something far more interesting and far more often used.
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes

Posted 2 years ago

  • 3
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes
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".
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes
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.
Photo of Rob N4GA

Rob N4GA

  • 144 Posts
  • 25 Reply Likes
Wow - big spender!
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 540 Posts
  • 310 Reply Likes

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

Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 640 Reply Likes
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.
(Edited)
Photo of KY6LA - Howard

KY6LA - Howard, Elmer

  • 3403 Posts
  • 1292 Reply Likes
Maybe I am missing something...

But why use the I2C port to kluge up an interface when there is a big fat 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....
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes
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.
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes
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.
(Edited)
Photo of KY6LA - Howard

KY6LA - Howard, Elmer

  • 3403 Posts
  • 1292 Reply Likes
@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
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes
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.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 640 Reply Likes
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.
(Edited)
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes
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.
(Edited)
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes
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.
Photo of KY6LA - Howard

KY6LA - Howard, Elmer

  • 3403 Posts
  • 1292 Reply Likes
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.
Photo of Al / NN4ZZ

Al / NN4ZZ

  • 1653 Posts
  • 563 Reply Likes
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
Photo of KY6LA - Howard

KY6LA - Howard, Elmer

  • 3403 Posts
  • 1292 Reply Likes
I might note that I use DDUTIL to interface all my peripherals. And it provides a Telnet to various apps.
Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 334 Posts
  • 82 Reply Likes
For devices integration without the PC, the best option is a "stupid 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 stupid 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.
(Edited)
Photo of Steve - KD8QWT

Steve - KD8QWT

  • 74 Posts
  • 14 Reply Likes
Thanks Walt.  Excellent stuff.  I've implemented some of these.  I've never actually experienced fs corruption, but I tend to not cheap out on the SD cards.  I run an APRS igate with a TNC-pi.  The logs are written to my NAS via NFS.  It has been pretty stable, but still, it's an OS I have to periodically look at and update.  It's an excellent use of a pi, although now that I'm thinking about it, an Arduino Due with the TNC would work quite well.  I might add that to the list of projects.  I'm now wondering if the Due can handle the audio processing directly.....

Junk power supplies is probably one of the biggest issues with the pi.  I ran across a POS supply when I setup Kodi on the pi2.  Everything worked but video was jumpy.  A new 2A supply fixed it.  It's not always obvious that the power supply is insufficient. 

These linux SBCs are very slick and I love playing around with them.  For something very specific, like interfacing an old serial port based device to ethernet control, I'd prefer a microcontroller like the Arduino Due.  It would be interesting to have a base sketch using the Flex ethernet APIs that can be used as a starting point for antenna switches and such.  With the Arduino, there's no need to deal with issues like having the right version of libusb.

Now I'm waiting for the Pine64
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 540 Posts
  • 310 Reply Likes
Steve, KD8QWT, asked:
>Does FlexLib work on Windows 10 IoT now?

I've been told that it does, by the folks who own Windows IoT. I have not, however, personally verified this.

I've had a project on my plate to play with this for better than a year... I've got all the hardware and software, but priorities have conspired against my ability to make this very simple project happen. Sigh... life gets in the way sometimes.

Peter
K1PGV
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 640 Reply Likes
@Steve, Pine64 does look impressive but I am not sure it buys much...but at $15, I am willing to not look the gift horse in the mouth!

I think I'd do the same, mount iSCSI storage on my NAS, which is where I keep my virtual images for my cloud and main dev environment.

What would you recommend for a solid power supply and SD choice?
Photo of Steve - KD8QWT

Steve - KD8QWT

  • 74 Posts
  • 14 Reply Likes
My NAS is an OpenIndiana server with 16GB RAM and running 6 1TB drives as zfs radiz2.  I have 2 32GB RAM servers running ESX and a dozen or so server images.  One of these days I'll replace the drives with 2TB ones when they get closer to the price I paid for the 1TB drives.  Mounting an NFS drive on the pi is almost trivial.

For SD cards I stick to name brands.  So far I've only used Sandisk Ultra MicroSDHC Class 10 Cards.  No issues as of yet.  The last one I got was 8GB.

For my APRS igate, I chose to hang it of my HF power supply system.  It consists of a Astron RS-35M with a RIGrunner 4007U and a Super PWRgate PG40S.  The 4007U has a USB port which I run the pi off of.  I have a couple 12V UPS batteries I will soon replace with a single larger battery.  The igate runs for several hours after a power failure.  The generator is usually up long before before the batteries run out.

I am trying this one I got on Amazon for my Kodi pi.  I've only had it for a couple weeks.  It still works, so that a plus.  The little cubes you get with the expensive cell phones are generally junk, at least most of mine have been.  I previously ran the igate off a supposed 2A supply that came with my phone, but it was getting way too warm for my liking.  The market is flooded with USB power supplies that are anywhere from crap to junk, with a few good ones sprinkled about.  I haven't bought and burned through enough of them to know which ones are good. 

The Arduino requires a bit less current.  I usually run it with the power supply I bought with it, but in the case of my satellite rotator, I have a 12-24V DC motor controller that also powers the Arduino.  I have a few buck converters scattered around that I use off the RIGrunner.  I started using that after I etched some lines in my desk.
Photo of Steve - KD8QWT

Steve - KD8QWT

  • 74 Posts
  • 14 Reply Likes
@Peter, yes, life always takes priority.  Lately work and wife projects have taken priority.  I just finished restoring an old commercial chocolate tempering machine for my wife, so back to fun stuff again.
Photo of Steve - K5FR

Steve - K5FR

  • 62 Posts
  • 8 Reply Likes
This is a great philosophical discussion, but according to Eric at FRS I2C is not implemented yet in the F6K radios.

73, Steve K5FR

Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 640 Reply Likes
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.
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes
I'm struggling a little to understand these snippets.  One is presumably some C++ enablement code to suggest how it works "underneath".  The other, I presume, is the actual Java code that would monitor?

As discussed below, I think I need to know these basic things:

1.  Frequency of at least the slice owning the transmitter.
2.  Which slice does, in fact, own it.
3.  Which antennas (send and receive) are used by the slice(s).

With that, I can do the kinds of external control I may someday wish or need to do.  (Right now, I'm getting by without it, but I have more gear coming).
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 640 Reply Likes
Larry, that was all java code. I don't believe I've done C++ in 15 years. Well, the radio object owns the slices but they are associated with whatever panadapter it is resident on. The information to populate the rx and tx values are set when parsing slice status information sent from the radio. The value of those attributes is in String form as in "ant1" etc. In the first set of snippets the point I was demonstrating was the totally asynchronous nature of events.
Which slice owns the transmitter is determined by the value of 'tx=' in the status messages or the value of Boolean tx = slice.get transmit();

What I was trying to do was give you the accessors for the attributes along with the programmatic method of hooking async events to methods vs what name value pairing to look for in the status message.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 640 Reply Likes
Ah, I get it now. No -> is not a c++ pointer dereference, it is a Java lambda expression. Amount other benefits it is a highly efecient anonymous class invocation.
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes
Man, I gotta keep up.  You'd never know it, but I programmed in Java, professionally, from 1.1 onwards.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 640 Reply Likes
Java 1.x was a toy compared to Java 8 today. Java 5 was a major improvement over 1.4 as was Java 6 over Java 5 etc up through Java 8. Java 9 is in the works now.
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes
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.
(Edited)
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 186 Posts
  • 23 Reply Likes
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.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 640 Reply Likes
getRcvAnt() or getTXAnt() in the api or
processing the raw status messages look for "rxant=" or "txant=".

setRcvAnt(...) or setTXAnt(...);

In the case of xpssdr, you could also directly bind the relevant property and process a change event. or just ask the Slice what it's rcvAnt and txAnt are, i.e. String txAnt = slc.getTXAnt();

Again, any statement I may make about how something works is based on XPSLib or XPSSDR. Any similarity between how things work in xpslib and anybody elses software, published or not, if purely coincidental.
(Edited)
Photo of James Whiteway

James Whiteway

  • 830 Posts
  • 180 Reply Likes
One question Walt, (and please don't take it the wrong way) you keep posting about how to do things in XPSLib or XPSDR, yet, neither is available. So, how does that help answer questions someone has trying to work with either Flexlib or the Ethernet api's? I can only guess that the code is similar enough that you feel it gives some indication of discovery and event handling.
james
WD5GWY
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 640 Reply Likes
Fair question James. I was admonished for discussing how flexlib does things. So if I couch answers as how it works in XPSLib or XPSSDR I sound less like I am speaking for, or as, FRS engineering, which I am not. I have never portrayed myself as having Insider information or being an insider. So I am attempting to contribute to the community without offending anyone.

I believe Stu's code, therefore dog park, use Apple's in app purchasing. Safe assumption as stu has said that. I dont want to speak authortatively abt others code. Apple knows who you are when you sign into the app store. Consequently the app knows who you are as well. There is a facility Google provided an API for doing that in Android. There is no facility to do that elsewhere. Stu's comment on the future of subscription software I consider spot on while I do not mind supporting XPSSDR, I do mind doing it for free. XPSLib will be available as binary. When I've plumbed in licensing into the GUI, it'll be available as well.

And this conversation revolves around a platform FRS has no product solution for so, hopefully, I am not stealing anyone's thunder.
(Edited)