I have a working hand-held arduino based telecom test set made out of a plastic capacitor kit case. It generates audio frequency tones from 0-3000 Hz. The tone() function produces audio frequencies at about -9.5dBm from what I have observed. That level is very useful to my for my intended purposes. I also need it to generate tones at a level of -16dBm. To achieve this, I put a selector switch to attenuate the level to -16dBm by putting the output of the tone() pin in series with 30K Ohms of resistance.
It measures the frequencies that it generates in TX mode, but also measures frequencies from other devices from it’s RX port. The RX port must have a level of -3dBm or greater to work at this time. I will be experimenting with an amplifier stage to measure weaker signals.
I have considered several design possibilities for myTIMS project. I was going to use the TimerFreeTone library because of the timer conflict between tone() and the FreqCount library, and have the user type in the desired frequency using a keypad. I do not have enough GPIO on my nano for this as I need 6 pins for my LCD and seven for my 4-column 3-row keypad. (I know I could get an i2c display, but I’m using what I have laying around!)
Anyway, the two nano approach is acutally looking better. I am using one nano to generate the desired frequency when the TIMS is in transmit / generate mode. I am using a 10-K potentiometer to tune to the desired frequency and basically copied and pasted the tonePitchFollower example sketch with a few modifications. The other nano does the frequency counting and drives the LCD. As you can see above, the nano frequency counter is only off by 1 Hz from a professional TIMS.
SO MUCH has changed in the telecom world over the course of my 20-year career. Back in the day, we had monstrous Fujitsu PBX’s with dozens of 50 – 100 pair copper cables snaking through our buildings and across our campuses that were punched down and cross-connected to workstation cables that ended up at a clerk’s telephone. VoIP has long since replaced this paradigm.
Not only that, I worked on an analog 6Ghz microwave system that multiplexed hundreds of analog circuits on an archaic concept called the ‘baseband’ which consisted of amplitude modulated channels (using either upper or lower sideband) that modulated the 6GHz carrier.
A totally indispensable piece of test equipment at that time (in addition to my frequency selective volt meter) was the TIMS set (transmission impairment measurement test set).
It is mostly used for generating / measuring audio frequencies at a precise dBm level. In today’s world where copper cable is an increasingly unused medium for data / voice transmission, and older analog technologies (such as land line phones) are migrated to IP, new TIMS sets are getting harder to find. Most I can see are refurbished.
In spite of all the changes over the years, I still need a TIMS set for various analog FSK systems that I work on. In particular, I still have many 300 baud and 1200 baud (202t) systems in wide deployment, so measuring VF frequencies and their levels is essential to maintaining theses systems.
Anyone familiar with the arduino’s ‘tone’ function knows how incredibly easy it is to generate a variable audio frequency tone (a great demo is the included ‘tonePitchFollower’ program in the examples included in the IDE). That is half of the TIMS set. For the frequency counter side of the TIMS, I found an awesome library called FreqCount. It works great, and compares well to my professional TIMS set. However, when I try to use ‘tone()’ and FreqCount together, I get a nasty message when I try to compile:
The problem is a conflict using ATMega328’s timer 0. Bottom line is that you cannot use FreqCount (awesome) and tone() at the same time. I could use two nano’s: one to do the TX and one to do the frequency counting. However, I found the TimerFreeTone library. I am experimenting with it, and it may suit my needs. Not as accurate as tone(), but it might be ok for what I am doing. I am in the bread boarding stage right now, and hope to have more to show soon.