Saturday, July 29, 2017

Choosing "pull" value for the Si5351 VCXO for APRS

Choosing "pull" value for the Si5351 VCXO for APRS


When configuring the VCXO frequency on the Si5351b, there is a register setting for the "Pull range".  It is described as follows in Silicon Labs publication AN619 "Manually Generating an Si5351 Register Map":

Set VCXO_Param register value according to the equation below. Note that 1.03 is a margining factor to ensure the full desired pull range is achieved. For a desired pull-range of +/– 30 ppm, the value APR in the equation below is 30, for +/– 60 ppm APR is 60, and so on.
This sounds a lot like the FM Deviation to me, though I wish they used those words.

For APRS, the deviation for the 2200hz tone should be about 3.5khz.  The 1200hz tone will be proportionally lower.  So, I need to do some math:

Desired pull: 3,500 hz.
APRS frequency: 144.390 Mhz.

PPM = 3,500 / 144.390 = 24.2 .  Rounded to an integer, it's "24".

The Etherkit Si5351Arduino library, which I've ported to the STM32CubeMX environment, claims that the PPM value must be in the range of 30 .. 240.  I guess I'll set it to "30" and see how it goes.

Since the library does all the number crunching to calculate the register values, I don't need to calculate them myself..

Correction

Subsequent to posting this blog, I realized that I really want to set the PPM for 5 khz deviation (standard FM), but only modulate my signal to 3-3.5 khz.  Redoing the math:  PPM = 5000 / 144.390 = 34.6, rounded to 35.


Monday, July 10, 2017

AFSK modulation experiments - Part 1

AFSK modulation experiments - Part 1


So, on the next version of my Wisp tracker, I would like to attempt AFSK (APRS) modulation in addition to the WSPR modulation.  The Si5351b clock generator chip provides a VC input pin, which allows for FM modulation.  By using the DAC on the Microcontroller to make the appropriate sine waves, I should be able to achieve the proper 1200 and 2200hz tones necessary to modulate AFSK.

Step 0 of this project is to make a sine wave on an ARM Cortex processor similar to the one I will use in flight. The STM Nucleo L152RE fits the bill nicely.  I use the L151 processor on my Wisp tracker.  I did a fair bit of prototyping for the Wisp1 with this Nucleo.



Using STM32CubeMx, I was able to build some skeleton code to drive the DAC.  I found a Sinewave table online that someone had built that fit the bill nicely.  It had 128 points.

I ran the code, and it generated an absolutely beautiful Sine wave.  Sorry I forgot to take a picture. Unfortunately, when I tried to increase the frequency of the sine wave, I couldn't get above about 1500hz before the microcontroller failed to make a signal.  I didn't look into it deeply, but I suspect there simply wasn't time for the DAC to process the values between interrupts.

I reduced the number of samples from 128 to 36.  It made a respectable sine wave.


Having done that, I was curious how it would look with 12 samples.  As expected, it was rather lumpy.


So, I wondered whether I could throw a simple RC filter into the mix to smooth out the sine wave.  I built one with a 330 ohm resistor and 0.1uF cap.  



According to an online calculator, with those values, the filter cutoff frequency should be about 4825 hz, which is well above the 2200hz I was experimenting with.  Voila.  This is the sine wave with just 12 data points, run through the RC filter.


About attenuation


Note that the signal before filtering was about 3.3v peak to peak.  After the filter, it was about 2.7v peak to peak.  I didn't expect this much attenuation from the filter, but still, it's not bad.  It could simply be due to the breadboard and cheezy connections I was using.  Still, provided that 2.7v is sufficient to swing the signal on the Si5351b to achieve the proper deviation, I should be fine.

Alternatives


Should the attenuation prove too much to make a good signal on the Si5351, I have the option of running without a filter, and just fooling with the number of samples in the sine wave until I strike a good compromise.  Still, I'd really like to use the filter if I can.  I figure the GIGO (Garbage In, Garbage Out) philosophy applies here.  The cleaner the signal I put into the Si5351, the nicer the output should be.

Watch future blog posts for more experiments.


Tuesday, June 6, 2017

High Altitude Balloon flight - 6/3/17 from Rochester, NY Hamfest

High Altitude Balloon flight


Having modified a camera and built a controller, I wanted to fly it to see how the camera worked.  I assembled the payload into a foam box and rigged it up with a parachute.

