Date   
Re: Made Mods to V3 uBitx - no longer transmitting #ubitx-help #v3

 

Is it receiving ?

Raj


At 23-01-20, you wrote:
I've completed 3 fixes/modifications to my uBitx v3.  These include:

Make your rig compliant by removing unwanted spurs  http://ubitx.net/spectral-purity/

Make your rig (mostly) compliant by removing unwanted harmonics (same link)

FIX: UNEVEN TX OUTPUT ACROSS BANDS Relay and potentiometer solution (Bill K9HZ  THE N6CNY VERSION)  http://ubitx.net/fix-fix-uneven-tx-output-across-bands/

After completing the mods, the rig is no longer transmitting.  I have tested the new board and believe it is working properly.  As far as I can tell, the new relay switches are working properly.  I've installed and reinstalled the L5 and L7 capacitors.  I've adjusted the new pots in several different ways.  Still nothing. 

Radiuno appears to be functioning properly. 

I fear I've messed up something else in the process. 

What advice can you give me on the best method to debug the board?  I have little experience in modifying and/or building electronics. 

Re: Knob "Momentum" #ubitx #v6

Reed N
 

Hi Mark,

The simple solutions (and formulas) are often the best. Just wish I had thought of it sooner!

I don't think it's all that hard to read, since sizeof(thing) is returning the size of the thing, but we may have to agree to disagree on this point. Related, don't look at setup.cpp's RUN_MENU macro :P


Reed

Re: Knob "Momentum" #ubitx #v6

Smitty, KR6ZY
 

Oh sure, go all precise and site reference documentation on me. ;-)

Yeah, alright. I trust that the code is doing the right thing. I still contend that you’re relying on some subtle definitions of the language and the code could be more readable if you’re explicit. But at least it’s not broken. :-)

I didn’t understand most of those strategies you listed (at least not by name), but I do really like the non-linear function you used. Super simple to do in integer math, super quick, and very effective for this use case. 

-Mark

On Jan 22, 2020, at 10:43 PM, Reed N <greenkid336600+groupsio@...> wrote:

Hi Mark,

Thanks for the comments.

You're right to be concerned about array sizes and initialization. Using brace notation, any omitted values are assumed to be zero (see https://en.cppreference.com/w/c/language/array_initialization ), and since the array is of a known size in this context, the sizeof will return the full size of the array, not the size of the pointer (see https://www.geeksforgeeks.org/using-sizof-operator-with-array-paratmeters/). Thus, the code as written should be doing the correct thing in it's current state, however it wouldn't be too hard to mess it up by accident if somebody didn't understand the subtle differences between arr[3], arr[], and arr*. The fact that you were worried about these things at all suggests you've been bitten by them before, and have learned from it, which is a good thing :)

With respect to the lack of documentation, per https://groups.io/g/BITX20/message/75173, I spent a LOT of time trying a LOT of different strategies before settling on what is in the branch now. I'm not sure that I have it totally nailed (still hoping that Bert will provide additional feedback), so I'm a bit hesitant to write up a lot of documentation on it into the code right now, but just to give you a feel for why I didn't spend the time of documenting up front, here's a list of some of the other strategies I tried:
  • Thresholded accelerations that acted as a step-wise P term
  • Thresholded accelerations that acted as a piecewise-linear P term
  • Thresholded accelerations that acted as a step-wise I term, with several different types of per-function-call zero-tending corrections
  • Linear accelerations acting as an I term, with a number of different values for a basic IIR filter, with several different types of per-function-call zero-tending corrections
  • Thresholded accelerations that acted as a step-wise P term, with 10Hz timer interrupt reduction
  • Linear accelerations acting as an I term, with 10Hz timer interrupt
  • Thresholded acclerations that acted as a step-wise I term, with 10Hz and 5Hz timer interrupt
  • Nonlinear acceleration that acted as an I term, with 5Hz timer interrupt
