Monday, May 11, 2015

Tektronix 2246 Repair Part II

In the process of debugging the strange intermittent display issue on my Tektronix 2246 after re-capping the power supply, things are not looking so good. Things have actually gone from bad to worse. First of all, the short (or open connection) somewhere in this unit which I can return the unit to normal operation by twisting the chassis has been more difficult to find that planned. I pulled and went through the entire power supply again and did not find any issues. Same for all of the connectors, all are seated correctly without issue. Every screw was in place and I checked to make sure there were no poor grounding issues throughout the scope. What happened next is the result of my own stupid mistake (again) which is just making things worse.

In the process of removing the power supply, you have to remove the high voltage anode cable to the crt which is generated in the main power supply. This cable runs out of the supply towards the front of the unit and has an insulated high voltage connector that is clipped on the the metal chassis between the power supply and front panel board. When I was pulling the power supply out for the third time, I wasn't careful and unplugged this connector only a minute or two after powering the scope down. At this point I let the cable go and it fell towards the A16 main processor board letting a nice spark jump from the high voltage cable to the main board most likely due to stored capacitance that had not been bled off yet. I didn't see exactly where it hit, but it didn't matter. The stored voltage had hit the board and I knew damage had been done. Upon reassembly and power up it was confirmed.

The display was in bad shape at this point, everything to the left say 2/5ths of the display was not showing up and squashed into a vertical line. Definitely not good. So now my priorities have changed, now I have to debug this issue to make sure I haven't burnt out something serious like the main display DACs or readout processors as these would most likely be difficult parts to locate and replace.

I started right with the schematic, which was my next stop anyway in locating the intermittent display issue. The full service manual including schematics is easily available for this scope which is another reason why I love the older Tektronix gear. I focused right away at the character generator and display readout circuitry.

After some probing around, I noticed that output from the A16 processor pcb was odd, the horizontal output drive for the display was not looking right, the bottom half of the waveform was clipped which would explain the left half of the display being smashed into a vertical line. Further up the signal path, the signal was looking correct from the DAC and the multiplexer. So the final op amp stage was looking to maybe be the culprit which makes sense as these op amps definitely wouldn't survive a direct high voltage hit.

Output of mux on left, output after op amp on right
So only the final output stage from the A16 pcb was looking bad, this is a good sign as the actual logic does not look to be damaged. Only the final outputs through an op amp look to have been hit. The op amp in question is a TI TL074. There still may be more damage but I'm going to focus on this op amp for now. I didn't have any in my parts bins, so I placed an order for a handful with Digikey which I should have in a few days. Stand by for part III.

Saturday, May 9, 2015

Tektronix 2246 Repair

Last year I had talked about how I accidentally destroyed my Tektronix 2246 oscilloscope by removing the cover. There was a small dent in the metal bottom panel that while removing it had snagged a heatsink on a Motorola 151-0846-00 labeled TO-39 transistor, specifically Q702 on the A10 main board. This ended up ripping the pins out of the transistor can leaving me with a unusable scope. Unfortunately this was not a common part and trying to locate one is next to impossible. I had attempted to use a 2N3866A with no success, the scope was definitely not happy with that transistor in it, an original replacement part would be necessary.

I did ultimately find a donor board. Late last year I found a complete used replacement board on eBay for around $40 which contained both of the 151-0846-00 labeled transistors. This option was definitely cheaper than a whole parts scope and I would hate to ruin another 2246 which may be repairable just for this one transistor. Once I replaced this transistor in my 2246 it was good as new.

I want to focus the attention now to a second Tek 2246 scope that I own with its own set of troubles. I purchased another 2246 a few years ago for cheap, I think it was only around $100. This scope had a lot more use than my original one, while it was in good cosmetic shape it had some issues mostly related to old capacitors. The display was not stable, the character generated osd and cursors would jump around and upon probing the supply rails you could see there was some noise present. A re-cap would be necessary and possibly some additional caps on the A-10 main pcb if necessary.