Photos of the launch


Are available in this album

Payload parameters



Parameter Value
Payload mass 650 g
Parachute 30" octagonal (corner to corner)
Estimated Descent Rate 5.91 m/s (using Hexaagonal)


Flight prediction input


Parameter Value
Location Set with map to the Hamfest venue
Launch Altitude Unset (0)
Launch Time 15:00
Launch Date 6/3/2017
Ascent Rate Initially set to 5.5 m/sec.  Predictor overwrote it to 6.3.
Burst Altitude Left to default at 30,000.  Predictor over wrote it
Descent Rate 6.0 m/sec
Burst Calculator
Payload Mass 650g
Balloon Kaymont 1200
Target Ascent Rate 5.5 m/sec
Advanced
Gas Hydrogen

Flight prediction Output and Actuals


Parameter Predicted Value Actual Value
Burst Altitude 34315 m 33880
Time to burst 93 m 88 m
Ascent Rate 6.12 m/sec 6.388 m/sec
Launch Volume 103.8 cu ft 103.8 cu ft (est)
Descent Rate 5.91 m/sec 10.12 overall
 3.2 m/sec last 2000 feet
Descent Time 133 m 143 m


Flight path comparison


The flight followed the prediction almost exactly!  It landed 10.24 miles further SSE than predicted. The parachute performed very well.  I need to re-measure it to assure it's a 30" (and not 36") chute. That might explain the discrepancy.  NB: I measured it.  Yup, it was a 36" chute.  That explains a lot!


Temperature data


Charts in aprs.fi showed the internal tracker bottoming out about -39 degrees celsius, and the external tracker at -42c.  I didn't work really hard on taping up the box, but it seems that such a large open box with a still camera really doesn't have much thermal mass.  It'll be interesting to see how that changes when I have a video camera in there on the next flight.

Lessons Learned


  • Using a time profile for scheduling the snapshot frequency worked just fine.  It was a good way to get more picture density during interesting periods of the flight.
  • I need to work on sealing the payload box better to see if I can stabilize the temperatures some. Everything functioned, but I would have preferred the cameras stayed warmer.
  • Using the "Landscape" mode on the Kodak Pixpro yielded blurry pictures.  I got some great images, but more than 50% were blurry.  I'm going to try "Sport" mode next time.
  • The camera performed well enough that I have purchased a second one to use as a video mode camera in the payload, and run two at once.
  • I need to remeasure the parachute to see if I can sort out the discrepancy in descent rate.

Sunday, June 4, 2017

Modifying a Kodak Pixpro FZ43 for external shutter control

Modifying a Kodak Pixpro FZ43 for external shutter control


I've been using REALLY cheap 808 Keychain cameras for video on my flights.  I decided I wanted to upgrade to something a little nicer, to get better video and still quality.  There are some cameras out there with open firmware that people are using, but they're on the used market, and won't be available forever.  I figured I'd try to venture off on my own and see what I could do.

Design points:

  • Relatively inexpensive (sub-$100) camera that has decent resolution for video and stills.
  • External microcontroller to run the shutter.  I targetted the Atmel ATTINY13, since I have about 5 of them in my junk box.
  • AA powered camera, so that I can use Energizer Ultimate Lithiums (good in cold weather)
  • Depending on battery life when testing, I might want to wire in more batteries in parallel to allow for more pictures.
After trolling around on Amazon, I settled on the Kodak Pixpro FZ43.  I scored it on Amazon Prime for $64.  


The specs for the camera indicated that it could take about 120 pictures on a pair of batteries.  I would definitely want to wire in more. 

Modification


I opened up the camera, and it was a simple matter to find a little semi-riser where traces led from the shutter.  As expected, pressing the shutter shorts a connection to ground.   I connected two tiny wire-wrap wires to do some testing.



I whacked together a little circuit diagram to control the shutter from my ATTINY13 chip.  I was unsure how much current the shutter might sink, so rather than wiring it directly to the chip, which can only handle about 20ma, I elected to control the shutter via a transistor switch.  A 2N3904 served nicely, and I had a about 8 of 'em in my parts box.



I confirmed that I could trigger the shutter by holding the pin (PB3 in my setup) high for 1/2 second. I assumed there would be some button de-bouncing done by the camera, so I started with 1/2 second, and it worked, so I left it.  It worked like a champ.

