Topics

Tuning reversed issue


W2CTX
 

Working with Jim, W0EB, I found that if the black and brown wires
are reversed on the encoder then the frequency tuning is backwards.
Some people, including myself, just changed the "doTuning" routine
to reverse the offsets.  This however fixes the frequency tuning but
the menus options seem to be backwards.

Better fix is to change the enc_read(void) routine and then both the
freq tuning and menus selections are in sync.

Please correct me if I am wrong.

Ron


Jack, W8TEE
 

One of the beautiful things in C are symbolic constants. These are textual strings that get substituted by the compiler. Around line 75 in ubitx_20.ino you will find  these two symbolic constants:

#define ENC_A (A0)
#define ENC_B (A1)

these define encoder tab A and B to be assigned to Nano pins A0 and A1. Now reverse these to:

#define ENC_A (A1)            // NOTE: these are reversed from the original code
#define ENC_B (A0)

and everywhere those symbolic constants (END_A and ENC_B) are used have now been reversed. Save, recompile, and upload and you're done.

                                                                                  OR

you can open your µBITX, unsolder pins A1 and A0, reverse those two connections, resolder the two leads, and put everything back in it's case. To me, the software change is easier and the change presented here doesn't mess with the function code.

Jack, W8TEE



From: Ronald Pfeiffer via Groups.Io <w2ctx@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 4:09 PM
Subject: [BITX20] Tuning reversed issue

Working with Jim, W0EB, I found that if the black and brown wires
are reversed on the encoder then the frequency tuning is backwards.
Some people, including myself, just changed the "doTuning" routine
to reverse the offsets.  This however fixes the frequency tuning but
the menus options seem to be backwards.

Better fix is to change the enc_read(void) routine and then both the
freq tuning and menus selections are in sync.

Please correct me if I am wrong.

Ron



Dave Bottom <ars.kd6az@...>
 

As commented earlier the Wire-Up schematic is viewed from the Shaft side of the Encoder.  Although I like to always show the more natural view as from the back how you might wire it up.
Hopefully when Farhan edits this schematic to swap the Volume control wiring error he will add the "view" so it will save a lot of confusion. 

Dave WI6R

On Sun, Jan 7, 2018 at 1:09 PM, Ronald Pfeiffer via Groups.Io <w2ctx@...> wrote:
Working with Jim, W0EB, I found that if the black and brown wires
are reversed on the encoder then the frequency tuning is backwards.
Some people, including myself, just changed the "doTuning" routine
to reverse the offsets.  This however fixes the frequency tuning but
the menus options seem to be backwards.

Better fix is to change the enc_read(void) routine and then both the
freq tuning and menus selections are in sync.

Please correct me if I am wrong.

Ron




--
73 Dave WI6R


W2CTX
 

Thanks Jack.  I remember you posting this last week.
At 73 somethings take a while to sink in! hi hi

Ron



From: Jack Purdum via Groups.Io <jjpurdum@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 4:22 PM
Subject: Re: [BITX20] Tuning reversed issue

One of the beautiful things in C are symbolic constants. These are textual strings that get substituted by the compiler. Around line 75 in ubitx_20.ino you will find  these two symbolic constants:

#define ENC_A (A0)
#define ENC_B (A1)

these define encoder tab A and B to be assigned to Nano pins A0 and A1. Now reverse these to:

#define ENC_A (A1)            // NOTE: these are reversed from the original code
#define ENC_B (A0)

and everywhere those symbolic constants (END_A and ENC_B) are used have now been reversed. Save, recompile, and upload and you're done.

                                                                                  OR

you can open your µBITX, unsolder pins A1 and A0, reverse those two connections, resolder the two leads, and put everything back in it's case. To me, the software change is easier and the change presented here doesn't mess with the function code.

Jack, W8TEE



From: Ronald Pfeiffer via Groups.Io <w2ctx@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 4:09 PM
Subject: [BITX20] Tuning reversed issue

