About these ads

Archive for category Amateur Radio

Getting 20% Duty Cycle From a 555 Timer

Posted by Ed in Amateur Radio, Electronics Workbench, Software on 24-December-2012

I want to stress-test some LEDs for the long-stalled bike taillight project with a high current / low duty cycle drive. The usual specs give something like 100 mA at 10% duty cycle in a 100 μs period, but maybe they’ll withstand more abuse than that; I don’t have any specs whatsoever for these LEDs. The usual DC rating is 20 mA, so 100 mA at 20%, say 2 ms in a 10 ms period, should give the same average power as the DC spec. I plan to run them continuously until some failures to pop up or it’s obvious they’re doing just fine.

Although this would be a dandy Arduino project, a classic 555 timer IC makes more sense for something that must run continuously without changing anything. The usual 555 circuit restricts the duty cycle to more than 50% for high-active pulses, a bit over the 20% this task calls for. The simplest workaround is a Schottky diode across the discharge resistor to separate the two current paths: charge uses the upper resistor, discharge the lower, with the diode forward drop thrown in to complicate the calculations.

Rather than putz around with calculation, a few minutes iterating with Linear Technologies’ LTSpice IV produces a reasonable result:

NE555 pulse generator

NE555 pulse generator

In round numbers, a 1 μF timing capacitor, 2.7 kΩ charge resistor, and 13 kΩ discharge resistor do the trick. Given the usual capacitor tolerances, each resistor should include a twiddlepot of about half the nominal value: 1 kΩ and 5 kΩ, respectively.

I’m thinking of repurposing those Wouxun KG-UV3D batteries for this task and found a 7.5 V 3.5 A wall wart in the heap that will be close enough for the test rig. The 555 output should drive a logic-level MOSFET just fine, although even an ordinary FET would probably be OK for the relatively low current required for LED toasting.

About these ads

11 Comments

ARRL Hands-On Radio Column Tabulation

Posted by Ed in Amateur Radio, Electronics Workbench on 22-December-2012

Having been unable to find a single listing of all the ARRL Hands-On Radio columns(*) by Ward Silver, N0AX, in QST magazine, I scraped their lists, did some cleanup, and roughly categorized each column’s topic. If you want to bootstrap yourself (or someone you know) from zero to pretty good, he can get you there!

[Update: (*) You must be an ARRL member to access the collection, but you need not hold an amateur radio license...]

