Maestro Display

  • 9
  • Idea
  • Updated 3 years ago
  • (Edited)
How about displaying UTC below the MENU button
Photo of Bernie W7DMC

Bernie W7DMC

  • 31 Posts
  • 7 Reply Likes

Posted 3 years ago

  • 9
Photo of Wayne VK4ACN

Wayne VK4ACN

  • 136 Posts
  • 21 Reply Likes
I think that is a great idea
Photo of Andrew Russell

Andrew Russell

  • 276 Posts
  • 43 Reply Likes
Either from the net or the GPS if installed.
Andrew VK5CV
Photo of WW1SS - Steve

WW1SS - Steve

  • 755 Posts
  • 259 Reply Likes
Another wet dream. . . . It will get added to the feature list for further consideration in the future
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
The potential problem with that, Andrew, is the radio has a concept of time, minimally from the GPS, SSDRfW has a concept of time, presumably from the radio, and SSDRfM, should and probably does share the same common source for what time it is. It wouldn't make sense 3 devices have 3 time sources.
(Edited)
Photo of Martin Ewing AA6E

Martin Ewing AA6E

  • 322 Posts
  • 76 Reply Likes
Funny thing is that Maestro does know UTC.  If you touch the right side of the waterfall, the waterfall freezes (as it's supposed to), and it shows you UTC.  Unfortunately, it's not true UTC.  It may have been correct at the factory, but now it's drifting.  Flex should, IMO, turn on Windows' time sync or NTP -- and find a place to display UTC on screen.  You have to be on the Internet for this -- or allow a manual time setting process.
Photo of EA4GLI - 8P9EH - Salvador

EA4GLI - 8P9EH - Salvador

  • 1780 Posts
  • 547 Reply Likes
Or at the very least tap on the GPSDO on the radios equipped with it.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
OK, std disclaimer: I don't work for FRS and I am not an FRS insider. There!

In flexlib there is an attribute gpsUtcTime with standard accessors (get/set). How that attribute is (in flexlib) set is from the GPS status message from the radio to the client (using flexlib). As I actually have GPSDO, it is logical I'd see those status messages. Which I do, btw. So when a client calls getGpsUtcTime it will have been set, in my case. I do not know if SSDR (the radio) dummies out a fake GPS status message when the GPSDO is not installed or what it does for time in the case of it not being installed. However, and this is the speculation part, given SSDR (the movie...er..the radio) is a Linux based app, it could be running an NTPD or, at the very least, an NTP client such that, in the absence of a GPSDO it has access to a reasonably accurate time. Keep in mind the farther away (ttl wise) the radio is from Ft Collins, CO, the less accurate NTP client is going to be. The SSDRfX clients may well ask the radio for the GPS time and getting null back, ask the OS for the current time. But, regardless of how, it makes no sense, system wise, to have multiple different time sources.

In the absence of a GPSDO, the radio may well ask the Linux OS what time it is, trusting the backup battery has not run down, and uses that in the fake GPSDO status messages.
(Edited)
Photo of Martin Ewing AA6E

Martin Ewing AA6E

  • 322 Posts
  • 76 Reply Likes
Any argument based on GPS availability won't carry the day with the 99% (?) of 6000-series users who don't have GPS. (But you knew that.)

The first question is who needs to know the real UTC.  The first proposition is just for user convenience.  (What to write in your logbook, etc.)  At some point in the future, the "radio server" and the "client" need UTC for their own purposes.  The server, so that it can schedule events accurately (new types of modulation?) and time-tag received data (for special modes and other time domain applications).  These suggest lots of interesting new applications, but they are somewhere in the future and probably well down the list for Flex, alas. (UTC doesn't win contests.:)

Anyway, a system-wide timebase, such as NTPD could be the way to go.  NTPD can use network servers (if you're on the Internet), or it can use the GPSDO if you have one, or if all else fails, an HF source.  Furthermore, it can be a time server for your entire shack/LAN, which would be really neat.

[Sidebar: What accuracy do you need?  Are you interested in seconds or microseconds?  Are you doing JT65 or VLBI?]

But while we're waiting for the Ultimate Solution, a user-friendly UTC clock on the Maestro would be appreciated. (It's already there in SSDRfW, getting time from Windows OS.)
Photo of EA4GLI - 8P9EH - Salvador

EA4GLI - 8P9EH - Salvador

  • 1780 Posts
  • 547 Reply Likes
True that! I didn't mean to derail the OP question. I just thought that it would be nice if I could use the IP of the Flex radio with the GPSDO as my SNTP server. So I can point Dimension 4 to it or any other software.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
Windows doesn't routinely do actual NTP type time resolution. I used to think so too but nope it gets Windows time which is not terribly accurate. But, to your point Martin, if it is just for the log, yeah, Windows time is close enough as most, if not all, automated logging services have a very generous +/-..I think on the order of 20mins?
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
Sal, you could actually do that...without requiring FRS. Write an NTPD and point windows or Dimension 4 to it and have it simply listen to GPS status messages and pull the utc time off of it to feed your system clock or NTP client. I suspect there are several people on here hacking around with C# that could cannibalize NTPD source to register to the radio asking only for GPS messages and go from there.

(Edited)