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.
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.
Posted 3 years ago
Peter K1PGV, Elmer
KY6LA - Howard, Elmer
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....
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....
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.
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.
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.
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)
KY6LA - Howard, Elmer
@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
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
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.
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)
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.
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)
KY6LA - Howard, Elmer
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.
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.
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
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
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.
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)
Not exactly missing Enzo. We'll discuss more.
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 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".
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".
(Edited)
Peter K1PGV, Elmer
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
Then you can create whatever outputs you want, like I said before.
Peter
K1PGV
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.
I agree 100%. On the reliability aspect Arduino wins hand down.
I'm interested. There is still "flash" memory on the Arduino Due. Don't see how it is any more or less vulnerable than an SDR card.
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.
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.
It may be flash based memory in both, but their usage of that memory is very different. The Arduino uses it at boot time to read the code that was uploaded to it. There are libraries that allow for the reading/writing of memory blocks for data storage, but for the most part the memory isn't written to again. I suppose it's possible to have memory corruption if the memory is being written to when the power goes out. More often, memory issues are related to logic and not hardware. For persistent storage I just use the SD card on the ethernet shield.
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.
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.
That's a good writeup, thanks Steve. Linux knows how to understand UPS state and auto initiate a controlled shutdown. There is a way to daisy chain Linux boxes together such that the unit connected to the UPS can act as a repeater to others. At the moment I've forgotten how, thank goodness for goggle. I wonder what would happen if the SD were formatted as a journalled drive, like ext4. Now if you lost power during a system update, all bets are off, just as with Windows. But the system itself is r/o so it shouldn't prevent a reboot...right?
(Edited)
Sure, ext4 would help, but even a journaled fs isn't immune to "bad things".
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.
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
Windows on the RPI2 can boot and run with the disk set completely to read only. Any temporary writes can be saved in me rot and then discarded on boot.
Perfect for a "dumb box"...
Peter
K1PGV
Perfect for a "dumb box"...
Peter
K1PGV
Does FlexLib work on Windows 10 IoT now?
I found something that might interest you Steve.
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/
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/
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.
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
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
>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
@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?
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?
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.
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.
@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.
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.
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.
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.
(Edited)
Me too! I'm looking forward to seeing XPSDR too!
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.
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.
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.
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.
/*
* 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 */);
* 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.
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).
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).
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.
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.
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.
Man, I gotta keep up. You'd never know it, but I programmed in Java, professionally, from 1.1 onwards.
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.
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.
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.
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.
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)
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
james
WD5GWY
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.
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)
