Date   
Re: The SAGA is COMPLETE!

Dean Souleles
 

Dan -

I was surprised that there was a separate BFO calibration  and did much as you did, but yes it means there is a separate BFO calibration for SSB and CW and I am not exactly sure why.   

When I checked with uBitx Manager, the CW BFO calibration had been set 0  and then reviewing the code - when the CEC firmware starts up it see the 0 and sets the CW BFO to a hard coded default value that was about 40 KHz off of where my SSB VFO was so I made them the same - then adjusted to the CW BFO until I got a clean 700 Hz tone while keying another rig transmitting to a dummy load nearby.  I didn't have a scope at the time so I measured the CW tone with an audio analyzer app on my phone.

Dean
KK4DAS

Re: AGC Installation

KE2GKB
 

Hey Richard,
Off hand I do not know of a chemical to strip the solder mask. However a sharp knife used to scrape at the solder mask not slice definitely works well and safely.
Based on what you are doing it sounds like you are installing a kit-projects AGC, if you are please read all the instructions to ensure that you cut and scrape the traces appropriately. We have hundreds of boards sold and many reports of happy customers who were shocked with how easy the task was. Even if it was initially seemingly scary to scrape at the solder mask!
If its not the above i feel still applies read the instructions and scraping is definitely safer then you think! Copper on the fiberglass is way more flexible/forgiving then you may realize
Tim 'KE2GKB' Keller


On Sat, Feb 15, 2020 at 9:32 PM Richard Spohn <wb2gxm@...> wrote:
Ready to install AGC into a v5 which requires removal of the green pcb coating over 4 traces. Anyone know of a chemical that can do this without damage to the traces? Would use a small q-tip - Rich WB2GXM

Sent from my MetroPCS 4G LTE Android device

------ Original message------
From: Daniel Flanagan
Date: Sat, Feb 15, 2020 4:48 PM
Cc:
Subject:Re: [BITX20] The SAGA is COMPLETE!

OK... I played around in the ARRL DX Contest today and made about 100
QSOs on 20M with the uBITX.

I've been looking through the menus.... and have one question so far.
There are two menu selections for adjusting the BFO.  One says adjust
BFO and the other says adjust   CW RX BFO which lets you pick CWU and
CWL.  CWU was way off.  I adjusted CWU  setting until i heard normal
sounding CW signals.  I then tried CWL and it sounded pretty much the
same with no adjustment needed. It was out of wack before I made the
CWU adjustment.

So... My question is...  What is the difference between these two BFO
adjustment menus? Is it just allowing one to have different BFO
settings for SSB and CW?  The manual does not say anything here.

Maybe I'll take a peek at the source code for any comments in this area.

73, Dan (W3DF)







On 2/15/20, Jack, W8TEE via Groups.Io  wrote:
>  Thanks, Dean!
> Jack, W8TEE
>
>     On Saturday, February 15, 2020, 3:25:14 PM EST, Dean Souleles
>  wrote:
>
>  We hijacked Dan's thread!  In any case Dan, I no of no better user
> documentation than what you already have.
>
> Jack that is good advice to all developers.  As a 40+ year software
> developer, CTO and technology executive (and a much more recent HAM) I can
> attest to a couple of things....
>
> 1. I am not nearly a good  an electrical engineer as I am a software
> engineer.
> 2. Many HAMs writing software for Arduinos and Raspberry Pi's etc, could
> benefit from a programming 101 course with an emphasis on the basics of
> structured programming (and simple things like using readable variable names
> and using functions)  Most Arduino programs I've tried to adopt are
> mercifully brief but man they can be a challenge to reverse engineer.  Since
> C and all the languages derived from it (nearly everything) are notoriously
> cryptic in their notation, it is even more important that developers learn
> to structure and document.
> 3. User guides  are pretty poor - even when written by pros.  And worse when
> written by engineers.  I just got the 400 page document for my Rigol scope -
> sure there are descriptions of every single menu item - but very few
> descriptions of what things actually do or why, when or how you should use
> them  or what their limits are.  And it is made worse when the software guys
> insist on user messages like "Function limit exceeded." with no other
> context.
> 4. Message board (like this one) and YouTube are your friend - but your
> mileage will vary a lot, and you should double check everything - we've all
> had the experience of seeing things online stated with certainty that I know
> to be false.
>
> 5. Hams who want to learn to program well should read (and learn) from
> "Beginning C for Arduino" by a fellow named Jack Purdham.
>
> Cheers and 73,
>
> Dean
> KK4DAS
>
>
>
>
>
> 
>
>




