Date   
Re: : Thank you!

Andy_501
 

Mick,

I appreciate your comments and feedback and they are very valid points to consider. I am not trying to find the easy way out, as it were, in searching for previously compiled indexes to ref info but more to get 'er done quicker without having to re-invent the wheel as it were.

I am looking at this experience from three different points of view.

        1. to determine if the uBITx transceiver kits are ideal kits to include as a practical lab component to an advanced amateur qualification course (Canada)

        2. to determine if the transceiver kits would be useful for noobie hams at basic-plus qualification level to consider as an entry level priced HF rig to keep their interest up until they can afford a full                     powered commercial 100 W rig or whether another competitor kit would be more suitable

        3. a useful training aid for the occasional hobbyist as this group's collective interest appears to focus on.

1. can a single pdf document outlining the shortcomings and cheat/shortcuts to use make the kit useful and affordable enough to make it useful as a practical lab project in a limited time course plan layout even though the groups.io hobbyist purists may not want to have a "Noobies Quick Overview" available with each kit;  so that paid time to course instructors can be spent on qualifying for advanced license?

2. self explanatory also, if a noobie bought the kit and built it and an advanced amateur signed off on it being in conformance with regs would it be something the hew ham would be receptive to?

3. here the application is as broad as it is long; so I will show  by an example here;  I had a 14 yr old lad call to write the ham test. I gave him some study info and he also had his Dad drive him 1.5 hrs each way into the city 4 Saturdays in a row, to attend an organized course; he came back to me to write his exam and passed with mid nineties mark. A short time later he is now interested in coding devices as part of his interest in the "InternetofThings".

So much so that at 14 yrs of age he is now an elmer to another 8 year old where said coding is concerned. They have apparently started out learning on an arduino starter kit and the UBITx and ANTUINO are considerably more complicated as far as that goes and because of his interest in amateur radio a possible logical next step for their coding progress. Hence, I keep info related to this in the back of my mind also as I work through the kit here myself. ( of course the end view is he gets a QRP HF rig and SWR/Analyzer and possibly gets another 8 yr old ham to study up and pass)

I appreciate Reed's hex loads also for quick ease of use to correct the glitches quickly. I have downloaded the advertised git hub versions also so that I can load the sketch files into the arduino IDE I have installed in my linux box to be able to get through the actual code on occasion; something that one can't do with just the hex file. I am also keeping an eye out for one of those arduino starter kits on sale as well so I can tinker without affecting a working transceiver.

I have done a lot of compiling of different programs over the years on the linux boxes both to work as installs in the a linux OS as well as other executables from C C++ etc on the linux box using those included compilers like gcc etc. So it is a bit easier and more comfortable for me to understand what I am doing each step of the way; but when you don't have the source text files like the .ino files in our case here there is a bit more searching to do to discover what and where our resident coder gurus here made the changes and why.



On 2020-01-22 10:17 a.m., Mick wrote:
Jack I agree! Thank you Reed!

Andy,
like you I’m new to this and so far have benefited from Reed and Ray’s hex file loads. Soon I’ll be looking into source code and compiling as well.
So far I’ve found the ubitx.net page has interesting information including how to load a sketch  “http://ubitx.net/how-to-load-up-a-sketch-on-your-raduino/“
Mainly I’m following leads like:
loading Arduino IDE software on your computer
signing up to github where all this software resides and version control is implemented
next will be how to compile.
I agree I think it is a right of passage. Not that the information is not there, but rather finding the information
and piecing  it together and that is part of the adventure.
73
Mick VA3EPM 

Re: Knob "Momentum" #ubitx #v6

Reed N
 

Sorry, I misspoke. Not Jerry, but Jack. Appologies.


Reed

Re: Knob "Momentum" #ubitx #v6

Reed N
 

Hi Bert,

What exactly do you mean by "aggressive"? Does the acceleration kick in too soon, or is it that when it does kick in, it goes to fast, or perhaps both?