The 2246 main power supply is pretty basic, much more simple to work on than the Tektronix 2445B power supply which I have also done. One interesting observation upon accessing it is that all of the caps look to be large axial electrolytics:

Trktronix 2446 Power Supply

The bottom of the board told a different story, and once removing a capacitor and testing it was indeed a standard radial cap with an interesting third lead out the top that wasn't connected to anything. Maybe it was designed for additional stability? I know this scope was a popular portable model so my guess it was just some additional ruggedness built into the design. Interesting regardless, at least I can replace them with standard radial caps which are much easier to source.

Replacement caps were all Panasonic 105 degree C. units which are always my first choice, then using Nichicon capacitors in cases where the Panasonic's were not available. The final rebuilt version looked like this:

Tek 2446 Power Supply Rebuild
Quite a difference in size. For good measure I also replaced all of the high voltage film capacitors on the board, many looked stressed as they did in the 2445B. I left the large primary switching capacitor alone, they are rarely every a source of trouble. Everything else looked okay.

This is where things started to get interesting. After putting everything together and powering the scope back up, I had strange display issues. The entire display was shifted left. I started looking around to see if I had missed a cable or possibly had a connector loose during the reassembly but didn't see anything obvious. This scope was working just fine before the power supply rebuild so this issue was definitely something that I caused. At this time I went to turn the scope over on its side while powered up that the display snapped back into alignment. After some more poking around I realized that if I put pressure on the chassis, twisting it just lightly I could get the display back in alignment. So it must be a bad ground, loose connector, bad solder joint, or some other mechanical failure where putting pressure on the chassis would complete whatever broken connection was occurring. It will just be a matter of tracing down where the issue is at. More to come in part II.

Friday, May 8, 2015

Large Display for GPS Disciplined Time Server

Since building my own GPS disciplined local time server I have wanted a large display of some sort to display my super accurate clock. The primary purpose of doing this was really just because it would be rally really cool looking. I also have a personal issue with any clock that does not set itself from the WWVB or support NTP, in 2015 we shouldn't have to manually set clocks anymore. A secondary use for doing this would be for ham radio purposes. A nice large clock that is always accurate so I can easily and quickly log contacts in UTC would be very useful. Ultimately I ended up with a very nice solution and here is the result:

ESE ES-166 timecode display used for GPS clock

Searching for someone who makes such a clock was frustrating. It seems either you can have a large format clock for cheap that does not support NTP, or you can have one that does support NTP but costs hundreds of dollars. Designing and building my own was the next option that I had considered for awhile. A simple PIC based device that drives some large 7 segment led displays would be trivial to build, but I couldn't get into the project. It just didn't excite me, It's one of those things that would be so simple and mundane that I just couldn't drive myself to do it. It would be like a software engineer being assigned the task of writing a word processor. It's already been done so many times and is such an unfulfilling project you can just never get excited about it.

So on to Plan C. Let's see what's already available and either modify or make it work for my intended use. Basically I would be looking for a large LED, backlit LCD, or big VFD display of some sort that would be able to easily display time. Input can be via various means, ethernet or serial would be first choices, some other parallel type interfaces would be not ideal although I could still make it work if needed. Luckily having some experience is professional video editing when I was in college, I looked towards something I felt might me the perfect solution: Timecode displays.

Upon scrounging around I found a perfect device on eBay, an ESE-166 remote timecode display. These can be found for less than $50 at times are are beautiful pieces of gear. It is a big 2U rack mount enclosure with a nice large format LED display on the front panel. This display is designed for displaying accurate time code for video editing systems. The particular display I purchased had hour, minute, and second digits which would be perfect. Many time code displays also include a 4th digit section for frames which this one did not as I did not need it for my purpose. The inputs on these devices are typically a single 75ohm timecode serial input for SMPTE timecode. I was fine with this as designing some hardware to convert an rs232 serial stream to SMPTE timecode actually sounded pretty fun, but I ended up not needing to. This specific display also included an rs232 serial input that supports a few ASCII time formats. This would be a perfect solution, just have a script that takes my local time directly off of the time server itself and dump it out the serial port to this display. There would be some very minimal latency with this obviously, but regardless this solution would be perfect! The ASCII format I chose to use is as follows:

Format #0: (CR)(LF)I(^)(^)DDD(^)HH:MM:SS(^)DTZ=XX(CR)(LF)

As for getting the time data into the ESE, it has two runtime options set by some dip switches inside. The first is a free running clock that when the serial port receives a time string, it updates the internal clock to the time received. The second option does not free run, you simply continuously provide the time signals to update at the interval you specify. In this option, you would need to provide the time signal at least once a second to keep the display real time. For now, I went with the first option. I have the ESE free running with a cron dumping data from my NTP server sending an rs232 time string via cron every five minutes. The noticeable time drift of this clock over a five minute period is not noticeable at all and this solution keeps the clock up to date on five minute intervals without having to constantly send it serial data.

For those that are curious what is inside the ESE ES-166, it is pretty basic:

There is a whole lot of room in that chassis with not very much there. Just a mains transformer and simple analog rectified power supply with a handful of logic to decode the SMPTE / serial port data and drive the display. I'm planning on moving my Trimble GPS receiver inside of this case as there would be plenty of room for it. This would consolidate some of the hardware laying in the back of my server rack.

Additionally the manual for the ES-166 includes a schematic which is also nice to see. There was one part of the design that I really loved, the rs232 to TTL translation:

There is no serial driver there, MAX232 or equivalent. Just a simple level converter based on a 2n2222 with a diode and resistor. I love it! You see MAX232s in everything these days when they are often just not needed for serial RX conversion.

Further plans include racking this unit in my server rack and possibly getting a second unit so I can display both local time and UTC.

Wednesday, April 1, 2015

IoT Security Fail

So I am not a huge fan of the whole Internet of Things movement that is going on right now, mostly due to the recent lack of any real security or thought of security being placed into these IoT devices. A more accurate name for the IoT would be the Internet of Insecure Things (IoIT). Recent (or not so recent) news of consumer home wireless access points and routers being compromised and used for various botnets are one example of this concern, and this is just one small example. Home routers, thermostats, IP cameras, VOIP phones, DVRs, smart TVs, etc, all things that can contain embedded firmware of now outdated or obsolete libraries that are exploitable. And if they are not exploitable, great, there is probably just some hard coded admin user and password in the device or another debugging backdoor that was forgotten to be disabled.

'Junk Hacking' is a term I like that is used to describe people finding exploits in these devices, it seems every week there is some new little embedded device that has a vulnerability. Stop. When these stories break, everyone always seems to be surprised that there is a backdoor or other exploit on IoT device N. Really?! Of course there was a vulnerability on it! I would have only been surprised if there wasn't! I go by the opinion that every device is vulnerable. Proving me correct is not difficult, proving me wrong on the other hand would actually be impressive.

Now sure, most of these devices (with exception to the router itself) will live on a home private network and all have private ip's assigned by the routers DHCP server, so risk to them should be very minimal even if they are vulnerable in some way or another, although wireless devices are an exception. Some vulnerabilities require physical access to the device as well, which imo is not really a vulnerability (anyone can re-flash devices if it's physically in your hands ). That said, it is amazing how many of these devices end up being publicly accessible on the internet, either on public ips themselves or port forwarded to private ips. Not excluding commercial and industrial devices as well, they are also exposed everywhere. Everything is just hanging out waiting to be poked at. Having convenience over security seems to be the norm.

Favoring backwards compatibility is another issue that needs to be overcome. 'Well, it needs to work on IE6!' No, actually it doesn't, and it definitely shouldn't. This mentality needs to go away. Software goes obsolete for a reason, and that is because it's usually broken. This rule needs to be enforced by all.

The wireless side of things is the same story. Wireless ISM band mesh devices are the new hotness with everything communicating over ZigBee, Z-Wave, or other protocols. You don't need to look hard or far to find known vulnerabilities in these protocols or tools to sniff these networks. While sure, newer devices will have updated firmware with possibly better encryption and security, what about all of the existing devices in the wild?

