122GHz Feedhorn machining

Time to turn the CAD design into something physical. Brass rod and my ancient Colchester 1800 and Bridgeport have come up with this as a first try. The barrel adjuster permits positioning the back of the waveguide flush with the inner end of the 8mm cavity, and up to about 6mm inside the reamed 4mm tube. Normal setting will probably be around 1.6mm

Complete horn assembly
Fusion360 model
Small, isn’t it!
Components
Coupler/Diplexer
Horn and 2mm waveguide with threaded barrel
Locknut
Mounting detail

Experimental 122GHz feedhorn

Based on the excellent work being done in Australia with the boards using the SiliconRadar 122GHz chips, I decided to have a go at making a version of their diplexer with a thread and locknut instead of a sliding piston and grubscrew. Also I am using brass. No particular reason other than the fun of making things. I did some initial sketches in Fusion360, and made a few of the locknuts last night, now making some horns to see how they look in real life.

See here http://www.g4dbn.uk/?p=1312 for the first machining attempt.

View of whole assembly
Rear view showing mating face of the PCB diplexer cavity
Semi-transparent view
Horn body with M8 x 0.5 thread and Chaparral style horn choke
Coupler body with internal thread
Rear of coupler body
Locknut 12mm diameter, M8 x 0.5 thread

Notes on Windows 10 Time Service

There are some very useful changes to the available registry entries to control Windows Time Service in recent W10 versions:

  • Slewing during leap-second events
  • Maximum slew rates for corrections
  • Spike detection thresholds
  • Max/min polling intervals
  • Configurable update interval during slews
  • Verbose logging.

I have configured it pretty much the same as I had configured the NTP from Meinberg, with a set of UK-based pool.ntp.org servers, and a minimum poll of 64s and max poll of 1024s.

At initialisation, it does a DNS lookup for the hostnames of configured time servers, returning multiple addresses as expected when I use the 0.uk.pool.ntp.org address (or the 1., 2. or 3. of course).

It then sends a single NTP request to the first address in each of the pools, using NTP version 3.

and gets back a response:

It then polls again after 64 seconds.  Once the dispersion and offset are within limits, it backs off to 128s, then 256s and finally to 1024s between polls.  Only a single request each time.

Initially, the HostPoll value is 64s.

After 20 minutes, it has backed off to 256s between polls

Checking sync with other ntp servers out in the internet, it looks like we are within 10ms, but again that is probably closer than you could verify using a simple request as the network latency is at least twice that.

The slewing controls need some serious verification, as does the spike detection.  For an SNTP server, this isn’t too bad.  It does look as though there isn’t quite the equivalent of the drift file in NTP, but there is a record in the registry showing the current clock rate, which can be offset from the default 156250 and may offer the same drift-control facility (mine is at 156249 at the moment).

In HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config I have:

I have enabled verbose logging, checked the HoldPeriod is set to the default 5 attempts and set the Max and Min poll intervals to 2^10 (1024s) and 2^6 (64s) respectively.

The UpdateInterval only applies where you have configured a Type 1 NTP server, and there is a special update interval setting to match that.  I am using only Type 3 server entries (the default) which says “Dear Server, please feel free to configure my time, but I won’t try to mess with yours”.

In the HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient registry section I have:

SpecialPollInterval isn’t used except with a type 1 server entry.

The key

Blocking the replies from the currently-selected source results in the ValidDataCounter for that source decrementing by one after each update interval.  Despite the update interval being dropped to 16s, the W32Time client process only appears to poll at the rate of the overall application, and it is now 256s, so I have a long wait for it to time out.  It has decremented the reachability to zero and the same for the ValidDataCounter and puit the server intp “Pending” status after about 1000s.  No sign of any DNS lookups since the client first started.  Also (weirdly) no sign of a DNS TTL in the DNS returned by my broadband router, and neither is there any entry in ipconfig /displaydns for the time servers.

After 2400 seconds, the client decided that the server was dead, and it did another DNS lookup for the missing host, and started sending single ntp queries to the new IP address.

I’ll keep an eye on it to see if it remains at this sort of offset. 10 to 20ms is fine for all the hobby digimode stuff I’m doing, but it would be pants for forensics or trading. After a few hours is it running at 5ms ahead of a range of other ntp servers, climbing slowly.  It hit 8ms and the clock value changed and now it is ramping slowly downwards.

So at the moment, this up to date Win10 1903 desktop is running a slightly-more-configurable SNTP with decent audit logging, but not “proper” NTP.  Is there a trick to make it do “proper” NTP like Meinberg does?  I tried making the servers type 0x1, that had no effect.

Also, when a normal human being is asked to make a load of registry changes just to get a useable time facility, the response is usually a bit less positive than “Oooh, great, no problems”.

Can’t say I’m over-keen on putting the necessary keys into a .reg file for distribution, but I guess that is the only way except for reg-hacking geeks.

Meinberg beats this hands-down for simplicity and performance at the moment, and the Meinberg monitoring tool and CLI tools are better. OK, I could run a load of CLI things in Powershell or the Windows Linux subsystem, but it still feels like the usual MS way of reinventing the wheel, late and poorly.

We shall see if the stability and handling of spiked or drifty sources is better or worse than “proper” NTP. 

Dual band POTY Patch for 2.4 and 10GHz on QO-100

This was my first attempt at making a “Patch of the Year” dual-band 2.4GHz circular and 10GHz linear feedhorn.

I used 1.5mm brass sheet and 22mm copper pipe, with a brass adaptor to fit a “Red Rocket” LNB.

The completed patch, using the Red Rocket lens

Clamps for 144MHz EME array

A friend in the Netherlands asked me to make a few bits for his new giant 144MHz EME array

The first batch, sleeves, boom clamps, spigots, boom extensions and collars

Replacement Masthead Rotator adaptor

Mike asked me to make a stronger rotator attachment plate for his telescopic mast. The top section is thick walled GRP with 40mm OD. I made a collar and a central pin to fit inside the tube, and fitted the usual 12mm plate with 119mm PCD 8.4mm holes to fit Yaesu or Kenpro rotators. The collar was put in the freezer and the plate in the oven, then they were aligned and pressed swiftly into position to make a string shrink fitted join.

The completed assembly was fixed in place with gap-filling Loctite.

The completed assembly with original guy ring and stub mast and the internal (invisible) pin
All the things….
Rotator plate top side
Rotator plate underside
Collar and rotator-plate mount. The raised section is 0.03mm oversize for a shrink/press fit
Underside of the collar
HDPE bearing bush with guy plate in place
Stub mast inserted and top half of guy ring bearing fitted
Top side of the collar before drilling the centre hole
Underside of the assembly with guy ring HDPE bearings and retaining ring and centre hole
Complete assembly showing (L-R) stub mast, retaining ring, lower HDPE bearing, Guy ring, upper HDPE bearing, collar and rotator plate
Reinforcing pin to fit inside the GRP mast
Pin in the test stub mast which Mike helpfully sawed off for me to use as a template
Underside with the pin bolted through the rotator plate
The mount in place on top of Mike’;s mast with his Kenpro rotator.