Date   
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

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

Don, ND6T
 

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