After cleaning the synthesizer inside and out, I replaced multiple screws that were missing from the internal metal frame, and bolted down the power supply, which was obviously replaced in the past (without putting it back in properly). Despite the TLC, the reset issue continues.
While I am quite sure the caps in the PS need replacing, I took the +5 regulator out of the equation by supplying it with my bench power supply, so the input to that regulator is now rock solid (per scope measurement) That hasn’t impacted the reset problem. Other power supplies are still questionable, like the -8 VDC unregulated supply which has a low frequency ripple on it that is about 1 Vpp.
The Controller card in the 3335A is quite old, obviously (the design dates to 1976). It is based on a Motorola 6800 CPU (privately labeled for HP at the time). Since resetting was the issue, I dug into the service manual and schematic, to discover that there is a power-on reset circuit on the card intended to hold the CPU in reset until the power supplied have stabilized long enough for the processor to start executing code. It is based on a 74LS123 multivibrator and a opamp used as a voltage detector (driven from +5 regulated and -8 unregulated supplies). The schematic is shown below:
The Q’ (the ‘ means NOT, as in Q-not) output of U12B above is the RESET’ signal that goes to the CPU on the controller card and (HORRORS) travels unbuffered off the card through multiple feet of unshielded cables to the HP-IB card on the rear of the instrument. (ED: Whoever designed the Controller card for HP back in 1976 certainly wasn’t well informed as to noise issues with NMOS inputs — a fact attested to by the layout as well.) U21 forms a voltage detector circuit which presents a ‘0’ to the B input of U12B when the voltage is stable. The other half of U12A is fed from a 2 MHz off-card source and is used to guarantee that the RESET’ signal meets the minimum low time for a valid reset.
The good news is that by pulling the B input of U12B low the reset issue goes away. So it isn’t noise on the RESET’ line itself, but is coming from the valid power detector. The root cause is either noise on the +5 regulated supply or the -8 unregulated supply. Replacing the ancient Caps (about $150 worth) should resolve the issue.
I’ve always been sort of a time nut, but that’s pretty closely related to frequency. The ARRL helps to sponsor a periodic Frequency Measurement Test, usually held in April and November. A good friend of mine, John WA1ABI, always participates and usually has outstanding accuracy. I’ve always been fascinated by that, so I went looking for some surplus gear.
My plan was to us a milliHertz resolution frequency synthesizer to generate a carrier of known frequency that was manually adjusted to be within a few hundred Hertz below the unknown signal. A RX in AM mode would produce a heterodyne audio beat note equal to the frequency difference. Add the audio frequency to the known frequency and the unknown will be revealed.
I put my sites on a HP 3335A signal generator. This is a massive beast that is about 40 years old (would have been new when I started my first engineering job in the late 1970s). They are fairly common on eBay, and can be found in various states of disrepair. I happened to locate one locally from someone who had worked on closing a capacitor factory in Massachusetts. The good news was it was inexpensive. The bad news it was sort of working and absolutely filthy.
After several hours of scrubbing the covers, they now are no longer sticky to the touch and dirty, but they show 40 years worth of wear and tear. The unit powers up and generates a fantastically stable/repeatable signal (the internal 10 MHz source, once warmed up for an hour, is within 44 milliHertz of spot on — that’s 4.4 parts per BILLION). It is pretty amazing to be able to change any of the 10 digits by one and see that exact change show up in the output.
But there is a significant problem. The unit randomly resets itself every 30 – 300 seconds. At that point the frequency is reset to 1.0 MHz, and the output level drops down below -80 dBm. The reference oscillator remains running, and within a fraction of a second of entering the frequency and amplitude via the keypad, it is up and running again.
After going through the service manual and schematics, it appears the only reason this would happen is if there were a voltage issue with the internal 5 volt supply. That could cause the 6800 CPU to reset. The 3335A never really powers off fully. The unregulated supplies are always on as long as the power cord is plugged in. It is highly likely that 40 years of this has fried the large power supply caps, and that would make the 5 volt supply unstable. We shall see!
Posted in FMT, Gear, Testing
Many other projects (like teaching another set of Technician’s) reduce the amount of time I have on air, but DX progress continues slowly. My confirmed country count hasn’t changed (262), but the DX Challenge count has creeped up to 1250. No endorsement until 1500, which may be years away at this rate
The Annobon Island DXpedition has been racking up QSOs. I finally got a chance to listen to their 160 meter signal tonight and it’s outstanding here in RI. Haven’t broken through the pileup yet.
While I am sure I’ve had many more QSOs (I’ve got many old written logbooks from 1970-2000), I didn’t start using LotW until I got back on the air in February of 2011.
Today I entered my 7,000th QSO into LotW. It was with Mill, LX1CC, in Luxembourg. No special prize, and I don’t know why 7,000 feels different from 6,999 or 7,001, but it seemed worth marking.
A massive solar flare struck the earth today, a X-class 9.3. This is the largest flare of Solar Cycle 24 by far. It does have an Earth-directed CME that will be following on the heels of an earlier M-class flare/CME.
Image at peak absorption near the US about 7 hours later
The absorption at the time of this posting is worse:
Version 22.214.171.1243 (Dec 2016) of HRD predates the WSJT-X “FT8” mode. If you use the latest version of JTAlert (2.10.1), it has added back in HRD version 6.3+ logging support (but only temporarily, according to the author). That’s great, but you need to make a change to the HRD Logging program to support FT8. If you don’t it will log the contact as “FM” (the closest thing alphabetically).
Open the logging program and select “Tools/Configure/Modes”. Click “ADD” on the “Modes Editor” window that pops up, then populate Mode/ADIF/Comment for FT8 as follows:
After making that change, FT8 will show up at the end of the list of available modes, and it will automatically be selected when you use JTAlert to log a contact.
NOTE: LotW doesn’t support FT8 yet, explicitly, converting it to a generic “Digital” mode. The ADIF.org group has added FT8 to version 3.0.6 of the spec, so the change in LotW will happen soon.
I’ve been bouncing between my Windows PC and a Macbook Pro as I am writing the code for the Feather NTP Clock. (Gotta love BitBucket and TortoiseHG which provide me with the latest source code wherever I am).
While it isn’t unique to the Adafruit Feather, I’ve been having frequent OS X Kernel Panics — the Mac equivalent of a Blue Screen of Death — when using the Arduino IDE with the Feather connected via USB. The Macbook always recovers but the reboot process is about a minute long.
There is lots of online stuff, mostly rumors of fixes like loading signed drivers for the Chinese CH340 USB chip, which isn’t used by the Feather at all. Sadly, none of the online suggestions works.
What DOES work, is using a USB Hub. In my case it was a DLINK Powered USB 2.0 hub, but I suspect that any hub would be adequate, because the Powerbook USB connection is no longer direct to the Arduino device.
NOTE: Using a hub will certainly change the OS X detected port, so make sure to get the correct port selected in the IDE.
While my obsession with accurate time continues, these days my obsession with avoiding the hassle of resetting clocks on DST/STD changeover and power failures grows.
My original NTP Clock, based on the Raspberry Pi worked just fine, but it really didn’t like power failures, which sometime trashed the SD card, plus it was about $75 or so per clock.
The Adafruit Feather M0 WiFi board has caught my attention. It’s darned tiny, and very power stingy. Add a FeatherWing OLED board, and you’ve got the hardware required for a tiny (2.1″x0.8″) NTP Clock that costs about $50.
Adafruit Feather M0 WiFi with FeatherWing OLED Display
After messing with HRD & QSO Relay, I determined that inability to support FT8 with older HRD versions was a show stopper for me.
I decided to use ACL, which was fully supporting FT8 and simply gather my digital FT8/JT9/JT65 contacts in that log until such time that LotW accepts the FT8 mode.
My first snag was in creating a ADIF file for export from HRD. In the default display order, where newer contacts appear at the top of the screen, the order of the ADIF file is reversed (leading to the higher numerical entry number being the oldest log entry. So I simply reversed the display order (clicking on the date column), and exported that file.
Importing that into ACL went fine, but ACL doesn’t keep track of any confirmation data during that sort of import. That meant that every FT8/JT9/JT65 station was needed. The fix for that situation was to download my entire LotW log, a process that took about 15 minutes to complete. That corrected things, so I was able to scan the log and now had proper “need” data shown in JTAlert
Finally, so that JTAlert can put log entries into ACL, the Settings/Application Program Interface Enabled Checkbox must be set
Posted in FT8, JT65, JT9, LotW