FT-817 (& FT-897) Phone Audio interface part 3

Hi all,

This is a continuation of FT-817 Phone Audio interface part 2.

It has been a while since I have posted on this topic, and the principle reason for that is that I was patiently, and then not so patiently waiting for boards that I had ordered. They arrived while I was away on a series of SOTA activations, but I have populated one of these boards and tested. Apart from getting one of the cables wrong – which I needed to fix, everything works quite well. The markings of the rectifier diodes are wrong, but I already knew that upon ordering as that is a bug in the device files in my design software.

There is quite a lot of latitude with the potentiometer settings, both audio in to the phone and audio out. I ended up using a volume level about 2/3rds on the phone. There is going to need to be individual adjustment of these, as it is a function of the phone used, the digital mic setting on the radio and also the need to ensure that the signal is not being splattered. If you do not have access to two radios with one having an existing audio interface – eg a Signalink for testing, then you will require some on air reports to ensure that your audio is at a good level without causing splatter.

Here is a pic of both an unpopulated board and a populated board. For an Samsung Galaxy S2, I used a 12K resistor for R10. Apple devices might need a lower value, around 4.7K to raise the current that the interface draws. It seems like around 600uA is the threshold for Apple devices, but the Galaxy S2 is happy around 300uA.

FT-817 to phone interface

Populating the board is quite straightforward. Although most components are surface mount, they are either 1206 or 0805 size, and I did not even need to use a magnifying glass. I recommend using a temperature controlled iron with a fine tip.

I have a few spare boards, and can make these available for $12, or $25 with the parts, either $A or $US plus postage. Send me an email at vk3wam@gmail.com if you are interested.

It should be possible to adapt these boards for use with other radios as the connectors at each end are straight inline. On the phone side, most modern devices have ground on pin 3 and mic on pin 4, but many older non-Apple devices are the other way around, ground on pin 4, mic on pin 3. If you have such a device, then you’ll need to wire it that way. On the radio side, RX audio (phone in) TX audio, GND and a PTT grounded to TX signals are required and most radios should support these. The Yaesu radios provide a constant audio input on their data port, but some radios (I believe the Elecraft KX3 falls into this category) will change the output audio based on the AF gain (volume) setting.

73 de Wayne VK3WAM

FT-817 Phone Audio interface part 2

Hi all,

I have continued to work on the interface, described in Designing a Phone/Radio interface, and I think things are looking pretty good. I have changed some component values slightly to fit in with easily obtainable parts. One approach is to use thru-hole parts for everything, but this results in quite a big board. Now SMT does scare people. but if we stick to the larger part sizes, it should be easy enough. This does however means steering clear of 0402 and 0201 tiny sized components.

