smart sdr version 3

Steve K9ZW

Folks - you are looking in the right place as FRS has announced new releases here at the community.

So this is the right place to watch.

Finding a URL that appears to be a link for future use is great, speculating about possible feature sets even better, though we can do little more than guess until FRS tells us more.

Personally I think it is awesome and cool that so many folk are impassioned and actively speculative about the timing and substance of a future version.

Without getting crossways with my own personal FRS NDA, I can share ..... <pregnant pause>..... that I am excited that everyone is so keen on a new version.

As an aside, if you ever hear FRS reference an item number for software fixes/bug-reports/enhancement suggestions - the numbers themselves are just "labels" and don't appear to be more than a label to track things with.  I've seen a couple mentioned in various places by FRS, and had once asked them if they meant anything. 

Seems not so much, though I don't think they recycle them once used.  It of course doesn't mean that there are oddles of things unresolved - kind of like a small contractor that was near me who had their three shop van vehicles marked 121, 122, and 123, yet I knew they didn't have another 120 vehicles in their fleet.  But over coffee they told me they had used all the earlier fleet numbers during their nearly 100 year existence, as I had suggested they made them up to impress customers.  The early numbers had been traded in or scrapped over the years.  I think similarly FRS just indexes their control number labels.  

73

Steve
K9ZW