Working with Jim, W0EB, I found that if the black and brown wires
are reversed on the encoder then the frequency tuning is backwards.
Some people, including myself, just changed the "doTuning" routine
to reverse the offsets.  This however fixes the frequency tuning but
the menus options seem to be backwards.

Better fix is to change the enc_read(void) routine and then both the
freq tuning and menus selections are in sync.

Please correct me if I am wrong.

Ron





W2CTX
 

Maybe this should be part of Calibration.  Turn clockwise
and have software determine the offset for the encoder.

Beats soldering or changing the code.

Ron



From: Dave Bottom <ars.kd6az@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 4:26 PM
Subject: Re: [BITX20] Tuning reversed issue

As commented earlier the Wire-Up schematic is viewed from the Shaft side of the Encoder.  Although I like to always show the more natural view as from the back how you might wire it up.
Hopefully when Farhan edits this schematic to swap the Volume control wiring error he will add the "view" so it will save a lot of confusion. 

Dave WI6R

On Sun, Jan 7, 2018 at 1:09 PM, Ronald Pfeiffer via Groups.Io <w2ctx@...> wrote:
Working with Jim, W0EB, I found that if the black and brown wires
are reversed on the encoder then the frequency tuning is backwards.
Some people, including myself, just changed the "doTuning" routine
to reverse the offsets.  This however fixes the frequency tuning but
the menus options seem to be backwards.

Better fix is to change the enc_read(void) routine and then both the
freq tuning and menus selections are in sync.

Please correct me if I am wrong.

Ron



--
73 Dave WI6R



Jack, W8TEE
 

At age 74, I didn't remember posting it!! :>)

Jack, W8TEE



From: Ronald Pfeiffer via Groups.Io <w2ctx@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 4:34 PM
Subject: Re: [BITX20] Tuning reversed issue

Thanks Jack.  I remember you posting this last week.
At 73 somethings take a while to sink in! hi hi

Ron



From: Jack Purdum via Groups.Io <jjpurdum@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 4:22 PM
Subject: Re: [BITX20] Tuning reversed issue

One of the beautiful things in C are symbolic constants. These are textual strings that get substituted by the compiler. Around line 75 in ubitx_20.ino you will find  these two symbolic constants:

#define ENC_A (A0)
#define ENC_B (A1)

these define encoder tab A and B to be assigned to Nano pins A0 and A1. Now reverse these to:

#define ENC_A (A1)            // NOTE: these are reversed from the original code
#define ENC_B (A0)

and everywhere those symbolic constants (END_A and ENC_B) are used have now been reversed. Save, recompile, and upload and you're done.

                                                                                  OR

you can open your µBITX, unsolder pins A1 and A0, reverse those two connections, resolder the two leads, and put everything back in it's case. To me, the software change is easier and the change presented here doesn't mess with the function code.

Jack, W8TEE



From: Ronald Pfeiffer via Groups.Io <w2ctx@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 4:09 PM
Subject: [BITX20] Tuning reversed issue

Working with Jim, W0EB, I found that if the black and brown wires
are reversed on the encoder then the frequency tuning is backwards.
Some people, including myself, just changed the "doTuning" routine
to reverse the offsets.  This however fixes the frequency tuning but
the menus options seem to be backwards.

Better fix is to change the enc_read(void) routine and then both the
freq tuning and menus selections are in sync.

Please correct me if I am wrong.

Ron







Jim Sheldon
 

After Ron helped me get over the "stupids" and I finally learned how to properly compile & upload stuff to the Raduino, I now have Ron's mods running and he's fixed a lot of little annoying things (annoying to me anyway).  In between bricking & fixing the rig (all firmware, no hardware) I managed to make a couple of real nice 20 meter SSB QSO's and also a couple of 40 meter CW QSO's as well with it.