First Test


With the camera working by microcontroller, I decided to do a duration test to see how the batteries held up.  I turned off the flash, and left the camera running, taking one picture per minute, overnight with just a pair of internal batteries.  The documentation stated about 120 pictures.  I got 460!  Those Ultimate Lithium batteries really rock!  Also, there was no flash, and we were operating at room temperature, so in flight, I'm SURE there would be less capacity.  I settled on wiring in two additional batteries in parallel with the camera, for flight, assuming that I could do 400-500 still shots in flight without difficulty.

For balloon operations, I also like to have a beeper on the payload.  I decided to put that under microcontroller as well, since hell, I'm a geek and idle hands are the devil's playground!  The final schematic looked like this.



Again, I used a transistor for the beeper.  In testing, it was drawing well under 20ma, but I wasn't sure what the surge current was, so rather than take a chance, I tossed in another transistor.

Here are the final mods to the camera.  I found a third pin that had the VCC rail on it.  I put a wire to that, and secured it down with a little kapton tape.  The wires are strain-relieved by knots on the inside of the case, which are too big to pass through the holes I drilled.



I decided I would attach the camera to my controller and external batteries via a connector with some riser pins on it.  Here's the finished product.


Having tested all functions on breadboard, I just needed to whack together a little board for the payload.  Here's the finished product, sitting on top of the breadboard mock-up.  Subsequent to this picture, I wired in a few LEDs which fire when the transistors do.  This just gives some visual indication that things are working, even if the camera or beeper aren't attached.

I set up the board to be powered from a bus which consists of the two external batteries wired in parallel to the internal camera batteries.  The circuit, therefore, runs on 3.0 volts, which is well within spec of the ATTINY13.  I did reset a "brownout" software fuse on the chip to make sure that it didn't reboot if it had a bit of voltage drop.

I built the board with an 8-DIP socket on it, so that I could externally program the chip, test it on my breadboard, and then just pop it off, and transfer it to the flight board.  That way I didn't need to put programming risers on the flight board.


I ran predictions for my first flight.  It estimated 93 minutes to burst, and 135 minutes to landing.  So, I wrote code for the ATTINY such that it took 6 pictures per minute in a 15 minute around burst time, and around landing time.  I scaled back the picture rate during "boring" times for the flight.

Final flight configuration

Here's a picture of all the "guts" of my first flight payload.    The green thing on the left is the tracker, which runs on one AAA battery.  Then, I have the camera, flight board, beeper, and the two batteries that supplement the camera.  The two batteries in the upper left are for the camera itself.



The first flight showed that this system worked like a champ!  I was getting 6 pictures per minute at burst, and at landing time.  This allowed me balance battery power (and weight) against the desire to get interesting pictures.

First flight.  Two minutes after apogee, on the descent.  That's Lake Ontario in the background.


Next Steps


While the shutter mechanism worked great, I was disappointed in the focus of the pictures.  The camera does auto-focus on the center of the screen,  An unfortunate number of the photos were out of focus.  I'm going to mess with the settings to see if I can do better, or perhaps have it hard-code to "focus on infinity".

Also, this worked very nicely.  I'm getting a second camera which I will wire similarly.  I'd like to have one taking stills and another taking video.  I'll wire up the video record shutter (a different button) on the second camera, in addition to the shutter, so I'll have a 4-wire configuration.  The microcontroller will then be able to switch between video and stills, should I choose.



Thursday, January 19, 2017

Hojo and the case of the faulty FT-2800M

Hojo and the case of the faulty FT-2800M


Background

A friend, Joe / W2IFB mentioned that he had a Yaesu FT-2800M fail on him.  He had been keyed in a long QSO for more than 10 minutes when the radio failed, catastrophically.  Thinking that he had blown the final, he tried replacing the final transistor.  Unfortunately, it didn't work.  He reported that the radio was basically in a "short" when plugged in.

He gave me the radio and said "It's yours!  If you fix it, maybe I'll buy it back!"  I accepted the challenge.

Initial testing


I took the radio and set the current limiting on my power supply to 300ma, figuring that would be sufficient to demonstrate a problem.  I plugged the radio in, and sure enough, it was drawing current HARD.  Placing my ohm meter across the power leads, it showed 0 ohms.  It's in a dead short.