As you can see, there's quite a lot of variation on both the what and how of the various techniques! However, I can give you a description of what's going on in the current rendition:
  • Every 200ms (that is, at 5Hz), the timer interrupt fires, and stores the total number of counts on the knob since the last interrupt. An interrupt is used so that it doesn't matter what the main loop is doing, and will work in all menus, tuning situations, etc. 5Hz was chosen to balance responsiveness against resolution. For instance, 1000Hz interrupts would likely only register at most 1 count, so we could only expect values of 0 or 1, which doesn't give much information about how fast the dial was being turned. However, selecting 1Hz interrupts would take a full second to notice that the dial was being turned more quickly (or slowly) than before, and would take a full second before they stopped accelerating, leading to significant overshoot.
  • The last 3 interrupt measurements are stored, which allows the code to not only observe the last 200ms speed, but also the previous 2 periods before that, giving a total window of 600ms. This gives a little more context to the numbers: are we seeing wildly changing knob speeds, or are they fairly constant?
  • We then look at the minimum number of counts across these three measurements, with the idea that if the dial was briefly bumped, we don't want to jump too far, but if the dial is consistently high, then the user probably is actually trying to move quickly. We use the absolute value (aka magnitude) so that everything works regardless of turn direction, and it nicely affords the ability to reverse tuning direction at speed without losing the acceleration.
  • Finally, there's the nonlinear mapping of this minimum count value. For small numbers of counts, we don't want to accelerate, because the user is probably trying to fine-tune. For large numbers, we set a maximum speedup so that a VERY fast knob turner won't end up in no-man's land by accident. For medium numbers, we scale nonlinearly, with more acceleration the faster the knob is turned, so that there's a large range of accelerations possible, despite a somewhat small linear input space.

For my own testing, I would load up the trial code, then try to tune from one point to another and back (1.000MHz -> 7.028MHz -> 1.000MHz, if anybody is curious), and (subjectively) evaluated how easy I felt it was to accurately tune to those exact frequencies, and how "fast" it felt to tune that distance. The main adjustment points for the currently implemented acceleration are the interrupt frequency, depth of the history, and the thresholds for "large", "medium", and "small" numbers of counts (which may require changes to the nonlinear function for the medium acceleration for mathematical reasons).

AAAAND if you made it this far into that text wall, congrats, and thanks for reading :P



Reed

Re: Knob "Momentum" #ubitx #v6

Reed N
 

Hi Sarma,

Glad to hear you've got it working. I'd love to hear any feedback on the acceleration feature if you have any issues or concerns with it.


Reed

Re: : Thank you!

Reed N
 

Hi Jack,

The code files were named *.cpp even before I started work on it, so I can't take any credit for that. See Ashhar's commit just prior to when I started working on the project for evidence: https://github.com/reedbn/ubitxv6/tree/fe1ff169380f744d8a07c194dcae51e3264e2a39

I haven't touched the README.md (having too much fun working on the actual code!) but I agree that the wording isn't quite right. Could you make the required changes and then create a pull request into my master branch?


Reed

Re: Knob "Momentum" #ubitx #v6

MVS Sarma
 

Thanks Reed.
I can compile from 1.8.5 and manage. No issues.in fact xlodear etc are more cumbresome than directly loading from ide. 
Thanks foe the support.
Sarma

On Thu, 23 Jan 2020, 12:18 pm Reed N, <greenkid336600+groupsio@...> wrote:
Hi Sarma,

Sorry to hear you're having issues with the newer versions. I didn't notice any major usage changes between 1.6.6 and 1.8.9, but I'm also fairly savvy when it comes to these sorts of things.

If you make the changes I mentioned in https://groups.io/g/BITX20/message/75189, or if you can load the hex attached to the initial message in this thread https://groups.io/g/BITX20/message/75140 (using AVRDUDE or Xloader, for instance), then you should be able to try it yourself.


Reed

Re: Knob "Momentum" #ubitx #v6

Reed N
 

Hi Sarma,

Sorry to hear you're having issues with the newer versions. I didn't notice any major usage changes between 1.6.6 and 1.8.9, but I'm also fairly savvy when it comes to these sorts of things.

If you make the changes I mentioned in https://groups.io/g/BITX20/message/75189, or if you can load the hex attached to the initial message in this thread https://groups.io/g/BITX20/message/75140 (using AVRDUDE or Xloader, for instance), then you should be able to try it yourself.


Reed

Re: Knob "Momentum" #ubitx #v6

Reed N
 

Hi Mark,

Thanks for the comments.

You're right to be concerned about array sizes and initialization. Using brace notation, any omitted values are assumed to be zero (see https://en.cppreference.com/w/c/language/array_initialization ), and since the array is of a known size in this context, the sizeof will return the full size of the array, not the size of the pointer (see https://www.geeksforgeeks.org/using-sizof-operator-with-array-paratmeters/). Thus, the code as written should be doing the correct thing in it's current state, however it wouldn't be too hard to mess it up by accident if somebody didn't understand the subtle differences between arr[3], arr[], and arr*. The fact that you were worried about these things at all suggests you've been bitten by them before, and have learned from it, which is a good thing :)