I heard a lot of RTTY (contest this weekend) and sure wish there were at least 5 more digital pins on the Nano.  Then it would really easy to implement a good CW Keyer and even implement true FSK for RTTY.  You'd still need a computer with sound card running something like Mako Mori's (JE1HHT) MMTTY program, but that would really work well.  Hardware FSK would be much cleaner to implement than tones into the SSB section.  As wide as the filter is, I'd be wary of the 2nd and maybe even 3rd harmonics of the tones being transmitted at the same time as the fundamentals.  That would really create havoc on the bands especially during a RTTY contest, not to mention incur the wrath of the FCC as well.

Jim - W0EB

This little rig just keeps getting better and quite rapidly too!


John McFadden <johnamcf@...>
 

Even easier is using a small object (thumb tack, tiny drill bit, etc) to unhook the black and brown wires from the header and reverse their positions. Then you can change sketches without worry in the future.

John


On 1/7/2018 4:22 PM, Jack Purdum via Groups.Io wrote:
One of the beautiful things in C are symbolic constants. These are textual strings that get substituted by the compiler. Around line 75 in ubitx_20.ino you will find  these two symbolic constants:

#define ENC_A (A0)
#define ENC_B (A1)

these define encoder tab A and B to be assigned to Nano pins A0 and A1. Now reverse these to:

#define ENC_A (A1)            // NOTE: these are reversed from the original code
#define ENC_B (A0)

and everywhere those symbolic constants (END_A and ENC_B) are used have now been reversed. Save, recompile, and upload and you're done.

                                                                                  OR

you can open your µBITX, unsolder pins A1 and A0, reverse those two connections, resolder the two leads, and put everything back in it's case. To me, the software change is easier and the change presented here doesn't mess with the function code.

Jack, W8TEE



From: Ronald Pfeiffer via Groups.Io <w2ctx@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 4:09 PM
Subject: [BITX20] Tuning reversed issue

Working with Jim, W0EB, I found that if the black and brown wires
are reversed on the encoder then the frequency tuning is backwards.
Some people, including myself, just changed the "doTuning" routine
to reverse the offsets.  This however fixes the frequency tuning but
the menus options seem to be backwards.

Better fix is to change the enc_read(void) routine and then both the
freq tuning and menus selections are in sync.

Please correct me if I am wrong.

Ron




Jack, W8TEE
 

Sounds like more work to me. There's nothing sacrosanct about the two analog pins. As far as changing sketches, whose sketches? If you write your own, it really doesn't matter. If you use someone else's, make a few typing changes and you're done. If you change the wires and then replace the board, then what? Quite often it is easier to make a software change than a hardware change.

Jack, W8TEE



From: John McFadden <johnamcf@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 10:15 PM
Subject: Re: [BITX20] Tuning reversed issue

Even easier is using a small object (thumb tack, tiny drill bit, etc) to unhook the black and brown wires from the header and reverse their positions. Then you can change sketches without worry in the future.
John

On 1/7/2018 4:22 PM, Jack Purdum via Groups.Io wrote:
One of the beautiful things in C are symbolic constants. These are textual strings that get substituted by the compiler. Around line 75 in ubitx_20.ino you will find  these two symbolic constants:

#define ENC_A (A0)
#define ENC_B (A1)

these define encoder tab A and B to be assigned to Nano pins A0 and A1. Now reverse these to:

#define ENC_A (A1)            // NOTE: these are reversed from the original code
#define ENC_B (A0)

and everywhere those symbolic constants (END_A and ENC_B) are used have now been reversed. Save, recompile, and upload and you're done.

                                                                                  OR

you can open your µBITX, unsolder pins A1 and A0, reverse those two connections, resolder the two leads, and put everything back in it's case. To me, the software change is easier and the change presented here doesn't mess with the function code.

Jack, W8TEE



From: Ronald Pfeiffer via Groups.Io <w2ctx@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 4:09 PM
Subject: [BITX20] Tuning reversed issue

