Jeff - KO7M brought over his Spectrum Analyzer so we could look at the output. Harmonics were well below requirements and that was very good news.
But, during the inspection we noticed that once in a while the PA appeared to jump into low level oscillation, and some how it was associated with the make-shift connection to the Propeller board. The oscillation only happened once in a while.
I (some what) expected this to happen, as the PA was built to be a wide band amplifier with only some filtering on the output. Oscillation (Gremlins) can easily occur on untried designs. According to the Analyzer, the Oscillation was NOT on the Frequency of my Beacon (10.140MHz), but at slightly lower unknown frequency.
I was a little bummebed out, as it meant that I needed to rework my faulty (guilty) PA design to provide some neutralization. That would have to wait for another day.
Now, A Few Weeks Later
The last few days I have been building and attempting to characterizing a new set of Low Pass Filters (see previous post). The Filters are intended to be connected directly to the Propeller board via a cable and SMA connectors. Again, with the loan of Jeff's Spectrum Analyzer the task was made easy. The Filters passed with with flying colors.
But Then, . .
On occasion, a very Low Level signal appeared on the Analyzer between RF transmissions, and near (slightly lower) the intended test 10.140MHz signal that I was using for the experiment. It appeared only about 50% of the time, and after an RF output. It was measured about 15db above the noise floor on the Analyzer.
But Then, . .
When the above signal was not present, and looking closer (at the same high gain setting) an even lower level signal was always present. It was measured at about 3db above the noise floor.
I assumed it was hash being picked up by the connecting wire around and from the Propeller Processor.
But Then, . .
It only was observed after tests were started, that is, after the first RF transmission. It was NOT observed just after Propeller power up and before the first RF signal was produced. Note: the photos were taken with the same configuration for each.
And Then, . .
It occurred to me that, maybe the RF output Pin was Leaking !
To check it out, . .
I changes the RF signal Frequency to 7.030MHz.
But No, . .
The Propeller was not leaking at the set RF frequency, the leak was higher, near the previously observed 10MHz Frequency.
What is going on, . . ?
In the transmit program code, we traditionally turned on the PLL Oscillator by setting the intended Frequency. And then, to turn off the output, we just set the frequency of the PLL Oscillator to Zero, as per the Propeller Object Library suggestion.
pri sendTone(tone)
Freq.Synth("A", RFPin, Frequency + tone)
pri noTone
Freq.Synth("A", RFPin, 0)
This has always worked well in the past, or at least we thought so. Maybe we had never looked close enough at the output.
I changed to code to; just turn on-and-off the output pin, and leave the Synth (oscillator) running between transmissions, and only executing the Synth command as necessary (if Frequency changes).
VAR
Long PrevF
pri sendTone(tone) | F
F := Frequency + tone
if F <> PrevF
Freq.Synth("A",RFPin, F)
PrevF := F
dira[RFPin]~~ 'set for output
pri noTone
dira[RFPin]~ 'turn off output
And the Results, . .
It worked, no observable leakage!
I now suspect that the open output pin allows the Master Clock (at 10MHz) to leak at very low levels at the pin. Maybe a product of clocking the Propeller COG in which the program is running.
And So, . .
The previous suspected problem with the PA oscillating, was NOT actually a problem at all. The PA was just doing what it does best, it was amplifying the small Leaking Master Clock of the Propellers.
Problem solved!
The code will be changed on each of my Propeller Programs.
My Prop and PA can now be put back in service as a 30m QRSS, WSPE, and OPERA Beacon without, out-of-band concerns.
With restored faith in design, I can move on, and produce a proper PCB to replace the now acquitted PA circuit.
--
Loving all this. I'm not a big proponent of the Propeller*, but I wanted to mention that I saw some Propeller starter boards at Radio Shack yesterday. I was out picking up some ferrites for my neighbors, and happened to notice a Propeller board in amongst the Arduinos.
ReplyDeleteThis makes it that much easier for anyone to get the first piece of the puzzle here.
* On paper, I love it. In practice, the reality of it makes me really appreciate GCC for the Atmega and ARM platforms.
Jbm,
ReplyDeleteI too am an Atmega (and PIC) fan, and have written many programs for process control and Amateur Radio projects.
But, I found that much of my code was written to effect multitasking for a project. To keep the display running in real time, output controls for other peripheral, data communication, sensor input, etc. Very little of the code was what I call "real application". The Atmega (and PIC) are a great products, but not fun to program for multitasking.
The single Propeller supports up to eight tasks at the same time, one in each of its COGs (processor), with very little or no coding. And each GOG has access to any of the 32 I/O pins. Each pin can be connected for; digital data output, DC to 120MHz PLL output with 1Hz resolution, TV and VGA signal generation, PWM, each two pins can be used for Sigma-Delta Analog-to-Digital input, and lot more.
I am not Prop Pusher, just a very happy user.
Eldon
You might want to put the 5 MHz crystal back in and see if the observed leakage occurs in the 5 MHz range just as a second check. I am certain you are correct however as to the source of the RF energy observed.
ReplyDelete