--
Tim Keller - KE2GKB
https://shop.kit-projects.com

Re: Anybody want to sell V4 board?

Evan Hand
 

Mark,
You might have the wrong version numbers.

v4 corrected the "pop" and audio amp issues, there were no changes to the RF sections to address the later found spurs and harmonics issues.

The v3, v4, and  v5 boards, the v5 are the ones that are best for spectrum purity.  ARRL Labs reviewed and found them to be in compliance, though some on this forum did state that their measurements did not agree.

v6 is the current version.  This one has pretty much the same components as the v5, the difference is the change in the stock display, Raduino and main board layout.  There are also changes in the board layout that do away with any soldering, at least as far as a stock radio getting on the air.

I have not purchased the v6, as I already have a v5 with a 3.5" Nextion display, so not much reason to go to the v6 with the touch screen.  I also have 2 v4 boards with Nextion displays (bought the second to act as a backup and base for comparison of mods board).  Not much difference in performance between them, and each seems to operate about the same.  I would recommend the v5 board if available, as that version would not need the mods to correct signal purity issues.

FWIW and YMMV
73
Evan
AC9TU

Re: TSW's T4_V1.04 software BUG! #ubitx #v6

Jim Sheldon
 

A couple more bugs cropped up during user testing of the V1.041 fix and V1.042 has now replaced it on the www.w0eb.com website.  Hopefully, the can of RAID we sprayed on this one will have killed the nasties this time instead of just putting them to sleep.

Please discard 1.04, 1.041, download and start using TSW_T4_V1.042 .  We apologize again for the crazy problem(s) that inadvertently cropped up.

73 to all and again thanks for bearing with us and using our software (and hardware).

Jim, W0EB
TSW Project Coordinator

AGC Installation

Richard Spohn
 

Ready to install AGC into a v5 which requires removal of the green pcb coating over 4 traces. Anyone know of a chemical that can do this without damage to the traces? Would use a small q-tip - Rich WB2GXM

Sent from my MetroPCS 4G LTE Android device

------ Original message------
From: Daniel Flanagan
Date: Sat, Feb 15, 2020 4:48 PM
Cc:
Subject:Re: [BITX20] The SAGA is COMPLETE!

OK... I played around in the ARRL DX Contest today and made about 100
QSOs on 20M with the uBITX.

I've been looking through the menus.... and have one question so far.
There are two menu selections for adjusting the BFO.  One says adjust
BFO and the other says adjust   CW RX BFO which lets you pick CWU and
CWL.  CWU was way off.  I adjusted CWU  setting until i heard normal
sounding CW signals.  I then tried CWL and it sounded pretty much the
same with no adjustment needed. It was out of wack before I made the
CWU adjustment.

So... My question is...  What is the difference between these two BFO
adjustment menus? Is it just allowing one to have different BFO
settings for SSB and CW?  The manual does not say anything here.

Maybe I'll take a peek at the source code for any comments in this area.

73, Dan (W3DF)







