Once again, the Vienna Wireless Society participated in ARRL Field Day from Burke Lake Park in Northern Virginia. For the last three years, I have captained the non-40m CW tent. The plan this year was slightly updated to move the stations closer together, while maintaining adequate antenna spacing.
I had a few secret weapons this year. First, with the move up the hill, I was close to the spider beam mount that I was able to use it to work 20 meters, and for a bit of the contest, 10 meters. The 40m station typically runs 15 meters, so I did not use the beam on that band. When the spider beam went up, I also tacked on an AO-50 omnidirectional 6 meter antenna, so we picked up a few contacts on that band as well, but far fewer than I had hoped. The other trick I had up my sleeve was to roll out a newly minted K3 rig. I had put it together about two weeks back, just in time to test it out in the NAQCC sprint for May. In addition to the stock 2.7 kHz roofing filter, the K3 has 200 and 400 Hz roofing filters for CW.
As for weather, we enjoyed both heat and humidity on Saturday and were surprised by chilling, drenching thunderstorm on Sunday. Good times.
I’ve stopped hearing CW in my car creaks and the howling of my home’s air ducts, but my brain is still not entirely recovered from the continuous operation of the station over that 24 hour period. Thanks to Leon, NT8B, I did catch some sleep during the event, otherwise I would be even more posty-toasty.
Some preliminary results (some contacts logged separately, e.g., our VHF activity, also all of the added point categories like GOTA, solar power, etc., are not included):
Things that were planned and worked out well:
Rain gear: Packed a poncho and umbrella despite a clear forecast. Similarly, packed long sleeve shirts and a sweater despite heat and humidity in the 90s.
Trash bags: Plastic bags enabled us to keep the station up, even when sideways rain was splashing through the mesh sides of our operating tent
Plastic sheeting stashed in the club’s field day bucket, someone years back had thought to buy some large plastic sheets. Not long after rain started, John Righi realized that he could drape our tent with the sheets to keep water out.
The spider beam: It is a pain to put up, but works well.
N1MM: Prior planning and testing with N1MM lead to a smooth operation
Poison Ivy on the main antenna support tree: Recognized, avoided.
Food: Yummy, and plenty of it.
Things that did not go entirely according to plan:
The deep-dwelling ground rod: An 8-foot ground rod, hammered in 4 feet deep proved difficult to extract. With many helpers, a hydraulic jack, a vise grip to provide purchase on the rod, and a thick wood log to increase surface area under the jack, the rod was recovered, averting plan B, which involved a hack saw.
The tree-loving guy line: one of the supports for the 80m dipole was particularly long, and an overlooked knot in the end became fouled on a high tree branch. Pulling only lead to comical moonbouncing around on the lawn. The solution: tying the line to a pick up truck and running for cover. The 3/8″ line held, a tree branch came down, and the problem was considered solved.
The logging computer, an old Panasonic Toughbook, decided that its track pad would no longer function when we set it up at the station. The touch screen still worked, so we weren’t entirely out of luck, but we had to scramble a bit to find an external mouse. I’m still not sure what happened, as the pad had worked right through the WVQP a week ago, and up to the previous evening when I was setting up the database for field day.
It turned out that we did not have a satellite station for field day, so between HF stints, Ben Gelb and I monitored satelite passes and attempted to jury rig a station from my car, which is outfitted with a computer controlled TS-2000. Ben was at least familiar with the software, whereas I was reading the TS2000 manual right up to the first pass. We had a 70cm yagi, the car’s 70cm/2m vertical, and a small 70cm magmount antenna. We ran HRD’s satellite tracking program, and set up a waterfall using Ben’s digicube dongle, while the TS2000 provided duplex audio for both up and downlink. We did manage to find the satellites each time, but had some difficulty setting the T/R offset and tuning around in real time during the pass. We heard both CW and SSB transmissions on the birds, and even succeeded in hearing our own CW signal, so at least we knew that we were making it in. This set up may have worked on a quieter day, and I think it needs only a bit of tweaking to get it right…maybe next year, with some practice in between.
Things to consider for next year:
We worked absolutely everyone that we heard and were often the first station through pile-ups. Maybe we could go entirely QRP next year? Bigger score multiplier, less inter-station interference
Check that we have plastic sheeting for every operating position.
Check wireless routers for RF emission. I’m not sure this was a problem, but something blanked out our satellite receive capability on one pass, and having eliminated other sources, we suspect a wifi router may have been the culprit.
I hadn’t planned on entering the WV QSO Party this year because I thought that I had another event on Saturday. Then, scheduling shifted around and the weekend opened up. Having recently participated as a rover in the Indiana QSO Party, the car was still set up for mobile operation. Further, I had a hideous showing in last year’s WVQSOP, so I was hoping to redeem myself this year.
I did the planning late on Friday afternoon. After grabbing the current rules and a list of WV counties from the event website, I headed over to an online county mapping tool. Between that and google maps, I plotted a loop through the northeastern part of the state, concentrating on reasonably large roads that crossed county borders, but not over a river. I didn’t have much time, so rather than obsess about the route as I usually would, I just took the first candidates, without optimizing for elevation, signs of power lines, and so on. The route is saved as a google map. On that map, if you select a way point and hit “directions”, the map provides the long/lat for the way point. I programmed those coordinates into a dedicated GPS, having learned last year that my android phone does not do well as a GPS once I’m a few miles into West Virginia, and out range for my (and sometimes any) cellular network.
For the record, here are the waypoints, each of which turned out to be a reasonable operating location:
Range to next
The weather looked great on the morning of the event. Even the space weather looked not half bad. Solar flux had been drifting down, but it was around 100 and most importantly, quiet. I left around ten in the morning, hit the bagel shops on main street in Fairfax, and made it to the first way point at noon. It took a few minutes to set up the antenna and get sorted out, and the first contact was recorded at 12:15 local, fifteen minutes into the contest. From then, I operated non-stop until the closing bell at 10 pm local.
My main antenna was the 40m hamstick, but I also adjusted the screw driver to 20m and used it from time to time to test the waters on that band. I alternated between CW and phone throughout the day. I hovered on each location for at least an hour, and spent the last three hours at Grant-Hardy. I was surprised that I got so few contacts at the Berkeley-Morgan stop. It seemed ideal — the top of a mountain, a nice place to pull over, and no obvious sources of electrical interference. Maybe it was propagation or time of day, but as soon as I started driving again through Morgan County, I started picking up more contacts.
Here are the statistics for the day:
So…what’s my score? I’m not sure. The contest rule do not fully describe scoring, but refer to a summary sheet. QSO points are weighted, CW counts more than Phone and contacts with mobile stations are also more valuable. There are bonuses to work the official event stations (I worked them ten times), plus bonuses for number of counties activated (11 — see the map). Speaking as a mobile operator, these incentives to work rover stations are very appreciated. Looking over the logs from past WV QSO parties, I’m surprised that more stations don’t enter in the mobile category given the scoring algorithm. Anyhow, part of the scoring method seemed ambiguous for me, so before I do any totaling, I’m waiting for some clarification from the contest organizers by email. At least I am sure that I did better than last year.
From the perspective of fixed stations there is a bonus for working the same mobile station in five counties. By my reckoning, I provided this credit to:
Looking through the log, I worked 27 US states, plus Ontario in Canada, and one station each in Germany and the Slovak Republic. As in the INQP, I think I would have done better had I been able to get a 20m antenna into the trees, but operating this contest single-handed, I didn’t want to take the time to wade into the brush and grapple with ropes, wire and coax.
It was a great day for a contest, and while I was driving frantically around West Virginia, I was also enjoying the scenery. My final location was on a mountain top, where I watched the sun set. Around dusk, a family of deer walked through the clover and grass next to the car. By the end of the event, the stars were out in full force and I started at the constellations for a bit…
…which was helpful, because for the last mile of the trip, my GPS stopped functioning normally. The road that I was on was a shiny new highway, and evidently not in the memory of the Tom Tom GPS, that I had purchased in 2009 in Belgium. The GPS constantly tried to recalculate where I was, as it could not accept that I had driven the car off a farm and up into the woods on the side of a mountain. Taking bearing from Polaris, I headed east until I found a road that my mildly brain dead GPS recognized, and made it home about two hours later.
In August 2010, one of the Mid-Atlantic summer lightning storms did some damage — the strike was nearby and not direct, but it fried my Astron power supply, a Panasonic tough book, and my Kenwood TS-450SAT radio. The radio would power up and the display looked normal, but I had no audio and suspected that the front end and perhaps switching diode had been zapped. At the time, I didn’t feel up to tackling the radio repairs, so based on eham reviews, I contacted KI4NR at LPC Wireless and mailed the rig off to Florida.
Meanwhile, I checked out the Astron and concluded that the voltage regulator IC was dead. After replacing the chip, the supply was as good as new. Next, the computer: it had been interfaced to the radio via a G4ZLP cable, a work-alike to the original IF232 from Kenwood. As mentioned previously, I had modified the cable to also serve for CW keying of the rig. The computer powered up from battery okay, but did not work on wall power. A small board with the voltage regulator and battery charging circuits had been fried. I found the same model Toughbook on Ebay for a good price — broken screen, no hard drive or battery, and was able to combine the two into a functional unit.
LPC had sent me pictures of both the damage and repair, which are displayed in this posting. When received by LPC, the lightning protection diode had vaporized and the PC board was charred. They repaired the lightning damage, but also performed factory calibration, enabled transmission on the 60m band, and replaced the backup battery, which was close to the end of its life.
The only item that didn’t work right was CAT control of the rig, but at first it wasn’t clear where the problem was: in the computer port, the interface cable or the rig itself. Swapping computers didn’t seem to matter, so the next step was to order another G4ZLP cable. Even with a pristine new cable, I was not able to establish serial communications to the rig.
Not having CAT control was a minor inconvenience. For normal operation, it wasn’t a big deal to type in the frequency, but for contests, it slowed me down a bit to not have the band map automatically populated. Similarly, for digital modes, it made operating awkward.
Looking at the schematic for the digital board within the TS450/690 service manual, there is an inverting buffer right after the physical connector to the cat cable. This chip is all there is between the outside world and the microprocessor that runs the radio. I reasoned that if the microprocessor had been cooked, nothing would work, so it was very likely that the 7404 chip had been cooked by the electrostatic discharge. The chip is designated SN74AS04NS, so an “advanced schottky” version of the chip.
I couldn’t find that exact version of the chip, so I ordered the “next best” version: SN74ASO4D. According to the data sheet, the two are electrically equivalent and have the same pin out. Both have 0.05″ pin spacing, but the dimensions of the ICs are slightly different: the D model is 1.75 mm shorter, 1.6mm narrower, and from side to side the “arm span” of pins is about 2mm less. I was hoping, though, that this would be close enough.
I removed the old 7404 by cutting the pins near to the chip body and then removed the remaining leads with a soldering iron. This left behind some clean, well-tinned pads. When I aligned the new chip, it was apparent that the replacement chip was not wide enough to span from pans on one side to the other. Since the new chip had the same pin spacing, I taped it in place and soldered one side of the chip, leaving a gap of 1-2 mm to the free pads.
After experimenting for a while, I settled on using a very fine tipped soldering iron and made the connections using individual strands from stranded copper hookup wire. I did my best to check continuity, closed the radio up, and connected the newer interface from G4ZLP. I fired up Ham Radio Deluxe and defined a new radio, with communications set to the correct COM port, and serial parameters of 8 data bits, no parity and 2 stop bits. The radio synched up immediately and displayed the correct frequency. After brief testing, it appears that the CAT control is operating correctly.
I then went back and tested the original CAT cable from G4ZLP, and it appears that it had also died in the electrostatic discharge. Opening up the serial cable end connector, there is a small circuit board, covered by white rubber or silicone. I peeled a bit of it back to reveal a small circuit board with surface mount components. I didn’t consider it worth fixing, since I do have another cable that works fine.
Although it was something of a pain to replace the cable and the 7404 chip in the radio, the sacrifice of these two components was far preferable to having the damage go one chip further and take out the radio’s microprocessor.
In 2011, I got together with Ben (NN9S) and Tymme (K9TYM), and we participated in the Indiana QSO Party from Tymme’s house, just outside Bloomington, Indiana. None of us were experienced contest operators, but we managed to set up a multi-multi station in short order and kept it on the air for the duration of the event, giving out QSOs for Monroe County.
We couldn’t pull the team together last year because of jobs and travel schedules, but we entered this year as a Rover team. My 2009 Hyundai Sonata is outfitted with a Kenwood B2000, similar to the TS-2000, but without a front panel. The main radio unit is housed in the trunk, with a remote head mounted on the dash.
Over the last year, I’ve gradually modified the car for this operation, with power connectors running down the left electrical channel to the trunk, and audio, keying, RS-232 and antenna control cables running along the right electrical channel. One of the radio’s antenna ports is dedicated to a 2m/70cm antenna, while the other is used for HF: either a screw driver antenna or MFJ hamsticks.
I took a few days off of work for the event and camped on the way out and back to Indiana from Virginia. Before leaving, I lightened up the car a bit by removing the passenger side seat. The seat is held down by four bolts, easily removable with a socket wrench, plus some electrical cables that had to be disconnected. In place of the seat, I screwed in a RAM Mount for my panasonic toughbook laptop, with power from the car’s accessory power port and rig control via RS-232. This allowed the computer to be operated from either the driver position or the rear seat. Similarly, the microphone reached to the rear seat.
Either passenger in the back could operate the microphone, and the passenger behind the driver typically also fulfilled the role of navigator. The other passenger in the rear seat operated the computer, and the driver either drove, or while parked, operated CW using paddles mounted on the center console behind the shift lever. An autokeyer with rate adjustment was installed into the front dash.
We followed a counter-clockwise loop, starting near Tymme’s house in Monroe county. Our plan was to aim for county borders that were along an efficient route. In the weeks before the event, we roughed out a plan using Google Maps and Street View to try to find places that would be safe to pull over and operate and ideally far from sources of electrical interference. We also tried to find locations with some elevation and good prospects for pitching an antenna into a tree or setting up a support pole.
We got off to a wobbly start because we did not make good time from Chicago to Bloomington, and we got a little turned around in Bloomington. Consequently, when the contest started, we were still on the way to Tymme’s house. This wasn’t a major set back, as we just started operating mobile on voice until we got there. As soon as we pulled it, storm clouds were gathering, and the decision was made to shoot the 80m antenna for the evening’s operations before the sky let loose. While Ben and Tymme disappeared into the woods to shoot strings into trees, I operated CW from Tymme’s driveway.
Before long, we were underway, first way point: the Monroe/Lawrence border. Our circuit continued with operations in Orange, Dubois, Martin, Washington, Scott, and Jackson counties. We had surprisingly few contacts in Martin country, which I thought would be a highly sought location, and I’m not sure why — we had a remote, high location; maybe propagation was just off at that point in the day.
As the first person to operate phone when we got to the Orange/Dubois border, I learned that “Dubois” isn’t pronounced the way I thought I was. In Indiana, it rhymes with “noise” rather than “quoi”.
We continued operating the entire duration of the contest, driving through pouring rain for the last few hours. The rate began to drop off in the evening, a reflection of the poor efficiency of mobile antennas on the lower bands. Looking at the clock and the map, we reckoned that we would need to get back to Monroe country quickly if we wanted to have a chance to use the 80m full-length dipole that we had spent some time setting up earlier in the day. We nicked Brown county on the way back to Tymme’s, but unfortunately didn’t land any QSOs. In retrospect, I think we should have written off getting back and tried to get a couple contacts in Brown country, but we were also constrained by our over all travel plans — we had to be back in Chicago by 6 am the next morning, so we were keen to get back to Tymme’s by midnight and catch a few hours of sleep.
Tymme took the wheel for the last hour or two of the contest, flying through Indiana back roads like Luke Skywalker in the trenches of the version 1.0 deathstar. I’m pretty sure Tymme turned off the targeting computer and just followed his instincts home. Surprisingly (to me), when we got to Tymme’s house, he didn’t stop driving, even though the driveway had run out. Tymme continued to sail over lawn and into the forest behind his house, with the car slicing through waist-high grass. He stopped when he got to the tree supporting the 80m dipole and we hooked up the feed line to the radio in the car’s trunk.
Aside from some boozy yokels on 75m, we didn’t hear much activity, but once we started calling CQ, we had a pile up of responses. When we had wrung out sideband, we switched down to CW and a similar hot run. In the last half hour of the contest, I was pleased to work many calls that I recognized as QRP stations.
During the 12 hour event, we reckon that we worked 30 states/provinces and 48 sections. This is actually fewer states than we had worked in 2011. I believe that this could be improved in future efforts if we used higher antennas and paid more attention to the 7Q contest. Here is the breakdown by band and mode:
band mode qsos pts mults
3.5 cw 33 66 8
3.5 lsb 24 24 6
7 cw 135 270 47
7 lsb 127 127 44
14 cw 12 24 5
14 usb 13 13 8
21 cw 2 4 0
total 346 528 118
Doing some quick calculations after the contest, it appears that Ben has now achieved the first rank of “worked all Indiana” between Operations Sizzling Pork and Rolling Pork.
On the way home, I attached the 10m MFJ hamstick to the trunk mount and worked CW. Conditions were great, with solar flux up around 150. I logged QSOs to the following countries: Honduras, Nicaragua, Argentina, Cuba, Guadeloupe, Brazil, Canary Islands, Mexico, Paraguay, Puerto Rico, the Balearic Islands, and South Africa.
This year, we had some nice mini-pileups, which made it an exciting event. After getting back to Virginia, I called up records from dxsummit to see if and when we were spotted (thanks, by the way, to everyone who did spot us). I would have guessed that we had been spotted at some additional times, so maybe this records isn’t all-inclusive of spots, or perhaps people are just good at finding fresh stations to work:
N9IO 3530.0 NN9S inqp 0347 05 May United States
K3CT 7225.0 NN9S QSO Party 0012 05 May United States
KB9NW 7244.9 NN9S 2244 04 May United States
I hope we are able to build on our effort in INQP 2014. The first item on the plan for INQP 2014 will be operation from Brown County.
I have a few CW rigs that have lousy filtering. Rockmites and other low part count direct conversion rigs naturally don’t have much in the way of selectivity, but this is also (unfortunately) true of my unmodified Yaesu FT-817nd. I should probably invest in the an IF filter for the 817, but for other rigs, it makes sense to have an external audio filter that I can use across projects. A natural choice would be the New England QRP Club’s NESCAF filter.
The NESCAF filter is designed around a family of versatile switched capacitor filter chips. The grand-daddy of the family is the MF10, but more modern versions exist (e.g., the pin-compatible LMF100 or the LTC1060) and have better performance. Each of these chips has two 2nd order filter stages, which can be configured as low pass, high pass, all pass , notch, or band pass depending on how it is wired up and what external components are used. One stage can serve as input to the other to create 4th order filters.
In the case of the NESCAF, the chip is configured as a Butterworth filter — maybe not the sharpest band edges, but minimal ripple in the pass band. Referring to the MF10 datasheet, it looks like the NESCAF implements this through two sequential mode 1 filters with a Q of 10. The filter bandwidth is controlled by two ganged 50k ohm potentiometers, with a section devoted to each filter stage. The center frequency is driven by dividing a time base by 100. A 555 timer outputing 70 kHz will result in a 700Hz center frequency. The 555 rate is controlled by a panel-mounted potentiometer. The center point of that potentiometer is set an onboard trimmer potentiometer. Output from the filter is amplified by an LM386. Some builders make this an onboard trimmer set to yield a gain of 1 relative to the input signal, but I made it panel mount to allow adjustment of volume.
Power input is nominal 12V and the LM386 uses this level directly, with only a couple of capacitors for smoothing. The rest of the circuit operates at 9V regulated by an 78L09. The MF10 chip is used in single-supply mode via a resistive voltage divider.
This design is sold as a kit through the New England QRP club, but schematics are openly available. To try it out, I decided to build my version on vector board, which was great in terms of character building, but next time I would certainly save a boat load of time and get their PC board.
The dual-ganged bandwidth pot takes up a lot of room in a case, so ideally the project would be housed in a deep enclosure. I had a bud box on hand, so I used that. The project schematics call for a 4.7k resistor on the power indicator LED, but that value results in such a dim LED that it would only be useful in a dark room. I knocked the value down to 1k in one build and 1.5k in another, and both worked fine. The marginal power cost is insignificant to me — I’d rather have a reasonably bright LED to let me know that the unit is powered.
I had no difficulty machining the cast aluminum case with titanium coated bits, but a stepped drill bit made it a pleasure to bore out the holes for pots and switches, leaving a burr-free hole with minimal effort. The rectangular hole for the power pole connector is still something of a pain. I drill a few holes, enlarge them, and then refine it with some tedious file work. It amazes me that there is no elegant way to panel a single power pole pair. There are snap-fit panel mounts for 2×2 and larger arrays, but I would think the most common requirement would be a simple pair. The only solution I have found so far is to order very overpriced metal retention brackets that clamp on both sides of the socket. With a single screw in each bracket, they have a tendency to tilt, which gives the project an unprofessional look.
For once, I remembered to drill first and paint later. In this case, two layers of white spray paint. I made the lettering by printing text on water gilde decal paper using my laser printer. I filled the sheet with words, numbers, abbreviations, etc., that I thought I might need in future projects, since the paper is somewhat costly. After applying the decals and letting the cure for half a day, I went over everything with two coats of clear matte acrylic spray and then assembled the project.
As a functional test, I played back a recorded session of PSK31 signals and output to a computer running MixW. I made a video of this session and also took the photo at left. In that photo, events at the bottom of the waterfall are the oldest. So, proceeding upward, I had the filter off with audio bypassing it entirely. When the filter was turned on, signal was lost until I turned the AF gain up to the point where the level was similar to the source volume. The filter was already set to narrow bandwidth and the curvy line resulted from me dialing down the center frequency. Towards the top of the waterfall, I had opened up the bandwidth and then dialed up the AF gain to greater than unity, oversaturating the waterfall.
For the 50th anniversary of the Vienna Wireless Society, the club operated under a special event call sign: W5O. As usual, there was a good turn out of club members for both the picnic and on-air activities. We put a couple rockmites, FT817s, and a KX3 on the air, and accumulated 62 contacts in our log in total running predominantly CW, but some phone as well. We had multiple contacts with other operators also participating in the QRP TTF, but also the Florida QSO Party, and one SOTA station. In the next couple weeks, we should send out our QSL cards to confirm the contacts.
In the days before the event, I put together an “untangleable folded dipole” antenna made from 300 ohm twinlead, plus a matching box comprised of two toroids and two capacitors. The antenna was based on a design found on the blog of KI6SN, and I summarized the construction details for my effort on a Google-plus post.
After spudgunning two trees, we hoisted the folded dipole to a flat 40-foot deployment. The feed line is about 25 feet, so a short BNC-terminated coax extension was used. The antenna worked great and allowed us to work a Swiss station, and to score reverse beacon hits throughout Europe on 20m. I swept the antenna with a MFJ analyzer at the end of the event, and noted that SWR was below 1.2 for the entire CW portion of the band, and less than 2 from below 20m to above the voice portion of the band. So, quite impressed with the folded dipole design. As advertised, it packed up easily and without tangling.
For the QLF project, I had to get my code onto an ATTINY 45, which wasn’t so difficult, but also to free up the RESET pin to act as a digital output, which a bit more doing.
My experience with microcontrollers, aside from some PIC activity a decade ago, has been confined to the Arduino, a prototyping platform that hides some of the complexity of creating projects built around some popular Atmel microcontrollers. There are many tools for developing code, transferring code to these chips, and setting the fuse options on these chips, but all I had on hand was my trusty Arduino, so I used it as a middleman to program the ATTINY 45. There are plenty of other options available to get the compiled code (a hex file) into the flash memory of the chip, for example, the USBtiny or the tiny AVR, or the over-the-top Atmel STK600 programmers.
While the ATTINY45’s were on order, I worked out the code using the Arduino itself – this is, after all, its job in life: to serve as a rapid prototyping platform. The circuit was laid out on a solderless prototyping board and jumped over to the Arduino for testing. I realized that I’d need to change some of the pins later, but otherwise the code within the Arduino IDE is the same, whether developing for the ATmega328 on my Arduino Duemilanove or for the ATTINY. There may be differences in the way the code compiles for the different chips, but all that is abstracted away.
With all of the code working when tethered for life support to the Arduino, I needed to migrate it over to ATTINY 45. I found instructions on how to use the Arduino as an in-system programmer (ISP) and how to connect it to the ATTINY on the High-Low Tech website. Their procedure worked for, using my Duemilanove board and version 1.0.1 of the Arduino environment. However, I have a couple comments on their recommended procedure — I didn’t see a place on their website to provide feedback, but it is possible that they’ll have corrected these items in the future:
1. The general idea of connecting the “ISP header” from the Arduino over to a target can be used to program a number of chips, including the ATTINY. The idea is to connect power, ground, MISO, MOSI, SCK, and RESET from one chip to the other. MOSI goes to MOSI, MISO goes to MISO (rather than crossed wiring). The picture shown on the instruction page is correct, but the pin numbering for the ATTINY described below the picture isn’t. It should read:
ATtiny Pin 7 to Arduino digital output 13, physical pin 19 (or SCK of another programmer.
ATtiny Pin 6 to Arduino digital output 12, physical pin 18 (or MISO of another programmer)
ATtiny Pin 5 to Arduino digital output 11, physical pin 17 (or MOSI of another programmer)
ATtiny Reset Pin (1) to Arduino digital output 16, physical pin 16 (or RESET of another programmer)
2. That tutorial recommends installing ATTINY-specific definition files into the Arduino IDE, and points towards a file found on github, https://github.com/damellis/attiny/. This file provides a mapping of the pins on the ATTINYx5. A number of basic arduino functions like the ability read and write to pins will work on the ATTINY, but not the tone() function. Instead of using installing the file from github, I found another core on Google Code, arduino-tiny. This provides not just a pin definition, but a number of libraries like serial, wire, and the tone function that I needed.
3. The 10uF capacitor shown in the picture will not be needed for all versions of arduino; having it probably doesn’t hurt anything, though.
So, to reiterate the main points of that tutorial, the major steps are:
Write code for the ATTINY. Make sure it compiles. Save it.
Close the arduino IDE, add the core definition files to the hardware subdirectory, relaunch the IDE.
Upload the “Arduino as ISP” sketch to the Arduino. This comes with the Arduino distribution.
Connect the Arduino to the ATTINY — six wires.
Select the ATTINY from the “Boards” menu.
Select “Arduino as ISP” from the “Programmer” menu. No change to the serial port settings, please.
By default, without an external clock, the ATTINY will run at 1 Mhz. To get it run faster, make sure that 8Mhz is selected in the board menu, and choose the “burn bootloader” option. It doesn’t really burn a bootloader, but it does set the fuses appropriately in the ATTINY. This operation also wipes out the flash memory in the ATTINY.
Load ATTINY code that you want transferred.
Hit “upload”. The code should transit the Arduino and end up in the ATTINY.
If you want to modify the code, no problem – just edit and upload again.
Physical pin 1 of the ATTINY is typically used for RESET, but to use it for I/O, bit 7 of the high fuse (RSTDISBL) has to be set. Once this happens, the chip cannot be reprogrammed by the ISP method described above — it essentially becomes read-only, unless the chip is restored using a high-voltage programmer – an item that I don’t have on hand (although one can be made with some common parts thanks to various plans online plans). Once I was sure that the program behaved as desired, I looked for a way to manually set the fuses (short of using avrdude from the command line — I’m not quite there).
I came across a program called “hexloader” that can both upload hex files and set fuses without requiring anything beyond an Arduino in terms of equipment. Unless you modify the hexloader sketch, by default it uses other pins to connect to the ATTINY. Arduino digital pins 4, 5, 6, and 7 connect to ATTINY physical pins 7, 1, 6, and 5, respectively. Refer to the picture on the gammon.co.au website.
To change the fuse settings on the ATTINY, open the serial monitor and make sure that the line termination character is set to “newline”. Also, make sure that the serial speed matches up with the hexloader program. A menu will display in the serial monitor; choose “F” to access fuses. The low, high and extended fuse settings were 0x62, 0xDF, and 0xFF.
Adding a high bit in the 7th position to the high fuse, the desired high fuse setting is 0x5F. You could also consult an online fuse setting calculator to see what options are available.
Follow the menu settings to commit this change to the fuses. Once this is done, the hex loader program reports that it can no longer enter “program mode” — which makes sense, since the chip is no longer programmable.
One of the limiting factors in making optimal use of a radio is the number of human appendages that interact meaningfully with the radio, hence the importance of a big knob on the front of the radio and hands to turn it. Morse code operators have known this since the dawn of time and have a Q-signal dedicated to the use of the left foot to send messages: QLF. This versatile expression is more often used in the interrogative, i.e., “QLF?”, or “Are you sending with your left foot?”
There are several physiological reasons why sending code with the left foot is not a good idea, although with practice it might be an option for some. For the rest of us, though, perhaps the left foot could be used for other purposes, leaving the hands free to operate the radio, and more importantly, convey items back and forth from the mouth during radio operation, supplying the operator with the necessary calories and hydration to make it through a contest.
And so was born the QLF Device.
Well, not really.
Several factors led to development of this project. First, our radio club had started using TeamSpeak for internet conferencing. We had run a few CW practice nets on HF, but most of the time, band conditions did not permit all of the interested members to participate, since our members are not just from the local area. This VOIP solution worked very well, and while we know it’s not radio, it’s a fine way to practice.
One issue that arose was that the software worked best in “”PTT” mode, where a key was depressed when the sender wanted to open his/her microphone. There is a VOX option in the software, but it often led to unintentional microphone keying during the session, feedback, and general interruption of the practice sessions. Any key can be designated, but metakeys (like ALT, CTRL, etc.) work best, since they are not likely to be used for anything else during the session. A number of members remarked that it takes some coordination to depress a computer keyboard key with one hand, while working a straight key or paddles with the other.
Another need that has arisen in the past relates to contesting. Foot pedals would be helpful in two contexts: 1) for keying the rig’s microphone PTT during voice operation, allowing the operator to use a hands-free boom mike, and 2) for sending a “CQ” message during a contest. In the former case, we’re looking for some kind of physical connection to either the microphone jack or ACC jack of a rig, in the latter case, since “running” a frequency usually amounts to repeatedly stabbing the F1 key of some contesting software (e.g., N1MM) to play a canned message or send a CQ message in morse code, what we want is a means of sending the “F1” keystroke to a computer.
These thoughts were rolling through my head when I noticed that Adafruit was offering a foot pedal switch at a reasonable price ($7.95 for single units, less if ordered in quantity). I ordered a few to check them out, and while awaiting delivery, sketched out the “design spec” for the QLF device:
The QLF should allow direct control by making or breaking a connection for physical switching, i.e., for microphone PTT.
The QLF should send “keyboard” characters — at least two of them: F1 and a meta character
When sending keyboard characters, the device should operate in three modes: a) PTT (continuous while pushed); b) One shot (no matter how long QLF is actuated); c) Toggle on/off (to avoid fatigue)
The QLF should provide adequate feedback for the user to know which mode and character are selected
The QLF should be dead simple to operate, even after 24 hours in the contest chair on a diet consisting solely of cheetos and lime diet coke.
The QLF should be relatively RF resistant
The QLF should not require its own batteries and shouldn’t consume much power
The QLF should be smaller than the rig it operates
The QLF should be cheap. Like, less then ten bucks or otherwise made of stuff in the junque box.
Before deciding on how to hook things up, a few dissections were in order, starting with the foot pedal. The construction of the foot pedal appears to be sturdy. It has a hard plastic upper portion, which seems thick enough to stand on and the bottom portion is metal. Although there might be enough room inside the pedal to stash some components, it doesn’t seem easy to open the case.
A grey wire about two meters in length emerges from the back of the switch. Slicing the wire open reveals three internal conductors: red, white, and black. There is no shielding on the cable, and no ferrite is present. If RF were a problem, it might be worth replacing this wire with a shielded cable (for example, a sacrificed USB cable) and slapping ferrite clamp around the wire on the end that attaches to the QLF device. So far, this hasn’t been necessary, though.
The three wires allow the switch to be used to either open or close a circuit. Red and black are normally connected, but depressing the switch breaks that connection. If you use red and white, you get the converse case, which is likely of more use. My plan was to terminate the switch wire with a 3.5mm connector so that I would have maximum flexibility in connecting devices to the switch, depending how I wired the jack connecting to the device (i.e., a radio or the QLF device). Since red is common to both configurations, I connected it to the barrel, and soldered black to ring and white to tip. This means that I can use the cheaper mono jack or stereo jack to access the red/white combination.
The next step was figure out how to make the action of stepping on a switch send one or another character to a computer, presumably over USB, since PS2 connectors are now passé. Again, I started with some dissection to understand how keystrokes are normally sent from keyboard to computer. Actually, there are plenty of fine descriptions of this on the internet, so it wasn’t so much a matter of understanding as needed to harvest the brains of a few keyboards for use in this project.
Starting from an existing keyboard seemed reasonable because 1) the number of trashed usb keyboards on this planet exceeds the number of rats; 2) USB is complicated, and developing a device to duplicate the functionality of a keyboard seemed like a difficult and potentially expensive way to start.
If you rip apart an USB keyboard, there are usually three layers: the keys, a rubbery mat, and a matrix of conductors printed on plastic sheets. Conductors from the upper plastic sheet are brought into contact with the lower sheet when keys are mashed down. The conductors all lead back to an edge connector, and a small logic board attaches to the plastic sheets at that point. Usually, there are about 25 to 30 pins that join the board to the plastic. One sheet connects to about eight of the pins, and the other sheet to the rest. The USB cable itself also connects to the board — two data lines, a positive, a reference ground, and a shield ground.
Without really knowing too much else about how all this works, it was clear that connecting some of the pins to other pins would send characters to the computer… but which pins? One internet how-to site recommends tracing the keyboard key layout onto the plastic layers and then obsessively tracing each one back to the edge connectors to create a complicated map. That should appeal to anyone who has enjoyed mapping a maze of twisty passages, all alike.
I opted for plan B — a program that runs on the computer and displays which character is being pressed. I downloaded keyposé, a program that is free for private and academic use. It ran fine under Windows XP SP3. The program was developed to assist in creating software demos. When this program runs, it will indicate which key is pressed, whether on the computer’s main console keyboard or on another one attached to a USB port. The beauty of this program is that it shows which meta keys are being pressed, or even which combos are pressed.
I initially mapped the keyboard logical module pins by noting which character appeared when I connected every permutation of pins, i.e, pin 1 and 2, pin 1 and 3, pin 1 and 4, etc. This yields a matrix which has both some blank spots and some redundant spots. After I did this with three keyboards, I came to the conclusion that this mapping is not standardized, even for a given manufacturer, so this process of figuring out which pins are important cannot be avoided.
However, there is a short cut. Since we’re only trying to fire off the F1 key and some other meta key, why bother mapping all the keys? First, concentrate on finding the two-pin combination that produces F1. If possible, see if either of the pins involved can be paired with another pin to produce a meta-character. If so, this makes life easier later on and saves on part count since one pin can be common.
How smart is it to take a piece of wire and start strumming it across the connector pins, while the logic board is plugged into your valuable laptop via the USB cable? Well, I can only give you my experience — nothing blew up. Most laptops are smart enough to shut down a USB port when the current draw exceeds specification. Even so, it might be a good idea to use an older laptop or to connect via a USB hub for testing.
After using a piece of copper wire for this purpose for a while, it occurred to me that they keyboard itself might have some resistance between leads rather than a dead short, as some of the runs of ribbon-thin conductor are pretty long. I measured between 30 and 70 ohms resistance on average for short and long runs, so some small value resistor might serve the purpose better than plain wire, but using a wire didn’t seem to harm anything when I did it.
Since the solution is now to make a connection between different pins to send either “F1” or a meta-character (I settled on “CTRL”, but any would do), the next step was pretty obvious – to use a transistor as a switch between the appropriate pins. To get all the functionality of the different “modes”, though, would require some circuitry upstream of the switching transistor. My first inclination was to use a microcontroller, but that seemed like overkill and probably not the cheapest way to get what I wanted. Instead, I opted to use a couple old workhorse components. Power for the circuit is derived from the USB cable itself. The USB standard guarantees up to about 500mA available, and we won’t come near that.
A single SP3T switch selects the mode (PTT, one-shot, or toggle on/off) by directing the appropriate high output signal to the gate of a 2N7000 N-channel MOSFET. This switches the MOSFET on, and current flows through the pins connected to the MOSFET’s source and drain. I had measured the voltage on those pins before connecting, and the higher voltage should go to the drain, and lower or ground to the source. If you get this backwards, it’s not a problem, but the MOSFET will conduct all the time, and this will be apparent because the keyposé program will show that the character is being sent constantly. Since there are two characters that potentially could be sent, a second switch directs the appropriate pins to the source and drain terminals of the MOSFET. The state of this version 1 QLF device is always obvious from the position of the switches, one for mode, one for character. Since the gate of the MOSFET is brought high whenever a character is sent, an indicator LED is also attached to the gate. When the LED glows, a character is being sent; this provides some useful feedback to the user about what is going on during normal use.
The PTT function is the most straight forward. When the foot pedal is depressed, the base the 2N3906 PNP transistor pulled to ground and current flows from +5V on the collector to the emitter, and through the mode select switch to the MOSFET described above.
The one-shot function is desirable because sending multiple key strokes quickly to a program like N1MM results in a string of CQ messages being generated, one after the other. Similarly, holding down the character on a keyboard could result in repeated generation of the character. Since neither case is what the user usually intends, the purpose of the one-shot is to emit a single keystroke, even if two switch closures happen very close together (i.e., switch bounce), or if the switch is held down. You can stand on the foot pedal, but you’ll only get one keystroke when this mode is active.
To achieve this functionality, a 555 timer is used in monostable mode, with its output (pin 3) connected to the gate of the 2N7000 MOSFET via the mode select switch. The 555’s trigger pin (2) is normally pulled high. It connects to the switch through a 0.1 uF capacitor. When the switch closes, that capacitor is grounded and pin 2 sees a transient dip in voltage — enough to satisfy the op amps inside the 555 that something important is going on. The 555 fires off, and the duration of its output on pin 3 is determined by the combination of the capacitor and resistor connected to pins 6 and 7; specifically, the duration in seconds is 1.1 * R * C. I went with a 0.1 second pulse because this should be long enough for the logic board to register this keystroke and not so long that it starts repeating. The tolerances of electrolytic capacitors are not precise (particularly when they have been sitting in the junque pile for an indefinite period), so best not to choose to low a value for the capacitor. The LED provides a direct read out that the one-shot is functioning as designed.
Finally, there is the toggle on/off mode. This mode is meant to spare operators some foot fatigue. Rather than hold down the pedal for their entire long-winded transmission, the pedal can be pressed once at the beginning of the session to key the computer (and/or rig), and then again at the end to unkey it. What is needed here is a T-flip/flop circuit – a circuit that can remember its state, and every time it is poked, change to the complementary state.
I grabbed the cheapest, simplest IC that I had on hand for this purpose, but many substitutes would also work here. There are plenty of references on the internet about how to make other kinds of flip-flops (e.g., a JK Flip-Flop) replicate the function of a T-flip-flop, but I used a 74HC4024 ripple counter which internally has a series of T-flip flops. I pulled down the reset line of the counter to take it out of the equation, and then just drove the clock input from the output of the 555 timer. Now, every time the 555 emitted a pulse, the first flip-flop in the counter would change state, high or low. That flip-flop’s output was connected to the 2N7000 MOSFET through the mode-select switch. The rest of the functionality of the counter was not used, which seems like a waste until you learn that the cost of the chip, new, is 37 cents.
The general solution for connecting to the pins on the logic board is to use a DPDT switch. However, if a pin combination can be found such that one pin is in common for both F1 and a meta key, a cheaper SPST switch can be used — the common pin goes directly to the MOSFET, and the switch just selects which of the other pins connects to the other side of the MOSFET.
A few items were thrown into the design for good measure — decoupling capacitors on the ICs, as well as one across the switch leads. That latter capacitor was meant to shunt high-frequency RF from the switch line – but I don’t know if it actually helps. The capacitor on the reset line of the counter chip is not a decoupler – it’s job is to transiently go positive when the circuit is energized, putting the counter in a determinate state at power up. This assures that initially, if the device is put into toggle on/off mode, it will be off. (One corollary of this logic is that if the device is later switched into toggle mode, it might be in the “on” state, since the counter will receive one-shots from the 555 every time the pedal is down, even when other modes are active).
Finally, I added a 56 ohm resistor between the logic board pins, since this would come closer to the real resistance of a keyboard. I have no idea if this is important or not, but resistors are cheap.
I felt good about this solution, so I transferred the circuit to vector board and stuck it in a cast aluminum case strong enough to survive the zombie apocalypse. To get it into a case, I made a sandwich, with the keyboard logic board on the bottom, some spacers, and the vector board on the top, with various screws to hold things in place. The most expensive part of the project was the $5 box (not counting the cost of the pedal itself, since it can be used for other purposes in addition to the QLF).
In developing version 2 of the project, I wanted to try a microprocessor solution to the same problem. The motivating factors (aside from, wouldn’t it be cool?) were:
To save on hardware costs. The electronics in version 1 were all cheap, but as often is the case, most of the cost came from the mechanical items — toggle switches and the case itself. A smaller case with cheaper switches would be preferable.
Flexibility – rather than “coding” everything in wiring, a microprocessor-based QLF could be “reprogrammed” to some extent by popping the chip, re-flashing it, and sticking it back in.
Lower part count – in principle, the core functions could all be done in one rather than two chips, without outboard resistors and capacitors to handle timing, trick the chips into triggering, etc.
Better user interface, in this case blinky lights and sound. Not absolutely necessary, but nice touches.
I started roughing out the design using an Arduino Duemilanove, but my intention was not to include this prototyping platform in a final product. After all, even an older Arduino costs above 20 dollars. The ATmega328 used on this board also seemed like overkill – much more memory and ports than needed, and in a 28pin package, larger than I would have liked.
Instead, I went with the ATTINY45, a chip that costs less than a dollar, and which can be programmed via the familiar Arduino IDE with minimal additional effort (described in the next post). The challenge in using the ATTINY chip was to achieve all the desired functionality using a chip with a limited number of pins devote to input/output.
The vision for the version 2 design was to have two push button switches, one for mode and one for character. Pressing the mode button would cycle through the three modes available: PTT, one-shot and toggle on/off. To keep track of this, we’d need some indicator, since switch position would no longer tell use what mode we are using. The character select would toggle between F1 and meta-character, and again, we’d need some indication of which character was active. As in the previous design, we would also need some way of reading and acting on the pedal switch state.
One frill I wanted in this design was an audio indicator for mode and character, since the QLF might not be visible from the operating position. The tone function is part of the standard Arduino library and it is easy to drive a piezo speaker using a single digital output.
The ATTINY series chips have 8-pin chips, and the models differ in amount of flash memory: ATTINY 25, 45, and 85, have 2k, 4k and 8k, respectively. Two chips are devoted to power (Vcc, GND), and one is used to reset the chip. Of the remaining, two pins are connected to a crystal to provide an external clock, leaving three pins. This is clearly not enough for everything described above. However, between the chip’s versatility and some design tricks, a solution was found.
First, the external crystal was dropped from the design. The ATTINY can use an internal RC oscillator for a time base. It is less precise, but nothing we’re doing here requires exquisite timing. Depending on how the chip’s fuses are set, the RC oscillator can generate a 1 Mhz or 8 Mhz clock. I opted for 8 Mhz, but 1 Mhz probably would work, and would take less power.
Refer to the version 2 schematic for the following discussion:
Next, the three switches (pedal, mode, character) were multiplexed onto one analog input. The switches connect in common to one side of a voltage divider, and each switch connects to ground through a resistor with a specific value. The values were chosen (see spreadsheet) such that even with maximum tolerated deviation of the two voltage divider resistors, the resulting voltages would fall into non-overlapping ranges as detected by the chip’s ADC (1023 values, from 0 to 5V).
For indicators, one digital output was devoted to a single LED for mode: off for PTT (default), on for single shot, and blinking for toggle on/off mode. Another digital output was devoted to which character was selected. A design decision was made to indicate F1 on one LED, and the meta-character on the other LED. This design used complementary transistors to assure that one of the two character LEDs was always lit. Another option that would have saved a few parts would have been to use a single LED with it off state representing F1 and on state representing the meta-character. This seemed like more to remember, though, versus having the name of the character written next to the LED on the case.
Two 2N7000 MOSFETs are used in this design, one to switch on each pin pair on the keyboard logic board. A digital output from the microcontroller is directly connected to the gate of each MOSFET.
With this layout, the design was still a pin short — the one needed to drive the piezo element for sound. This was a workable design, but to get that last pin required special effort. I’ll describe how the ATTINY was programmed from the Arduino IDE, and how I freed up the RESET pin to use as an output in the next post because it does get a bit more hairy.
Sound is used in this design by beeping one, two or three times in a high tone to indicate mode, and once or twice in a lower tone to indicate which character is selected.
Here is some pseudocode for what’s going on inside the ATTINY:
The code that I actually wrote for the project can be found in a repository on Google Code. If this code is loaded on a chip that has not been modified to use the RESET pin as audio out, the code runs normally, but of course there is no sound output. The code compiles into less than 4K, so it will fit on an ATTINY45. Without the sound-related routines, it would fit on an ATTINY25. Counterintuitively, when I went to buy chips for this project, ATTINY25 was more expensive than the 45, and the 45 was just a couple cents more than the 85.
The version 2 board was smaller than version 1 and fit in a smaller a marginally cheaper aluminum case. Overall, this is a less expensive approach, but not by too much (see spreadsheet). The main cost drivers are the mechanical components in the first design, but purchasing the items in bulk and/or from ebay brings the prices down considerably. The cost of assembly also depends on what is in the junque bin. In both designs, most of the components are very common, and there is considerable latitude for substituting other values.
I did attempt a third version — one that doesn’t require gutting an old keyboard, but this approach hasn’t really paid off at this point — except as an example of what not to do. I’ll write up that experience, but first, more details on programming the ATTINY45 (next post).
Postscript 1: In retrospect, an obvious source for the flipflop in the QLF version one would have been another 555 module. One 556 could serve both purposes. This is the sort of thing I think of after the project…
Postscript 2: With USB integrated into more modern arduino and work-alike boards and the boards becoming so cheap, the project could be done in software only, without having to dumpster dive an old keyboard control board. But where would be fun be in that?
VAQP 2013 didn’t go quite the way I’d imagined it would, but it was still fun. Getting N1MM set up the night before the event, I was surprised to see fields for an exchange number. I’m pretty sure this was a new feature, and I’m not sure how popular it will be with people who prefer more casual operation in state QSO parties.
The contest ran from 10 am to 10 pm on Saturday and 8 am to 8 pm on Sunday. I spent Saturday with the Vienna Wireless Society, operating from the Annandale Swim Club. We got to the club at 9 am and it was probably unrealistic to think that we’d have antennas up, rigs configured, and N1MM networked by 10 am.
We had some technical difficulties — our spud gun line broke a few times, the reels jammed, and trees claimed a lot of line and a few spuds. At one point, while I was working on another antenna placement, I noticed the other antenna hanging team trying to get one of our fouled lines out of a tree using the tools at hand: a lifeguard chair and a pool net.
It took a couple hours to get the antennas deployed. With the contest starting at 10 am, we started operating from the parking lot. I popped the tarheel antenna on my car, tuned to 40 meters, and Kevin WB0POH began working stations. By the time we had the indoor stations set up and configured, he had worked fifty contacts, including the bonus station, K4NVA. I think all his contacts were CW, so worth twice the points to boot.
I’m not sure why, but we were not able to get the two logging computers to talk to each other. We tied them both into the club’s router, which should have worked like a hub. Both computers received DHCP addresses, and as far as I could tell, could see each other on the network. Not wanting to waste any more time, I set up the voice station to start with an exchange number of 500, while the CW station continued to build on Kevin’s earlier contacts. I’m sure hearing our SSB exchanges in the 500 range early in the day put the fear of god into our more competitive neighboring clubs. Heh.
The CW station was set up in a different room from the SSB station, and we had a counter and some stools as operating space. After sitting for a while, I got rid of the stool and used the counter as a standing desk. It felt good to dance around while working CW, and I think I might try for this sort of set up in the future as it keeps the blood flowing. Ian, N0IMB, took some video of TS-450 I was using. Unfortunately, the video does not capture my dance moves. You can’t hear the dits and dahs on the video because I’m wearing headphones.
We broke down our field stations and took down the antennas on Saturday night. The next morning, I set the home station up again. I had brought a number of station items to the field, so I had a little rewiring to do before I could get on the air Sunday morning at around 11 am. I worked intermittently until the end of the contest at 8pm that evening, but had a number of fairly large breaks to take care of family, do chores, etc. I entered as single-op, all bands, low power (100W), CW-only, non-assisted, one radio.
Propagation was so-so, and I kept hoping that after a break, it would improve. It wasn’t just my imagination: conditions were much better on Saturday. Looking at the space weather data, a CME thrown on Friday hit the ionosphere Sunday morning, just when I was starting operation. The K-index bumped up to five and stayed there the rest of the day. Conditions did seem to improve as the day went on, but this perception may also be a matter of more people joining the contest for the last few hours.
I spent almost all of my time on 40m, using the attic dipole rather than the outside 40m vertical that does better in DX contests. I had good coverage of New England earlier in the day, and worked westward into Wisconsin, Kentucky, and Arkansas. Operating NVIS, I had a reasonable chance of operating other VA stations, including VWS club member Kevin, WB0POH.
Twenty meters was not as helpful as I’d have liked — at one point, Europe opened somewhat, and I worked a succession of stations in Poland, Germany and the Slovak Republic. Later in the day, I had a brief opening to the west coast: WA, OR, and CA. Otherwise, 20m was my direct line to Florida. I did reach two stations on ten meters, but probably ground wave.
In the last hour and a half, I did good business on 80m, where I mostly ran into stations that I had worked on other bands.
I was surprised in the contest how many times I was called by stations that I had already worked. As a matter of course, I worked them again. Maybe conditions were marginal on some of those calls, and maybe they just wanted an insurance contact. I didn’t hear anyone else operating from Fairfax City (FXX) — at least not on CW — so maybe my exchange was in high demand.
My final tally was 166 contacts (some dupes), with a paltry 26 Virginia City/County, 23 State/Province, and 3 DX entities. If I calculated correctly, I may have nosed over 20,000 points. Not a great performance, but not too bad considering time and conditions.
As for the club log, I’ll have to more or less manually merge the databases from the two workstations that we used into one file for submission to the Sterling Club which runs the VAQP.
It occurs to me that I’ll likely be writing about the Significant Other project for a while, so it now gets its own category on the blog. I’ll go back and fix the tagging on older posts to be consistent.
The main board and relay board prototypes are in a final enough state that I can begin to work on firmware. Rather than start from scratch, particularly as I don’t have a lot of experience with this type of project, I decided to look at similar projects with open source code for both ideas and potentially as a scaffold for this project’s firmware.
I have come across the K3NG cw keyer, which is as full-featured a keyer as you could ever want, and which is written in such a modular and generalizable way that it can be made to fit on a variety of chips, depending on their resources and which features are included in the build. The package also includes a serial interface, command-line mode, and debugging features that should make the development process as painless as it can be.
I hadn’t seen this project while I was planning the main board, but the hardware layout envisioned in the K3NG keyer was very similar to what I had come up with, so it took minimal work to get it running on my main board.
The K3NG code lives in a sourceforge repository, and one of my first concerns was how to manage the code base. Considering that the S.O. is a specific design (and perhaps one that only I will ever care about), it seemed reasonable to take the most recent version and start a separate repository — I guess this could be considered a fork. To keep things organized, I’ve deposited that code, some test programs for individual subsystems, and the schematic on GoogleCode. As with other projects, I’ll update the repository whenever I’m working on any of these files.
I spent a few days reading and pondering the K3NG keyer code to get the gestalt. It is very well organized, and every feature can be enabled/disabled through compiler directives. It may be poor programming practice, but I decided to thin out the code to make it easier to work with. I realize that having features commented out so that they are never compiled has the same effect in terms of final size of the compiled code that will be programmed onto the chip, but I felt that I needed to remove sections that are not part of the intended application for the S.O., particularly since I’ll be adding other features.
Consequently, with some reluctance, I performed some surgery, removing fun stuff like code practice, CW receive decoding, and the extensive winkey emulation functions. In developing this device, the code will become less general. For example, instead of an expandable number of buttons, the S.O. front panel will have four. All feature selection will take place through these buttons and the LCD display, rather than via the paddles. This is consistent with the design goal of not being able to leave behind anything when heading into the field to operate — if you forget the paddles, you should still be able to have QSOs. To that end, the front panel buttons have been modified so it is possible to press two of them at a time — in a pinch, the front panel buttons themselves will be able to serve as a straight key or iambic paddles.
For all I took out, the core keyer functions still take a good deal of space. I’ll have to see what the trade offs are in implementing a menu-driven interface and then in adding the clock, frequency counter, and antenna tuner functionality. Fitting it all in will take some doing — I hope it is possible. I’m sure that during development, I’ll have to turn off some features to test others if I want to make use of the serial interface and debugging features.