Working with Jim, W0EB, I found that if the black and brown wires
are reversed on the encoder then the frequency tuning is backwards.
Some people, including myself, just changed the "doTuning" routine
to reverse the offsets.  This however fixes the frequency tuning but
the menus options seem to be backwards.

Better fix is to change the enc_read(void) routine and then both the
freq tuning and menus selections are in sync.

Please correct me if I am wrong.

Ron






W2CTX
 

Jack you are right.

I was thinking of this ubitx software center git.

Ron



From: Jack Purdum via Groups.Io <jjpurdum@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 10:20 PM
Subject: Re: [BITX20] Tuning reversed issue

Sounds like more work to me. There's nothing sacrosanct about the two analog pins. As far as changing sketches, whose sketches? If you write your own, it really doesn't matter. If you use someone else's, make a few typing changes and you're done. If you change the wires and then replace the board, then what? Quite often it is easier to make a software change than a hardware change.

Jack, W8TEE



From: John McFadden <johnamcf@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 10:15 PM
Subject: Re: [BITX20] Tuning reversed issue

Even easier is using a small object (thumb tack, tiny drill bit, etc) to unhook the black and brown wires from the header and reverse their positions. Then you can change sketches without worry in the future.
John

On 1/7/2018 4:22 PM, Jack Purdum via Groups.Io wrote:
One of the beautiful things in C are symbolic constants. These are textual strings that get substituted by the compiler. Around line 75 in ubitx_20.ino you will find  these two symbolic constants:

#define ENC_A (A0)
#define ENC_B (A1)

these define encoder tab A and B to be assigned to Nano pins A0 and A1. Now reverse these to:

#define ENC_A (A1)            // NOTE: these are reversed from the original code
#define ENC_B (A0)

and everywhere those symbolic constants (END_A and ENC_B) are used have now been reversed. Save, recompile, and upload and you're done.

                                                                                  OR

you can open your µBITX, unsolder pins A1 and A0, reverse those two connections, resolder the two leads, and put everything back in it's case. To me, the software change is easier and the change presented here doesn't mess with the function code.

Jack, W8TEE



From: Ronald Pfeiffer via Groups.Io <w2ctx@...>
To: BITX20@groups.io
Sent: Sunday, January 7, 2018 4:09 PM
Subject: [BITX20] Tuning reversed issue

Working with Jim, W0EB, I found that if the black and brown wires
are reversed on the encoder then the frequency tuning is backwards.
Some people, including myself, just changed the "doTuning" routine
to reverse the offsets.  This however fixes the frequency tuning but
the menus options seem to be backwards.

Better fix is to change the enc_read(void) routine and then both the
freq tuning and menus selections are in sync.

Please correct me if I am wrong.

Ron








Tim Gorman
 

Jim,

Aren't RTTY tones 2125hz and 2295hz? The filter in the ubitx should be
narrow enough to filter out 2nd and 3rd harmonics of these frequencies.

If it can't filter out the harmonics of these tones then the SSB voice
signal is probably also far wider than it should be.

tim ab0wr



On Sun, 07 Jan 2018 18:11:44 -0800
"Jim Sheldon" <@W0EB> wrote:

After Ron helped me get over the "stupids" and I finally learned how
to properly compile & upload stuff to the Raduino, I now have Ron's
mods running and he's fixed a lot of little annoying things (annoying
to me anyway).  In between bricking & fixing the rig (all firmware,
no hardware) I managed to make a couple of real nice 20 meter SSB
QSO's and also a couple of 40 meter CW QSO's as well with it.

I heard a lot of RTTY (contest this weekend) and sure wish there were
at least 5 more digital pins on the Nano.  Then it would really easy
to implement a good CW Keyer and even implement true FSK for RTTY.
You'd still need a computer with sound card running something like
Mako Mori's (JE1HHT) MMTTY program, but that would really work well.
Hardware FSK would be much cleaner to implement than tones into the
SSB section.  As wide as the filter is, I'd be wary of the 2nd and
maybe even 3rd harmonics of the tones being transmitted at the same
time as the fundamentals.  That would really create havoc on the
bands especially during a RTTY contest, not to mention incur the
wrath of the FCC as well.