On 2/15/20, Jack, W8TEE via Groups.Io  wrote:
>  Thanks, Dean!
> Jack, W8TEE
>
>     On Saturday, February 15, 2020, 3:25:14 PM EST, Dean Souleles
>  wrote:
>
>  We hijacked Dan's thread!  In any case Dan, I no of no better user
> documentation than what you already have.
>
> Jack that is good advice to all developers.  As a 40+ year software
> developer, CTO and technology executive (and a much more recent HAM) I can
> attest to a couple of things....
>
> 1. I am not nearly a good  an electrical engineer as I am a software
> engineer.
> 2. Many HAMs writing software for Arduinos and Raspberry Pi's etc, could
> benefit from a programming 101 course with an emphasis on the basics of
> structured programming (and simple things like using readable variable names
> and using functions)  Most Arduino programs I've tried to adopt are
> mercifully brief but man they can be a challenge to reverse engineer.  Since
> C and all the languages derived from it (nearly everything) are notoriously
> cryptic in their notation, it is even more important that developers learn
> to structure and document.
> 3. User guides  are pretty poor - even when written by pros.  And worse when
> written by engineers.  I just got the 400 page document for my Rigol scope -
> sure there are descriptions of every single menu item - but very few
> descriptions of what things actually do or why, when or how you should use
> them  or what their limits are.  And it is made worse when the software guys
> insist on user messages like "Function limit exceeded." with no other
> context.
> 4. Message board (like this one) and YouTube are your friend - but your
> mileage will vary a lot, and you should double check everything - we've all
> had the experience of seeing things online stated with certainty that I know
> to be false.
>
> 5. Hams who want to learn to program well should read (and learn) from
> "Beginning C for Arduino" by a fellow named Jack Purdham.
>
> Cheers and 73,
>
> Dean
> KK4DAS
>
>
>
>
>
> 
>
>



Anybody want to sell V4 board?

Mark Hatch
 

Finally looking to get my JackAL board online and don't need the additions of V5. Looking for a V4 so I don't have to deal with the spectrum purity issues of a V3.

I am located in California., so USA is probably best to avoid international shipping and hassle. Please reply direct via the "private" option.

73
Mark
AJ6CU

Re: The SAGA is COMPLETE!

Daniel Flanagan
 

OK... I played around in the ARRL DX Contest today and made about 100
QSOs on 20M with the uBITX.

I've been looking through the menus.... and have one question so far.
There are two menu selections for adjusting the BFO. One says adjust
BFO and the other says adjust CW RX BFO which lets you pick CWU and
CWL. CWU was way off. I adjusted CWU setting until i heard normal
sounding CW signals. I then tried CWL and it sounded pretty much the
same with no adjustment needed. It was out of wack before I made the
CWU adjustment.

So... My question is... What is the difference between these two BFO
adjustment menus? Is it just allowing one to have different BFO
settings for SSB and CW? The manual does not say anything here.

Maybe I'll take a peek at the source code for any comments in this area.

73, Dan (W3DF)

On 2/15/20, Jack, W8TEE via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
Thanks, Dean!
Jack, W8TEE

On Saturday, February 15, 2020, 3:25:14 PM EST, Dean Souleles
<dsouleles@...> wrote:

We hijacked Dan's thread!  In any case Dan, I no of no better user
documentation than what you already have.

Jack that is good advice to all developers.  As a 40+ year software
developer, CTO and technology executive (and a much more recent HAM) I can
attest to a couple of things....

1. I am not nearly a good  an electrical engineer as I am a software
engineer.
2. Many HAMs writing software for Arduinos and Raspberry Pi's etc, could
benefit from a programming 101 course with an emphasis on the basics of
structured programming (and simple things like using readable variable names
and using functions)  Most Arduino programs I've tried to adopt are
mercifully brief but man they can be a challenge to reverse engineer.  Since
C and all the languages derived from it (nearly everything) are notoriously
cryptic in their notation, it is even more important that developers learn
to structure and document.
3. User guides  are pretty poor - even when written by pros.  And worse when
written by engineers.  I just got the 400 page document for my Rigol scope -
sure there are descriptions of every single menu item - but very few
descriptions of what things actually do or why, when or how you should use
them  or what their limits are.  And it is made worse when the software guys
insist on user messages like "Function limit exceeded." with no other
context.
4. Message board (like this one) and YouTube are your friend - but your
mileage will vary a lot, and you should double check everything - we've all
had the experience of seeing things online stated with certainty that I know
to be false.

5. Hams who want to learn to program well should read (and learn) from
"Beginning C for Arduino" by a fellow named Jack Purdham.

