Top Band Shows Signs of New Life

The new greyline feature in VOACAP Online is superb – its shows the multiple twilights which are very important when DX-ing on Top Band. In fact, I used to have to look at DX Atlas and then go to a web site called “Sunrise – Sunset” to get some of this information, but it was a real pain and wasn’t as instantly useful as VOACAP Online is now. For example, we will lose about 30 minutes of daylight in July – which is a main reason why Top Banders like getting past Summer Solstice (heh heh):

Sunrise-Sunset is very simple and doesn’t break it down like VOACAP Online does.

Conditions sounded better this morning – and I heard LU5OM and AA1K very workable on top band. It seems like its been a while.

There was lightning, and some crashes were pretty big, but only once maybe every 10 minutes.

I was surprised I could hear AA1K so well – but I was using the K3’s Diversity receive function and I had the Wellbrook ALA1530LNP Loop on one receiver, and I switched between the DXE DV-40-P and the Mod Bob for the second antenna. Both would have been workable, and as you can see from the map above, being in the right part of the grey line is critical on top band. In fact, as I write this, we are getting a nice enhancement with LU5OM, and here is what the map looks like now:

You can see that we were right in the middle of Nautical Twilight. I will start watching this map when I listen to stations on Top Band and see what the correlation between which “phases of twilight” we are in when the enhancement happens. I expect that this will be different depending on time of year and where each station is on the map.

The real point of a propagation forecast is not to take them as 100% truth, but to help us better understand propagation just by thinking a bit about what is happening and how that might affect us. VOACAP Online isn’t predicting on Top Band – but is educating, which is far more important because this is how you develop DX-ing “tricks” that help you get in the log.

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.