(disclaimer - I'm NOT a FRS employee, but have lots of FRS gear and am part of the FRS Alpha testing team as an add-on with the PGXL testing. 

So I'm biased by commitment, investment and inclination, and respect of my FRS NDA.

YMMV as they say, but mine won't as "I say!")  (edit was to fix a nasty split word and a typo)

Pat N6PAT

Huh???

KC2QMA_John

I set aside for Christmas $199 for SSDR V3, I sure hope my Christmas wish comes true this year

James Whiteway

Bill is not an employee of FRS as far as I know. Just very much into their products. Even though he and I may have different opinions of FRS and their business model at times, I do respect his opinion. And his quotes from FRS at times has kept me from having to dig for answers. ( I've never found a single quote of his to not be correct,yet) James WD5GWY

Bill -VA3WTB

I have..lol

Ted VE3TRQ

Bill's only fault is his enthusiasm :-) Merry Christmas, and I hope FRS _does_ deliver us a present sooner rather than later.

Mike-VA3MW

Pat

I don't think we have any machines running on Windows 8.1 in house.  Windows 8.1 was not one of Microsoft's best releases and it was pretty much left in the dust but most of the customer base.  It is also End of Lifed by Microsoft on January 9, 2018.  I will also make an executive guess that no one on our Alpha team is running it since it was too bloated and just plain slow. 

You would do yourself a favour to upgrade to Win 10 Pro for  many reasons.

I have no idea how many customers are running SmartSDR on Windows 8.1, but it might be a small install base.   I did check with Tim and he has to see an issue that is unique to Windows 8 if that helps at all.

I think Steve addressed some other concerns.    

Mike 

Mike-VA3MW

Hi Salvador

Thanks for this.  I have seen the same issue from time to time (not all the time) and reported on on #4949.    I do use SmartEther VPN with encryption turned off - or I used to.  I am 100% SmartLink now.

I talked to engineering about it there is a slight be of overhead on SmartLink channel, but it continues to be a Peer to Peer connection between the radio and the end user.  

On your 2 screen shots, you are seeing about 50ms overhead.  When I ran long term tests, the difference was about 25ms (this is not an official FRS test, just me being a typical user).  

What I can say is that 50ms made no difference on my operating experience either for rag chewing on contesting and my internet at my remote end is pretty limited.

Mike

Mike-VA3MW

Burt, can you explain, step by step what you are trying to do?  There might be a bug in there on 2.4.9, but I have yet to be able to recreate it.  

In order for us to deal with it, we need to recreate it.

Take some time and elaborate please.

Mike-VA3MW

Yes, there was a v3 link in the store.  It is part of getting ready for the release when it happens.  It is actually somewhat hidden and you can't find it normally, but not hard for people like Jean.   

You do that well in advance just so you can test things.  Not a big deal.

As for when, Steve N5AC answered below.  Feel free to read on.

KC8P

Mike,

I don't want to hackjack the thread, but I have a specific question, how does the SmartSDR measures the RTT? 

It is quite puzzles me, I have average RTT with ping - 25ms, SmartSDR shows latency (RTT) 100ms! I can't find anywhere explanation, please elaborate.

Both endpoints have excellent connectivity...10Gb uplink and the home 500 Mb/s down /  30 Mb/s up





 1     1 ms    <1 ms     1 ms  141.210.186.129
  2    <1 ms    <1 ms    <1 ms  c1-ge-7-8.net.oakland.edu [172.22.32.1]
  3    <1 ms    <1 ms    <1 ms  172.20.0.102
  4     1 ms    <1 ms    <1 ms  172.20.0.105
  5    <1 ms    <1 ms    <1 ms  198.111.3.161
  6     2 ms     1 ms     8 ms  ae2x562.sfld-cor-123net.mich.net [198.108.23.195]
  7     8 ms     8 ms     8 ms  irbx1922.eq-chi2.mich.net [207.72.237.1]
  8     8 ms     9 ms     9 ms  te-0-12-0-2-5-pe01.350ecermak.il.ibone.comcast.net [66.208.228.141]
  9    10 ms     9 ms    10 ms  be-10563-cr02.350ecermak.il.ibone.comcast.net [68.86.82.157]
 10    15 ms    22 ms    19 ms  be-7922-ar02.pontiac.mi.michigan.comcast.net [68.86.90.46]
 11    15 ms    15 ms    15 ms  96.108.20.226
 12    15 ms    15 ms    15 ms  68.87.187.70
 13    24 ms    26 ms    25 ms  c-x.x.x.x.hsd1.mi.comcast.net [x.x.x.x]

Mario

Pat N6PAT

Mike,

According to Tim Flex stopped supporting SSDR on versions of Windows that reached EOL. Therefore, Flex stopped supporting SSDR for my 8.1 machine almost a year ago right around when Flex released V2.

So I purchased for $199 SSDR that was not going to be supported by Flex because I was using a version of Windows that had just reached EOL.

Did Flex inform anyone of this when they stopped the support for 8.1? I didn't see any notice. Do you think I would have paid $199 for software if I thought it wasn't being supported?

Why did I have to ask about this 6 times and never get an answer until I opened a ticket? I asked Steve directly a few days ago and he answered a different question but ignored this question.

I paid $7,000 for my 6700 and I expect better customer service than this. Flex has made a great radio. I think it's the best on the market and I say so on QRZ almost every day. Unfortunately I would not rate your customer service  as high

Mike VE3CKO

To help you in the future I will try to name the source of my comments. I have also made it clear that when something is my own opinion I say so.
Bill -VA3WTB

Geez Bill, I will never be so PC, give you credit for that. I will not be pressured to quote my sources. Your accumulated knowledge is quite beneficial to many so I would encourage you to keep doing what your doing.

Many times his comments come across as those of an employee or a representative of FRS. It's very misleading and I do not find it beneficial.
Pat N6PAT

Bill contributes to this community just as you and others do Pat. I'm no rocket scientist but I can easily see that he is not an FRS employee. How one might ask?  It doesn't say it in his profile name. So why speculate and question ?

To go from questioning FRS's integrity to that of a fellow community member is uncalled for and has no positive purpose. Besides certain etiquette is expected here, it's the Christmas season. 

Mark WS7M

Would be nice, but if I were FRS I would not release over the holidays just to keep the customer support down during the holidays.

But yes... Looking forward to it.

Mike-VA3MW

So, I had to do some digging on this after I consulted with Eric.  The, I had to convert that to something we could all understand.  Thanks to Google, I found that it worded nicely.  Short story is that it is not uncommon for RTT to be longer than Ping as RTT is calculated totally differently.

Round-trip time (RTT) is the time it takes for a packet to go from the sending endpoint to the receiving endpoint and back. There are many factors that affect RTT, including propagation delay, processing delay, queuing delay, and encoding delay. These factors are generally constant for a given pair of communicating endpoints. In addition, network congestion can add a dynamic component to RTT.  

Propagation delay is usually the dominant component in RTT. It ranges from a few milliseconds to hundreds of milliseconds depending on whether the endpoints are separated by a few kilometers or by an entire ocean.

The remaining components (processing, queuing, and encoding delays) can vary by the number of nodes in the network connecting endpoints. When only a few router hops separate endpoints, these factors are negligible.

In real-time communications, we must consider the impact of network topology on RTT. Any infrastructure-based topology introduces incremental delay as compared to a peer-to-peer connection. 

Round-trip time and ping time are often considered synonymous. While ping time may provide a good RTT estimate, it differs in that most ping tests are executed within the transport protocol using ICMP packets. In contrast, RTT is measured at the application layer and includes the additional processing delay produced by higher level protocols and applications (e.g. HTTPS or other protocols).

Network latency is closely related, but different than RTT. Latency is the time it takes for a packet to go from the sending endpoint to the receiving endpoint. Many factors may affect the latency of a service. Latency is not explicitly equal to half of RTT, because delay may be asymmetrical between any two given endpoints. RTT includes processing delay at the echoing endpoint.


I hope that helps explain it (and, I learned something as well).

Mike 

KC8P

Yeah, I understand this, here is an another great article explaining RTT

https://queue.acm.org/detail.cfm?id=2539132

I know and agree that ping use ICMP and it maybe deprioritized or filtered over the networks....Sounds like SmartSDR use application level RTT which my have an additional overhead....but 4 times more seems to be excessive.

Do you access to developer who can answer the question about how the latency is measured from the application perspective?

Thanks
Mario 

Mike-VA3MW

Hi Mario

Not in the near future, only as they are headsdown in V3.  And, I mean seriously heads down.  That is why they haven't been online as much as they have in the past.  We have a bug logged on this (4949 I think the number is).    Getting them to go back and dig at published code will distract them from the current goals of V3.  Your question is similar to those I've seen in the gaming community.

But, I did discuss it with them and he did confirm that between the application and the priority that they are processed that this ok.   Yes, it is the application level RTT.

Personally I operate 100% HF remote for DX and Contests and haven't ever seen it as a problem that impacted my operating at 100ms.  If the number was never published, then we would never know.

What I don't know is if ICMP Ping is a measure of the time from sent to received, or is it just the time for my packet to reach the far end.  

The other thing to consider is that Ping using windows and ICMP is only 32 bytes long and in Linux is 56 bytes.  With SmartSDR showing RTT, that packet is significantly longer, so while you may see much longer times that your ping times, we really aren't moving the same type of payload with the priority.

Mike

Neal Pollack, N6YFM

I think the above people that speculate about a hand-full of bugs, somewhere in the "tens" rather than hundreds or thousands, simply do not have large complex software engineering experience.  The Flex product is really great, does a far better job than my Icom 7300.   That said, in ALL products, there are bugs and room for future improvement.   It is the nature of complex software development, and trying to translate abstract human ideas into working computer machine code.

I work for a fortune 500 computer operating system software manufacturer.  NOT Microsoft.
I can tell you that our systems run banks, airlines, military, gov, hospitals, schools, logistics/shipping, etc.  But at any time, we have well over 2,000 software bugs on file.   The vast majority of those are not seen by any customer.  But the cost of delaying and investing to fix every last one would bankrupt any modern day company.   So product teams prioritize which critical bugs to fix before shipment, and then ship it.   When you get any product, it has far more software and firmware bugs than you realize.   But you should never worry about that, since you will likely never see more than
a handful.    That includes your cell phones, cars, home appliances, etc.
I can tell you that I found over 25 bugs in the dash software for my 2012 Ford, and there were
hundreds more.  But I love driving that SUV, and it works great, except for the touch screen
nits that could be improved.
This same software and firmware issue also includes Icom, Yaesu, Kenwood, etc.   
The choice is balancing the idea of delivering a product that does mostly what people need, or delaying, not delivering, and going out of business.

We like our radios, cell phones, cameras, cars, washing machines and TV sets.
But they all have bugs.   Get over it.
Good companies prioritize the bugs that customer complain about most, and do the best they can.
Flex at least delivers free updates approx 3 or 4 times a year.   And each update has both
new features and bug fixes.    I wish the same could be said for my Icom and Yaesu radios.
No big new features there, and very few bugs fixes.   Icom, for my 7300, has come out with maybe
4 to 6 updates since 2013?   No significant new features, one or two fixes.

Cheers,

Neal
N6YFM

mikeatthebeach .

Life is too short so I use CATSync Web SDR with SmartSDR SSDR and mute My Flex Receiver which is questionable and mute it and use WebSDR receivers Since I cannot take out interference with phasing similar to Anan100D to geout Plasma TV Interference, Solar Panels and Plant **** grow lights Just my two cents Life is too short to wait for stuff “fixes” that may never be !

KC8P

Mike,

Thanks for the additional info, this is helpful! Ping ICMP is defined as "It measures the round-trip time for messages sent from the originating host to a destination computer that are echoed back to the source"

https://en.wikipedia.org/wiki/Ping_(networking_utility)

https://tools.ietf.org/html/rfc1739#section-2.2

Agree, the payload may influence the RTT as well, here is the example:

Pinging xxxx.dynu.net [x.x.x.x] with 65300 bytes of data:
Reply from x.x.x.x: bytes=65300 time=57ms TTL=51
Reply from x.x.x.x: bytes=65300 time=56ms TTL=51
Reply from x.x.x.x: bytes=65300 time=59ms TTL=51
Reply from x.x.x.x: bytes=65300 time=60ms TTL=51

I've used 65300 bytes size packet, this is a little below the max packet size for IPv4

I would like to emphasize that I DO NOT experience any issue despite the measurement values in the app.

Thanks
Mario

KC8P

Well said  Neal Pollack, N6YFM !

No new improvements and features translates to limited number of issues.

BTW....Are you saying Sun?.... Ok, I know already ;-)  

Al_NN4ZZ

Hi Neal,
My background is in IT also and includes mainframe, mini and micro systems and software.  Our systems also served many customers but is much smaller in scale than the systems you described.  We probably have on the order of a hundred active defects across all of them at one time.  If a bug doesn't have any real impact (e.g. a typo in an error message) then it might just be closed. 

The SSDR ecosystem would be smaller in scale that either of these examples.  So I would have expected significantly fewer than 1,000 active defects for SSDR.  It would be interesting to get the FRS perspective since I'm sure they use a defect tracking system and could provide a number.  Typically the defect trackers contain a lot of detail on the defect.  Some of the detail can be supposition, or confusing without the full context and proprietary so I understand why FRS would not want to publish the list.  

But every defect must have been discovered by someone (tester, coder, user) and then documented.  1,000 active defects in SSDR defect log still sounds quite high to me.  

I guess the number will be speculation unless Steve or someone from FRS wants to provide the details. 

Regards,  Al / NN4ZZ  
al (at) nn4zz (dot) com

 

Neal Pollack, N6YFM

There is no reason for any appliance or electronics company to disclose
this information, since the general public simply does not understand the
process and economics, and that information would be used by their
competitors marketing group, who would never disclose THEIR own bug

Mark WS7M

I've always worked for smaller companies except for one small stint for Agilent which really was not fun.

My software work has been highly technical.  For years I wrote software to measure tiny things.  During those years I was far more comfortable thinking in micro-inches than anything else.   

During that time I wrote software that helped build many of the rotating disks by manufacturers like Seagate, Tandum, Micropolis and many others. 

During this period in time our bug lists were always very small.  First the software was small but bugs meant a line was down usually so we spent lots of time with extensive verification and validation plans and we practiced fault tolerant methods whenever possible.   Still we had bugs and as described here we had a process for deciding if a bug was worth fixing or not.

These days I work in the research medical industry on a very complex piece of software that captures data at very high event rates and plots this data on graphs for the user while computing statistics on the data and controlling the instrument at the same time.

I would honestly say our software is more bug prone now down it was in my disk drive years because as a research tool these users sort of expect it.  It drives me crazy but that is the mind set.  

I have no issue with another $199 for 3.0 when it is released.  Each day I connect to my radio and listen to the world I realize it is a heck of lot cheaper than travel.

KC8P

I don't know any private software company that disclose their bug list publicly....SmartSDR is a proprietary software that comes with support, if you experience particular issue contact them and they will tell you if this is a bug or not...on another end if you dealing with open software package with community support and contribution you will easily find a bug tracker for every single issue, but this is a little bit different story...

Also, if there is well known bug affecting software the common practice is to create a KB article with workaround until permanent fix will be avaiable to help the customer and reduce the number support requests.

 

Pat N6PAT

".SmartSDR is a proprietary software that comes with support"

Not if you're using Windows 8.1 or 7

KC8P

Pat N6PAT I don't want to repeat myself...their documentation states otherwise.

Both Windows versions are under Microsoft extended support.

https://support.microsoft.com/en-ie/help/13853/windows-lifecycle-fact-sheet

Pat N6PAT

You need to review what the FRS employees said in their posts.

KC8P

Yes, he was correct about the dates for end of mainstream support for Windows 8.1, but he did not say that extended support ends January 10, 2023.

When mainstream support ends, this is what occurs: 

*Microsoft no longer supplies non-security hotfixes unless you have an extended support agreement
*All warranty claims end
*Microsoft no long accepts requests for new features and design changes

When extended support ends, you can no longer count on any security patches or reliability patches. This is what happened in April of this year for Windows XP, and what will happen on July 15, 2015 for Windows Server 2003.

Jon_KF2E

"and what will happen on July 15, 2015 for Windows Server 2003."

Did they miss the date or has it already happened?

Jon