My First Oscilloscope

The Arduino and Raspberry Pi offer a wonderful set of inputs and outputs which will let me really dig in and start to understand electronics and computers in a way I have never been able before. I know that there are continuous signals and voltages and pulsing signals and voltages, and vaguely remember PWM (Pulse Width Modulation) from my ham test – but I am a visual learner – so a scope will no doubt be a great addition to my little “lab”.

I’m also getting a variable power supply.

Well, I really feel like I’m moving fast into my next “chapter” in my hobby. DXCC and DX-ing was great for all those years – as was antenna designing and building, but the combination of hardware / software / firmware has caught my entire attention.

The best news – since I am coding C and Python in conjunction with this Maker world – it firmly aligns with what I do at work.

To Pi or Not to Pi?

The Raspberry Pi with DRV8825 drivers

Nanotec Support Tutorial web page, which I learned about from this excellent tutorial on how to set up steppers on a Raspberry Pi:

Rototron has a great web site with many Python and Raspberry Pi tutorials:

The “existential technical question” I’m having is whether or not to use an Arduino or Raspberry Pi for this project. It will all hinge on what happens with the Elecraft KPOD. Paul, N6HZ is the lead developer and will be helping me troubleshoot why his C code isn’t finding the KPOD on my Raspberry Pi. It seems as though a HIDRAW service or Daemon is not started on Raspian. Regular HID devices are detected, but not HIDRAW.

If we do get it to work, then there is a very compelling reason to go with the Pi – and that is – I can do everything with one board. I really don’t want to even think about having to use the Raspberry Pi just for the KPOD and then have it talk to the Arduino for the stepper control – that is overly complex and a waste of money.

The Raspberry Pi offers the ability to use Python or C – and I can also use it more as a command and control platform than Arduino – which is more like a single “slave” application.

I’ve learned that there is a Python to C interface called boost.Python, so I can call Paul’s C code from Python. This means that the KPOD code just looks like a device driver of sorts.

So, there is a clear decision:

  • Arduino if I end up building my own control box
  • Raspberry Pi if I use the KPOD

I really, really want to use the KPOD since that ends up  taking this project beyond just getting the job done. Imagine if I help Elecraft open their KPOD device to the Maker market? That would be pretty durned awesome! I also love the KPOD and would love to have it as my controller.

I’m doing research on Pi stepper drivers – but I know its all do-able. I’m also starting to think about an oscilloscope. This is all way too much fun!

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.