You can find the code doing the acceleration here: https://github.com/reedbn/ubitxv6/blob/knob-acceleration/encoder.cpp#L113, however I'd appreciate more specific feedback, since you're probably not the only person who will have whatever preferences, and as Jerry mentioned earlier, it may be that I need to add a setting for its "aggressiveness", but I need to understand what part of the current acceleration strategy is objectionable to do so.


Reed

Re: Knob "Momentum" #ubitx #v6

Bert N8NN
 

I like the added feature of "acceleration".  It is needed.  I would like it to be less aggressive.  Can you point me to a place in the code where I can change the speed?  Or is it not so simple....

Bert N8NN

Re: : Thank you!

Mick
 

Jack I agree! Thank you Reed!

Andy,
like you I’m new to this and so far have benefited from Reed and Ray’s hex file loads. Soon I’ll be looking into source code and compiling as well.
So far I’ve found the ubitx.net page has interesting information including how to load a sketch  “http://ubitx.net/how-to-load-up-a-sketch-on-your-raduino/“
Mainly I’m following leads like:
loading Arduino IDE software on your computer
signing up to github where all this software resides and version control is implemented
next will be how to compile.
I agree I think it is a right of passage. Not that the information is not there, but rather finding the information
and piecing  it together and that is part of the adventure.
73
Mick VA3EPM 

Re: STM32F769-FT8-Transceiver

Art Olson
 

Charley 

Thanks for clearing up my confusion. Now to melt some more solder

73
Art N2AJO


On Jan 22, 2020, at 10:47 AM, Charles Hill <chillmf20@...> wrote:

Art,

In my using the Arduino Prototype Board with the F769 Disco Board, the only "stacking" is a connection between the Arduino Prototype Board and the F769 Board. There is no "stacking" with a Nano board.

However, for interface with the Nano board located on the RS-HFIQ board, I used interconnecting cables between the 9 pin header shown on the right side of the Arduino Prototype Board and  connector  J2 on  the RS-HFIQ Board plus a power connection to the Nano on the RS-HFIQ Board.

Also, we have found that for recently produced RS-HFIQ Boards that powering its Nano via it's Vin pin at 7 volts causes problems with the boot up of the Nano. We have found that powering the Nano at 5 volts from the F769 Board solves this problem.

To do the RS-HFIQ   Nano power at 5 volts, connect pin 5 of CN11 (5 V output) on the F769 Board to the 5V pin on the Nano.

I have not yet had an opportunity to do an interface with an UBITX board but I am confident that a proper interface can be built from the information provided in the STM769_FT8_Tranceiver.pdf   document.

Regards,

Charley


Re: STM32F769-FT8-Transceiver

Charles Hill
 

Art,

In my using the Arduino Prototype Board with the F769 Disco Board, the only "stacking" is a connection between the Arduino Prototype Board and the F769 Board. There is no "stacking" with a Nano board.

However, for interface with the Nano board located on the RS-HFIQ board, I used interconnecting cables between the 9 pin header shown on the right side of the Arduino Prototype Board and  connector  J2 on  the RS-HFIQ Board plus a power connection to the Nano on the RS-HFIQ Board.

Also, we have found that for recently produced RS-HFIQ Boards that powering its Nano via it's Vin pin at 7 volts causes problems with the boot up of the Nano. We have found that powering the Nano at 5 volts from the F769 Board solves this problem.

To do the RS-HFIQ   Nano power at 5 volts, connect pin 5 of CN11 (5 V output) on the F769 Board to the 5V pin on the Nano.

I have not yet had an opportunity to do an interface with an UBITX board but I am confident that a proper interface can be built from the information provided in the STM769_FT8_Tranceiver.pdf   document.

Regards,

Charley


Re: : Thank you!

Jack, W8TEE
 

I don't think there is a summary, but the file names give a good idea of what's in each source file. Also, he has this warning near the top of the of the README file:

     IMPORTANT: It will compile only if you place this in the Arduino's own sketch directory!