While manufacturer of devices intentions may be good to keep devices secure and up to date, the real result of these devices is that none of them actually are. The OpenSSL vulnerabilities that occurred last year and recently are an example of these concerns. How many of these devices are still running an old version of OpenSSL? Probably most, unless of course you have updated your firmware, which I know usually never actually happens. This is assuming new firmware is even available.

This issue of updating these home devices to keep them up to date ends up being your (the consumers) responsibility. Manufactures are more than capable of having their devices auto update when new firmware comes available, but the risk and cost would be too high in doing so. The day that the device auto updates and becomes a brick because of a mistake is just too high, especially if it happens to thousands of devices. Manufacturers could of course design in fail-safes to prevent this, things like dual flash memories for running and updated configs allowing a rollback option, but this would of course increase costs. Plus manufactures don't want to have to support their own devices, that is just additional cost.

So the result is it is your responsibility as the consumer to make sure your device stays up to date. I'm not okay with this, but you have no choice. The alternative is to not use the device, if it isn't on, it is not vulnerable. The real issue falls onto the larger portion of the population that doesn't really know or understand, or care to know or understand security, networking, or recent CVE listed identifiers that come out, not to mention understand the actual details of the vulnerability. It is this group of the population that results in everything being at risk, but I don't believe they should be held responsible. Maybe manufacturers should be responsible for the security and patching of their own devices. Maybe they should not be designed so insecure in the first place.

So what is the solution? Should manufacturers be more security minded and allow automatic updates to all IoT based devices? Sure, that would be a good start. Putting any actual thought and time into security in the first place would be another great idea. Having anyone who actually knows anything about security audit your product before production would probably catch a lot of the really stupid mistakes. Another thought would be to not make every device IoT enabled if it doesn't half to be in the first place. Just because something could be internet enabled doesn't mean it should be. I'm pretty sure I have been hearing news of internet enabled refrigerators for over 10 years now, even seen one or two in some stores. Everyone thinks its neat and cool and somehow it will be useful as it solves a problem that doesn't exist. I just know it will be end up being another vulnerable device.

Friday, December 5, 2014

Stratum 1 Time Server Based on a Trimble Placer GPS 450 with PPS Output

Setting up GPS disciplined stratum-1 timeservers are not a new or technically difficult task, plenty of articles are already available including some excellent ones from David Taylor's site. The basic idea behind using a GPS device as a stratum-0 reference is the ability to have a very low latency and low jitter accurate local time source. The only complicated part is finding or modifying a GPS receiver that can provide a precise 1 pulse per second source.

This post is going to focus on a simple, inexpensive, and somewhat elegant solution based on a Trimble Placer 450 GPS receiver. The Trimble 450 is by no means a modern device. It was originally produced in the 1990s and used within vehicles for fleet management purposes. It is large compared to modern units and is also only an 8 channel receiver that uses only satellites in the US GPS satellite constellation. The reasons why I really like the Trimble 450 are that is is very rugged and well designed (as it was to be used in the field). It can also run off of a wide voltage supply range and it is easily modified for a true precise 1 pulse per second (PPS) output which is the key part to having an accurate stratum-1 time server.

Trimble Placer GPS 450s are plentiful (there are available on eBay all the time for less than $15 including shipping). I had a unit myself sitting in a parts box for maybe 10 years that I picked up somewhere for free, this is why I went with this unit to begin with as my time source. I also love re-purposing old and somewhat obsolete inexpensive hardware. You will need an external active GPS antenna to use with it, any cheap ones from China will work, the one I purchased was $6. Note you will need an antenna with an MCX connector (or adapter) to interface to it. One additional nice thing about the 450 is you can easily replace the on-board MCX connector with an SMA, BNC, etc if you wish.

By default the Placer 450 outputs a Trimble ASCII Interface Protocol (TAIP) serial datastream, but this is easily changeable to NMEA-0183 strings. Going through the docs I believe gpsd is capable of decoding TAIP messages, but I didn't spend the time to try. TAIP is a binary format and while it is a brief and compact data format, I like the human readable NMEA output strings as they can provide visual output of  your GPS devices status. The Placer 450 can be switched to NMEA with the following commands:


Once switched to NMEA, it will provide the following standard strings: GPZDA, GPGGA, GPGLL, GPGSA, GPVTG, and GPRMC. I recommend reading the Trimble Placer 450 manual as it does have good information if you are unable to successfully communicate to the device via RS-232. There is also an old dos based configuration utility available that you can use to program it and switch its output to NMEA format. You will need a machine running win98 or older to run it though. I keep an ancient Pentium 133 machine around for programming old Motorola radios and I had no issues using it for programming the 450.

If your Placer 450 has been sitting around for years without being used, its internal GPS almanac is going to be extremely outdated. This resulted in a cold start of mine taking about an hour to finally acquire four satellites for 3D navigation and update its GPS almanac. Any subsequent warm starts after this will lock on within about 60 seconds. This would also be a good time to check the internal lithium battery. The memory in the Placer 450 is volatile and if the battery is bad every power on will result in a cold start. Checking on my receiver, the battery was fine.

PPS Output

Utilizing the PPS output of a GPS receiver is really the most important part of having a truly disciplined stratum-1 time server. Not all GPS receivers offer a true 1-PPS reference, fortunately the Placer 450 does, it just isn't where it needs to be. While the NMEA strings that come off of the GPS receiver contain accurate time data, various delays through the serial communication result in a time reference that has significant latency and jitter. This usually ends up being no better time keeping than just pointing your time server to another stratum-1 server. That said, the GPS time is still useful for events where internet connectivity is lost or unreliable.

The PPS output provides an extremely accurate time pulse that occurs once per second. Ntpd ( or your time server software of choice) can use this pulse to keep extremely accurate time. I will only be discussing the integration of ntpd in this post. The Placer 450 does indeed have a PPS output, unfortunately this output is on a separate DB-9 data connector. Probing its output on a scope, this pulse is clearly visible and has a very fast falling edge when it occurs (1.1 microseconds on average).

Now that we know we have an accurate PPS pulse, we need to get it into the computer running ntpd as quickly and with as little latency as we can afford. The solution to this is to send the pulse across the serial port on an unused pin (data carrier detect is standard to use in this case) which will drive an interrupt on the ntpd machine. In regards to the Placer 450, I decided to take this negative edge pulse, feed it into a max232 serial driver and send it down the unused DCD pin on the serial port. This worked perfect as the max232 inverts the data and results with a positive ~+15V RS-232 compliant pulse. The final setup of this is shown here:

The small blue board I added contains the max3232c serial driver and necessary charge pump capacitors. I pulled +5 volts off of a positive rail on the Placer 450 along with ground. Since the DCD pin on the RS-232 connector was unused, this modification was very simple. I also removed the original 3 pin power connector and hardwired it to +12v as there is no reason to worry about sourcing an original power cable. Since these devices are usually pulled from service, the original wiring harnesses usually never stay with the unit. Here is the resulting outgoing pulse through the max3232c:

Now that we have the pulse going to the NTP server via the DCD pin over RS-232, we need to verify its operation. Any modern Linux distribution will have PPS support built into the kernel, the serial module for PPS will just have to be loaded. To verify the arriving pulses, you can use pps-tools which is available for most distributions. The following output from ppstest shows my arriving 1 PPS pulse indicating my hardware modification is working.

[root@time01 ~]# ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1417642033.999999820, sequence: 226503 - clear  1417642033.000028598, sequence: 173333
source 0 - assert 1417642035.000000722, sequence: 226504 - clear  1417642034.000021949, sequence: 173334
source 0 - assert 1417642035.999999642, sequence: 226505 - clear  1417642035.000022821, sequence: 173335
source 0 - assert 1417642036.999999339, sequence: 226506 - clear  1417642036.000023328, sequence: 173336

