Friday, March 31, 2023

Free windows software - read the fine print!

A ham radio friend who runs windows and is using various digital chat modes recommended some software that takes dictation and enters it in to a text field. He said "it's free".

I took a quick look at LilySpeech and noticed the little asterisk next to FREE*. When I drilled in to see what that was about I was amazed.

"The free version of LilySpeech is made possible by doing market research in the background. While there are many examples of what this might entail, the most common example would be a business looking to measure their visibility in search engines such as Google, Bing or Yahoo.

As a practical example, a national insurance company may wish to know where they come up in Google when you search for ‘auto insurance’ within the city of Seattle, or Chicago, or Dallas, etc.

As a LilySpeech user with a unique location and profile, you can provide insight to these companies that nobody else can.

These activities use a dedicated browser meaning no history from these activities will appear in your history or browsing activity. These activities are completely invisible meaning you will never be interrupted or inconvenienced.

Examples of the types of marketing activity that may occur include but are not limited to:

Checking and verifying websites positions in search engines for different search terms

  • Ad placement verification
  • Competition price checking
  • Website uptime monitoring

At no point will any market research be performed in the background that relates to the following industries:

  • Adult entertainment
  • Gambling
  • Pharmaceutical products
  • Any other gray/illegal market

At no point will any of these activities be malicious in intent or violate local, state, or federal law."

Wow. I've got to credit their honesty but they are basically turning your Windows computer into a bot to be used by third parties. This is new to me but perhaps it is done by other "free" software as well?

Wednesday, March 29, 2023

Minimal transceiver with Hellschreiber interface

Some years ago Stephen, VK2BLQ, and I experimented with using low cost CW transceivers and the Hellschreiber mode. This mode works with simple transceivers as it is simply keyed on and off.

Having moved house several times since then I had to re-build the interface. I think this version is neater. FlDigi keys a hellschreiber transmitter by keying a tone on and off and to key the transmitter an interface needs to rectify this audio and activate a transistor. 

I've just had a contact with Richard, VK3LRJ:


He's using an IC-7300 at his end but my side is simpler:


The transceiver, lower left, is a micro mountaineer kit, from an original design by W7ZOI. It's a step up from the Pixie kits and the receiver works much better than on them. There's no keyer to get around so it's well suited to use with Hellschreiber. Here's the interface board:


At first I used silicon diodes but found the audio level was too low. Substituting germanium diodes works better but is even a bit too sensitive so I have to reduce the audio level a bit. Here is the circuit I ended up with:


The 8R:1K audio transformer was purchased at Jaycar.

Thursday, March 16, 2023

Bush 40 transceiver

Inspired by the VK3YE Beach 40, I have constructed the "Bush 40" which is a version tailored to The Australian outback. (Just kidding).


It is a direct conversion receiver and double sideband transmitter. I've replaced the VXO with a very simple, three component, VFO.

I'm joking a bit here too, it has an Arduino Nano, an Si5351 board, and a rotary encoder. On boot up it starts at 7.1MHz and you can tune up and down from there.

The mic amp, mixer, rf power stages and low pass filter are as per the Beach 40.

The receive audio stages are from the Soldersmoke High School DC receiver

Overall, this is a minimal design and the door is open to many improvements.




As you can see, it's a gadget of great beauty. At this stage the receiver is working but is quite deaf - I'll keep working on this.

Notes for future builds:

  • Use a larger baseboard so there's plenty of space for access to the boards
  • Always put a reverse diode on the relay coil - I killed an Arduino Nano presumably from inductive spikes on the power line.
  • Don't try to drive a mixer directly from an Si5351. (I was puzzled about why the balanced mixer was so far off balance when I switched from the VXO to Si5351, the reason is that the output RF is 0-3.3V not AC) A 0.1uF capacitor fixed this.
  • Building modules on their own boards for easy debugging is the way to go. Also, this means the successful stages can be re-used easily.
My thanks to many people including Bill, Paul, & Stephen for suggestions.

Friday, March 10, 2023

Minimal Si5351 VFO for Bush 40 DSB Transceiver

Recently I've been going a bit "old school" and built the Soldersmoke Direct Conversion receiver with its PTO VFO and another VK3YE Beach 40 DSB transceiver with a ceramic resonator based VFO (it can be slightly pulled).

I was thinking about a minimum VFO configuration using just an Arduino Nano, a rotary encoder and an Si5351. If you count a Nano as a single component you could argue that this is a three component VFO.

My implementation boots up on 7.1Mhz and can be tuned up and down with the rotary encoder. There's no display (although that can be easily added) but a frequency counter could be added. 

The wiring is like this circuit on the Arduino project hub but I haven't added the display.

