The first RX module which down converts 10GHz to 144MHZ was finally finished today. Initial results were disappointing. However, after some modifications to improve the noise characteristics of the first local oscillator everything is running nicely now.
The conversion takes a while but the result is a sensitive down converter suitable for SSB and FM use. I'm not posting full details of all the changes required at this point. Please get in touch if you'd like to know more and I'll consider blogging further details.
In the meantime I have a few more modules to convert. The RX module has the following model identifiers:
em FM RECEIVER
10.5-10.68 GHz, Synth
P/N 036D S/N 111xxx
A blog about homebrew projects for Ham Radio. I cover aerials, test equipment, transmitters, both QRP and QRO, receivers and transceivers. The emphasis is on design and building. Generally I have boards and parts available at a modest cost. If you need more details, like a board layout, or any questions please ask. I'm more than happy to help.
Monday, 12 February 2018
Wednesday, 17 January 2018
EM 10.5-10.68GHz microwave modules - Mods to use on 10.368GHz
This started out as what appeared to be an ambitious project but it is so far straightforward. I was fortunate enough to be given the chance to modify a few sets of the FM Tx and Rx boxes for ham use. It transpires that just about every set of modules is the same but different! They are all broadly similar but subtle variations exist so if you have some of these modules and yours don't match exactly then this shouldn't deter you.
Here's what I have done so far:
The units I modified had the LM2326 PLL chip. It has a different data format than the LM2325 chip I saw on the units I have not yet modified. In a few words the 2.5GHz PLL uses a 250KHz reference frequency. It is multiplied by 4 on both tx and rx units. On the tx units it is mixed with the IF, presently 69MHz but I am modifying this to use a 144MHz IF on tx. On Rx the multiplied signal is mixed with a 692MHz oscillator down to a 140MHz IF. At present I'm leaving this oscillator alone since the saw filter appears wide enough to be serviceable with a 2m IF.
Micro
Once I knew what the existing data stream was it was relatively simple to work out the data stream needed to load the PLL chip with data to put it on the desired frequency. See the chart below for an overview. I used an ATTINY13 and a few lines of assembly to do this.
Achieving lock.
This should be straightforward but sometimes the soldering proves difficult due to the heatsinking the board has. I moved the short until the PLL locked with around 4V-6V on the tuning voltage link.
I'll post some more pics soon but for now the following may prove useful.
Regards
Richard
Here's what I have done so far:
- Used a cheap logic analyser to check what was being loaded into the PLL chip by the micro.
- Inserted my own micro to control the 2.5GHz PLL
- Achieved lock on several TX and RX units
The units I modified had the LM2326 PLL chip. It has a different data format than the LM2325 chip I saw on the units I have not yet modified. In a few words the 2.5GHz PLL uses a 250KHz reference frequency. It is multiplied by 4 on both tx and rx units. On the tx units it is mixed with the IF, presently 69MHz but I am modifying this to use a 144MHz IF on tx. On Rx the multiplied signal is mixed with a 692MHz oscillator down to a 140MHz IF. At present I'm leaving this oscillator alone since the saw filter appears wide enough to be serviceable with a 2m IF.
Micro
Once I knew what the existing data stream was it was relatively simple to work out the data stream needed to load the PLL chip with data to put it on the desired frequency. See the chart below for an overview. I used an ATTINY13 and a few lines of assembly to do this.
Achieving lock.
This should be straightforward but sometimes the soldering proves difficult due to the heatsinking the board has. I moved the short until the PLL locked with around 4V-6V on the tuning voltage link.
I'll post some more pics soon but for now the following may prove useful.
Regards
Richard
![]() |
| An unmodified receiver showing what is required to modify for 10.368GHz use |
| Details of how the IF signal on Tx gets to the mixer diode for up-conversion to 10GHz |
![]() |
| Data loaded into PLL chips to shift to 10.368GHz |
Thursday, 5 October 2017
Lead Acid Batteries - Measurement of Internal Resistance - Results
It's been about 4 weeks now and some observations of the impact pulse conditioning has had on internal resistance and perhaps battery capacity are warranted. More importantly, the need for a more rigorous approach has become apparent.
Over that last 4 weeks the measured internal resistance has fallen from 264 milli-ohms to 175 milli-ohms. While the reduction in the internal resistance tapered off after about 10 days, there is some support for the battery's capacity having increased as well. At the start I was recharging the battery after 3 days on the pulse conditioner. Now it runs for 5 to 6 days before I have to recharge the battery.
So my initial observations are that the pulse conditioner is beneficial. However, there are several issues with the approach and the results cannot be construed as anything other than weak support for pulse conditioners.
The biggest drawback to the approach is the lack of a control battery. With a second battery I could cycle one on the pulse conditioner whilst the other was cycled on a static load. If the static load battery showed little, or no improvement, in internal resistance then there would be much stronger support for the pulse conditioning approach.
Another drawback stems from the lack of automation. I still have to manually changeover the battery at each step of the pulse, charge, measure cycle. So the time between measurements is not constant and the level of charge and discharge varies from one cycle to the next. I clearly need to automate the cycle and let it run unattended.
The final obvious shortcoming is temperature. We are moving towards summer and the average ambient temperatures have increased over the last month. The temperature change could be influencing the results either directly via battery chemistry somehow, or indirectly by it's impact on the voltage regulator which serves at the voltage reference for the D2A conversion. A temperature controlled testing environment would be useful to remove another source of potential error but that is beyond my reach at present.
The biggest obstacle to the full automation with the W1209 board is the need for an additional two digital outputs. I have considered two approaches. The first is using the + and - keys as both inputs and outputs. That would require some careful soldering to insert a resistor, say 2k, in series with each switch. The second approach is a 4017 counter clocked by the pin driving the relay. Then each of the decoded outputs for 1-3 from the 4017 driving a relay to perform each step of the pulse charge measure cycle.
I'm leaning towards the first approach since I don't know if I have a 4017 in the drawer and the first approach avoids any ambiguity over which step the cycle is in.
Over that last 4 weeks the measured internal resistance has fallen from 264 milli-ohms to 175 milli-ohms. While the reduction in the internal resistance tapered off after about 10 days, there is some support for the battery's capacity having increased as well. At the start I was recharging the battery after 3 days on the pulse conditioner. Now it runs for 5 to 6 days before I have to recharge the battery.
So my initial observations are that the pulse conditioner is beneficial. However, there are several issues with the approach and the results cannot be construed as anything other than weak support for pulse conditioners.
The biggest drawback to the approach is the lack of a control battery. With a second battery I could cycle one on the pulse conditioner whilst the other was cycled on a static load. If the static load battery showed little, or no improvement, in internal resistance then there would be much stronger support for the pulse conditioning approach.
Another drawback stems from the lack of automation. I still have to manually changeover the battery at each step of the pulse, charge, measure cycle. So the time between measurements is not constant and the level of charge and discharge varies from one cycle to the next. I clearly need to automate the cycle and let it run unattended.
The final obvious shortcoming is temperature. We are moving towards summer and the average ambient temperatures have increased over the last month. The temperature change could be influencing the results either directly via battery chemistry somehow, or indirectly by it's impact on the voltage regulator which serves at the voltage reference for the D2A conversion. A temperature controlled testing environment would be useful to remove another source of potential error but that is beyond my reach at present.
The biggest obstacle to the full automation with the W1209 board is the need for an additional two digital outputs. I have considered two approaches. The first is using the + and - keys as both inputs and outputs. That would require some careful soldering to insert a resistor, say 2k, in series with each switch. The second approach is a 4017 counter clocked by the pin driving the relay. Then each of the decoded outputs for 1-3 from the 4017 driving a relay to perform each step of the pulse charge measure cycle.
I'm leaning towards the first approach since I don't know if I have a 4017 in the drawer and the first approach avoids any ambiguity over which step the cycle is in.
Subscribe to:
Posts (Atom)

