If you digitize the audio, you could delay it to match your pokey AGC scheme (and fancy audio filters and such too).
That's what many SDR rigs do.
In extreme cases it's like talking over a satellite link, and conversation becomes unnatural.
toggle quoted message
Show quoted text
On Mon, Apr 22, 2019 at 06:44 PM, James Lynes wrote:
I wondered about this approach myself.? I figured there would be too much time lag in the software path to be effective(untested).
?
|
If I'm listening intently to some weak signal from far far away and kW of carrier opens up from across the street, I want a very fast attack in my AGC.
For a strong SSB signal, the decay must be slow enough that the AGC's attenuation is determined by the voice peaks.
Best of luck with that slow everything AGC.
Jerry, KE7ER
toggle quoted message
Show quoted text
On Mon, Apr 22, 2019 at 07:01 PM, Hasan Murtaza wrote:
AGCs are supposed to be slow to react. If they were too fast then they would distort the received signals' envelope and effectively clamp the? RF signal to a constant value.?
|
Exactly. Consider the ESP32 with 1.3Mb of flash, 350Kb of SRAM, all scooting along at 240Mhz at a price of around $6. It also has two DAC ports. While the DAC ports are only 8 bit, it's better than no DAC. Also, you can program the ESP32 from within the Arduino IDE. So far, I haven't found any libraries that don't work with it. Oh, it also has builtin WIFI and Bluetooth.
Jack, W8TEE
On Monday, April 22, 2019, 9:37:05 PM EDT, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:
Doing AGC in software would incur added delay, especially with an i2c pot on our beloved little Nano.
We want to keep the attack time as short as possible.
Would be fun to try, perhaps using one of the small ARM processors with fast embedded ADC and DAC capabilities.
Jerry
On Mon, Apr 22, 2019 at 05:45 PM, Hasan Murtaza wrote:
Technically the simplest circuit (for some people) would be a software solution. Send the amplified output to a diode plus capacitor in a peak detector configuration. The capacitor voltage will be a quasi DC signal proportional to the maximum value of the signal. Read it into the arduino via an ADC pin.?
So far, component count =2.
Next replace the collector resistor in the class A common emitter amplifier with a digital potentiometer. Control the pot resistance (and hence the transistor amplification) with a digital output pin of the arduino. Write some software to set the gain based on the measured peak output voltage.
Total parts count is 3.?
If you sample the audio voltage directly you can do even fancier tricks like computing rms value or histograms etc.
Hasan
|
AGCs are supposed to be slow to react. If they were too fast then they would distort the received signals' envelope and effectively clamp the? RF signal to a constant value.?
That might be fine for FM, but it would make it impossible to demodulate AM. For AM, the AGC loop filter should have a time constant that is tunable and long enough to not distort the audio.
Software control opens up the possibility of more adaptive AGC...squelching transients etc.
Hasan
|
I wondered about this approach myself.? I figured there would be too much time lag in the software path to be effective(untested).
James
|
Doing AGC in software would incur added delay, especially with an i2c pot on our beloved little Nano.
We want to keep the attack time as short as possible.
Would be fun to try, perhaps using one of the small ARM processors with fast embedded ADC and DAC capabilities.
Jerry
toggle quoted message
Show quoted text
On Mon, Apr 22, 2019 at 05:45 PM, Hasan Murtaza wrote:
Technically the simplest circuit (for some people) would be a software solution. Send the amplified output to a diode plus capacitor in a peak detector configuration. The capacitor voltage will be a quasi DC signal proportional to the maximum value of the signal. Read it into the arduino via an ADC pin.?
So far, component count =2.
Next replace the collector resistor in the class A common emitter amplifier with a digital potentiometer. Control the pot resistance (and hence the transistor amplification) with a digital output pin of the arduino. Write some software to set the gain based on the measured peak output voltage.
Total parts count is 3.?
If you sample the audio voltage directly you can do even fancier tricks like computing rms value or histograms etc.
Hasan
|
Technically the simplest circuit (for some people) would be a software solution. Send the amplified output to a diode plus capacitor in a peak detector configuration. The capacitor voltage will be a quasi DC signal proportional to the maximum value of the signal. Read it into the arduino via an ADC pin.?
So far, component count =2.
Next replace the collector resistor in the class A common emitter amplifier with a digital potentiometer. Control the pot resistance (and hence the transistor amplification) with a digital output pin of the arduino. Write some software to set the gain based on the measured peak output voltage.
Total parts count is 3.?
If you sample the audio voltage directly you can do even fancier tricks like computing rms value or histograms etc.
Hasan
|
The V3 is next on the to do list.? I have downloaded the V3 firmware that is updated but has the V3 IF frequency.? I will check but I think the menu firmware did not change.
Again, thanks for the help.
73, Dan
|
Re: ubitx v5 down: IRF510 heatsink very hot immediately after turning on the radio
#ubitx-help
#ubitx
Jens,
I assume the rig is transmitting when first powered up, unless you plug in the microphone.
I think your microphone jack may be grounding the orange PTT wire,
except when the microphone is plugged in.
The microphone jack is at the center bottom of the wire-up diagram:
? ?
That microphone jack is not shown correctly, it should be more like the first answer here:
? ??
(Note that the pin numbers for the two stereo jack diagrams are completely different.)
The orange wire out of the microphone jack in the first diagram is the PTT line,
which is listened to by the Nano processor,? The Nano has a very weak pullup to 5v,
so that orange wire should be near 5v when receiving, 0v when the PTT switch
shorts the orange wire to ground.
When you power up the rig without the microphone plugged in and it does not receive,
is the orange wire near 0v?
Look closely at the second diagram above of a stereo phone jack such as our microphone jack.
If pin 2 is the orange wire for the PTT switch and pin 4 happens to be (incorrectly) grounded,
then when the microphone is not plugged in, pin 2 (the PTT wire) is going to get grounded.by pin 4
causing the rig to transmit.? When the microphone is plugged in, the pin 2 contact gets pushed up away
from the pin 4 contact, and PTT is no longer grounded by the jack and everything can operate normally.
Note that the microphone jack in the hfsignals wireup diagram does not correctly show a
stereo phone jack for mike, keyer, and speaker.? As pictured, it looks like the contacts
are closed with no plug (as they should be), but with a plug inserted the contacts would
be pushed together to be even closer.
Jerry, KE7ER
On Mon, Apr 22, 2019 at 11:41 AM, Jerry Gaffke wrote:
That's very good news!
The IRF510's don't draw current during receive because the LM78L05 at U2 is not getting fed 12v from "TX",
and so the voltage at the IRF510 gates is zero.? If you have not twiddled RV2 or RV3, then those gate voltages
should be such that the IRF510's pull 100ma each (200ma total) through that brown PA wire when pressing PTT
with no audio into the mike.
Did you ever find out why plugging in a mike made the rig stop transmitting and go into receive mode?
That should be figured out before anything else, it is transmitting if TX has 12v and not zero.
Do so with a dummy load at the antenna port, don't want the rig transmitting with a 50 ohm load there.
Triple check that you wired the mike and key as per the hfsignals wireup instructions.
|
I installed that rf amp but had big issues with bci from a station in South Carolina on 5920khz.
I had to remove it if I wanted to operate after 4 pm. I live in Pennsylvania!
Barry
|
Re: ubitx v5 down: IRF510 heatsink very hot immediately after turning on the radio
#ubitx-help
#ubitx
That's very good news!
The IRF510's don't draw current during receive because the LM78L05 at U2 is not getting fed 12v from "TX",
and so the voltage at the IRF510 gates is zero.? If you have not twiddled RV2 or RV3, then those gate voltages
should be such that the IRF510's pull 100ma each (200ma total) through that brown PA wire when pressing PTT
with no audio into the mike.
Did you ever find out why plugging in a mike made the rig stop transmitting and go into receive mode?
That should be figured out before anything else, it is transmitting if TX has 12v and not zero.
Do so with a dummy load at the antenna port, don't want the rig transmitting with a 50 ohm load there.
Triple check that you wired the mike and key as per the hfsignals wireup instructions.
Jerry
toggle quoted message
Show quoted text
On Mon, Apr 22, 2019 at 11:22 AM, Jens Kaemmerer wrote:
Update on 'fixing TX' after being able to revive RX yesterday:
I had already prepared to remove the existing IRL510 MOSFET's be
practicing 'de-soldering' on some broken electronics boards ...
However, before doing any surgery on the uBitx, I connected the multimeter to
test how much current the existing IRL510 MOSFET's draws.
There was still hope that the IRL510 MOSFET's are not really broken:
Maybe they develop a lot of heat instantly after turning on the radio because they
are actually transmitting because of the 'stuck' relay (K3?) discovered and 'fixed'
yesterday.
The radio had been in RX continuously since yesterday and I simply connected the
brown PA power wire through the multimeter to activate the TX PA circuit. Surprisingly
the 'idle' current draw was so small that I could not measure it with the 10A multimeter
setting, heatsinks stayed completely cool.
A good sign, but will the IRF510 MOSFET's still transmit?
Sending just 2 FT8 CQ's showed that they still transmit (see attached
'pskreporter' screenshot). Current draw while transmitting was 0.48 ADC
(this value seems low?).
Conclusion:
TX and RX are once again working - no surgery required!
Some of the things I plan to do in the future:
1) install MOSFET insulation kit and connect the IRF510 MOSFET's to the aluminum frame of the case for improved heat dissipation
2) go through the PA calibration procedure
3) build a 20W dummy load and to be able to measure power output of the uBitx ()
4) experiment with higher PA voltages (16VDC) to increase transmit power (currently using 12VDC)
73,
|
Ah, ok.? So it's the ND6T AGC scheme, but with an extra shunt 2n7000 (let's call it Q4) placed at the RF going into this new pre-amp, the gate of the new 2n7000 is controlled by the same attenuation signal that drives Q3 of the ND6T board.? ??
Should have the same attack and decay on your new Q4 as Don is giving Q3.? ? The kitsandparts RF pre-amp is placed between this Q4 and the RF input of Don's AGC.
With the preamp, the receiver might be hot enough to use one of those 3 foot chrome plated telescoping whips stolen from a commercial SW receiver.
When you want to transmit using a truly decent antenna, the extra AGC action sees the background noise, and sucks down the surplus gain provided by the preamp.
The manual RF gain control might be of help when using that decent antenna.
|
Re: ubitx v5 down: IRF510 heatsink very hot immediately after turning on the radio
#ubitx-help
#ubitx
Update on 'fixing TX' after being able to revive RX yesterday:
I had already prepared to remove the existing IRL510 MOSFET's be
practicing 'de-soldering' on some broken electronics boards ...
However, before doing any surgery on the uBitx, I connected the multimeter to
test how much current the existing IRL510 MOSFET's draws.
There was still hope that the IRL510 MOSFET's are not really broken:
Maybe they develop a lot of heat instantly after turning on the radio because they
are actually transmitting because of the 'stuck' relay (K3?) discovered and 'fixed'
yesterday.
The radio had been in RX continuously since yesterday and I simply connected the
brown PA power wire through the multimeter to activate the TX PA circuit. Surprisingly
the 'idle' current draw was so small that I could not measure it with the 10A multimeter
setting, heatsinks stayed completely cool.
A good sign, but will the IRF510 MOSFET's still transmit?
Sending just 2 FT8 CQ's showed that they still transmit (see attached
'pskreporter' screenshot). Current draw while transmitting was 0.48 ADC
(this value seems low?).
Conclusion:
TX and RX are once again working - no surgery required!
Some of the things I plan to do in the future:
1) install MOSFET insulation kit and connect the IRF510 MOSFET's to the aluminum frame of the case for improved heat dissipation
2) go through the PA calibration procedure
3) build a 20W dummy load and to be able to measure power output of the uBitx ()
4) experiment with higher PA voltages (16VDC) to increase transmit power (currently using 12VDC)
73,
-jens (KM6ZJV)
|
Thank you,Adrian, appreciate your help.
On Mon, Apr 22, 2019 at 1:26 PM Adrian Chadd < adrian@...> wrote: hi!
ok. lemme go see if I can publish an image and send ashar an update for the v5 board.
-a
Thanks Adrian, but I have a big problem with that, I? know nothing about programming It seems simple in the git-hub link you supplied but it's way beyond my? capabilities. I don't know what to do with that and at my age I don't feel like getting bogged down in something that will no doubt require a lot of time. I can handle a download that would set everything right but that's about it.
On Mon, Apr 22, 2019 at 1:05 PM Adrian Chadd < adrian@...> wrote: yes, it's a bug in the firmware. It doesn't reprogram the VFO until you change the frequency or transmit.
Here's my pull request against the upstream v4 tree that fixes this and another bug. the diff should apply cleanly against the v5 tree too as they're so similar.
Hi all, my V5 ubitx wont switch side bands on RX, the display says it does but in fact it makes no difference on a RX signal. It does switch side bands on TX. any ideas? Thanks.
|
Hi,
ok. I've pushed in a pull request against the v5 firmware.
I'll see if I can build a separate image with this fix in it for you. I haven't actually published a binary image to flash before; I write software. :-)
-a
On Mon, 22 Apr 2019 at 10:26, Adrian Chadd < adrian@...> wrote: hi!
ok. lemme go see if I can publish an image and send ashar an update for the v5 board.
-a
Thanks Adrian, but I have a big problem with that, I? know nothing about programming It seems simple in the git-hub link you supplied but it's way beyond my? capabilities. I don't know what to do with that and at my age I don't feel like getting bogged down in something that will no doubt require a lot of time. I can handle a download that would set everything right but that's about it.
On Mon, Apr 22, 2019 at 1:05 PM Adrian Chadd < adrian@...> wrote: yes, it's a bug in the firmware. It doesn't reprogram the VFO until you change the frequency or transmit.
Here's my pull request against the upstream v4 tree that fixes this and another bug. the diff should apply cleanly against the v5 tree too as they're so similar.
Hi all, my V5 ubitx wont switch side bands on RX, the display says it does but in fact it makes no difference on a RX signal. It does switch side bands on TX. any ideas? Thanks.
|
Jerry, Yes, that's the RF preamp.? What really happened is that I just wanted a hot receiver, plain and simple. No excuse, no glory, just that I wanted to pick up almost anything on a string of wire for demo purposes or for field use.? Regardless of reason for it, the perception of attack and decay seem to be controlled by the traditional AGC board output (that is, the S-Meter output), as it would be after all since the traditional AGC is just before the radio's front end stuff.? To simplify: If the latter's initial reaction to a heap of a signal were to show a high S-meter reading [had I been using the S-meter output to run an S-meter], then the former (the preamp) is going to be put on speed brake to lower what gets sent past it; I'd assume that the latter (the AGC) will immediately perceive less signal shoved into its face and will relax at whatever normal, preset recovery has been programmed.? I don't see the two fighting against each other, so, there is that bit of success. As to which ND6T circuit i have, I've got a kit version sent to me by the same fellow who solld me a V3 board near the end of winter this year, and, I've got an SMD version right from the maker's.? Both of my uBitx radios are using this preamp/AGC combo, one with the home-wired AGC and t'other with the ready-made SMD board.? It just so happens that when a strong signal comes rolling in over a weak one, two devices are getting instruction to reduce flow. My addition partially shorts out the RX path, while the normal or ND6T type AGC "fails to pass" as much signal as it did a moment earlier. The result is the same either way, and, I'm doing both (once each in two radios) and it's fine.? Overkill, but doing fine.... Here's the hook-up, simple enough:  At first - when I had the preamp and no AGC controller at all, I did use a 386-based amp board from somewhere or another to provide the control signal.? This setup seems to only needs about 0.7v on the gate of the 2N7000 to make at least some difference; at about .8-.9v, incoming gain is subjectively reduced to just under unity/without preamp levels and at around 1.2v on the gate the radio is deaf as a post.? If operating with another AGC, it's fine that way; operating without one, I expect that I'd want the 386 back? so that the RF preamp would function better as a one-piece combination.
|
hi!
ok. lemme go see if I can publish an image and send ashar an update for the v5 board.
-a
Thanks Adrian, but I have a big problem with that, I? know nothing about programming It seems simple in the git-hub link you supplied but it's way beyond my? capabilities. I don't know what to do with that and at my age I don't feel like getting bogged down in something that will no doubt require a lot of time. I can handle a download that would set everything right but that's about it.
On Mon, Apr 22, 2019 at 1:05 PM Adrian Chadd < adrian@...> wrote: yes, it's a bug in the firmware. It doesn't reprogram the VFO until you change the frequency or transmit.
Here's my pull request against the upstream v4 tree that fixes this and another bug. the diff should apply cleanly against the v5 tree too as they're so similar.
Hi all, my V5 ubitx wont switch side bands on RX, the display says it does but in fact it makes no difference on a RX signal. It does switch side bands on TX. any ideas? Thanks.
|
Thanks Adrian, but I have a big problem with that, I? know nothing about programming It seems simple in the git-hub link you supplied but it's way beyond my? capabilities. I don't know what to do with that and at my age I don't feel like getting bogged down in something that will no doubt require a lot of time. I can handle a download that would set everything right but that's about it.
On Mon, Apr 22, 2019 at 1:05 PM Adrian Chadd < adrian@...> wrote: yes, it's a bug in the firmware. It doesn't reprogram the VFO until you change the frequency or transmit.
Here's my pull request against the upstream v4 tree that fixes this and another bug. the diff should apply cleanly against the v5 tree too as they're so similar.
Hi all, my V5 ubitx wont switch side bands on RX, the display says it does but in fact it makes no difference on a RX signal. It does switch side bands on TX. any ideas? Thanks.
|
yes, it's a bug in the firmware. It doesn't reprogram the VFO until you change the frequency or transmit.
Here's my pull request against the upstream v4 tree that fixes this and another bug. the diff should apply cleanly against the v5 tree too as they're so similar.
Hi all, my V5 ubitx wont switch side bands on RX, the display says it does but in fact it makes no difference on a RX signal. It does switch side bands on TX. any ideas? Thanks.
|
Hi all, my V5 ubitx wont switch side bands on RX, the display says it does but in fact it makes no difference on a RX signal. It does switch side bands on TX. any ideas? Thanks.
|
Ted