That's not correct. You can place the code anywhere on your system, provided the root name of that directory matches the INO file name. For example, if you wish to place your code in a root directory named uBitxV6 and C is your root disk drive, you must name the subdirectory as follows:

    C:\uBitxV6\ubitx_v6.3.1_code\(all of the program files and folders here)

In other words, the folder name that holds the source code for the project MUST match the name of the INO file (i.e., ubitx_v3.6.1_code.ino). It makes sense to arrange things this way, otherwise, the Arduino sketch directory is going to get super crowded with a bunch of unrelated projects.

Jack, W8TEE




 

On Wednesday, January 22, 2020, 10:15:00 AM EST, Andy_501 <andrew.webb.501.ve4per@...> wrote:


Is there a kind of dedicated index of each file and a precis or summary para what each does or how it contributes to the whole or big picture as it were. I haven't begun looking into coding and compiling yet as getting the basics working completely is consuming enough time at this point. I gather from the posts here it is a common practice or occurrence; almost a right of passage hihi.

Andy_501

On 2020-01-22 8:25 a.m., Jack, W8TEE via Groups.Io wrote:
To me, the real win here, even if nothing was changed, is to have only 1 *.ino file. Farhan did us a favor of breaking out the code into separate files, which makes it much easier to find/change things. However, I was not able to convince him of the single *.ino file idea. The reason why it is such a HUGE win is because the IDE's compiler supports incremental compiles. I've seen an app with over 10000+ lines of C code in a single ino file. The JackAl code is 11000+ lines spread out over 19 source code files. The first time I compile the code in the morning, it takes over a minute to compile the code, and that's on a multi-core processor with 32Gb of memory scooting along at 3.8MHz. However, on the second compile, the time drops to about 5 seconds. The reason is because the IDE's compiler uses a "dirty flag" to mark those files I've changed since the last compile and it re-compiles only those files with a set dirty flag. Since debugging typically means re-compiling the same file over and over, I save myself almost a minute each time I re-compile. I might recompile the code at least 30 times/day, which saves me a half hour of thumb-twiddling each day. Add that up over 19 months and you're talking some serious time.

We all should appreciate and thank what Reed's done here. The fact that he enhanced the code is just icing on the cake.

Jack, W8TEE

On Wednesday, January 22, 2020, 3:57:29 AM EST, Reed N <greenkid336600+groupsio@...> wrote:


Hi Neil,

1) Pretty sure this has been fixed for a while
2) Others have reported this too. I hope to look into it in the not-too-distant future
3) The CW tone is generated by a PWM signal from the Arduino. There might be some tricks to turn the normal PWM output into a class D amp of sorts, but that could be a rabbit hole, and is not something I anticipate I'll be looking into soon
4) I slightly bent the pins on my screen to get it to sit flush against the case, but didn't have any issues with shorting (that I've noticed)
5) In my software version, you can view the current values by going to the respective menus - it doesn't revert them to default. I don't know if this helps you if you're blind.
6) The uBitx software switches USB/LSB separately from CW mode, so you could potentially run USB CW
7) It looks like Ashhar put a fair number of pieces in place to support menu navigation with Morse Code audio feedback, but never hooked them up. I just created a branch that hopefully does something useful in this regard: https://github.com/reedbn/ubitxv6/tree/morse-menu . I've also attached a hex file, if that's easier for you. In this build, the long press of the tuning knob no longer goes to the menu - instead, it will toggle the menu audio feedback. To get to the setup menu, you'll instead need to select the "MNU" button (or 'M' as the audio will play). NOTE: there's currently no way to skip the audio on an item. Once it starts playing, you have to listen to the whole text before you can select the next item. This can make it quite slow to navigate menus, however I hope that it's better than nothing. Feedback on this build is welcome, but I make no promises of support or further revisions.


Reed

--
Jack, W8TEE

--
Jack, W8TEE

Re: : Thank you!

Ashhar Farhan
 

Jack,
the new code is a single ino file and the others are cpp file. the compilation is a breeze, now!

-- f

On Wed, Jan 22, 2020 at 8:44 PM Andy_501 <andrew.webb.501.ve4per@...> wrote:

Is there a kind of dedicated index of each file and a precis or summary para what each does or how it contributes to the whole or big picture as it were. I haven't begun looking into coding and compiling yet as getting the basics working completely is consuming enough time at this point. I gather from the posts here it is a common practice or occurrence; almost a right of passage hihi.

Andy_501

On 2020-01-22 8:25 a.m., Jack, W8TEE via Groups.Io wrote:
To me, the real win here, even if nothing was changed, is to have only 1 *.ino file. Farhan did us a favor of breaking out the code into separate files, which makes it much easier to find/change things. However, I was not able to convince him of the single *.ino file idea. The reason why it is such a HUGE win is because the IDE's compiler supports incremental compiles. I've seen an app with over 10000+ lines of C code in a single ino file. The JackAl code is 11000+ lines spread out over 19 source code files. The first time I compile the code in the morning, it takes over a minute to compile the code, and that's on a multi-core processor with 32Gb of memory scooting along at 3.8MHz. However, on the second compile, the time drops to about 5 seconds. The reason is because the IDE's compiler uses a "dirty flag" to mark those files I've changed since the last compile and it re-compiles only those files with a set dirty flag. Since debugging typically means re-compiling the same file over and over, I save myself almost a minute each time I re-compile. I might recompile the code at least 30 times/day, which saves me a half hour of thumb-twiddling each day. Add that up over 19 months and you're talking some serious time.

We all should appreciate and thank what Reed's done here. The fact that he enhanced the code is just icing on the cake.

Jack, W8TEE

On Wednesday, January 22, 2020, 3:57:29 AM EST, Reed N <greenkid336600+groupsio@...> wrote:


Hi Neil,

1) Pretty sure this has been fixed for a while
2) Others have reported this too. I hope to look into it in the not-too-distant future
3) The CW tone is generated by a PWM signal from the Arduino. There might be some tricks to turn the normal PWM output into a class D amp of sorts, but that could be a rabbit hole, and is not something I anticipate I'll be looking into soon
4) I slightly bent the pins on my screen to get it to sit flush against the case, but didn't have any issues with shorting (that I've noticed)
5) In my software version, you can view the current values by going to the respective menus - it doesn't revert them to default. I don't know if this helps you if you're blind.
6) The uBitx software switches USB/LSB separately from CW mode, so you could potentially run USB CW
7) It looks like Ashhar put a fair number of pieces in place to support menu navigation with Morse Code audio feedback, but never hooked them up. I just created a branch that hopefully does something useful in this regard: https://github.com/reedbn/ubitxv6/tree/morse-menu . I've also attached a hex file, if that's easier for you. In this build, the long press of the tuning knob no longer goes to the menu - instead, it will toggle the menu audio feedback. To get to the setup menu, you'll instead need to select the "MNU" button (or 'M' as the audio will play). NOTE: there's currently no way to skip the audio on an item. Once it starts playing, you have to listen to the whole text before you can select the next item. This can make it quite slow to navigate menus, however I hope that it's better than nothing. Feedback on this build is welcome, but I make no promises of support or further revisions.


Reed

--
Jack, W8TEE

Re: : Thank you!

Andy_501
 

Is there a kind of dedicated index of each file and a precis or summary para what each does or how it contributes to the whole or big picture as it were. I haven't begun looking into coding and compiling yet as getting the basics working completely is consuming enough time at this point. I gather from the posts here it is a common practice or occurrence; almost a right of passage hihi.

Andy_501

On 2020-01-22 8:25 a.m., Jack, W8TEE via Groups.Io wrote:
To me, the real win here, even if nothing was changed, is to have only 1 *.ino file. Farhan did us a favor of breaking out the code into separate files, which makes it much easier to find/change things. However, I was not able to convince him of the single *.ino file idea. The reason why it is such a HUGE win is because the IDE's compiler supports incremental compiles. I've seen an app with over 10000+ lines of C code in a single ino file. The JackAl code is 11000+ lines spread out over 19 source code files. The first time I compile the code in the morning, it takes over a minute to compile the code, and that's on a multi-core processor with 32Gb of memory scooting along at 3.8MHz. However, on the second compile, the time drops to about 5 seconds. The reason is because the IDE's compiler uses a "dirty flag" to mark those files I've changed since the last compile and it re-compiles only those files with a set dirty flag. Since debugging typically means re-compiling the same file over and over, I save myself almost a minute each time I re-compile. I might recompile the code at least 30 times/day, which saves me a half hour of thumb-twiddling each day. Add that up over 19 months and you're talking some serious time.