Cheers and 73,

Dean
KK4DAS







Re: The SAGA is COMPLETE!

Jack, W8TEE
 

Thanks, Dean!

Jack, W8TEE

On Saturday, February 15, 2020, 3:25:14 PM EST, Dean Souleles <dsouleles@...> wrote:


We hijacked Dan's thread!  In any case Dan, I no of no better user documentation than what you already have.

Jack that is good advice to all developers.  As a 40+ year software developer, CTO and technology executive (and a much more recent HAM) I can attest to a couple of things.... 

1. I am not nearly a good  an electrical engineer as I am a software engineer. 
2. Many HAMs writing software for Arduinos and Raspberry Pi's etc, could benefit from a programming 101 course with an emphasis on the basics of structured programming (and simple things like using readable variable names and using functions)  Most Arduino programs I've tried to adopt are mercifully brief but man they can be a challenge to reverse engineer.  Since C and all the languages derived from it (nearly everything) are notoriously cryptic in their notation, it is even more important that developers learn to structure and document.
3. User guides  are pretty poor - even when written by pros.  And worse when written by engineers.  I just got the 400 page document for my Rigol scope - sure there are descriptions of every single menu item - but very few descriptions of what things actually do or why, when or how you should use them  or what their limits are.  And it is made worse when the software guys insist on user messages like "Function limit exceeded." with no other context.
4. Message board (like this one) and YouTube are your friend - but your mileage will vary a lot, and you should double check everything - we've all had the experience of seeing things online stated with certainty that I know to be false.

5. Hams who want to learn to program well should read (and learn) from "Beginning C for Arduino" by a fellow named Jack Purdham.

Cheers and 73,

Dean
KK4DAS




--
Jack, W8TEE

Re: The SAGA is COMPLETE!

Dean Souleles
 

We hijacked Dan's thread!  In any case Dan, I no of no better user documentation than what you already have.

Jack that is good advice to all developers.  As a 40+ year software developer, CTO and technology executive (and a much more recent HAM) I can attest to a couple of things.... 

1. I am not nearly a good  an electrical engineer as I am a software engineer. 
2. Many HAMs writing software for Arduinos and Raspberry Pi's etc, could benefit from a programming 101 course with an emphasis on the basics of structured programming (and simple things like using readable variable names and using functions)  Most Arduino programs I've tried to adopt are mercifully brief but man they can be a challenge to reverse engineer.  Since C and all the languages derived from it (nearly everything) are notoriously cryptic in their notation, it is even more important that developers learn to structure and document.
3. User guides  are pretty poor - even when written by pros.  And worse when written by engineers.  I just got the 400 page document for my Rigol scope - sure there are descriptions of every single menu item - but very few descriptions of what things actually do or why, when or how you should use them  or what their limits are.  And it is made worse when the software guys insist on user messages like "Function limit exceeded." with no other context.
4. Message board (like this one) and YouTube are your friend - but your mileage will vary a lot, and you should double check everything - we've all had the experience of seeing things online stated with certainty that I know to be false.

5. Hams who want to learn to program well should read (and learn) from "Beginning C for Arduino" by a fellow named Jack Purdham.

Cheers and 73,

Dean
KK4DAS



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

_Dave_ AD0B
 


K1 pin 5 should have 12v. when radio is on. K1 p3 should have 12v in receive. K1P1 should have 12v on transmit. I have had k1 die 2-3x.
Pin 8 k3 gets its power from k1p1.

If you are not getting voltage on k1p1 when in transmit your radio isnt turning on the transmitter. You may not get much out just by keying the mic switch. 

I am measuring the voltage from the indicated test point to the minus power connector.

I would assume that you would test your radios output into a dummy load. I have a 50 ohm 5-10w resistor hooked to an antenna connector.


On Sat, Feb 15, 2020 at 11:08 AM, Steve - KE0VCD wrote:
K3 pins 8&9 0v and 20mV

 

Re: The SAGA is COMPLETE!

Jack, W8TEE
 

Reed:

There's two kind of documentation, and I think you're confusing the two.