One note regarding serial to USB adapters. I was using one initially and was not seeing the pulse arriving on my machine. Once I switched to the onboard serial port (/dev/ttyS0) my pulses were immediately visible. If you are going to use a USB adapter, make sure that it supports the DCD pin as mine did not.

A few more prerequisites are needed including having gpsd installed along with ntp. The ntpd configuration is really the last critical step, in the case of my Placer 450, the following configuration is used:

# GPS reference
server prefer
fudge refid GPS

# PPS reference
server minpoll 4 maxpoll 4
fudge  flag3 1  refid PPS

How this configuration works and what it should be set to could be an entire separate discussion, luckily it is documented very well. Basically the ip addresses shown above are driver interfaces to the gps NMEA serial interface and the kernel PPS. Once ntpd is restarted, checking ntp's status you will see the following:

[root@time01 ~]# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
-time3.chpc.utah    2 u    2   64  377   71.766   14.708   0.200     2 u   39   64  377   71.081    2.188   3.051
+segfault.boom.n  2 u   25   64  377   45.549   -4.891   0.548
+  2 u   31   64  377   58.978   -4.452   0.654
*SHM(0)          .GPS.            0 l    8   64  377    0.000  -71.444   4.780
oPPS(0)          .PPS.            0 l   12   16  377    0.000   -0.001   0.001

A few things to note in the above output:

1. Both the GPS and PPS sources now show up in the ntp output.
2. The tally flag for the GPS source is '*' indicating it is a system peer.
3. The tally flag for the PPS source is 'o' indicating the system sync is derived from a PPS signal.
4. Jitter on the PPS source is significantly lower than the other network based sources.
5. The jitter and offset for the GPS source are higher than other sources, this is expected as the serial communication latency between the Placer 450s NMEA strings and server is not guaranteed.

The next steps are to monitor and log the time servers accuracy and precision over time to see how much drift there is with the GPS source and without. After some basic testing it seems to be much improved but only time will tell.

Wednesday, November 12, 2014

10GHz Transverter Design and Testing

Ham radio operation on 10GHz and above is one of the many things that finally persuaded me to get my ham license. I love RF design, specially in the microwave bands, so allowing me to do so and at the same time travel to hilltops to work line of sight contacts just sounded awesome.

10GHz is the easiest place to start as surplus (and new) components are plentiful. Most of my station was built through surplus parts purchased on eBay and from the Dayton Hamvention. The rest I milled and assembled out of various parts I had laying around.

The best part about 10GHz and up is there is no off the shelf hardware available to work these bands. There are some commercial bits available such as Kuhne transverters and such that can simplify the design greatly, but you still have to homebrew the rest of the radio. This is what makes 10GHz and up so neat, there are no two radios that are alike. Each and every design is different based on the components available and how you want to make it. With most of the assembly complete, here is my stations final build:

KD8TBD 10GHz Radio

My design is based on the following:

10GHz transverter
Please excuse the crudeness of the above block diagram, I have a better one somewhere, but this one is pretty accurate to the final design. The design in its simplest form consists of a mixed upconverter / downconverter handing the signal transversion between a 144Mhz IF to the 10.368GHz RF. A PLL brick oscillator provides the 10.224Ghz LO signal. RF switches with a custom designed TX/RX sequencer handle the path switching as well as the power switching for the power amplifier.

The transmit and receive paths each have their own device chain separating them from each other. I went back and forth on this decision as I could have easily used a single mixer with additional RF switching, but I chose the dual paths as it actually simplified the design and I had the mixers available. So with this decision, each path contains its own mixer, both driven by the same local oscillator.

The local oscillator itself is a PLL brick that uses the x13 harmonic off of an ovenized crystal. The original output frequency was slightly off of 10.224GHz but was tuneable to my desired LO frequency. A nice feature of this brick is that it contains two outputs, each which provides more than adequate drive of about +13dBm for both mixers. A downside of this LO is that its stability is not perfect. Warm up time takes about 10 minutes or more until it has a stable frequency without drift. Another issue it is is very difficult to tune precisely which results in it being a few KHz off of my desired frequency. This ultimately plagued me during testing.