Jim - W0EB

This little rig just keeps getting better and quite rapidly too!


Gordon Gibby <ggibby@...>
 

Using FLDIGI, you can put your RTTY tonesanywhere you want them.....

And by watching the waterfall, you can visualize your receiving filter as well.

gordon


________________________________________
From: BITX20@groups.io <BITX20@groups.io> on behalf of Tim Gorman <tgorman2@...>
Sent: Sunday, January 7, 2018 11:36 PM
To: BITX20@groups.io
Subject: Re: [BITX20] Tuning reversed issue

Jim,

Aren't RTTY tones 2125hz and 2295hz? The filter in the ubitx should be
narrow enough to filter out 2nd and 3rd harmonics of these frequencies.

If it can't filter out the harmonics of these tones then the SSB voice
signal is probably also far wider than it should be.

tim ab0wr



On Sun, 07 Jan 2018 18:11:44 -0800
"Jim Sheldon" <@W0EB> wrote:

After Ron helped me get over the "stupids" and I finally learned how
to properly compile & upload stuff to the Raduino, I now have Ron's
mods running and he's fixed a lot of little annoying things (annoying
to me anyway). In between bricking & fixing the rig (all firmware,
no hardware) I managed to make a couple of real nice 20 meter SSB
QSO's and also a couple of 40 meter CW QSO's as well with it.

I heard a lot of RTTY (contest this weekend) and sure wish there were
at least 5 more digital pins on the Nano. Then it would really easy
to implement a good CW Keyer and even implement true FSK for RTTY.
You'd still need a computer with sound card running something like
Mako Mori's (JE1HHT) MMTTY program, but that would really work well.
Hardware FSK would be much cleaner to implement than tones into the
SSB section. As wide as the filter is, I'd be wary of the 2nd and
maybe even 3rd harmonics of the tones being transmitted at the same
time as the fundamentals. That would really create havoc on the
bands especially during a RTTY contest, not to mention incur the
wrath of the FCC as well.

Jim - W0EB

This little rig just keeps getting better and quite rapidly too!


Tim Gorman
 

With a 2.4khz to 2.5khz filter you wouldn't want to run the tones any
lower than about 1.25khz so you could filter out any audio harmonics,
right?

My guess is that if you are generating audio harmonics you have
something else badly wrong!

tim ab0wr

On Mon, 8 Jan 2018 04:46:35 +0000
"Gordon Gibby" <ggibby@...> wrote:

Using FLDIGI, you can put your RTTY tonesanywhere you want them.....

And by watching the waterfall, you can visualize your receiving
filter as well.

gordon


Gordon Gibby <ggibby@...>
 

If you're having problems with audio harmonics, yes, you would want to put your tones higher than the midpoint of the filter....but with any reasonable sound card, there should be negligible harmonics, so I don't completely understand the issue or concern....I use $5 Adafruit 1475 usb dongles without any untoward effects that I know of....


________________________________________
From: BITX20@groups.io <BITX20@groups.io> on behalf of Tim Gorman <tgorman2@...>
Sent: Sunday, January 7, 2018 11:53 PM
To: BITX20@groups.io
Subject: Re: [BITX20] Tuning reversed issue

With a 2.4khz to 2.5khz filter you wouldn't want to run the tones any
lower than about 1.25khz so you could filter out any audio harmonics,
right?

My guess is that if you are generating audio harmonics you have
something else badly wrong!

tim ab0wr

On Mon, 8 Jan 2018 04:46:35 +0000
"Gordon Gibby" <ggibby@...> wrote:

Using FLDIGI, you can put your RTTY tonesanywhere you want them.....

And by watching the waterfall, you can visualize your receiving
filter as well.

gordon