Good afternoon from snowy New Hampshire, USA.

Just getting started with IC706_BKT and so far have not been able to get it to work.

I need an Icom CT-17 or equivalent cable, right?  I have the LCU3-I and OPC-478 cables and they don't work, so I assume I need to get a CT-17 equivalent cable, right?

Second question... how do I get back to the IC-706_BKT configuration page?  When I first started it up it took me to the config page but since then it just takes me to the main page and I can't change the configuration.  I assume there is something I click to take me to the configuration but I don't see it.

The defaults are 19200-8-N-1, RTS and DTR both ON.  Is that the correct configuration to talk to the IC-706MKIIG?

Thanks...

Rick WA1RKT
Londonderry, NH, USA
Catch me on 14.300 MHz Intercon / MMSN most days

Maybe I messed something up, but I installed 1.13.1 and it would not auto start with Windows. I found a reference to the Scheduled Task here on the forum that launches the program (with privilege to avoid UAC) and noticed I did not have this task. I found the .xml task and imported it, but Windows indicated that it was malformed. I uninstalled everything and found my copy of 1.12.2 and it properly installed the task and worked as expected (after the 2-minute delay). I then updated to 1.13.1 and everything is working properly. 

It's possible that my copy of the 1.13.1 installation file is bad, but that seems unlikely. Just thought I would mention this.

Thanks for an excellent program—I use the GPS on my main server in my home and my other machines NTP into it.

By Tom N2YTF:

The Surface Go and many computers like it seem to "hide" their built in GPS units and they are not available as COM ports.  
So for example with my Surface Go I use the Franson GpsGate Splitter (free) https://gpsgate.com/downloads along with the windows api plug in https://support.gpsgate.com/hc/en-us/art...e-Splitter to make the built in GPS available to BktTimeSynch on COM 4.

Un saluto a tutti,
è possibile utilizzare un programma di Log differente da BBLogger ? Se qualcuno ha già provato ed è riuscito con successo può postare la sua esperienza? 
Io attualmente utilizzo Log4OM.
Grazie.

If a memory bank doesn't open, try these solutions:

.Close IC7100BKT
.Open RegEdit (press Windows+R, type RegEdit, and click OK)
.Go to the key: \HKEY_CURRENT_USER\Software\IZ2BKT\IC7100BKT
.Delete the key MemorieX (where X is the memory bank that is not opening, e.g., MemorieB for memory bank B).
.Close RegEdit.

If this doesn't work, try the following:

.Close IC7100BKT
.Navigate to the installation folder (usually C:\IZ2BKT\IC7100BKT Icom CAT Control)
.Delete the file MemX.Dat (where X is the memory bank that is not opening, e.g., MemB.Dat for memory bank B)

If it is not possible to change the band on the Icom IC-7300 when it is connected to IC7300BKT, you need to deactivate polling by clicking on the relevant button.

Hi Mauro,

I have a new mobile and a new problem I can't install Plumble on android 14 because it's not compatible. I tried the official version of Plumble 3.2.0 and also the beta 3.3.0rc1, they won't install. No wonder, version 3.3.0 is from 2015


I installed the Mumla client for android.

After running and configuring Mumble 1.2.12 and Murmur 1.2.12 server contained in BKTRemoteServer.net with IS7000BKT, the sound on the android phone through Mumble works.

After starting BktRemote android 1.6.1 client connects, shows frequency and after seconds calls out on front Mumla client. After switching to BktRemote android 1.6.1 this one is already disconnected.

When setting up BktRemote android 1.6.1 without audio, an Plumble installation request pops up

When setting up BKTRemoteServer.net to GSM audio, BktRemote android 1.6.1 it works but with very bad audio and with dropouts

Can it BktRemote android 1.6.1 be updated to work with the current supported mumble client on android or at least turn off checking for plumble installed if streaming audio on server via mumble is selected?

Well thank you,

Anton OM1AEG

Hello,

I installed BKT73000 but it does not work with bblogger.
In the tools tab, bblogger BKT is not enabled.The duar bridge driver is installed. The CI_V 88H transceiver does not work. 
I stay on the CI_V94h function and it works a little better with some QSO passed in FT8 but not registered by bblogger. 

If you can help me, thank you.

   
   

Is available for download: 

bktTimeSync Version 1.13.3:
- Various improvements

BktTimeSync Version 1.13.2:
- Japanese translation added thanks to JA4JOE

BktTimeSync Version 1.13.1:
- Chinese translation added thanks to BD3OOX
- Added speed of 38400 BAUD for the serial port
- Improved install/uninstall script
- Russian translation added thanks to R6DOP

BktTimeSync Version 1.13.0:
- Adding Support for old GPS devices that do not support the new date format.
- Improved synchronization
- Various enhancements

I've searched the form posts but have not found my situation for reference. Please accept my apologies if I missed a relevant thread.

I am currently running BkTtimeSync version 1.11.3 on a Windows 10 PC to create a NTP time server for a private network unconnected to the Internet using a GPS receiver. The Windows 10 PC is a users desktop machine running multiple Putty sessions to connect to a UNIX application. The Users PC is left on 24 hours and not shut down unless the BktTimeSync is having trouble. The Windows power plan is set to "always on" and the PC does not enter sleep or suspend  modes.  The power plan on the SSD system disk is "always on"  as the SSD is not a spinning disk.