Investigation


I opened up the radio and snooped around the board a little.  I saw the power transistor that had been replaced, but didn't see any shorts nearby.  It also seemed unlikely that a problem in the final would cause a dead short when the radio was still powered off.   I also observed what appears to be a two-turn inductor coil that may have gotten a bit smushed.  None of this looked like the cause of the short, however.



I pulled out the schematics and took a look at the routing of the power.  I assume the short must be very early in the circuit, since the unit uses a soft power switch, and it hasn't even been powered on. Glancing at the schematic, and board, I saw a few voltage regulators, and a protection diode.




The protection diode was right near the edge of the board, and an obvious first thing to check.  It's a clamping diode, so a surge of some kind may have caused it to fail.


I removed the diode from the board, and sure enough!  It's a dead short.  0 ohms in both directions. Further, I hooked it to the power supply and confirmed that the diode was permitting full voltage rom the supply through it in both directions.  It's blown.



Yaesu is kind enough to list the manufacturers part number in their service manual.  Digi-key has the part for $0.48.  I'll tuck one onto my next order.

Further testing


With the diode removed, the power leads no longer showed a short.  Encouraged, I decided to simply hook power to the board and see if the current draw was reasonable. The head was still detached, so I didn't expect the radio to power on. Sure enough,  the current draw was down in the 10s of milliamps. I think that's reasonable.

Hooking up a more beefy power supply, I was able to run through a full suite of tests, and confirm that it was simply the diode at fault.  The radio was working just fine.

Repair and Alignment

I ordered up the diode and got it in from Digi-Key.  The installation was trivial.

I went ahead and did a few tests prior to aligning the radio.  It was transmitting about -650 hz off frequency at 146.000.  Most other metrics seemed good, though it was only making about 50 watts on high power (should be 65).

The Jig

The perform the alignment, I needed to inject signals into the microphone port.  I decided to make a jig that I could use for this project, and in the future.  

 I built a 6-pin cable to use for the project, and sorted out the pinout.  Yaesu uses a common ground for the Mic and PTT.  The Mic inputs go to the BNC port.  The PTT goes to the toggle switch.


The finished product.  Now I can pump signals right from my service monitor into the mic port on the radio.  The toggle switch makes it easy to engage the PTT without holding a button,



Alignment Details

I followed the alignment procedure from the manual.  Notes here for posterity.


Adjustment Original Value Adjusted Value
PLL Reference -645 hz -15 hz
TP-TVC 1.547 v 1.502
TP-TVC 0.925 v Not adjusted.  Broken Trim Pot.
Target value was 1.3 v.
TUN 137 1.987 v 2.009 v
TUN 146  2.050 v 2.051 v
TUN 160 2.026 v 2.026 v
TUN 173 2.018 v 2.018 v
TXPW H 50 w 65 w

All other setting values were already optimal when measured, and were left alone.  Current readings on transmit were all well under published maximums.



Sunday, January 15, 2017

RCA WV988 VTVM recap and repair

The purchase


I found an RCA WV988 VTVM at a hamfest.  It was labeled "Works - $10".  I figured it would be a fun project to learn a little about recapping and tube based equipment.  It has a minor crack in the face, but I don't really care.  I'm more interested in this VTVM for the "puttering" aspects than for usability.  Still, it'll be nice to have an analog meter on my bench if I get it working well.  It's got a nice big display, and the crack doesn't impede use.

I managed to find a manual for it online.  It's one one electrolytic cap, which I'll replace.  It's also got a selenium rectifier, which can release toxic "magic smoke" at failure.  The interwebz recommend replacing that with a diode and series resistor.

A peek inside


A previous owner had soldered in a D-cell battery to operate the Ohm meter.  I'll pull that out, and put in a battery holder.  Also, clearly in view are the electrolytic capacitor and the selenium rectifier that will need to go.


Checking it out


I went through and tried all the basic functions.  They were all pretty good, though it was slightly out of calibration.  I'll go through and attempt a recalibration after repairing it.

Installing a battery holder


Easy enough.  I desoldered the D-cell, and put in a AA battery holder.  I drilled a small hole in the plastic holder, and countersunk it a little. I used the existing screw to install the new holder.  I soldered in the wires and used a bit of heat shrink to insulate.

