Date   
Re: bitx40 v3 cw mods

Don, ND6T
 

Dave,

Not anything good. For one, it drifts like nobody's business. For another, about the only way to make it transmit CW is to put a tone into the transmit audio instead of the microphone. That results in a bunch of nasties being transmitted. Suppressed carrier remains, the suppressed sideband tone, and several intermod spurs within the passband. Sure, they are down 20 dB or so but folks nearby won't be pleased. You could always use just the receiver and a separate transmitter. Or you could build another, separate VFO in there, mute the original transmitted signal back near the balanced mixer, and use the new VFO signal as a source. But why? Easier to spend ten quid and digitize it, in my opinion. For what that's worth.
73,
Don

Re: bitx40 v3 cw mods

Jim WB2LHP in MI
 

Also, the CW Carrier (KEY) signal would have to go to +5 volts and the PTT (TX) signal to ground...

On Thu, Jan 23, 2020 at 11:21 AM dave <dgclifford@...> wrote:
starting from the bottom here my bitx 40 does not have a digital dislay and at the minute i do not want one i would hoever like to get it onto cw  any ideas most welcome  dave c gw0nvf

Re: bitx40 v3 cw mods

Jim WB2LHP in MI
 

Download Allard's v1.29 firmware for the BitX40...In the body of the .ZIP file there are schematics and descriptions for his CW mods...That will give you an idea of what is involved for CW operation...You could do it with a manual T/R switching arrangement without the Raduino or other controller but you would have to determine how best to implement it...Mods I think you would have to implement are Manual PTT (TX) and CW Carrier (KEY) ...You would have to come up with your own sidetone arrangement unless you have an external keyer that provides it...All in all it shouldn't be that difficult...Jim WB2LHP

On Thu, Jan 23, 2020 at 11:21 AM dave <dgclifford@...> wrote:
starting from the bottom here my bitx 40 does not have a digital dislay and at the minute i do not want one i would hoever like to get it onto cw  any ideas most welcome  dave c gw0nvf

bitx40 v3 cw mods

dave
 

starting from the bottom here my bitx 40 does not have a digital dislay and at the minute i do not want one i would hoever like to get it onto cw  any ideas most welcome  dave c gw0nvf

Re: bitx 40

Wayne Leake
 

 Actually, it's not my idea, at least regarding the boards from amateuradiokits.in (amateurradiokits,in).
 it is built into the board, and they sell/sold a separate frequency counter.
 and one can be used with Farhans V3 BITX40 boards.
 I forget the nitty gritty of connecting it though.
 I did connect the analog VFO version to a power supply to listen, and it seemed to go all over the place.
 I attribute that to the wall wart I tried being non regulated.
 Some are regulated, some are not.
 Using a single turn pot makes tuning very very touchy.
 I do recommend getting a ten turn version. Preferably with a vernier turns counter.
 Even is best, IMO, for use with the Raduino as it comes.
 Wayne WA2YNE

Re: bitx40 v3 cw mods

Don, ND6T
 

Dave,
This works for me: http://www.nd6t.com/bitx/CW . You might check out the other mods on the site, also. I mostly work CW and this makes a pretty good rig for that. I also recommend a good audio filter for those times when QRM gets annoying. I (sort of) copied the HiPerMite (http://www.4sqrp.com/hipermite) design with an LM324 that I had but the kit is cheap and very nice.
73,
Don

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

Dennis Zabawa
 

As a guideline for future mods, do one at a time and thoroughly test each before doing the next.  This minimizes the number of points to check for errors.  As for now, review the steps of each mode until you find the problem.

bitx40 v3 cw mods

dave
 

right i have the bit40 v3   working on ssb (not as much drift as i was led to expect) i would love to convert this to a cw rig what s  the best way to modify this set  just for cw  many thanks  dave c  GW0NVF

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