BktTimeSync.exe gets time from the GPS receiver and sets the Windows 10 PC clock. I use Meinberg NTP 4.2.8  to share the pc clock time to the network using NTP with the PC's configured IPv4 address of 192.168.10.44.

I see that BktTimeSync Version 1.12.1 is available.  But before I install the 1.12.1 version I want to run the setting I am using and the observed results by the form to see if anyone has experienced the same issue and successfully resolved it with a configuration change or software update.  The problem I describe below may be caused by a simple misunderstanding of the configuration options.

I have attached the developed settings I use for BktTimeSync:
   

The configuration has proven unreliable and I suggested to the PC user to reboot the Windows 10 PC on Friday of each week before leaving the office.

I have two issues demonstrated in the BktTimeSyncLog.txt fragments below,  BktTimeSync successfully sets the PC's clock from 00:00 to 17:59 each day (or from the time the Windows PC is rebooted during the day) and then at 18:00 experiences  "The time difference is greater than the specified maximum correction, NOT synchronized clock." This repeats on a daily basis.  Although the configuration is set to check/set the time every five minutes (and does this when successful) once BktTimeSync decides that the difference is greater then the maximum correction, it tries once every 60 seconds thereafter until the change over from 23:59 to 00:00 and then without human intervention once again sets the PC's clock.

BktTimeSyncLog.txt:

Last Sync :Monday, November 13, 2023 17:53:01 --> Local clock offset was 0.00400 seconds
Last Sync :Monday, November 13, 2023 17:58:01 --> Local clock offset was 0.00300 seconds
Last Sync :Monday, November 13, 2023 18:03:01 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
Last Sync :Monday, November 13, 2023 18:04:01 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
Last Sync :Monday, November 13, 2023 18:05:01 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
Last Sync :Monday, November 13, 2023 18:06:01 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
...
Last Sync :Monday, November 13, 2023 23:58:00 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
Last Sync :Monday, November 13, 2023 23:59:01 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
Last Sync :Tuesday, November 14, 2023 00:00:00 --> Local clock offset was -0.313000 seconds
Last Sync :Tuesday, November 14, 2023 00:00:01 --> Local clock offset was -0.001000 seconds
Last Sync :Tuesday, November 14, 2023 00:05:00 --> Local clock offset was 0.018000 seconds
Last Sync :Tuesday, November 14, 2023 00:10:01 --> Local clock offset was 0.009000 seconds
...
Last Sync :Tuesday, November 14, 2023 17:50:01 --> Local clock offset was 0.009000 seconds
Last Sync :Tuesday, November 14, 2023 17:55:01 --> Local clock offset was 0.00600 seconds
Last Sync :Tuesday, November 14, 2023 18:00:01 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
Last Sync :Tuesday, November 14, 2023 18:01:01 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
Last Sync :Tuesday, November 14, 2023 18:02:01 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
Last Sync :Tuesday, November 14, 2023 18:03:01 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
...
Last Sync :Tuesday, November 14, 2023 23:58:01 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
Last Sync :Tuesday, November 14, 2023 23:59:00 --> The time difference is greater than the specified maximum correction, NOT synchronized clock
Last Sync :Wednesday, November 15, 2023 00:00:01 --> Local clock offset was -0.22000 seconds
Last Sync :Wednesday, November 15, 2023 00:00:01 --> Local clock offset was 0.05500 seconds
Last Sync :Wednesday, November 15, 2023 00:05:01 --> Local clock offset was 0.07700 seconds
Last Sync :Wednesday, November 15, 2023 00:10:01 --> Local clock offset was -0.00000 seconds
...
Last Sync :Wednesday, November 15, 2023 10:58:01 --> Local clock offset was -0.00000 seconds
Last Sync :Wednesday, November 15, 2023 11:03:00 --> Local clock offset was 0.08800 seconds
Last Sync :Wednesday, November 15, 2023 11:08:01 --> Local clock offset was -0.02000 seconds <-- Last Log entry as found on 11/28

Final question: Does BktTimeSync have any setting to automatically limit the size of the BktTimeSyncLog.txt file?  The 1.11.3 version I installed in March 2023 created a large log file discovered when I responded to the Client's office on 11/28 (copied it to the UNIX server as it was too large to open with notepad or word pad):

-rwxr--r-- 1 root  sys  1268745653 Nov 15 11:08 BktTimeSyncLog.txt
# wc -l BktTimeSyncLog.txt
17,622,312 BktTimeSyncLog.txt  (comma's added for readability)

The BktTimeSync control panel shown above would not respond to "Sync Now" button click  when I tried to use it on 11/28 before shutting down BktTimeSync, changing the log file and rebooting the Windows 10  PC  (log file too large?).

The last displayed line was in the BktTimeSync control panel was:
Last Sync: Wednesday, November 15,  2023 11:08:01
Time was successfully synchronized using GPS receiver
local clock offset was -0.002000 seconds

Any suggestions on how to resolve the problems identified above or recommended changes to the sync check interval (10 minutes, 30 minutes 60 minutes?) is  eagerly anticipated.

TIA