Happy DeNogginizer!

Drake’s Brewing in Oakland is in an old car dealership on Broadway, which was called Auto Row.

They did a great job with this cool old place, and I had a Covfefe Double IPA, followed by an unfiltered IPA they call “Foraging Racoon”. Kat had the Saison, a very well done Belgian style beer, and the pizza was just phenomenal.

We rode our bikes to Orinda BART, then Rockridge, rode to Piedmont then 23rd and Broadway, where Drake’s is. We came back via 19th Street BART.

Nice way to avoid politics but still celebrate the good left in this country.

KY6R “Hackaday” and New Ideas for the BT1500A Remote Controller


We are very lucky to have the Computer History Museum in Mountain View, CA, and Kat and I were especially lucky to have attended a demonstration by the developers of “Space Wars” on the PDP-1. The most interesting thing is that my first job out of college was at Kodak in Rochester, NY, and I was an Octal Assembler programmer on PDP-11. After I started and found out that I wasn’t going to code in COBOL or Fortran – which I fully expected, I asked “Why did you choose me for this partiular role?” and they said “Because you are a Ham Radio Operator” and are more technical than the other college candidates. Turns out I didn’t care much for the job, but fast forward 36 years later – and I am getting a little bit closer to the machine and hardware than I was then. And the Arduino and Raspberry Pi are the things that are facilitating this! I will say Thank God for C and Python – they are SOOOOO much better than hacking Octal Assembler.

I am now officially in the mode of doing a “Hack A Day”. I swear, this is more fun than chasing DXCC!

Anyway, I have a new set of thoughts in my evolution toward building the KPOD – BT1500A Arduino based controller:

The KPOD would be powered by a USB port on my Laptop. My laptop would need to connect to the Arduino just long enough to program it (flash programs in memory). The KPOD talks to the K3 via an RJ-45 “radio” port, and I’m trying to better understand if that port is basically the same as a USB port – since the Elecraft C program that I have is run as a “HIDRAW” device – then its got two ports – one is that it is a USB device and the other – this RJ-45 that is specific to the K3. There is a third port – the Aux port. I’m betting that these ports will offer something I can use, but that I will have to incorporate what is almost a device driver as well as the bridge program that takes the KPOD as input and sends this to the Arduino in the same very basic way that my switches to in my “emulator” that I got up and running in yesterdays post.

Anyway, this configuration puts the driver boards and the steppers out with the BT1500A. I would definitely bypass the relay so that I wouldn’t have to keep the 12v power on the drivers all the time. I would turn the 12v line on, tune the two control knobs on the BT1500A, then turn it off.

The Arduino would go inside my little black control box, and it would only be wired so that the KPOD plugs into it. Then, the output 7 wires to the remote steppers and stepper drivers are made at that control box.

I think I will get rid of the WiFi idea and go wired. The cable is already run, and it just keeps this project a lot simpler. If for whatever reason I can’t get the KPOD to work – my fall back is to build my own controls using a prototype Arduino shield, and I will still split the system the way you see in the diagram above, the only difference is that there would be no KPOD.

But for both the “cool factor” as well as the ergonomics of the system, the KPOD controller is well worth the effort – WiFi just doesn’t do anything but make this more complex than it needs to be. It also doesn’t fit with how I am breaking the components up – with no Arduino out at the tuner, WiFi is a moot point,

The big benefit is that I can avoid using both the Raspberry Pi and Arduino and just go with an Arduino. I think I like dreaming up ideas the most – implementing them is fun too – but the initial seed ideas are what really excite me.

Less is most definitely more . . . lets call it more “elegant” . . .

The Eagle Has Landed!

If all I did was add two SPST push button switches and one DPDT switch to my little control box:

I would have all I need for the project. The software can set the speed and the travel of the stepper motors to something slow, safe and reasonable. I think the only thing I need to make sure is that the stepper on the inductor control doesn’t hit the stops hard. Since the capacitor can turn 360 degrees, there is no issue there.

Top View of a simple BT1500A in shack controller. If I were to just use wires out to the tuner from this box, I would exceed the number of control wires in the 8 conductor rotor cable that I have because I would need these wires:

  • Positive 12 volts
  • Negative
  • 6 wires for the L / C selector
  • 4 wires for the two SPST (CCW and CW) switches

HOWEVER, it would be possible to put just the stepper motors and their drivers out in the tuner box and keep the Arduino and switching logic in the shack. The reason – the 12V positive and negative already are out there, and it only takes 2 wires to switch between one or the other stepper driver.