1. There is the documentation that goes along in the source code. That includes not only comments, but the style used. You can write an if-else with those two keywords or you can write it using a ternary operator. To me, the if-else better documents what you're doing simply because its easier to read. If you look at the assembly code for the two types of expressions using an optimizing compiler, the generated code is the same, so there's no real cost to using the more-easily read form. Given that about 80% of the development time is spent testing/debugging, anything you can do to make the code easier to read and understand is going to pay off.

I also try to use a consistent style, like function header:

/*****
   Purpose: This function is used to.....

   Argument list:
        char *msg        the message to be sent
        int count           the length of the message

    Return value:
        int                    the final message length

    CAUTION:    none
*****/
int MyFunction(char *msg, int count)
{
   // function body
}

Using a fixed style like this, you can write a filter looking for " /***** " and copy everything up through the function signature to a file, print it out, and you have an up-to-date DOC file of all the functions you wrote for the app. You can use the __FILE__ and __LINE__ macros to even pinpoint where the function resides. In this case, the function header style "documents" the code at the function level. If you're writing Open Source code, you need to do this kind of documentation. If not, then you document so you (or your team) can read it.

2. The second type of documentation is the user's manual. Most programmers are not real good at this, probably for the reasons you mentioned. Large software houses rarely use programmers to write user documentation. There are exceptions (e.g., Hans), but they are rare.

Finally, time is less important to me now since I'm not writing commercial software, but programmers fighting the market face a different set of parameters.

Jack, W8TEE

On Saturday, February 15, 2020, 1:18:23 PM EST, Reed N <greenkid336600+groupsio@...> wrote:


I'm not sure I agree with this. I don't mind documenting, and I don't think many developers mind it either. However, we also have finite time, and given the choice between documenting existing code and fixing or writing new code, the latter wins. It's a lot of work to document a changing code base, so development speed is drastically reduced if the programmer has to formally document every change as it happens. Doubly so if they discover an issue with their change and have to undo or re-change it.


Reed

--
Jack, W8TEE

Re: Reed's latest uBITX software on CW

Reed N
 

Hi Jim,

Thanks for the confirmation! I've PM'd you the details of the icon to make it easy to "steal" :)


Reed

Re: The SAGA is COMPLETE!

Reed N
 

I'm not sure I agree with this. I don't mind documenting, and I don't think many developers mind it either. However, we also have finite time, and given the choice between documenting existing code and fixing or writing new code, the latter wins. It's a lot of work to document a changing code base, so development speed is drastically reduced if the programmer has to formally document every change as it happens. Doubly so if they discover an issue with their change and have to undo or re-change it.


Reed

Re: uBITX Ver. 5 Completion Report

Phil Karn
 

On 2/15/20 08:55, Ora Smith wrote:

Calibration: The calibration instructions mystified me, so I ended up
tuning the carrier frequency to 10 MHz on my Flex, which is pretty
accurate.  BFO adjustment was far off initially. I found that it also
affected carrier suppression. Tuning the BFO by the "sounds good"
technique resulting initially in only 25 db of suppression. QST
reported 49 db suppression, so I suppose I could tweak some more, but
at 35 db it's OK, about what I see with my S-line. Opposite sideband
suppression looks very good on the Flex scope - I can't see anything. 
Spectral purity (carrier spectrum) is not as good as expensive
commercial rigs, but I have had no complaints on the air.
In my case it would help if I had an *exact* description of how the
various generated clocks change with control adjustments (USB/LSB/CW,
tuning knob, calibration, BFO, etc). I know this depends on the firmware
running on the Arduino.

I don't see any carrier suppression adjustments on my v6, just a
balanced modulator that in theory (but not practice) should remove it
entirely. So I suspect the actual carrier suppression depends on where
you park the carrier relative to the crystal filter passband. That's why
it changes with the BFO frequency setting. Better suppression involves
moving the carrier farther away from the crystal passband, which means
cutting off the low frequency response.

This is where I'm really spoiled by SDRs and their razor-sharp filters.
A 'next generation bitx' really ought to go digital here. The crystal
filter, BFO and balanced modulator/product detector would move into
software.

