Date   
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

Re: IRF510 insulation question #v5

Don - KM4UDX
 

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...

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.

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

AndyH
 

Put another way, maybe:  I can't figure out how the audio signal makes the trip from the audio pre-amp to the LM386 final amp.


On Tue, Jan 21, 2020 at 12:26 PM, AndyH wrote:
I'm trying to understand the flow of the signal through the audio amp and pop-fix FET (Q74 in at least the V6).  I *think* I get that in the amplifier stage around Q70 (V6) has a bypass cap to ground, as indicated by flag M1.  The 2N7000 Q74 (V6) appears to have both terminals 2 and 3 grounded (pin 3 via flag M2).  Is that correct?  Am I reading the schematic correctly that flags M1 through M4 are ground?  If so, it appears that grounds the CW tone input and VOL-H via the 1K resistor R70.  

Thanks!
Andy  KG5RKP

Re: : #V6 software issues help please #v6

AndyH
 

I can't speak to the rest from the vantage point of my modded V3, but it appears that item 1 has been and/or is being worked.  Ashhar reported it on Christmas day, 2019.

https://groups.io/g/BITX20/message/74007


On Tue, Jan 21, 2020 at 02:33 PM, Neil k8it wrote:


 

Begin forwarded message:

From: Neil Sablatzky <k8it@...>
Date: January 21, 2020 at 3:26:58 PM EST
To: farhanbox@...
Subject: #V6 software issues help please

Asher
With help from an experienced uBitX builder we just finished putting together a V6 complete kit. I am very disappointed.
I would appreciate your help to resolve these issues ASAP.

1. No 17M band
2. Lag time on CW it is almost impossible to operate CW with either a straight key or a iambic panel since it takes about 1.5 seconds to respond.

3. No side tone volume adjustment can this be added in software? Or what is the best way to add this?

4. Mounting of display standoffs shorted to metal case. We fixed this by ordering nylon standoffs. The dimensions of the case seems off.
5. Unknown calibration numbers for 10MHz, set frequently , set BFO values. Please add a function to read back the calibration values so they can be recorded.
6. why does the LSB button stay  lit when Cw button is pushed?
7. You had indicated that you would add Morse code feedback for selections and frequency . I am completely blind and had the help of two others in building this radio. When will this update be available? It was stated on the blind hams net that you would have this ready this month.

Thanks
73 Neil k8it








: #V6 software issues help please #v6

Neil k8it
 




Begin forwarded message:

From: Neil Sablatzky <k8it@...>
Date: January 21, 2020 at 3:26:58 PM EST
To: farhanbox@...
Subject: #V6 software issues help please

Asher
With help from an experienced uBitX builder we just finished putting together a V6 complete kit. I am very disappointed.
I would appreciate your help to resolve these issues ASAP.

1. No 17M band
2. Lag time on CW it is almost impossible to operate CW with either a straight key or a iambic panel since it takes about 1.5 seconds to respond.

3. No side tone volume adjustment can this be added in software? Or what is the best way to add this?

4. Mounting of display standoffs shorted to metal case. We fixed this by ordering nylon standoffs. The dimensions of the case seems off.
5. Unknown calibration numbers for 10MHz, set frequently , set BFO values. Please add a function to read back the calibration values so they can be recorded.
6. why does the LSB button stay  lit when Cw button is pushed?
7. You had indicated that you would add Morse code feedback for selections and frequency . I am completely blind and had the help of two others in building this radio. When will this update be available? It was stated on the blind hams net that you would have this ready this month.

Thanks
73 Neil k8it








Re: STM32F769-FT8-Transceiver

Art Olson
 

Charlie



Hello again. I finally got back on this project and am a bit puzzled as to
which board stack on the headers. I ordered the adafruit proto board and it
can be stacked with the nano or with the F769 board. However I can’t seem to
find a way to stack all three together – maybe its just me. I have your
latest release with the proto board showing the jumpers soldered. But
haven’t found anything that shows the boards stacked or the backside of the
f769 display. So my question is – which boards stack together?



73

Art N2AJO



From: BITX20@groups.io <BITX20@groups.io> On Behalf Of Charles Hill
Sent: Monday, December 9, 2019 8:32 AM
To: BITX20@groups.io
Subject: [BITX20] STM32F769-FT8-Transceiver



Well I finally gotten the
<https://github.com/chillmf/STM32F769-FT8-Transceiver>
STM32F769-FT8-Transceiver project to a state worth releasing.

I have placed the files required for making the project on Github at this
location: <https://github.com/chillmf/STM32F769-FT8-Transceiver>
https://github.com/chillmf/STM32F769-FT8-Transceiver

I hope you enjoy the project.

Regards,

Charley

Re: Knob "Momentum" #ubitx #v6

Mick
 

Reed,
for fast tune I was referring to the fast tune mode when selecting VFO twice. The accelerated tuning feature is also  very nice. At very slow speeds more precise tuning is possible, as you speed up dialling the tuning incremental jumps are Appropriate and intuative.
I’m having fun playing with the changes
73 
Mick VA3EPM