SmartSDR v3.8.20 and the SmartSDR v3.8.20 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
Power Genius XL Utility v3.8.9 and the Power Genius XL Release Notes v3.8.9
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Does FlexRadio have any future plans to create a hardware upgrade pathway?
Answers
-
When I left doing Windows development there were compile/link time switches that governed multithreaded libraries vs single threaded libraries and meta instructions in the dll source to say which parts were thread safe and which weren't. If you have two instances of SSDR linking to the same dll's, I am not sure how safe that would be or even if FRS has a specific use case for that. In the webserver world one must take care to not persist attributes in the an instance variables as they are shared among multiple users. Again though, I left Windows development before .NET was even in the design stage so I cannot speak to what can and can't be done wit Visual Studio artifacts or VS switches.
Walt - kz1f
0 -
Yes, we have about a dozen or so radios on the same LAN in the office.0
-
Tim, do you folks simultaneously have multiple SSDR instances, same machine, connected to multiple radios. In other words, computer a, SSDR instance 1 connected to radio 1, computer a, SSDR instance 2 connected to radio 2. Two SSDR instances, one flexlib dll?
1 -
It would appear that one can attach multiple radios to the LAN but only one radio per customer. In other words, one computer would run one radio while another computer would run another one, etc.
Jim
0 -
That's consistent with what I suspected. I just wanted Tim to differentiate between "gee, nobody's don't that" and "no, that will not work with FlexLib (multi user mode)". Another use case but different is CRT, a program could link to the static runtime library or link to the dynamic runtime library. In the former case the exe is bound, forever, to the runtime environment it needs but it is bloated. In the later case the exe is dynamically linked to the runtime where the exe then is very tiny, relative to it having been statically linked. But should the user change deliberately or accidentally, that CRT, the applications dynamically linked to it may fail to run subsequent to that.
1 -
Only one instance of SmartSDR can run under Windows at one time and only one instance of SmartSDR can connect to a radio at one time (single user mode)0
-
Thanks Tim.
0 -
Radical Technologists with Passion, rather.
1 -
I find Tim's answer unclear. Perhaps the question can be phrased differently: If there are multiple client computers on the LAN and multiple radios connected to the LAN can each of these client computers operate separate radios simultaneously? Or can only one radio be operated at a time even though multiple radios and client computers are connected to the LAN?0
-
Further on this, yes you could theoretically add some kind of mezzanine board inside a 6000 series. There are even commercial examples of plug-in cards using the same Virtex-6 FPGA that Flex uses: http://www.acromag.com/catalog/815?gclid=CjwKEAjw6Z2pBRCmvaXq6d7FjUoSJAAc5Lri4EmDBJW524tbygZ27Bm-ai_...
That one card is $12,000. At that scale you can use connectors and design methods to make it work.
The parts in the 6000 series which would theoretically need updating are the FPGA, the ADC, the TI DaVinci DSP, and the ARM A8 CPU. As currently designed they are placed and signals routed for optimal performance, noise and heat characteristics. To gather those parts on a plug-in card (or cards) would require a major redesign, with knock-on effects regarding cooling, electrical noise, etc.
The entire user base would take the penalty for this in terms of higher cost, protracted development and additional testing - all to serve a fairly small % who might want that feature.
Regardless of the physical and electrical design, they cannot be upgraded individually without an underlying bus and socket architecture which supports this. FRS engineers would have to develop and test that, vs working on the radio itself. It's a lot more than just putting them on a plug-in board.
On top of that, the design would then be constrained by the interfaces used on the plug-in boards. What if the next ARM CPU or Virtex FPGA was hugely better but incompatible with the daughterboard design? Intel is under at least some pressure from the gigantic ecosystem to maintain limited pin compatibility for certain CPU sockets in selected cases. FRS and the tiny Flex user base have zero leverage to obtain this.
So it's not that it cannot be done, but there's a cost to doing it. This is a very old issue in electronic design. With older designs it was more achievable. As integration levels increase and clock frequencies, lead pitch and thermal factors become ever more difficult, it's hard to do -- especially in a consumer-priced, limited-production embedded system.
It appears even Intel will quit providing socketed CPUs from 2016 onward -- they will be Ball Grid Array soldered in, for reasons stated above. If it's so easy to provide a cheap, reliable daughterboard for ultra-high-speed components, motherboard manufacturers will do that then. However I seriously doubt it, despite having far greater resources than FRS.
1 -
Jim, the radio is just an endpoint, much like a tablet, phone, laptop, desktopm printer. A session is one endpoint (address:port) connecting to another endpoint (address:port). Think of it like a small corporate network, that one computer sending print output to a network attached printer doesn't interfere with another computer in ssh session to yet a third. I believe that is how FRS tests. Each Flex would have it's own IP address so even though the ports in use would be identical, the endpoints would be different.
The radios would likely need their own antenna, that could be an issue of course they could be connected to signal generators or dummy loads. Having two transmitters fire up on the same piece of coax would likely cause issues. I never tried that.
Furthermore, I think what prevents that is in the code. I've connected to the radio while SSDR was running on another machine. That was my own program connecting from Linux and SSDR running on..you guessed it, Windows. In fact, if you want to see some of the traffic sent from the radio, telnet to that ip address port 4992 and just let it sit. You'll see requests made to the radio and responses back from the radio all while SSDR is running and you are either in SSB, CW, DIGI to another station. It's really kind of interesting and would you a good idea of the actual tcp traffic flowing. But, telnet is not SSDR.
0 -
Any one out there who can explain this in English?0
-
1 instance of SSDR on 1 computer can connect to 1 radio. 2 radios would require 2 computers since only 1 instance of ssdr can run on a computer.
bottom line
2 radios 2 Windows computers at this time.0 -
Jim, That just hurts my feelings. I am sure you didn't mean it but....
;-)
0 -
If a third-party worked out an upgrade program where a ham would basically put a purchase sized deposit on a radio and pay a small monthly fee, with the right to later "buy-up" to a higher level radio, would this interest people? Would think there would need to be a buy-out for either when they move up to a Flex-6700 or decide they no longer have an upgrade interest. Thinking this would parallel some of the RPO (Rental-Purchase Option) agreements we see for major equipment. The monthly would be needed to fund the administration costs. Thinking out loud here, but certainly could see buying 50-100 radios for a program if the ROI bettered what the bank offers (which should be easy enough). Thoughts? Steve K9ZW1
-
Steve, I think administratively that would be 'prohibitive'. You'd not only have to add the use of money fee (interest) but also shrinkage allowance (possession is 9/10 of the law). Does the lessee have an insurable interest or must the lessor incur the insurance. Who has to make whole the other in the event of a fire, flood, theft, etc. If one doesn't own it can they still insure it. Furniture is different, it is covered by homeowners and if non-payment they send the truck to collect it. But, in those cases where they can't collect it others pay their piece of the shrinkage. When FRS comes out with the 7000 series, those owning a 6000 will have severe depreciation. If a third party is the owner, how do they ration out the cost?
What does upgrade even mean. Most, if not all, hardware sold today has a planned obsolescence. Companies want you to buy a new car, a new washer/dryer, a new TV, a new....radio.
0 -
Walt, all details to be worked out that only become worth systematically addressing once a determination of enough paying potential clients is established.
My guess is the costs would not be much different than the purchase & depreciation hams experience presently.
It would take at least 150 known interested hams, figuring that up to 2/3rds drop out when dollars down are needed, to be worth working through the details.
Personally I think it is too large a challenge to get the required numbers to make themselves known, join-in and most importantly pay in. Therefore not likely enough interest to commit to a program as the financials wouldn't make it worthwhile for either the participants or the sponsors.
Would love to be proven wrong by a huge swell in interest.
So far no private emails expressing interest or postings of a person's interest here. Not encouraging especially with the amount of work that would need to go into the program front end, not to mention the investment needed.
73
Steve
K9ZW
0 -
Effectively you are noodling a lease program for Amateur Radio gear. I agree that is kind of interesting but it is different than, say, leasing a car. For $200-$500/month you can always be driving a current model car, drop off the keys and get the next model year. The depreciation on a car is different than the depreciation on a radio and cars change far more rapidly. My 2012 Prius has radar cruise control. It could have had stay in lane technology. Tesla is upgrading all S series owners with full autopilot technology this spring/summer. Quite realistic, my next car could be voice actuated "Drive to 100 Staples Dr Framingham MA" and then I could read a book or connect to my 6000 series remotely and work DX while the car drove. How often is the 6000/7000 going to radically change? Also, what makes leasing attractive is it is a business expense and written off taxes. No such incentive exists in radios. My guess is there are 1400 or less 6000 owners. if 10% are interested would 140 be a workable number? I didn't see where you provided a private email.0
-
I think the 6000 series has a very limited lifespan as the concept of this type of radio expands. It would seem one of the stumbling blocks of the 6000 is the software end and the "computing power" of the radio. I expect to see a 7000 series in the not-too-distant future.0
-
I do too. I pretty much hesitated to mention planned obsolescence as raising that, well recognised business practice, might unleash a backlash from those denying FRS would do such a thing, especially since they are BFF's with some of the folks here and folks at FRS might blame me for starting that. I think that is what is behind this thread, hey, can I get a 7700 for just a small upgrade charge? You can have my 6700 back. If they are smart, and I know they are, they are designing it right now. Elecraft is also designing the K4 right now as well, ditto Kenwood, Yaesu, and Icom. The only constant in this multiverse is change.
0 -
I think Flex will see it will be pretty much like the old Linksys routers. All the hardware was there but user groups popped up and took the router too new unimagined limits. I see the same thing with the 7000. let other groups who want to be "stars" write the software/firmware, and let Flex sit back and concentrate on the hardware.
0 -
Jim, funny you should say that. I just finished saying that, sort of, in another thread. Is LinkSys still around or did they 'invent' a technology but lost in the ensuing battle for supremacy of that technology? As I've said in the past, FRS entered a existing race by, arguably, one upping the existing players (Kenwood, Yaesu, Icom, and Elecraft, which recently did the same thing). The business motivation for Flex now is to stay in the lead position.They may or may not be successful. I doubt the aforementioned players in the radio market will graciously cede dominance in the field. That is good for Amateur Radio Operators everywhere. Let the games continue!0
-
Regarding Linksys, they sold the some of their rights to Belkin who recently introduced a very fine router the WRT1900AC of which I am the proud owner. However, they have yet to open the flood gates to open source firmware development. However, the core firmware isn't all that bad as I see Flex migrating and to eventuallty opening it up to sell radios. A case in point is the writer of HRD, Simon Brown. He spends a lot of time developing software for many of the more popular SDR receivers. Maybe some day he will put his fangs into the Flex. He is an extremely talented programmer.
Jim
0 -
Isn't that what FRS did with PSDR? But in that model, PSDR was the radio. In the SSDR model the radio is nicely tucked under the chassis with a finite amount of memory. I, actually, don't see that happening, opening the Linux source to the radio logic itself. What if, however, they open the FlexLib interface above the tcp/ip to the actually radio logic and maintain that in the, for lack of a better word, 7000 series. In this way anyone who writes or rewrites the SSDR would have a protected investment and new cmds would be added to the radio where there is a loosely coupled GUI. Personally, I think the lowest common denominator (cmd line) interface is unnecessarily expensive, vs a REST base interface where the radio would emit something that the open interface could immediate instantiate. The command line approach requires parsing on 2 ends. In the REST or WSDL approach neither side would need to constantly be parsing. In other words, the SSDR facsimile wouldn't have to construct a Radio or Panadapter, or Meter object they would just 'materialize' and be directly mutable. This is a pretty much common model in Java, C# etc. Actually that is what I was originally intending but without intimate knowledge of the objects and Vita constructs that would take too long, so it is V2. But with that comes an incredibly open interface. Any language would immediately have access to the actual objects inside the radio. For me to do that it would be a shim layer on top of cmd line interface. If FRS put that INSIDE the box, now that would be awesome. This is the advantage of being (semi)retired. I've got the time to evolve this. From FRS's perspective, it is not a critical path item. Now I think about it, it isn't clear there wouldn't be an incentive for them to do that with the 6000, assuming there was enough headroom in the box, or encouraging someone to do it for them. Look at the model used in HTML5 for the media control, one of the constructors passes in a Stream....voila, a graphical widget directly listening to the radio or, in my case, one level of indirection away from the radio. I'm liking it, this is why it is good to talk about this stuff. I was kinda hoping to have this conversation with inside of FRS but, we play the hand we're dealt.0
Leave a Comment
Categories
- All Categories
- 294 Community Topics
- 2.1K New Ideas
- 538 The Flea Market
- 7.6K Software
- 6K SmartSDR for Windows
- 139 SmartSDR for Maestro and M models
- 337 SmartSDR for Mac
- 251 SmartSDR for iOS
- 226 SmartSDR CAT
- 175 DAX
- 345 SmartSDR API
- 8.8K Radios and Accessories
- 7K FLEX-6000 Signature Series
- 46 FLEX-8000 Signature Series
- 860 Maestro
- 45 FlexControl
- 838 FLEX Series (Legacy) Radios
- 809 Genius Products
- 401 Power Genius XL Amplifier
- 280 Tuner Genius XL
- 89 Antenna Genius
- 246 Shack Infrastructure
- 168 Networking
- 377 Remote Operation (SmartLink)
- 119 Contesting
- 593 Peripherals & Station Integration
- 116 Amateur Radio Interests
- 880 Third-Party Software