(Has anybody noticed just how *good* SSB can sound when generated and
received by an SDR with 100 Hz cutoffs instead of 300 Hz, and with good
frequency references?)

The lack of AGC on the receiver is bothersome. I have to ride the
volume control constantly when there is QSB or a roundtable with
greatly varying signal strengths.
Yeah, but I'm actually surprised at how usable it is without one.

I do get the impression that there's at least one opinion per ham on how
an AGC *should* work, so by omitting an AGC altogether Ashhar cleverly
avoided that argument. :-)

73, Phil

Re: The SAGA is COMPLETE!

Jack, W8TEE
 

I'm kinda different because I really do enjoy writing--even documentation--very much.

Jack, W8TEE

On Saturday, February 15, 2020, 12:40:44 PM EST, MadRadioModder <madradiomodder@...> wrote:


Documentation never seemed to be a problem for you…

 

 

From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of Jack, W8TEE via Groups.Io
Sent: Saturday, February 15, 2020 8:54 AM
To: BITX20@groups.io
Subject: Re: [BITX20] The SAGA is COMPLETE!

 

As a rule, most programmers don't like to write documentation.

 

Jack, W8TEE

 

On Saturday, February 15, 2020, 9:48:49 AM EST, Dean Souleles <dsouleles@...> wrote:

 

 

Hi Dan - 

To my knowledge Dr. Lee never wrote a manual for the firmware.  I believe the document you have is the most complete document that there is.  The rest of the info I have found in various blog posts on Dr. Lee's KD8CEC blog - http://www.hamskey.com/ and right here on the forum.   He hasn't posted in a while but in the past he has been responded to questions.   I learned about the CW offset from the posts on here and then on his blog.  I've also poked around in the firmware source a bit.

73,
Dean
KK4DAS


--
Jack, W8TEE


--

…_. _._

--
Jack, W8TEE

Re: The SAGA is COMPLETE!

Jack, W8TEE
 

Yeah, I've run into a few of those, too. Still, I've never seen a new user of a piece of software load up its source code, read it, and then start using the app.

Jack, W8TEE

On Saturday, February 15, 2020, 12:58:05 PM EST, Phil Karn <karn@...> wrote:


On 2/15/20 06:53, Jack, W8TEE via Groups.Io wrote:
> As a rule, most programmers don't like to write documentation.
>
>
Actually, most programmers will say that their code IS the documentation.

(I've been guilty of this myself.)

Phil







--
Jack, W8TEE

Re: The SAGA is COMPLETE!

Phil Karn
 

On 2/15/20 06:53, Jack, W8TEE via Groups.Io wrote:
As a rule, most programmers don't like to write documentation.

Actually, most programmers will say that their code IS the documentation.

(I've been guilty of this myself.)

Phil

Re: The SAGA is COMPLETE!

MadRadioModder
 

Documentation never seemed to be a problem for you…

 

 

From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of Jack, W8TEE via Groups.Io
Sent: Saturday, February 15, 2020 8:54 AM
To: BITX20@groups.io
Subject: Re: [BITX20] The SAGA is COMPLETE!

 

As a rule, most programmers don't like to write documentation.

 

Jack, W8TEE

 

On Saturday, February 15, 2020, 9:48:49 AM EST, Dean Souleles <dsouleles@...> wrote:

 

 

Hi Dan - 

To my knowledge Dr. Lee never wrote a manual for the firmware.  I believe the document you have is the most complete document that there is.  The rest of the info I have found in various blog posts on Dr. Lee's KD8CEC blog - http://www.hamskey.com/ and right here on the forum.   He hasn't posted in a while but in the past he has been responded to questions.   I learned about the CW offset from the posts on here and then on his blog.  I've also poked around in the firmware source a bit.

73,
Dean
KK4DAS


--
Jack, W8TEE


--

…_. _._

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

Steve - KE0VCD
 

20mV to antenna jack when keyed-up

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

Steve - KE0VCD
 

K3 pins 8&9 0v and 20mV