Exp Title DC Audio Digital Power RF Theory
1 The Common-Emitter Amplifier x x x x
2 The Emitter-Follower Amplifier x x x x
3 Basic Operational Amplifiers x x x
4 Active Filters x x
5 The Integrated Timer x
6 Rectifiers and Zener References x x
7 Voltage Multipliers x x
8 The Linear Regulator x x
9 Designing Drivers x x x x
10 Using SCRs x x
11 Comparators x x x x
12 Field Effect Transistors x x x x x x
13 Attenuators x x x
14 Optocouplers x x x
15 Switchmode Regulators, Part 1 x x
16 Switchmode Regulators, Part 2 x x
17 The Phase-Shift Oscillator x x x
18 Frequency Response x x x
19 Current Sources x x x
20 The Differential Amplifier x x
21 The L-Network x x
22 Stubs x x
23 Open House in the N0AX Lab
24 Heat Management x x
25 Totem Pole Outputs x x x x
26 Solid-State RF Switches x
27 Scope Tricks x x x x x x
28 The Common Base Amplifier x x x x
29 Kirchhoff’s Laws x x x
30 The Charge Pump x x x x
31 The Multivibrator x x x
32 Thevenin Equivalents x
33 The Transformer x x x x
34 Technical References x
35 Power Supply Analysis x x x
36 The Up-Down Counter x
37 Decoding for Display x
38 Battery Charger x x
39 Battery Charger, Part 2 x x
40 VOX x
41 Damping Factor x x x
42 Notch Filters x x x
43 RF Oscillators, Part 1 x x
44 RF Oscillators, Part 2 x x
45 RF Amplifiers, Part 1 x x x
46 Two Cs: Crystal and Class x x
47 Toroids x x
48 Baluns x x
49 Reading and Drawing Schematics x
50 Filter Design 1 x x x
51 Filter Design 2 x x x
52 SWR Meters x
53 RF Peak Detector x x x
54 Precision Rectifiers x x
55 Current/Voltage Converters x x x x
56 Design Sensitivities x
57 Double Stubs x
58 Double Stubs II x
59 Smith Chart Fun I x x
60 Smith Chart Fun 2 x x
61 Smith Chart Fun 3 x x
62 About Resistors x x x x
63 About Capacitors x x x x
64 Waveforms and Harmonics x x x x x
65 Spectrum Modification x x x
66 Mixer Basics x x x x
67 The Return of the Kit
68 Phase Locked Loops, the Basics x x x x
69 Phase Locked Loops, Applications x x x
70 Three-Terminal Regulators x x x
71 Circuit Layout x x x x x x
72 Return Loss and S-Parameters x x
73 Choosing an Op Amp x x x
74 Resonant Circuits x x x
75 Series to Parallel Conversion x x
76 Diode Junctions x x x
77 Load Lines x x x x
78 Bridge Circuits x x x
79 Pi and T Networks x x x
80 Battery Capacity x x x
81 Synchronous Transformers x x
82 Antenna Height x x
83 Circuit Simulation, Part One x x x x x x
83 Circuit Simulation, Build and Test x x x x x x
85 Circuit Simulation, Complex Parts x x x x x x
86 Viewing Waveforms in LTspice x x x x x
87 Elsie Filter Design, Part 1 x x
88 Elsie Filter Design, Part 2 x x
89 Overvoltage Protection x x x x
90 Construction Techniques x x x x
91 Common Mode Choke x x x
92 The 468 Factor x x
93 An LED AM Modulator x
94 SWR and Transmission Line Loss x x
95 Watt’s In a Waveform? x x x x x
96 Open Wire Transmission Lines x
97 Programmable Frequency Reference x x x
98 Linear Supply Design x x x
99 Cascode Amplifier x x x x
100 Hands-On Hundred
101 Rotary Encoders x
102 Detecting RF, Part 1 x x x x
103 Detecting RF, Part 2 x x x x
104 Words to Watch For x
105 Gain-Bandwidth Product x x x x
106 Effects of Gain-Bandwidth Product x x x
107 PCB Layout, Part 1 x x x x x x
108 PCB Layout, Part 2 x x x x x x
109 PCB Layout, Part 3 x x x x x x
110 PCB Layout, Part 4 x x x x x x
111 Coiled-Coax Chokes x
112 RFI Hunt x x
113 Radiation Patterns x x
114 Recording Signals x x
115 All About Tapers x x
116 The Quarter-Three-Quarter Wave Balun x
117 Laying Down the Laws x
118 The Laws at Work x
119 The Q3Q Balun Redux x
120 Power Polarity Protection x x

Corrections, amendations, commentary? Let me know…

Leave a Comment

APRS Electronics Case: Battery Contacts, Again

Posted by Ed in Amateur Radio, Electronics Workbench, Recumbent Bicycling on 21-November-2012

Although the contacts passing power to the Wouxun HT worked well, they were obviously (in retrospect, as always) in the wrong place. Recently I rode the bike over a major bump and heard the radio reboot (it gives off two low-speed Morse “M” characters), which suggests at least one of the screw heads just barely touches the radio’s spring contacts.

Two folded-under strips of copper tape may work around that problem until I build a whole ‘nother interface:

Copper foil on power contacts

Copper foil on power contacts

The black tape adds emphasis to the lightly sticky end of the copper tape. The folded-under ends lie to the left in the picture, so there’s a continuous copper sheet connecting the radio battery contacts to the screw heads on the green case. It’s not a huge cross-sectional area, but … it’s better than no area at all.

The last time I tried this fix, I used woven copper mesh tape. This time, the solid copper tape was on top of the TLB (Tape Lookaside Buffer) holding the specialty tapes. Either should work fine.

Leave a Comment

Inkjet Colors vs. Time

Posted by Ed in Amateur Radio, Machine Shop, Photography & Images, Recumbent Bicycling on 28-October-2012

Back in December 2007 I printed four copies of a picture on various papers with the Canon S630 and hung them up a floor joist over my workbench, directly below a fluorescent shop light. Having just hung those screwdrivers where the pictures used to be, it’s time to see what’s happened.

The pictures, scanned on an HP C7670A (aka Scanjet 6300C) against the neutral gray of the ADF platen:

Inkjet Colors vs. Paper vs. Time

Inkjet Colors vs. Paper vs. Time

The papers, clockwise from lower left:

  • Glossy
  • Matte
  • Plain
  • Inkjet

While the scanner isn’t renown for its color fidelity, the overall results look about right; the platen really is that shade of gray and the upper-right picture has a sickly green hue.

The faded edges along the right side of the left-hand image show where the adjacent sheet overlapped: the colors didn’t fade nearly as much. The small rectangles on the lower left corners of the right-hand images show where I put clothes pins to keep the sheets from curling.

All of the images have a blue overtone; the magenta dye fades out with exposure to UV from the fluorescent fixture.

As you’d expect, the glossy paper looks best, with very crisp detail. The inkjet paper is next, followed by the matte, and the plain paper in the upper right obviously doesn’t support the ink well at all.

Of course, after five years I no longer have any of those papers and am using entirely different ink…

To show that the scanner really does matter, here’s the same set of images from a Canon LiDE 30:

Inkjet Colors - Canon LiDE30

Inkjet Colors – Canon LiDE30

In both cases. that’s without any color correction / gamma compensation / whatever. I should fish out my scanner calibration targets and go through the whole color calibration dance again; with any luck, the Linux color management infrastructure will be less inadequate by now.

IIRC, we were doing public safety radio at an event at the Dutchess County Fairgrounds with the Mt Beacon Amateur Radio Club. This was before the Diamond antenna mounts disintegrated, too.

Memo to Self: If you love it, don’t expose it to UV.

Leave a Comment

APRS Position Error

Posted by Ed in Amateur Radio, Oddities, Recumbent Bicycling, Software on 24-October-2012

So there I was, riding along Thornwood Drive in Poughkeepsie, minding my own business, when I teleported into Vassar Farm… and back!

APRS data error - 2012-10-21 15:20:20

APRS data error – 2012-10-21 15:20:20

The aprs.fi database shows these packets around that glitch:

2012-10-21 15:43:55 EDT: KE4ZNU-9>T1TP3T,WA2YSM-15,WIDE1*,WIDE2-1,qAR,WB2ZII-15:`eSllA=b/"4Q}
2012-10-21 15:48:41 EDT: KE4ZNU-9>T1TP4U,WA2YSM-15,WIDE1,W2VER-15,WIDE2*,qAR,WB2ZII-15:`eS0mAQb/"4X}
2012-10-21 15:49:53 EDT: KE4ZNU-9>T1TP5W,WA2YSM-15,WIDE1*,WIDE2,qAR,WB2ZII-15:`eS$l{1b"4U}
2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,WB2ZII-15:`eR lzlb/"4V}
2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,KC2DHU:`eR<0x7f>lzlb/"4V} [Rate limited (< 5 sec)]
2012-10-21 15:52:31 EDT: KE4ZNU-9>T1TP8T,W2LW-15,W2LV,WIDE2*,qAR,W2GSA:`eR|lz:b/"4T}
2012-10-21 15:52:53 EDT: KE4ZNU-9>T1TP8S,WA2YSM-15,WIDE1*,WIDE2,qAR,N2MH-12:`eRsm*ub/"4S}
2012-10-21 15:59:52 EDT: KE4ZNU-9>T1TQ3X,WA2YSM-15,WIDE1*,WIDE2,qAR,K2DLS:`eQ}lz\b/"4N}

The two packets at 15:50:20 represent two different paths from the WA2YSM-15 digipeater to the APRS database: one through WB2ZII-15 and the other through KC2DHU. The “Rate limited” message indicates that the database regarded the two as different packets, which they are: the position data differs by one character. The database discards identical packets without comment, because the network must handle all the packets generated by a single RF transmission from one GPS tracker to multiple receivers, but rejects what it sees as deliberate (or inadvertent) attempts to overwhelm it.

Decoding the packets provides a bit more information:

2012-10-21 15:49:53 EDT: KE4ZNU-9>T1TP5W,WA2YSM-15,WIDE1*,WIDE2,qAR,WB2ZII-15:`eS$l{1b/"4U}
   type: location
   format: mice
   srccallsign: KE4ZNU-9
   dstcallsign: T1TP5W
   latitude: 41.67616666666667 °
   longitude: -73.91800000000001 °
   course: 121 °
   speed: 16.668 km/h
   altitude: 62 m
   symboltable: /
   symbolcode: b
   mbits: 101
   posresolution: 18.52 m
   posambiguity: 0

2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,WB2ZII-15:`eR lzlb/"4V}
   type: location
   format: mice
   srccallsign: KE4ZNU-9
   dstcallsign: T1TP5V
   latitude: 41.676 °
   longitude: -73.90066666666667 °
   course: 80 °
   speed: 16.668 km/h
   altitude: 63 m
   symboltable: /
   symbolcode: b
   mbits: 101
   posresolution: 18.52 m
   posambiguity: 0

2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,KC2DHU:`eR<0x7f>lzlb/"4V} [Rate limited (< 5 sec)]
   type: location
   format: mice
   srccallsign: KE4ZNU-9
   dstcallsign: T1TP5V
   latitude: 41.676 °
   longitude: -73.9165 °
   course: 80 °
   speed: 16.668 km/h
   altitude: 63 m
   symboltable: /
   symbolcode: b
   mbits: 101
   posresolution: 18.52 m
   posambiguity: 0

2012-10-21 15:52:31 EDT: KE4ZNU-9>T1TP8T,W2LW-15,W2LV,WIDE2*,qAR,W2GSA:`eR|lz:b/<4T}
   type: location
   format: mice
   srccallsign: KE4ZNU-9
   dstcallsign: T1TP8T
   latitude: 41.68066666666667 °
   longitude: -73.916 °
   course: 30 °
   speed: 16.668 km/h
   altitude: 61 m
   symboltable: /
   symbolcode: b
   mbits: 101
   posresolution: 18.52 m
   posambiguity: 0

Feeding the coordinates into Google Maps shows that the first packet (to WB2ZII-15) at 15:50:20 carries the damaged data. The second (to KC2DHU) has the correct position, but was rejected because it arrived just after the first and wasn’t an exact duplicate.

AX.25 packets carry a checksum and it’s a convolutional code, not a simple XOR, so I think it’s safe to say the packets were received as transmitted; you’ll find an intro to that whole topic, with further references, in the N1VG OpenTracker project. The database doesn’t store complete AX.25 packets, so we can’t run their headers and data through the checksum algorithm to see if they both produce good results. Here’s the raw packet payload:

2012-10-21 15:50:20 EDT KE4ZNU-9: 75 bytes
0x00 K E 4 Z N U - 9 > T 1 T P 5 V , W A 2 Y S M - 1 5 , W I D E 1 ,
     4b45345a4e552d393e5431545035562c57413259534d2d31352c57494445312c
0x20 K 2 P U T - 1 5 * , W I D E 2 , q A R , W B 2 Z I I - 1 5 : ` e
     4b325055542d31352a2c57494445322c7141522c5742325a49492d31353a6065
0x40 R   l z l b / " 4 V }
     52206c7a6c622f2234567d

2012-10-21 15:50:20 EDT KE4ZNU-9: 72 bytes [Rate limited (< 5 sec)]
0x00 K E 4 Z N U - 9 > T 1 T P 5 V , W A 2 Y S M - 1 5 , W I D E 1 ,
     4b45345a4e552d393e5431545035562c57413259534d2d31352c57494445312c
0x20 K 2 P U T - 1 5 * , W I D E 2 , q A R , K C 2 D H U : ` e R 7fl
     4b325055542d31352a2c57494445322c7141522c4b43324448553a6065527f6c
0x40 z l b / " 4 V }
     7a6c622f2234567d

So it seems the TinyTrak3+ sent out a packet containing bad position data, wrapped with a correct checksum.

The NMEA-format 4800 baud 8N1 serial data from the GPS receiver puck to the TT3+ has no parity error detection, so I suspect a character or two got clobbered (by RFI?) and produced a bad position. NMEA messages have a simple XOR checksum that’s susceptible to that kind of error. Note that the Mic-E encoded message shown above is not passed from the GPS receiver to the TT3+; we never see the raw GPS data.

Our TinyTraks use SmartBeaconing to transmit only on significant course changes, so the sequence of events probably went like this:

  • The TT3+ decodes a damaged NMEA message from the GPS receiver
  • It notices an abrupt position change and sends that incorrect position
  • The next NMEA message arrives correctly
  • The TT3+ sees another abrupt jump and sends that position
  • The aprs.fi database rejects the message due to rate limiting
  • The TT3+ remains silent until the next turn

