Bad Case of the DTs

Fear not, dear reader - I haven't given up the sauce. I am not in withdrawal, suffering severe autonomic instability. I refer not to Delirium Tremens, but to time differences, dt. Specifically to the "DT" data column in the WSPR GUI...

Everything was going FB with the multi-mode beacon and its new internal DDS until Thursday, when I started to notice large (and apparently random) timing errors. You can see the fall-off in performance on Thursday in this plot of the number of spots in each 24 hour period over the past two weeks...

The time errors "DT" were accumulating at an alarming rate, suggesting an impossible variation in my beacon controller's fundamental clock frequency.

Eventually I discovered it was caused by some kind of interaction between the new Controller board and DDS and the main VXO system. The interaction was either conducted through ground, power lines or interface lines or through radiation from clocks, RF sources etc... Whatever the cause, simply un-plugging the controller (and reverting to the SDR Kits USB synth) has cleared up the jitters for the moment.

All of which gives me time to address the issue of providing an interface between me and the Beacon Controller system. Remember - I needed some switches...

I had so much fun with building the DDS board in surface mount technology that I decided to stick in the nano scale and got some tiny tactile momentary action switches from Farnell (seen here against a PIC 16F873 for scale)...

Here's the schematic of my keypad...

...a conventional layout in which columns of switches are sequentially pulled low by pull-down transistors (in this case MMBT3904s - the surface-mount version of my beloved 2n3904) and read in "rows". I arranged two columns of three switches - four "arrow" keys to navigate up/down, left/right and two (as yet) un-designated switches.

The "arrow" keys are seen at the right-hand-side of the finished "Keypad" board...

That was the easy bit - now to code the PIC!

The actual software interface to the keypad is simple enough - the only real issue being the optimisation of the delays and rules for switch de-bouncing. I tested for two consecutive valid "reads" of the same key, separated by a small delay and then imposed another delay before looking for another key push. However, reading the state of a key and getting that state to do something useful are two very different things - especially in assembly language!

I have implemented a menu structure, in which the left/right keys are used to navigate from the "standard" operating configuration ("Menu 0") to a umber of other menu "pages". Each page has a (programmable) number of options, which are selected using the up/down keys (including a Boolean "On/Off" option if required)...


Here's a (bad) photo of the display telling me where I am...

The banner "Menu 1" is just a text string, such that I easily can replace it with something more descriptive...

Whilst I haven't yet finally decided what to do with the controller, the outline plans are for...

Menu	Name	# Options	Function
1	dF	~10	nudge freq up/down to avoid QRM
2	Band	4	Change Band (30m, 40m, ??)
3	Frequency Hop	On/Off	cycle through a defined band

That's all development effort (i.e. tedious coding) for the future - for now I must return to the job of fixing the timing errors inside the beacon. Some screening and some (more) power supply de-coupling will be the first ports of call.

...-.- de m0xpd

---

Post Script

Once again Google kindly has arranged for the image upload feature of Blogger not to work early on a Sunday morning when I want to post. He might not be watching me, but Big Brother is certainly deciding when I'm allowed to make my diary entries.

I did "try again in 30 seconds" - several times but to no avail. However, as you see, it worked fine when I came back at 09:15 local, by which time the servers had woken from their slumbers (but I still can't change the colour of the "Post Script" heading - What You See Is NOT What You Get).