With respect to the lack of documentation, per https://groups.io/g/BITX20/message/75173, I spent a LOT of time trying a LOT of different strategies before settling on what is in the branch now. I'm not sure that I have it totally nailed (still hoping that Bert will provide additional feedback), so I'm a bit hesitant to write up a lot of documentation on it into the code right now, but just to give you a feel for why I didn't spend the time of documenting up front, here's a list of some of the other strategies I tried:
  • Thresholded accelerations that acted as a step-wise P term
  • Thresholded accelerations that acted as a piecewise-linear P term
  • Thresholded accelerations that acted as a step-wise I term, with several different types of per-function-call zero-tending corrections
  • Linear accelerations acting as an I term, with a number of different values for a basic IIR filter, with several different types of per-function-call zero-tending corrections
  • Thresholded accelerations that acted as a step-wise P term, with 10Hz timer interrupt reduction
  • Linear accelerations acting as an I term, with 10Hz timer interrupt
  • Thresholded acclerations that acted as a step-wise I term, with 10Hz and 5Hz timer interrupt
  • Nonlinear acceleration that acted as an I term, with 5Hz timer interrupt
As you can see, there's quite a lot of variation on both the what and how of the various techniques! However, I can give you a description of what's going on in the current rendition:
  • Every 200ms (that is, at 5Hz), the timer interrupt fires, and stores the total number of counts on the knob since the last interrupt. An interrupt is used so that it doesn't matter what the main loop is doing, and will work in all menus, tuning situations, etc. 5Hz was chosen to balance responsiveness against resolution. For instance, 1000Hz interrupts would likely only register at most 1 count, so we could only expect values of 0 or 1, which doesn't give much information about how fast the dial was being turned. However, selecting 1Hz interrupts would take a full second to notice that the dial was being turned more quickly (or slowly) than before, and would take a full second before they stopped accelerating, leading to significant overshoot.
  • The last 3 interrupt measurements are stored, which allows the code to not only observe the last 200ms speed, but also the previous 2 periods before that, giving a total window of 600ms. This gives a little more context to the numbers: are we seeing wildly changing knob speeds, or are they fairly constant?
  • We then look at the minimum number of counts across these three measurements, with the idea that if the dial was briefly bumped, we don't want to jump too far, but if the dial is consistently high, then the user probably is actually trying to move quickly. We use the absolute value (aka magnitude) so that everything works regardless of turn direction, and it nicely affords the ability to reverse tuning direction at speed without losing the acceleration.
  • Finally, there's the nonlinear mapping of this minimum count value. For small numbers of counts, we don't want to accelerate, because the user is probably trying to fine-tune. For large numbers, we set a maximum speedup so that a VERY fast knob turner won't end up in no-man's land by accident. For medium numbers, we scale nonlinearly, with more acceleration the faster the knob is turned, so that there's a large range of accelerations possible, despite a somewhat small linear input space.

For my own testing, I would load up the trial code, then try to tune from one point to another and back (1.000MHz -> 7.028MHz -> 1.000MHz, if anybody is curious), and (subjectively) evaluated how easy I felt it was to accurately tune to those exact frequencies, and how "fast" it felt to tune that distance. The main adjustment points for the currently implemented acceleration are the interrupt frequency, depth of the history, and the thresholds for "large", "medium", and "small" numbers of counts (which may require changes to the nonlinear function for the medium acceleration for mathematical reasons).

AAAAND if you made it this far into that text wall, congrats, and thanks for reading :P



Reed

Re: Knob "Momentum" #ubitx #v6

MVS Sarma
 

I use ver 1.8.5  and my experience is newer version including 1.8.9 are posing issues for me. 
Let me admit that i am kust a user , but not into coding etc

Sarma vu3zmv


On Thu, 23 Jan 2020, 11:16 am Reed N, <greenkid336600+groupsio@...> wrote:
Hi Ashhar,

I have Arduino IDE 1.8.9 installed at home and the code compiles there no problem, but didn't even think to consider that the code might not compile in older versions of the IDE.


Reed

Re: Knob "Momentum" #ubitx #v6