The map doesn’t show all the turns, because that’s a hilly area and not all RF packets make their way from my bike to an APRS receiver.

For what it’s worth, although we were riding at a fairly steady pace, I don’t believe the five-significant-figure accuracy of those speeds, either.

2 Comments

Wouxun PTT Voltage Limit

Posted by Ed in Amateur Radio, Electronics Workbench, Oddities, Recumbent Bicycling on 5-October-2012

TinyTrak3+ D6 - SMD Schottky diode

TinyTrak3+ D6 – SMD Schottky diode

It seems that Wouxun KG-UV3D HTs require nearly 0 V to activate the PTT input, which I discovered after the radio on Mary’s bike began acting intermittently. The TinyTrak3+ would transmit correctly, but the PTT button on the handlebar began to not work at all / work intermittently / work perfectly. The switch and cable were OK, pushing the button produced nearly 0 Ω at the 3.5 mm plug, the connections seemed solid, but the radio didn’t transmit reliably.

I finally got the thing to fail on the bench, which led to the discovery that:

  • Shorting the PTT input to the GPS+voice adapter PCB to ground didn’t make the radio transmit and
  • Data bursts from the TinyTrack3 worked perfectly

Gotcha!

TT3 PTT In-Out

TT3 PTT In-Out

The TT3+ pulls its PTT OUT pin down from +5 V using a 2N2222A NPN transistor (off to the right in the schematic snippet), but, for reasons having to do with ESD, the input from the PTT switch on the handlebars goes through a 100 Ω series resistor, then passes to the TT3 board through PTT IN to D6 before joining the TT3 transistor collector. The low-active diode-ORed signal heads off through PTT OUT to a 10 Ω series resistor, thence to the KG-UV3D PTT input. D6 is an ordinary 1N4148, with the net result that the PTT input voltage at the radio dropped to 630 mV with the PTT button pressed.

Not finding anything else wrong, I replaced D6 with a BAT54 Schottky diode that pulled the PTT voltage down to 300 mV and the radio worked fine.

Of course, a BAT54 is a surface-mount diode, so I clipped off the unused no-connect lead (it’s the only way to be sure it doesn’t do anything) and tacked it down slaunchwise between the PCB thru-hole pads. If I had a BAT54C with common cathodes, I could replace both D5 and D6 in one shot, but D5 just pulls down a PIC input that has an ordinary logic-level threshold voltage.

I don’t know why the KG-UV3D PTT is so fussy, although it may really be a current-driven signal that requires more current than can flow through the 110 Ω + diode forward drop in series with the PTT button. Wouxun presents no specifications that I can find.

The identical circuitry on my bike works fine with the stock D6 diode and a presumably identical KG-UV3D. I should replace that diode before it gives me any trouble, but I’ll wait until I must take the box apart for some other reason.

9 Comments

Spammers vs. Turing Test: Inching Along

Posted by Ed in Administrivia, Amateur Radio, Oddities on 14-September-2012

Most of the dozen or so spam comments I delete every day consist of little more than gibberish. At best, a spam comment will have a poorly worded paragraph or two touting pharmaceuticals, handbags, shoes, or other junk, with absolutely no relation to the post. It’s easy to tell they’re generated by a script: keyword-heavy verbiage, bogus usernames, junk websites, and so forth and so on. Boring, is what they are.

Recently an interesting comment appeared in response to that post on KG-UV3D audio levels which Akismet tagged as spam:

The microphone and radio matching capabilities are terrific. Adjust the wide-range input level for optimum drive to the built-in microphone amplifier [...]

Fluent, idiomatic English that started out pretty nearly on-point for the post! The rest of the comment sounded like advertising copy, though. Well written ad copy, but ad copy nonetheless. Feeding a representative chunk into Google produced a link to the description of the W2IHY Two-band Audio Equalizer on the Official Website.

Now, as it turns out, Julius lives up the river from here and I’ve met him several times. I also know he’s not spamming me, because the URL associated with the post points to some weird-ass Angola gold mining fraud that’s all too familiar from previous spammage. Oh, and the IP address resolves to a Tor server.

As I observed there, eventually the spammers will become bright enough to hold an intelligent conversation and then they’ll be provisionally human. Depending on what they want to talk about …

4 Comments