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

I think this could really make Flexwire into something far more interesting and far more often used.
- 207 Posts
- 23 Reply Likes
Posted 3 years ago
- 207 Posts
- 23 Reply Likes
- 207 Posts
- 23 Reply Likes
Peter K1PGV, Elmer
- 541 Posts
- 315 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
- 3040 Posts
- 644 Reply Likes
KY6LA - Howard, Elmer
- 3642 Posts
- 1473 Reply Likes
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....
- 207 Posts
- 23 Reply Likes
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.
- 207 Posts
- 23 Reply Likes
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.
KY6LA - Howard, Elmer
- 3642 Posts
- 1473 Reply Likes
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
- 207 Posts
- 23 Reply Likes
- 3040 Posts
- 644 Reply Likes
- 207 Posts
- 23 Reply Likes
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.
- 207 Posts
- 23 Reply Likes
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.
KY6LA - Howard, Elmer
- 3642 Posts
- 1473 Reply Likes
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.
- 1776 Posts
- 620 Reply Likes
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
KY6LA - Howard, Elmer
- 3642 Posts
- 1473 Reply Likes
- 353 Posts
- 84 Reply Likes
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.
- 3040 Posts
- 644 Reply Likes
- 207 Posts
- 23 Reply Likes
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 bang 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".
Peter K1PGV, Elmer
- 541 Posts
- 315 Reply Likes
Then you can create whatever outputs you want, like I said before.
Peter
K1PGV
- 74 Posts
- 14 Reply Likes
- 353 Posts
- 84 Reply Likes
- 207 Posts
- 23 Reply Likes
That said, the card is intriguing. But there are a lot more Arduino boards out there, with all kinds of mix and match. I have also looked at the Yun, which runs OpenWRT, directly connects to the internet without a "shield" for about 40 bucks, and would seem to be an attractive Arduino for this sort of thing.
In my case, the application would be strictly indoors, so there's that piece of it.
- 74 Posts
- 14 Reply Likes
Linux on the other hand does many reads and writes to the SD card. The frequency of the writes has been reduced as more flash based storage is being used in recent years. Regardless of the storage, file system corruption can occur if the system is powered off before the files systems unmount. This is where things can get a bit more complicated, depending on how "hands off" the pi needs to be. If it's attached to a switch or antenna tuner on the tower, then you'll have to do everything you can to make sure that regardless of what happens to the power, it must go through a controlled shutdown before allowing the power to go off. If it's sitting on your desk, then worst case you plug a monitor and keyboard into it and try to fix the file system. Perhaps make regular image copies of the SD card for when it won't boot. There are other things that can be done, such as read only file systems and NFS storage. At this point it has already become far more complicated than a simple Arduino.
For a true "stupid/dumb box" you need something that is simple and works when you power it on. As wonderful as the pi is (I have several), it doesn't quite fit the "dumb box" requirement that well. On the other hand, if it's just something to play around with and it doesn't really need to work all the time, then the pi would be fine.
- 3040 Posts
- 644 Reply Likes
- 74 Posts
- 14 Reply Likes
There is software that interfaces to UPS systems that will initiate an OS shutdown. I've even seen pi specific battery "UPSs", which are little more than a battery and a charge controller. Things can be done to make the pi more reliable and trouble free, but in the end it's still a computer running an operating system, with all the complexities therein.
For my magnetic loop controller and satellite rotator controller, I'd rather not have to go out in the cold and climb something because a power outage took out my pi. I'm also far too cheap to have some kind of UPS or battery backup on it. I'd rather plug it in and forget about it and everyone once in a while marvel at how it's still working.
Peter K1PGV, Elmer
- 541 Posts
- 315 Reply Likes
Perfect for a "dumb box"...
Peter
K1PGV
- 74 Posts
- 14 Reply Likes
- 3040 Posts
- 644 Reply Likes
http://www.zdnet.com/article/raspberry-pi-extending-the-life-of-the-sd-card/
I also found several references to corruption caused by dropping, overclocking, under rated power supplies and cheap sd cards.
The primary link:
https://www.reddit.com/r/raspberry_pi/comments/3how8w/pi_keeps_corrupting_sd_cards/
- 74 Posts
- 14 Reply Likes
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.
Peter K1PGV, Elmer
- 541 Posts
- 315 Reply Likes
>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
- 3040 Posts
- 644 Reply Likes
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?
- 74 Posts
- 14 Reply Likes
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.
- 74 Posts
- 14 Reply Likes
- 66 Posts
- 9 Reply Likes
73, Steve K5FR
- 3040 Posts
- 644 Reply Likes
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.
- 207 Posts
- 23 Reply Likes
- 940 Posts
- 260 Reply Likes
- 3040 Posts
- 644 Reply Likes
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.
- 207 Posts
- 23 Reply Likes
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.
- 3040 Posts
- 644 Reply Likes
* 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.
- 207 Posts
- 23 Reply Likes
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).
- 3040 Posts
- 644 Reply Likes
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.
- 3040 Posts
- 644 Reply Likes
- 207 Posts
- 23 Reply Likes
- 3040 Posts
- 644 Reply Likes
- 207 Posts
- 23 Reply Likes
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.
- 207 Posts
- 23 Reply Likes
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.
- 3040 Posts
- 644 Reply Likes
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.
- 940 Posts
- 260 Reply Likes
james
WD5GWY
- 3040 Posts
- 644 Reply Likes
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.
Related Categories
-
FLEX-6700 Signature Series SDR
- 2843 Conversations
- 590 Followers
-
FLEX-6500 Signature Series SDR
- 3381 Conversations
- 872 Followers
-
FLEX-6700R Signature Series SDR
- 791 Conversations
- 146 Followers
-
FLEX-6300 Signature Series SDR
- 2772 Conversations
- 797 Followers