We all should appreciate and thank what Reed's done here. The fact that he enhanced the code is just icing on the cake.

Jack, W8TEE

On Wednesday, January 22, 2020, 3:57:29 AM EST, Reed N <greenkid336600+groupsio@...> wrote:


Hi Neil,

1) Pretty sure this has been fixed for a while
2) Others have reported this too. I hope to look into it in the not-too-distant future
3) The CW tone is generated by a PWM signal from the Arduino. There might be some tricks to turn the normal PWM output into a class D amp of sorts, but that could be a rabbit hole, and is not something I anticipate I'll be looking into soon
4) I slightly bent the pins on my screen to get it to sit flush against the case, but didn't have any issues with shorting (that I've noticed)
5) In my software version, you can view the current values by going to the respective menus - it doesn't revert them to default. I don't know if this helps you if you're blind.
6) The uBitx software switches USB/LSB separately from CW mode, so you could potentially run USB CW
7) It looks like Ashhar put a fair number of pieces in place to support menu navigation with Morse Code audio feedback, but never hooked them up. I just created a branch that hopefully does something useful in this regard: https://github.com/reedbn/ubitxv6/tree/morse-menu . I've also attached a hex file, if that's easier for you. In this build, the long press of the tuning knob no longer goes to the menu - instead, it will toggle the menu audio feedback. To get to the setup menu, you'll instead need to select the "MNU" button (or 'M' as the audio will play). NOTE: there's currently no way to skip the audio on an item. Once it starts playing, you have to listen to the whole text before you can select the next item. This can make it quite slow to navigate menus, however I hope that it's better than nothing. Feedback on this build is welcome, but I make no promises of support or further revisions.


Reed

--
Jack, W8TEE

Re: : Thank you!

Jack, W8TEE
 

To me, the real win here, even if nothing was changed, is to have only 1 *.ino file. Farhan did us a favor of breaking out the code into separate files, which makes it much easier to find/change things. However, I was not able to convince him of the single *.ino file idea. The reason why it is such a HUGE win is because the IDE's compiler supports incremental compiles. I've seen an app with over 10000+ lines of C code in a single ino file. The JackAl code is 11000+ lines spread out over 19 source code files. The first time I compile the code in the morning, it takes over a minute to compile the code, and that's on a multi-core processor with 32Gb of memory scooting along at 3.8MHz. However, on the second compile, the time drops to about 5 seconds. The reason is because the IDE's compiler uses a "dirty flag" to mark those files I've changed since the last compile and it re-compiles only those files with a set dirty flag. Since debugging typically means re-compiling the same file over and over, I save myself almost a minute each time I re-compile. I might recompile the code at least 30 times/day, which saves me a half hour of thumb-twiddling each day. Add that up over 19 months and you're talking some serious time.

We all should appreciate and thank what Reed's done here. The fact that he enhanced the code is just icing on the cake.

Jack, W8TEE

On Wednesday, January 22, 2020, 3:57:29 AM EST, Reed N <greenkid336600+groupsio@...> wrote:


Hi Neil,