All of this came from this web site:


Examples 1.6 and 4 – sort of combined, and just a very minor code tweak. But pretty much “straight out of the box”!

I circled in Orange the three wires per stepper controller I need. These two wires plus ground send the PWM signals to the stepper. Two wires are already taken for the 12 volt power to drive the steppers and turn on the BT1500A relay, so this means there would only be 2 wires required in addition for each stepper driver. This is the control lines from the Arduino to the stepper driver. So in total:

  • 12v positive
  • 12v negative
  • 5v negative
  • 2 wires for each driver

Which means I get away with 7 wires. There’s an issue though – while the tuner wants the relay switched on with 12v – the stepper motor driver boards get warm when you have 12v applied continuously. One thought is to wire a bypass to the relay that needs to be activated to switch, and then the 12v line will only be on long enough to turn the steppers and then it gets turned off. That should be easy – but I will have to mod the BT1500A. I would do that when I also have to figure out what kind of supporting motor “rail” that will be bolted onto the tuner for the controls. I also need to order some shaft couplers for the steppers to the L and C shafts.

The big benefit of splitting the system at the driver board is simplicity and fewer components out in the heat and cold. It also means I could change the control code any time I want since the Arduino would be in the shack.

Using the KPOD via wireless is the “advanced” version of this, and I still want to do it, but what is pretty cool is that I could actually get away with something already – that is as about as simple as you can get. In fact, I could keep it really simple and not go wireless and just try to figure out how to plug the KPOD directly into the Arduino board, even if this means a modification of the KPOD – but I am trying to avoid any modifications of any part of this system – I’d love to make this an “Open Source” project in the “Maker Mode” which is to treat all components as “plug and play commodities” and that the biggest variable is the code itself. Speaking of that – this most simple version of this project – the code is ridiculously simple:

#define DISTANCE 10

int StepCounter = 0;
int Stepping = false;