My first try at drawing a PCB used SMD capcitors while keeping everything else thru-hole. Using 1/4 watt thru-hole resistors ends up taking up a lot of space. I decided to change over to SMD resistors as well, but leaving the diodes, transistors and the trimmer potentiometers as thru-hole. This allowed me to get the board size at 2 inches by 1 inch. My resistors are generally 1206 size (this is .12 inches by 0.06 inches, or about 3 by 1.5mm. Most of the caps are 0805 (about 2mm by 1.2mm) size. These are reasonably easy to manage with tweezers.

People have asked what components are used for the transistors and diodes. I am using 2N4401’s for the BJTs and 1N5819 for the schottkies. Both these components should work very well.

In some of my simulations, I have tried quite “out there” scenarios. The circuit actually still works with a 1V power supply, especially with higher audio frequencies on the digital mode being used. It works with 8V, actually very well. I have not bothered higher voltages, perhaps I should give 12V a go, however no phone is going to be supplying that kind of voltage level. I suspect that they (i.e. the various phone manufacturers) are either stepping up the cell voltage output – typically a LiIon cell that will range from 4.2V down to 3.5V or so, and stepping it up to 5V, or just feeding it in unregulated, with a 5 to 10K resistor in series to current limit the supply on the microphone pin. Any of these scenarios will work with this circuit. If anything like a 3V or higher supply is involved, there will be over 50uA to drive the second transistor to sink 450uA of current on the PTT pin. Even if other radios to the FT-817 have different loads on their PTT pins, I can’t imagine it’s orders of magnitude!

On the radio side, there are clear variations. The FT-897 has a lower impedance output on the fixed audio, and a lower Vpp level. I still expect the circuit will work fine. I also had a look at the Elecraft KX3. This does not have a data port, but rather relies on the speaker output and microphone input. The speaker output will be at a higher level than what either the FT-817 or the FT-897 will drive this circuit. The trimmer potentiometer can be turned down to help. Also the radio audio control will change the voltages seen on the output. As for the input, again the potentiometer will have to be turned down, because the circuit is feeding something approaching a line level. Microphone is a good 15dB to 20dB down on that. I would presume that the KX3 would have some forgiveness about the input impedance, as cheap mics are high impedance (10K plus), while high quality mics can be as low as 100 ohs. I’ll need someone to investigate if there is any DC on the microphone input as well, as this could be there for the same reason that there is DC on the phone microphone input. If someone has a Oscilloscope and a KX3, it would be interesting to see the audio output levels, but you would also need to know what load resistor you used.

I have a picture of the circuit for you to enjoy below:

Phone Radio circuit board image

Btw, the diodes are back to front, and this is a consequence of whatever bug is in the schottky files used by GEDA. It is easier to just highlight it as an errata. The circuit will not work if the diodes are not correctly put in place.

I used the geda suite to design the circuit, using gschem to draw schematics, ngspice to do simulations, and PCB to draw the circuit art. These programs can be a little hacky and the help files are not for the uninitiated, but they certainly get the job done. I feel pretty comfortable with these, and I am now also looking to do a design for a bias tee and a preamp for 6m/2m/70cm. More about that later.

Send me an email at vk3wam (at) gmail (dot) com if you are interested in getting one of these interfaces. If people are interested, I could sell the boards at $10 US. I’ll need to look through the cost of the materials if people are interested in kits.

73 de Wayne VK3WAM

EDIT: Here is a slightly updated board design, optimised to remove some of the via holes, improve some spacing and comply with various production house design rules.
Phone to Radio interface board

Trans Tasman Contest

Saturday the 21st of June saw the Trans Tasman contest on 160m phone and 160/80m CW and digital on. It was a 6 hour contest with the best 5 hours to count.

The Eastern Mountain District Radio Club (EMDRC) was going to enter this, so I thought I would get involved doing CW and digital. I have a SignaLink USB on my FT-897 at home and so I put my hand up to focus on 80m.

Operating Station setup

I would have liked to have posted photos on this post, but I was busy contesting. Someone else took some photos, so hopefully they will show the station and I will edit this post at a future time.

My operating station consisted of my FT-897 brought in from home, a MFJ1025 noise canceller, a MFJ T-match manual tuner, a LDG ZPro-II auto tuner and the SingaLink USB. The antenna was an inverted-V full length for 80 metres. I had low SWR on the antenna without using the T-match, but found I had significantly less interference from 160m operations if I left the tuner in.

What was the ZPro doing? I had this tune a 20 metre beam for 80m to use as a noise sense antenna for the MFJ noise canceller. This seemed to work. The noise canceller was not able to lower the general noise floor, but what it was good for was getting rid of specific QRM that appeared throughout the night. The ZPro was affected by RF in the shack from 160m operations, so I had to put it in manual mode to not try to retune every time there was a 160m operation. I wonder what I was exposing myself to in the shack last night!

Anderson Poles

The EMDRC has been encouraging members to use Anderson poles There is nowhere in the shack to plug them in however, so lucky I brought a cable with rings on one end and Anderson Poles on the other. I still had to wedge these in to the power supply as it wanted lugs, but oh-well. It worked and I was able to use Anderson Poles for the rest. From the converter, I had a 3 way Y-plug, with the FT-897 plugged into this. I had a second 3 way y-plug, which was a little overkill, but plugged into this was the ZPro and the noise canceller. I could have easily plugged in 2 more things if required – so the setup is very flexible for use here at the EMDRC away from my own shack, and also for my QRO and QRP SOTA setups.

Digital observations

Digital modes that are AFSK based – i.e. all of them where a sound card is used to feed a SSB type mode on a typical rig – need the rig to stay as linear as possible. It is very important that there is no processor or ALC action. I had my rig showing ALC on its meter and increased TX level as much as possible, but not so much to activate the ALC. On the SignaLink, this ended up being around “10am” on the TX potentiometer. Other stations were transmitting with clear ALC action on their signal. This causes splatter. One station had so much splatter on their PSK31 signal that it was taking up nearly a full 1KHz for a signal that is supposed to only take 31Hz. This is multiple orders of intermodulation! I could not decode this signal – and sent them a message to turn down their TX! They did so, and while the splatter was still bad, it was at least then decode-able. A number had one order of splatter – giving a head and shoulders look. You want all of your TX energy in what is supposed to be there, and the shoulders are a waste of energy. A few stations had PSK-31 stations that had no observable splatter.

PSK31 does not tolerate almost any drift. Even on 80m there was one particular station that drifted 10Hz or so, and this was enough to cause decoding to stop until I re-clicked on the signal to move the decoding bars. This has implications for use of PSK on higher bands, especially VHF/UHF where this issue would be more critical. Some have suggested for this reason that PSK is not suitable for VHF work.

Contest Ops

In the end, I worked like a slave for the full 6 hours. My software was not that good at decoding CW, so lucky my brain can at least reasonably decode 20wpm. I operated the first 20 minutes or so of each hour CW, then the middle 20 minutes digital and the last 20 minutes CW again. The rules allowed for digital stations to be re-worked every half hour (once in the first half hour, and again in the second half hour), so I tried to take advantage of this – which mostly I was able to.

Most contest digital ops where PSK31. There was some RTTY near the start and occasionally later. One station was using Hell, but I had already worked them in that time slot. The key with Hell is to turn the software “squelch” all the way down. Hell is like reading a fax – the signal processing is in your brain.

In the end, contest activity was reasonably engaging. I found running got more contacts, so I spent about 75% of the time running. It was the first time ever that I had actually chased CW stations. This is because when I activate CW in SOTA, I am always the “running” station. I picked up the chaser caper without too much trouble. Of course in CW, one should not transmit on the running stations frequency, but offset 100Hz or so.

Having a narrow IF filter defiantly helps in both CW and digital. I would normally operate using the wide filter, but if something was happening 1KHz away that would affect the AGL, then I could quickly switch to the 300Hz Collins filter to get rid of it. The wide filter is good for seeing a broad picture on the waterfall when AGL action is not taking away the signal that I am interested in. I left the FT-897 menu on the selection where I could switch between the two filters with one press of the button.

In the end, it was an enjoyable contest. I had 87 non DUP contacts (1 DUP), so not too bad for a first effort.

Updating VKCL to v3.5

Last night, my little project was to get VKCL working for the upcoming Trans Tasman contest on 160m phone and 160/80m CW and digital. The last time I used VKCL was during the John Moyle Field Day contest. On that day, I started using a then current v3, but this crashed upon entering my first QSO. Upon a bit of frantic testing, I was able to use a late v2 of the program to complete the logging of the contest. I had to manually adjust the scores later in accordance with the 2012 rules.

The Trans Tasman has changed this year, with 4 previous contest days being merged into 2. The 80m phone contest remained separate, but all the other 3 were combined into one contest, which is taking place tomorrow night (Saturday 21st of July). I would need a new version of VKCL for this.

Upon installing the latest version, I noticed that it immediately wanted to pick up my John Moyle Field day log and it was not happy. If I pressed the config button, the configuration screen would come up, but completely empty. Pressing the “X” close button would close this, but shortly afterwards, the program would crash through an unhandled exception. What to do? Firstly, I was running VKCL under Wine 1.2 on Ubuntu, so I upgraded Wine to 1.4 to see if that would make any difference. No it didn’t. Next, I got a Windows XP laptop and tried it there. No difference. So it is not a Linux or Wine thing, it doesn’t work under Windows XP either.

I thought that this was getting a little ridiculous, surely the software must be more robust than this. I thought that perhaps the author, Mike VK3AVV had not thought to test this program installed over the top of a v2 VKCL, so I needed a way for the program not to see the John Moyle log.

Under the C:\VKCL3 file (/home/<username>/.wine/drive_c/VKCL3 when using Wine) there is a file VKCL3.ini. In this text file, there are two dbPath entries, under [Select] and [Config] respectively. If these entries are edited to point to a directory that has no pre-existing log file, then everything seems to work fine. Care needs to be taken to maintain the double backslash “\\” as the directory names. Changing this to a single backslash will not work. This is because the text is being fed into a computer language that uses backslash as an escape character (The C language does this). Once these two dbPath are changed, then VKCL3 can be run and a new log created wherever you desire by using the configuration screens in the program.

Also, the QSO crash bug seems to have been fixed. Hopefully no surprises tomorrow night.

Regards 73, Wayne