RF switching between each pathway is handled by a SPDT failsafe RF switch good up to 18GHz. A  switch is located on each end (at the antenna and radio). Being failsafe switches, upon any failure of the TX/RX sequencer the relays will fail to the TX side preventing me from accidentally transmitting into the RX path. The switches need +28VDC drive to function which is provided by a small DC to DC boost power supply.

Filtering occurs in many places and is a necessary requirement for this device to function. The most critical filtering has to occur out of the RF side of the mixers before the PA to allow the 10.368GHz RF signal to pass while blocking the 10.224GHz LO mixer leakage among other spurs. Additional filtering is also needed at the output of the RX mixers IF side to filter additional spurs and other high freq signals along with filtering on the RF side of the RX amplifier.

Low frequency filtering is relatively simple to accomplish as off the shelf filters for 144MHz are easy to source. The 10.368GHz filters are much more challenging. Many solutions are out there including building copper pipe cap based filters. I tried building a few of these with somewhat success. The filters did work but tuning was difficult and the passband was much wider than I wanted resulted in some 10.224GHz leakage. They have been proven to work and with some more tweaking (adjusting probe length and spacing) along with cascading some of them in series I know they could be used, but I ultimately decided to go with a different solution. I came across a couple nice Harris Farinon 10Ghz cavity waveguide filters that can be tuned to 10.368Ghz and have a very narrow passband. Based on the excellent performance of these filters they would be used in the final design.

10.368GHz Waveguide Cavity Filters

Due to the fact that this entire setup will be portable,  power would be provided by a 90 amp hour 12VDC sealed AGM battery. I have several of these and they are terrific mobile power sources. This would power both my entire transverter along with the Yaesu FT-290R II radio. Many voltages are required to power all of the necessary components within the transverter so a DC to DC boost converter is used along with various linear regulators to provide the necessary components their required voltage and current.

Automatic TX /RX sequencing was a necessary requirement for this transverter to function, having to manually switch the signal chain before each transmission was just not a feasible option. To do do this I would need a 2M radio capable of indicating when it was transmitting so I could interface directly off of it. I chose a  Yaesu FT-290R II for this transverter as I already had one and it is a terrific all mode 2M portable radio. An options with this radio was an additional external amplifier that clipped onto the back of it which was good as it provided a way of indicating when the radio was switching into TX for this external amp. I used this output to drive the input on my sequencer.

RF TX / RX Sequencer
The sequencer is very basic, it's just detecting the TX logic from the Yause to switch some relays for the RF switches and PA power in order. It also provides some led status indicators to verify its operation. There are two additional locations for relays that are not used, they were for the original design using four RF relays instead of two.

Amplification occurs at two points, a preamp directly off of the RX chain from the antenna and a power amp at the end of the TX signal chain. The RX preamp is a harris unit with +33dBm of gain at 10.368Ghz. The power amp is another Harris unit that can provide up to 100mw of output, this is lower than I had hoped but it will do just fine for now. I have 10GHz isolators on the amplifiers to prevent any stray reflections from coming back into the amps.

Physical construction consists of a small metal enclosure to house all of the transverter components. The box is white in color to reflect sunlight off of it during the day to help prevent it from going up in temperature. Inside, most RF components are mounted on a 1/4" aluminum sheet. I milled various other blocks and mounts to hold the other remaining components. This provides a very solid platform for everything in addition to being an adequate heatsink for the RX amplifier mounted directly to it. The PA amplifier is mounted directly to the back of the enclosure and mounted to a nice black Foxconn aluminum heatsink that came off of on old Pentium III Xeon processor. I went oversize on the heatsink as I plan to eventually replace the PA with a more powerful one. The front panel has a volt and amp meter and necessary power switches. The additional pushbutton is for manual RX / TX operation if for some reason the sequencer was not working.