1) Pretty sure this has been fixed for a while
2) Others have reported this too. I hope to look into it in the not-too-distant future
3) The CW tone is generated by a PWM signal from the Arduino. There might be some tricks to turn the normal PWM output into a class D amp of sorts, but that could be a rabbit hole, and is not something I anticipate I'll be looking into soon
4) I slightly bent the pins on my screen to get it to sit flush against the case, but didn't have any issues with shorting (that I've noticed)
5) In my software version, you can view the current values by going to the respective menus - it doesn't revert them to default. I don't know if this helps you if you're blind.
6) The uBitx software switches USB/LSB separately from CW mode, so you could potentially run USB CW
7) It looks like Ashhar put a fair number of pieces in place to support menu navigation with Morse Code audio feedback, but never hooked them up. I just created a branch that hopefully does something useful in this regard: https://github.com/reedbn/ubitxv6/tree/morse-menu . I've also attached a hex file, if that's easier for you. In this build, the long press of the tuning knob no longer goes to the menu - instead, it will toggle the menu audio feedback. To get to the setup menu, you'll instead need to select the "MNU" button (or 'M' as the audio will play). NOTE: there's currently no way to skip the audio on an item. Once it starts playing, you have to listen to the whole text before you can select the next item. This can make it quite slow to navigate menus, however I hope that it's better than nothing. Feedback on this build is welcome, but I make no promises of support or further revisions.


Reed

--
Jack, W8TEE

Re: Knob "Momentum" #ubitx #v6

Reed N
 

Hi Mick,

Glad to hear it feels intuitive for you. I spent at least 2 hours trying different acceleration profiles, and this one felt best to me of the ones I tried, so I'm glad at least one other person doesn't immediately hate the new feel :P

The fast tune mode actually was part of the stock software, so I can't take any credit for that, though the improved screen refresh and interrupt-based encoder readings definitely makes it go faster than stock.


Reed

Re: Knob "Momentum" #ubitx #v6

Reed N
 

Hi Andy,

I hope to look into the keyer stuff in the not-too-distant future. I don't have a keyer of any kind, so I'm limited to the PTT straight key for the time being, though it seems to work in some capacity on the mic/PTT port as well as on the keyer port.

I look forward to hearing back from you about the tuning speed, both in normal use as well as the extra resolution for zerobeat tuning, whenever you get around to trying this build.


Reed

Re: : #V6 software issues help please #v6

Reed N
 

Hi Neil,

1) Pretty sure this has been fixed for a while
2) Others have reported this too. I hope to look into it in the not-too-distant future
3) The CW tone is generated by a PWM signal from the Arduino. There might be some tricks to turn the normal PWM output into a class D amp of sorts, but that could be a rabbit hole, and is not something I anticipate I'll be looking into soon
4) I slightly bent the pins on my screen to get it to sit flush against the case, but didn't have any issues with shorting (that I've noticed)
5) In my software version, you can view the current values by going to the respective menus - it doesn't revert them to default. I don't know if this helps you if you're blind.
6) The uBitx software switches USB/LSB separately from CW mode, so you could potentially run USB CW
7) It looks like Ashhar put a fair number of pieces in place to support menu navigation with Morse Code audio feedback, but never hooked them up. I just created a branch that hopefully does something useful in this regard: https://github.com/reedbn/ubitxv6/tree/morse-menu . I've also attached a hex file, if that's easier for you. In this build, the long press of the tuning knob no longer goes to the menu - instead, it will toggle the menu audio feedback. To get to the setup menu, you'll instead need to select the "MNU" button (or 'M' as the audio will play). NOTE: there's currently no way to skip the audio on an item. Once it starts playing, you have to listen to the whole text before you can select the next item. This can make it quite slow to navigate menus, however I hope that it's better than nothing. Feedback on this build is welcome, but I make no promises of support or further revisions.


Reed

Re: V5 reprogram.

MVS Sarma
 

They are available at github of fahan mainly and ubitx.net is a link to same.


On Wed, 22 Jan 2020, 5:01 am Matt 9V1MH / VK3AMH, <matthoward.sg@...> wrote:
The original firmware for all versions is available at groups.io

Re: V5 reprogram.

Matt 9V1MH/VK3AMH/YF2AAH
 

The original firmware for all versions is available at groups.io

Re: Help with Audio Chain - M1 and M2 Are Ground? #ubitx-help #v6 #v5 #v4 #audiocircuit

Don, ND6T
 

