Maestro Display

Bernie W7DMC

How about displaying UTC below the MENU button

Wayne VK4ACN

I think that is a great idea

Andrew VK5CV

Either from the net or the GPS if installed.
Andrew VK5CV

[Deleted User]

Another wet dream. . . . It will get added to the feature list for further consideration in the future

Walt - KZ1F

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.

Martin AA6E

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.

EA4GLI

Or at the very least tap on the GPSDO on the radios equipped with it.

Walt - KZ1F

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.

Martin AA6E

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.)

EA4GLI

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.

Walt - KZ1F

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?

Walt - KZ1F

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.