The Old Battery, Soldered in.

Battery removed.  I'll reuse that screw in the center of the old holder.

Hole drilled in AA holder, and countersunk a little, so the screw isn't in the way of the battery.

Installed, with a little shrink-wrap on the wiring.

Now the battery is easily replaced.


Replacing the cap and rectifier


The cap was a 20uF 200v.  That was easily replaced.  The rectifier is rated tat 20mA.  It's easily replaced with a 1N4004 diode and a 2 Watt, 820 ohm series resistor.   I followed the basic recipe in Rich Bonkowski's (W3HWJ) excellent article.  I tried a few different resistors until I got a voltage that matched what I was reading prior to the replacement.

Since I was installing one additional component (the resistor) in series, I drilled two new holes in the board, and ran the diode to one of the new holes, and then connected the resistor from the adjoining hole to the other rectifier pin.  Since there was no trace on the board for that connection, I simply extended the leads to one another, twisted them once, and soldered them together.  The result looked nice and tidy.

The old rectifier and cap.


The PCB from the back side.  The two new holes (bottom box) have leads through them from the diode and resistor.  I simply twisted together and soldered them.  The existing pads from the rectifier and cap are marked.



The final installation of the diode, resistor and new cap.

Testing

Upon testing, it appears that the DC voltage calibration was off, and it is at the limit of the variable resistor for tuning.  It's off by around 1 volt.  More follows as I sort out the issue.


Building and using a Schmitt Trigger Oscillator

Building and using a Schmitt Trigger Oscillator


Inspiration

Alan Wolke / W2AEW has a youtube channel in which he does all manner of informational posts about electronics, RF and Ham Radio.    He did a great video showing how to do TDR measurements by using an oscilloscope and a Schmitt Trigger Oscillator which he built up from some scraps on his bench.  I decided to build one for my own use.

Build and Test



Being anal the way I am, I worked up the schematic and board layout in Diptrace. I decided to use thru-hole parts.  Unfortunately, I'm not a wiz at Diptrace.  It doesn't have great provisions to work in three dimensions.  Some of the traces overlap or take weird routes, where I intended to just route around with some wire jumpers.


I had most everything in my scrap box.  I elected to use a CR-2032 (3V) button battery, seen on the left, since it would keep the whole thing small.  I just had to order some Schmitt Trigger Oscillators from Digi-Key.


Here's the finished product.  There is some kapton tape wrapped around it simply to protect the bare wires soldered on the bottom.  The BNC plug is crazy glued to the perf board.


Running my initial test, I found two issues. First, the clock frequency was quite a bit different from Alan's, though I used the same values for the resistor and cap in the oscillator, I thought!!!!

Upon re-watching his video, he used a 47nF cap. I used a 4.7nF cap.  Oops.  Well, the oscillator frequency came out about 24 khz.  That's still completely serviceable.  I opted not to bother fixing it.

The second issue (which I don't understand) is that the rise time is not as fast as Alan observed.  I'm getting a rise time of about 9 ns.  He was getting about 2ns.  I used the same 72AC14 Schmitt Trigger DIP that he was using.  I'm not sure why it might be slower.  Still, even at 9ns, it's perfectly fine, and still much better than the cheap signal generator on my desk (24ns) which is also much bulkier.

Practical use



As it happened, we needed to know the cable length in our W2CXM shack between a new location and the antennas on the roof.  I used this Schmitt Trigger Oscillator to measure it.

I observed 173ns.  We are using Beldin 9913 coax, which has a velocity factor of 84%.   Using 11.8 inches/second, at 84% that's 9.912 inches/sec.  With 173 nanoseconds that yields 1714.78 inches (142.898 feet) round trip.   That's about 71.5 feet to the end of the cable.

Kevin / WB2EMS used a proper TDR cable measuring device and came up with 72 feet.  So, we're definitely in the right ballpark.



Here's the oscillator hooked up to a small LeCroy 60 mhz oscilloscope up in the penthouse of my building.  That scope is nice and portable, which made it perfect for this task.


Note the boondoggle of adapters one can end up with, if your bag-o-dapters is missing a few things!  I made note of what to pick up at my next hamfest!

All in all, it worked great and served the purpose. It's small and easy to use.  I've popped it in my toolbox with my adapters and other "antenna and coax" tools.   Project successful!