Reed N
 

Hi Ashhar,

I have Arduino IDE 1.8.9 installed at home and the code compiles there no problem, but didn't even think to consider that the code might not compile in older versions of the IDE.


Reed

Re: : Thank you!

Gary Anderson
 

On Wed, Jan 22, 2020 at 07:23 AM, Ashhar Farhan wrote:
Jack,
the new code is a single ino file and the others are cpp file. the compilation is a breeze, now!

-- f
Politely and concisely stated. While the subtly is probably missed by most, it is not missed by all.
Well done Sir.

Re: Made Mods to V3 uBitx - no longer transmitting #ubitx-help #v3

Curt
 

Funny thing, mine is on the bench after different spurious mods with the opposite problem. I can easily remove my 45 MHz added filter mod to see what I did.

Make sure there is no issue with relay orientation,  if misorientation is even possible, or more likely a poor or missing solder connection on a relay pin.  do check more than one band to see if its a particular relay.

Did you try both cw and ssb transmit to see if both are broken?

I presume you mean replacing L5 and L7 toroids with smt inductors. Look visually to insure one doesn't have a solder or other short across it. Yes hard to confirm.

Yes these times require patience.

I know nothing on that pot solution,  yes always best to only introduce one change at a time.

73 curt

Re: bitx 40

Smitty, KR6ZY
 

And by “some drift,” he means A LOT of drift. I basically have to constantly tweak the tuning knob. 

I like your idea of a frequency counter on the VFO. Even if it’s an analog VFO, at least knowing how it’s moving all over the place would be good. :-)

-Mark

On Jan 22, 2020, at 5:17 PM, Wayne Leake <wayneleake@...> wrote:


 I have 2 BITX40's, one was from just before the Raduinos came out.
 It uses just a simple analog VFO, that uses a Varactor Diode for the spread tuning.
 Also, I have a bare board BITX40 board that will be a BITX20 when done. It too uses a Varactor Diode for the spread tuning, though I plan on using an Arduino with an Si5152 (?) Board as a digitally tuned VFO instead of the analog VFO.
 It has the provision for a digital readout also.
 The second BITX40 came with a Toroid coil and cap that can be installed.
 But I like to know just where I am going to TX..
 You do need a very voltage stable power supply for an Analog VFO, and be prepared for some drift.
Wayne WA2YNE

On Wed, Jan 22, 2020, 3:07 PM Jim WB2LHP in MI <jmarco1955@...> wrote:
I believe on the V3 board you can add L4 and C93 then connect the tuning pot to the TUNING1 connector...C93 sets the range and the tuning pot sets the spread...

On Wed, Jan 22, 2020 at 3:51 PM dave <dgclifford@...> wrote:
hi does anyone know if the  bitx 40 can be run without a digital display if so how   many thanks   dave c  GW0NVF

Re: Knob "Momentum" #ubitx #v6

Smitty, KR6ZY
 

i think I figured out what your code is doing. I request a bit of documentation around the minimum magnitude stuff. It’s not immediately obvious why you want the minimum value over the last 600ms. Thinking about it, it makes sense, but it’s not immediately obvious. 

Otherwise, aside from some coding style differences and the what-i-think-are-bugs I posted earlier, it looks really good! Keeping track of encoder ticks over time and accelerating based on that is exactly what I was going to do, but I really like your method of using the timer to count, and the history for some better control. I can’t wait to load it up and try it out. 

-Mark

On Jan 22, 2020, at 5:29 PM, Smitty, KR6ZY <mark-groupsio@...> wrote:



Using sizeof(momentum) worries me. It’s unclear whether that returns the size of the pointer that “momentum” is, or whether it returns the size of the array the pointer points to. At runtime, I would expect it to return the size of the pointer. 

Instead, I’d suggest you 

#define MOMENTUM_ARRAY_SIZE (3)
int8_t momentum[MOMENTUM_ARRAY_SIZE] = {0, 0, 0};

Then use that when defining the array (as above) and in the for() loop on line 101. 

Also note that you only provided 1 element in your initialization of a 3 element array. It’s safest to provide all 3.

-Mark

On Jan 22, 2020, at 9:42 AM, Reed N <greenkid336600+groupsio@...> wrote:

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

Smitty, KR6ZY
 


Using sizeof(momentum) worries me. It’s unclear whether that returns the size of the pointer that “momentum” is, or whether it returns the size of the array the pointer points to. At runtime, I would expect it to return the size of the pointer. 