void setup() {
  pinMode(8, OUTPUT);
  pinMode(9, OUTPUT);
  digitalWrite(8, LOW);
  digitalWrite(9, LOW);

  pinMode(2, INPUT);
  pinMode(3, INPUT);

void loop() {
  if (digitalRead(3) == LOW && Stepping == false)
    digitalWrite(8, LOW);
    Stepping = true;
  if (digitalRead(2) == LOW && Stepping == false)
    digitalWrite(8, HIGH);
    Stepping = true;

  if (Stepping == true)
    digitalWrite(9, HIGH);
    digitalWrite(9, LOW);

    StepCounter = StepCounter + 1;

    if (StepCounter == DISTANCE)
      StepCounter = 0;
      Stepping = false;

Again, all of this came from Brian Schmalz of Schmalzhaus.

Summer Rides

The pedestrian / bike bridge over Treat Blvd in Pleasant Hill

Kat and I rode to Danville and back from the Pleasant Hill BART station. We had a great lunch at the Danville Brewing Company brew pub. The deal I made was that I have to pedal for my beer. Fair enough!

The Euryops in their full summer glory.

Hello Stepper!

YAHOO! I am now on my way. Its so easy to wire up these components, download some code, flash the memory with the code and start the engines!

The Maker Community is amazing – in fact, half of the battle is trying to decide which of many possible solutions would be best for your particular “use case”.

All I can say Ham Radio Operators, THIS is the future for sure. I’m actually already late to the game, but if you ever felt “regular” ham radio or DXCC or DX-ing was getting stale – here’s the way to re-invigorate that which got you excited about the hobby in the first place.

Think about it – I could keep posting how I haven’t worked any ATNO’s in a year, or prepare for the days when DX will again appear on the low bands!

KPOD to BT1500A Block Diagram

The KY6R “maker area” in the shack. The radio part of the shack is to the left.

I was able to get a C program that the lead KPOD developer from Elecraft sent me to compile and run on the Raspberry Pi. I learned what a “HID” device is – Human Interface Device, and that the KPOD is not a standard HID (like a Mouse or Keyboard is), but is a HIDRAW device – HID and RAW, the RAW meaning “direct” for Linux. Here is a good explanation:


The compiled program runs as root but while it seems to spit out some identifiers, it can’t find the KPOD. I will consult with the developer, and I am sure there is a simple fix for this. I’ve read the code enough to have a good basic understanding of what it does – and luckily its C – which is something I have coded enough to be very comfortable with.

What I did learn from this is that I will most certainly need Raspberry Pi on the KPOD side, and Arduino on the BT1500A side. The KPOD needs a proper Operating System, the BT1500A is a “slave” and doesn’t need an OS.

So – later today (after a bike ride) I will get the Arduino and stepper motors spinning – most likely following something like this:

And the fellow who posted this has a very nice web site:


I found one other web site that shows how I could emulate having the KPOD working – its almost exactly what I need:


In fact, the only difference is that where he has a joystick, I will have a KPOD which forces me into a client – server architecture. In fact, to get this all set up with just the Arduino part, I’ll just use an Adafruit rotary encoder instead of the joystick he has. In fact, he also has a little control box with buttons so he can switch between motors – so it is exactly what I need.

I’m still highly motivated to use the KPOD because of its expandability beyond what it can control. Maybe eventually, the Function buttons will change bands on a wireless remote antenna switch (?) We shall see. I need to walk before I can run . . .

But as a fall back – I could just run with this design as well. In fact, I could even just use my laptop and the control “unit” could be software with a couple sliders on a screen. The BEST part of this project is that its a journey as I am learning – which is what makes it so much fun. It used to be to avoid becoming a total “DXCC Zombie” I worked on antennas – now that that phase is done – this Maker stuff is rapidly taking over – its highly addictive.

I’m going to come back to the Raspberry Pi and KPOD later (after I get help figuring out why its not being found), and will spend the rest of this 4th of July weekend emulating the BT1500A tuner and Arduino “slave” part of what is essentially a “client server”, or more like a “master – slave” system.


VOACAP Online Now Does P2P Greyline Mapping!

Jari, OH6BG, has been constantly improving VOACAP Online, and it is now my favorite Propagation Prediction Tool. I have noticed that over the past year or so many new features have been added – such as specific station information – which makes it more accurate. I also really love the new ability to get the checkerboard prediction charts by month or year. But he has now added something that really helps me quite a bit, and that is detailed grey line time information as well as a map, as you see above. You know from my propagation studies, I am constantly switching between propagation software (and I use VOACAP Online mostly these days because I love the “data visualization” it offers) and DX Atlas. But that was pretty good, but Jari has upped the ante with this:

This is a very accurate chart of grey line, and includes not only the three types of grey line twilight (civil, nautical and astronomical), but also shows dawn and dusk at each end point in the radio circuit.

This is absolutely critical for Top Band, and is also very important for all low bands. But on Top Band – perhaps the band least understood propagation wise – since VOACAP does not predict it (and is a bit weak on several of the low bands), this new feature fills in the gap very nicely.

When I worked FT5ZM and VK0EK on Top Band, the timing was absolutely critical. You really had to know when to strike – otherwise you might miss a 10 minute or even 5 minute or less opening!

It isn’t quite this tricky on the higher bands, but I very clearly remember VU7RG and ZS8M both being greyline ATNO’s and both on 40M – at dusk – and VU7RG happened during the “set” time, and ZS8M happened on the “dusk” time. Now – here is the real “kicker” – when you look at the difference between pre and set and then set and dusk for mid October 2017, you will see that it lasts 20 minutes. That is EXACTLY how long my VU7RG and ZS8M openings were. These were not the only times I have experienced this, and it happens on all of the low bands.

One of the funny things I always see is a DX Cluster spot where someone is “asking” the DX-pedition to come on a band – like 160, 80 or 40M when its mid day at the DX-pedition location. This new feature would be great as an education tool.

In fact, I like it so much, I will say that once you get really expperienced at DX-ing, this might be THE most important skill. I do not have the best QTH or antennas. They are respectable but I am no big gun. HOWEVER, I beat everyone to several ultra rare DX-peditions because I could really guess what band they would start on based on grey line.

This my favorite data visualization for a year long prediction. It is crisp and very easy to understand. I’m looking at only the last three months of the year since that is the quarter closest to when 3Y0Z will be on the air. I can also look ahead to January, 2018:

No matter how you slice it, conditions for Bouvet look better than I had expected given conditions as they have been the last few months or so. I have a theory that the month leading up to summer solstice and then after is usually crummy – at least on the low bands. This makes a lot of sense – because the grey line and even the night time duration is so much shorter than during the winter.

HOWEVER – you also need to look at what is going on in the DX QTH’s part of the world – be they in the northern, southern or equatorial regions.

The new VOACAP Online gives you EVERYTHING you need now – from 160M all the way up through 10M.

Fantastic job Jari – you just made all of us low banders very happy!