Hah! I forgot to include the relay. Also I meant to say "source and gate" but wrote "source and drain"!  So yes,  I guess I shoulda stayed at Holiday In Express last night!

Re: Help with Audio Chain - M1 and M2 Are Ground? #ubitx-help #v6 #v5 #v4 #audiocircuit

AndyH
 

Crud.  There's an M1/M2 flag on the T/R relay, K3, as well as the M1-M4 flags to ground on the top of schematic.  I guess that's how the signal jumps the M1 to M2 flags.  Sorry for the noise, folks.

Don - thanks again for your walk through - it helped me see how the pop fix works.  Now...maybe...finally...I can get on with my scratch built V3 V4 V5 V6 radio. LOL

Best to the group,
Andy

Re: IRF510 insulation question #v5

Rick Green
 

On Tue, 21 Jan 2020, Don - KM4UDX wrote:

So I got the ceramic insulators.  The included bushing fits the screw just fine.  And the screw, without the bushing fits the wafer just fine. But put the bushing on the screw, and ain't
nothing going in the ceramic hole...
It looks to me like it was intended to be assembled thus:

1) Enlarge the hole in the heat sink to accomodate the bushing.
2) Insert the screw in the bushing, and the bushing in the BACK of the heat sink.
3) Place the wafer over the screw on the front of the heat sink.
4) Install the IRF510 on the screw protruding from the wafer.
5) Secure the entire stack with a lockwasher and nut.

This will insulate the IRF510 from the heat sink, but the screw head on the back will still be at the same potential as the IRF510 tab. At least, its a much smaller target for a distracted errant screwdriver ;-)

Rick Green


They are (relatively) thicker than thin silicon wafers/pads. Which would not be a problem if...
The hole were not too small for the insulating bushing. Which would not be a problem if...
The ceramic material were not so hard and brittle that I couldn't drill or sand/grind it bigger. Which wouldn't be a problem if...
I didn't want the heat sink and screw electrically isolated from the IFR510 case.  Which wouldn't be a problem if...
I could return them. Which as a practical matter I can't.  Does anyone want a few of these to play with? 
hahah.[IMAGE]
--
Rick Green

We, the People of the United States of America, reject the U.S. Supreme Court's
Citizens United ruling, and move to amend our Constitution to firmly establish
that money is not speech, and that human beings, not corporations, are persons
entitled to constitutional rights.

http://www.MoveToAmend.org

Re: Help with Audio Chain - M1 and M2 Are Ground? #ubitx-help #v6 #v5 #v4 #audiocircuit

AndyH
 

Hi Don,

   I appreciate the walk through!  Ultimately, I'm finding that I'm unable to trace the audio signal because it appears to go to flag M1, while the input for the final amp seems to have to come from flag M2.  What I don't understand is how the signal jumps from flag to flag, since the schematic says that flags M1, M2, M3, and M4 go to ground.  I figure I must be missing something simple (mostly 'cause I'm not an EE and didn't stay in a Holiday Inn Express last night :) ).

73, Andy

   


On Tue, Jan 21, 2020 at 03:40 PM, Don, ND6T wrote:
Andy,
Perhaps you're thinking of the MOSFET as being like a vacuum tube (Fleming valve) and requiring a bias voltage at the drain (corresponding to a tube plate). It does not.
Consider the device to be a resistor between the source and drain terminals and the resistance of that is controlled by the gate terminal. The important bias in a MOSFET is the voltage between source and drain only.
The drain isn't grounded directly. Rather it is connected through the body of the volume control. No DC voltage but the audio is still there.
So just concentrate upon the audio signal, instead. It passes from the pre-amplifier (Q70 collector) through a DC blocking capacitor (C51), through  R70 (which allows some side-tone audio to survive muting) and is applied to the volume control (RV4) which selects how much audio signal is to be applied to the input of the audio output amplifier (U1).
If the gate of Q74 is turned on by a positive bias then it presents a short circuit to that audio stream, routing it right to ground and reducing it so that effectively nothing reaches the volume control (except for side-tone, if it's there).
Does that help?
73,
Don