Instead, I’d suggest you 

#define MOMENTUM_ARRAY_SIZE (3)
int8_t momentum[MOMENTUM_ARRAY_SIZE] = {0, 0, 0};

Then use that when defining the array (as above) and in the for() loop on line 101. 

Also note that you only provided 1 element in your initialization of a 3 element array. It’s safest to provide all 3.

-Mark

On Jan 22, 2020, at 9:42 AM, Reed N <greenkid336600+groupsio@...> wrote:

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: bitx 40

Wayne Leake
 

 I have 2 BITX40's, one was from just before the Raduinos came out.
 It uses just a simple analog VFO, that uses a Varactor Diode for the spread tuning.
 Also, I have a bare board BITX40 board that will be a BITX20 when done. It too uses a Varactor Diode for the spread tuning, though I plan on using an Arduino with an Si5152 (?) Board as a digitally tuned VFO instead of the analog VFO.
 It has the provision for a digital readout also.
 The second BITX40 came with a Toroid coil and cap that can be installed.
 But I like to know just where I am going to TX..
 You do need a very voltage stable power supply for an Analog VFO, and be prepared for some drift.
Wayne WA2YNE

On Wed, Jan 22, 2020, 3:07 PM Jim WB2LHP in MI <jmarco1955@...> wrote:
I believe on the V3 board you can add L4 and C93 then connect the tuning pot to the TUNING1 connector...C93 sets the range and the tuning pot sets the spread...

On Wed, Jan 22, 2020 at 3:51 PM dave <dgclifford@...> wrote:
hi does anyone know if the  bitx 40 can be run without a digital display if so how   many thanks   dave c  GW0NVF

Re: bitx 40

Smitty, KR6ZY
 

Yep! I still have my very first BitX40 configured with the analog VFO. It’s drifty as all heck, but it’s still one of my favorite radios to use. 

I HIGHLY recommend getting a 10-Turn pot for the tuning knob. Tuning is not a Precise action on a 270 degree (aka 1 turn) pot. Any linear scale (if it doesn’t say “log” or “audio”, chances are it’s linear) 10-Turn 10k ohm pot will do. I got mine on eBay. 

Otherwise, it’s a lot of fun. No digital circuits at all!

-Mark

On Jan 22, 2020, at 1:07 PM, Jim WB2LHP in MI <jmarco1955@...> wrote:


I believe on the V3 board you can add L4 and C93 then connect the tuning pot to the TUNING1 connector...C93 sets the range and the tuning pot sets the spread...

On Wed, Jan 22, 2020 at 3:51 PM dave <dgclifford@...> wrote:
hi does anyone know if the  bitx 40 can be run without a digital display if so how   many thanks   dave c  GW0NVF

Made Mods to V3 uBitx - no longer transmitting #ubitx-help #v3

Steve - KE0VCD
 

I've completed 3 fixes/modifications to my uBitx v3.  These include:

Make your rig compliant by removing unwanted spurs  http://ubitx.net/spectral-purity/

Make your rig (mostly) compliant by removing unwanted harmonics (same link)

FIX: UNEVEN TX OUTPUT ACROSS BANDS Relay and potentiometer solution (Bill K9HZ  THE N6CNY VERSION)  http://ubitx.net/fix-fix-uneven-tx-output-across-bands/

After completing the mods, the rig is no longer transmitting.  I have tested the new board and believe it is working properly.  As far as I can tell, the new relay switches are working properly.  I've installed and reinstalled the L5 and L7 capacitors.  I've adjusted the new pots in several different ways.  Still nothing. 

Radiuno appears to be functioning properly.  

I fear I've messed up something else in the process. 

What advice can you give me on the best method to debug the board?  I have little experience in modifying and/or building electronics.  

Re: bitx 40

Jim WB2LHP in MI
 

I believe on the V3 board you can add L4 and C93 then connect the tuning pot to the TUNING1 connector...C93 sets the range and the tuning pot sets the spread...

On Wed, Jan 22, 2020 at 3:51 PM dave <dgclifford@...> wrote:
hi does anyone know if the  bitx 40 can be run without a digital display if so how   many thanks   dave c  GW0NVF

bitx 40

dave
 

hi does anyone know if the  bitx 40 can be run without a digital display if so how   many thanks   dave c  GW0NVF