Power enters through the VIN pin on the Nano which can take voltages up to 16V (I'm running 12V) and regulates down to 5V and 3.3V which I feed to the Si5351.

I prototyped this on a breadboard first:


Next I built the same circuit on matrix board with simple point to point wiring. Here it is driving the mixer on the Beach 40.


It's a very compact and usable VFO. I have a few ideas about some extra features such as stopping at band edges and maybe lighting an LED when you hit the band edge.

Observant readers will spot my LEDs on the boards and power wiring - I've been bitten by being buzzed about why things weren't working when the fault of in the power line. Adding a few LED power indicators makes it clear.

Here's my simple source code for this VFO (blogger messes code up so use the link to the Gist):

/*
Simple VFO for a direct conversion receiver.


Si5351 controlled by a rotary encoder.
Based on code from Paul, VK3HN
https://github.com/prt459/Arduino_si5351_VFO_Controller_Keyer


*/
const unsigned long int FREQ_DEFAULT = 7100000ULL;

#define ENCODER_A 3 // DT
#define ENCODER_B 2 // CLK


#include <RotaryEncoder.h> // by Maattias Hertel http://www.mathertel.de/Arduino/RotaryEncoderLibrary.aspx
#include <si5351.h> // Etherkit Si3531 library Jason Mildrum, V2.1.4
// https://github.com/etherkit/Si5351Arduino
#include <Wire.h> // built in
Si5351 si5351; // I2C address defaults to x60 in the NT7S lib
RotaryEncoder gEncoder = RotaryEncoder(ENCODER_A, ENCODER_B, RotaryEncoder::LatchMode::FOUR3);
long gEncoderPosition = 0;


unsigned long int gFrequency = FREQ_DEFAULT;
unsigned long int gStep = 100;


void setup() {
Serial.begin(115200);
Wire.begin();
gFrequency = FREQ_DEFAULT;
setupOscillator();
setupRotaryEncoder();
delay(500);
si5351.set_freq(FREQ_DEFAULT * SI5351_FREQ_MULT, SI5351_CLK0);
si5351.output_enable(SI5351_CLK0, 1);
}


void loop() {
// check for change in the rotary encoder
gEncoder.tick();
long newEncoderPosition = gEncoder.getPosition();
if(newEncoderPosition != gEncoderPosition) {
long encoderDifference = newEncoderPosition - gEncoderPosition;
gEncoderPosition = newEncoderPosition;
Serial.println(encoderDifference);
frequencyAdjust(encoderDifference);
}
}


void setupRotaryEncoder() {
attachInterrupt(digitalPinToInterrupt(ENCODER_A), checkPosition, CHANGE);
attachInterrupt(digitalPinToInterrupt(ENCODER_B), checkPosition, CHANGE);
}


// This interrupt routine will be called on any change of one of the input signals
void checkPosition() {
gEncoder.tick(); // just call tick() to check the state.
}


void frequencyAdjust(int delta) {
Serial.print("Adjust: ");
Serial.println(delta);
gFrequency += (delta * gStep);
setVfoFrequency(gFrequency);
}


void setVfoFrequency(unsigned long int frequency) {
si5351.set_freq(frequency * SI5351_FREQ_MULT, SI5351_CLK0); //
Serial.print("set frequency: ");
Serial.println(frequency);
}


void setupOscillator() {
bool i2c_found = si5351.init(SI5351_CRYSTAL_LOAD_8PF, 0, 0);
Serial.print("si5351: ");
Serial.println(i2c_found ? "Found" : "Missing");
si5351.set_correction(135000, SI5351_PLL_INPUT_XO); // Library update 26/4/2020: requires destination register address ... si5351.set_correction(19100, SI5351_PLL_INPUT_XO);
si5351.set_pll(SI5351_PLL_FIXED, SI5351_PLLA);
si5351.set_freq(500000000ULL, SI5351_CLK0);
si5351.drive_strength(SI5351_CLK0, SI5351_DRIVE_4MA);
si5351.output_enable(SI5351_CLK0, 1); // turn VFO on
}

Sunday, March 05, 2023

Soldersmoke Direct Conversion Receiver working

I didn't have a smooth run with this project, despite the best of help. Here's how it sounds now:


My tuning is very sensitive but at least it doesn't drift like it was with the original (not NP0) capacitors.

I ran into a few issues along the way that took me way too long to debug:

  • The audio chain was taking off at about 2MHz and upsetting the VFO via the power line.
  • I didn't use NP0 caps in the VFO and it was incredibly unstable at first.
  • The variable linear power supply I was using caused great audio hum - no idea why - another supply and the hum is gone.
My build is not very sensitive. I suspect I have the wrong diodes in the ring mixer.

My thanks to Stephen, VK2BLQ, for suggesting the addition of a 1k resistor to isolate the early stages of the audio chain from the output stage to stop the instability. And, of course, thanks to Bill for the design of this project!