The dish is a RadioWaves 18" aluminum dish with 37.8dBi of gain. It was originally designed for 43GHz operation so I had to cut off the front cover and remove the internal 43Ghz cassegrain feed. I then mounted a WR90 waveguide-to-coax transition with a small feed horn at the feed point with three brass rods. The mount is very rigid and allows for some flexibility in adjusting the feed to be right on the focal point. Very low loss Suhner Sucoflex microwave coax is used to connect the feed to the back of the transverter. The Yaesu radio is mounted directly to the top of the transverter via some velcro.

For mobile use, a motion picture camera tripod was used to mount everything together. It is a perfect mount as it is extremely sturdy but very lightweight since it is made completely out of aluminum. I usually will strap the battery placed underneath it to the bottom support of the tripod to give it some extra stability on windy days, but it has worked excellent for mounting the transverter and antenna. Setup and teardown is very fast as it is all held together with a few threaded rods.

A future post will discuss my first real testing of the unit during this past Septembers ARRL 10GHz and up contest, overall I was happy with the first testing as it almost worked really well. This was a good first real world test that isolated some issues including implementing better filtering and a more stable LO. The winter months will give me some time to get everything perfect before the spring.

Wednesday, May 7, 2014

APRS Station On a Boat - Part 1

Since purchasing my boat last year I have been wanting to add a 2m radio on it to access local repeaters. Recently while playing with my Yaesu VX-8DR HT  I recent began to experiment with APRS. APRS functionality is built into the radio and is fairly easy to setup. While its usefulness with the built in antenna is minimal I was able to reach some digipeaters while outside with the radio. Connecting the radio to my roof mounted 2m J-Pole resulted in a huge improvement, the coverage area was significantly impressive with this setup. At this point I was hooked, I wanted APRS on my boat, if anything it would allow family and friends to see where I'm at via

For the new station, I wanted a simple reliable system with a permanent and rugged 2m mobile for use on my boat. The Alinco DR-135 was a contender as it has a TNC built directly into the radio. Another unique feature is it has the capability for an APRS module to be directly inserted into the radio itself replacing the TNC. With this installed and configured, I could pull NEMA 0183 data right off my SIMRAD NMEA network into the radio making it a standalone APRS device. Unfortunately none were on the used market at the moment so I will be keeping watch for one in the future.

The next option I liked would be for some older Yaesu mobiles including the FT-2400 and FT-2500m. Both of these radios are built better than the Alinco to military standards and have all necessary external hookups available through the 8pin RJ45 mic connector. This would make it an easy single cable interface to my TNC and laptop. Another option is the Yaseu FT-2600m which I ultimately purchased as I came across one for cheap. The 2600m does not use the older RJ45 mic connector, but it does have a DB9 serial connector on the back which also contains all the connections available for a TNC.

Another benefit to the three Yaesu radios is that they can be modded to allow TX from 134Mhz to 170Mhz allowing them to be used as a backup marine radio in an emergency. Transmitting on the marine band through the 2m antenna would not be a great idea, but since the marine and ham radio will be near each other, I could quickly swap antennas to my marine band antenna if the need were to ever occur.

For the TNC I ultimately decided on the TNC-X. It is available in kit form, is inexpensive, supports the KISS protocol, has a USB interface, and has great reviews. I hadn't built a kit in probably 15 years, but I found this kit to be a simple build taking about an hour.

For APRS software I chose Xastir. I found it to be the best Linux based APRS application available and is available built in the Fedora 19 repos, although I ended up building an rpm for the latest version anyways as the builds currently available were a few versions older. For testing, I plugged both my TNC-X and a Garmin GPS receiver into my laptop, fed the speaker output of my Yaesu ft-8100r into the TNC-X temporarily and configured Xastir for the two devices. Once setup I began immediately receiving APRS message data.

Right now I have been spending most of my time with clearing and de-winterizing my boat as I have a scheduled date with my marina next week to place it in the water, so not too much time will be spent installing the station until it is in the water. Once I do set it up, it will consist of a 2m marine antenna going to the Yaesu FT-2600m, the TNC-X, NMEA-0183 GPS data from my existing network, and a laptop running Xastir. While definitely not as compact as the Alinco solution would be, I always have a laptop on my boat anyway so it will not be a big deal.