Call Search
     

New to Ham Radio?
My Profile

Community
Articles
Forums
News
Reviews
Friends Remembered
Strays
Survey Question

Operating
Contesting
DX Cluster Spots
Propagation

Resources
Calendar
Classifieds
Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement
About eHam.net

   Home   Help Search  
Pages: Prev 1 2 3 4 5 6 [7]   Go Down
  Print  
Author Topic: To SDR or not! That is the question!  (Read 22246 times)
NI0Z
Member

Posts: 569


WWW

Ignore
« Reply #90 on: January 09, 2013, 04:51:06 PM »

In the world of Microsoft, they want you developing with their tools using their methodology.  That's just one platform to choose from.  There are many others!  You can google all that, I'd rather not type all that here.  Java, perl, php, and keep your eye on HTML 5, it can do way more than people imagine HTML being able to do.

There are nice lightweight editors out there that don't require a mega computer to run.  For example, my websites has a CMS under it and its mostly developed on the iPad using a browser and then just local photo editing and FTP clients to move up images, files, ect.  It's all modular as well so if you want new functionality, you just upload the package and install it. That's a very minimal example but definitely what will come.  Btw, it's a wysiwyg environment.

Development will become more and more drag and drop and configure.  There are millions of dollars in rewards for developers that develop reuse able frameworks and code.  Take Java beans for example, they have been around for quite a number of years.  More of that will come as we develop more apps and less applications.  SDKs will become more and more predominant.

Cloud failures are just today's hiccups.  Serious cloud implementations have geo redundancy and don't experience failures.  Some company's have to learn that the hard way.  Some cloud computing architectures also allow some local work with periodic update or syncing.  That way an outage doesn't stop you.

It's all on the move, keep your eyes peeled for change!
Logged

W6RMK
Member

Posts: 656




Ignore
« Reply #91 on: January 12, 2013, 06:19:06 PM »


I would wait to see that API implemented, running, and documented before leaping in. There's a very small population of customers who actually would use it, so it's more likely that development effort will focus on the non-API parts of the software, and on new features for the 95% of users, before features like an API for the 5%.

  I'm pretty sure that Flex will want as many people building applications for the new radios as
they can get. The more "cool" stuff that is out there for the radios, the more they will sell.
Completely closed, no 3rd party applications would be a mistake in my opinion.
Maybe, but the ham world is very small. The number of people who can develop for the platform is small. It's not like an Android or iOS device, where you can get what's needed for development (the phone and dev kit) for fairly cheap.

The previous Flex radios had published source code with minimal documentation, but there were maybe half a dozen people doing things (other than within Flex).   There was a fair amount activity with things to drive the CAT interface, but that's not really an API.
Quote
As for the API
that is something they would want for their own developers as well. What will be interesting to
see is, how much of that API they expose to outside developers. Microsoft was well known for
not documenting a lot of functionality to outside developers in their various API's for Windows years ago. (and probably still leaves a lot out) There was a lot of complaining over that too.
Not necessarily. I don't know anything about their current internal software development practices, but in the past,that's not how they worked. They had a couple folks who provided the DSP core (dttsp) which had a DLL style interface. Then they had some folks doing UI in VC to call the DSP.
At no point did flex ever publish any design or interface documentation, other than for the CAT interface, which essentially emulates the serial port style interface for conventional rigs. Their answer was "look at the code", but the code doesn't really have many comments in it. You have to reverse engineer it.
Quote
  I am sure that they are working on the internals of the software for the hardware itself. And
the Client software too. (saw some of that in the recently released video of SmartSDR)
But, again, if they limit 3rd party development too much, "I think" that the new radios will be an even tougher sell.
Actually, I don't think most hams care if the API is published.  It's something that some fraction (maybe 10%) say they would like to have, but an even smaller percentage would actually use it.

And the costs to provide adequate API documentation, example code, test cases, and user support are enormous.  For an internal only team, your documentation is "ask Bob in the next office" when the API call returns something weird.

The other aspect is that the API is likely to only be for "display and UI" type functionality.  If you're expecting to get into the signal processing, that's even less likely. It's harder to design a good API for this, and Flex has some legitimate concerns about keeping the FCC happy.
Logged
WD5GWY
Member

Posts: 403




Ignore
« Reply #92 on: January 12, 2013, 07:04:16 PM »

From what I have been told, the API that Flex is developing is to allow outside
developers to create UI's for different platforms, such as Tablets and phones.
  I understand that they will not be allowing direct access to the actual software in
the radio itself. That would be bad and create problems.
  Also, I know that there is probably not that many hams that are also developers
and Flex users. Or even if they are Flex users, they may not want a 6000 Series radio.
(or cannot justify the expense)
Anyway, for now, it's all speculation.
james
WD5GWY
 
Logged
WD5GWY
Member

Posts: 403




Ignore
« Reply #93 on: January 12, 2013, 07:11:17 PM »

In the world of Microsoft, they want you developing with their tools using their methodology.  That's just one platform to choose from.  There are many others!  You can google all that, I'd rather not type all that here.  Java, perl, php, and keep your eye on HTML 5, it can do way more than people imagine HTML being able to do.

There are nice lightweight editors out there that don't require a mega computer to run.  For example, my websites has a CMS under it and its mostly developed on the iPad using a browser and then just local photo editing and FTP clients to move up images, files, ect.  It's all modular as well so if you want new functionality, you just upload the package and install it. That's a very minimal example but definitely what will come.  Btw, it's a wysiwyg environment.

Development will become more and more drag and drop and configure.  There are millions of dollars in rewards for developers that develop reuse able frameworks and code.  Take Java beans for example, they have been around for quite a number of years.  More of that will come as we develop more apps and less applications.  SDKs will become more and more predominant.

Cloud failures are just today's hiccups.  Serious cloud implementations have geo redundancy and don't experience failures.  Some company's have to learn that the hard way.  Some cloud computing architectures also allow some local work with periodic update or syncing.  That way an outage doesn't stop you.

It's all on the move, keep your eyes peeled for change!
I understand what you are saying and agree. Personally, I like Microsoft's development tools and
enjoy using them. I have used development software included with some Linux Distros that I have
used and found them lacking. The closest thing to VB in the Linux world that worked the best (well, actually it worked OK, not best) is Mono. And it is really intended for a C# implementation
for Linux. VB is just (or was the last time I looked at it and used it) tacked on.
  As I said, I am spoiled from using Visual Studio and especially VB. Even programming in C++ in Visual Studio is easier to me. C# is nice too.
  Oh, and I am keeping my EYE(blind in my left eye due to a chemical accident) peeled for change!!   Grin
james
WD5GWY
Logged
Pages: Prev 1 2 3 4 5 6 [7]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!