Topics

The SAGA is COMPLETE!

Dean Souleles
 

Hi Martin - 

Glad you got it working.  The user interface to uBITX manager is a bit confusing - despite the big box that says I2C Scanner these settings have nothing to do with I2C.   I scrolled by it about 10 times before I found the CW adjust settings.  That's why I sent the screenshot.  A picture is worth 1000 dih-dahs.

73,
Dean
KK4DAS

Martin Potter <ve3oat@...>
 

Hi, Dean,

Thank you for that definitive reply and the screen shot! A picture is certainly worth a thousand words.

Yes, I already had the latest KD8CEC firmware (v1.2) and his Manager (v1.11) for my v5 board. But you see, I have the stock 16x2 LCD and had always thought that the stock display was NOT an I2C device, so always ignored all the talk about I2C settings, etc. After seeing your screen shot, I thought dangerously that maybe I should try the I2C settings anyway. Well, you can guess the rest ...

My v5 uBITX now transmits, receives and displays the CW carrier frequency "properly", in both CW-U (my preference) and CW-L modes.

Thank you, thank you, thank you, Dean. And I am much wiser for the experience. Thanks for that too!

Very 73,
... Martin VE3OAT

Dean Souleles
 

Hi Martin  - 

The uBitx manager version is 1.11 - you have the latest.

The uBitX firmware is 1.2

All the links are on Ian lee's web site:

http://www.hamskey.com/2019/04/release-cec-firmware-v1200-for-ubitx.html

Here is what it should look like:




73,
Dean
KK4DAS

Martin Potter <ve3oat@...>
 

Hi, Dean,

Yes, I am aware of the need for settings specific to the actual crystal filters in each rig. I was wondering about the difference between the two settings that Dan used. (Thanks for the off-list reply, Dan.)

And I have read Vic WA4THR's comment carefully. But where can I download this "new" version of the Manager software?? I have v1.11 of KD2CEC's Manager and have a v5 uBITX. I think the new Manager version is 1.2 but I have not been able to find it to download. I assume you have it and know where to get it ...

Many thanks!
73,
... Martin VE3OAT

Dean Souleles
 

Martin -

The SSB and CW BFO settings are particular to your particular rig - if you are having problems receiving (Donald Duck  sounding SSB reception for example) you will need to calibrate the BFO, otherwise you don't need to do anything.

For you second question about the CEC firmware - already asked and answered in this thread.....

Here it is again...

For CW you should be aware that by default the CW transmit frequency is shifted from the displayed frequency by the frequency of the side tone,  so you may be transmitting 700-800Hz off the frequency displayed on user interface.  You can change that behaviour using CEC's UbitX Manager software.  The details are here: https://ubitx.net/2018/07/02/kd8cec-firmware-hint-cw-frequency-display/ -   here is the relevant part:
"
Update: Dr. Lee addressed this issue in the latest version of the software and Memory manager! If you select the boxes “Enabled Adjust CW Frequency” and “Shift Display Frequency on CWL, CWU Mode” and leave the “CW Freq Adjust Value” at zero (this adds to the CW offset or CW tone selected elsewhere), then the receiver will automatically shift up or down by the amount of the selected CW tone and appropriately for CWL and CWU such that the transmitter will be transmitting on the displayed frequency. " (from Vic WA4THR.)"

Cheers, have fun, 73 and good DX
Dean
KK4DAS

Martin Potter <ve3oat@...>
 

Dan W3DF wrote :
"Yes... the CEC V1.2 has separate settings for SSB and CW..."

Dan,
What settings are you using for SSB and CW?
And can you confirm that the rig is actually transmitting the CW carrier on the displayed (dial) frequency, or is the transmitted CW frequency offset by the sidetone value?
Thanks.
73,
... Martin VE3OAT

Daniel Flanagan
 

Curt/Dean,

Yes... the CEC V1.2 has separate settings for SSB and CW. I've
adjusted mine by ear.... to get good sounding SSB I set the BFO so
that the background hiss is a little higher pitched than the CW
setting. I like a cw note around 450-500 Hz so I set the CW BFO so
the background hiss is just above that frequency range. Your mileage
may vary.

I haven't used split yet but have played with the other CEC settings
like Memory Keyer... which I cannot get it to do anything.... I
assumed you could save a message there but without a manual that
describes it I haven't figured it out yet.

The CEC firmware doesn't seem to have the accelerated tuning to change
frequency rapidly but allows the tuning rate to vary between 10, 50,
100, 500 and 1000 Hz. Also, when you do Band Select, it toggles
between the ham bands.

I used the built-in keyer during the contest. It's weight setting,
which can't be changed as far is I know without getting into the
firmware, is a bit off to my taste., but certainly usable.

I am still playing with the rig and new firmware. I was surprised how
easy it was to make contacts in the contest. Worked 71 countries on
20M. The only multipliers heard that I missed was ZL. I didn't hear
VK but worked about 10 JAs on 20M. I was only on for a few hours
Saturday and Sunday.

73, Dan (W3DF)

On 2/18/20, Curt via Groups.Io <wb8yyy=yahoo.com@groups.io> wrote:
Dan/Dean

my best effort to sort this out --

1. stock firmware has just ONE bfo calibration to make, because CW and SSB
are the same 'mode selection.'  and its the same for LSB/USB because of the
unique spectral flip in the RF chain

2. CEC firmware (I am not there yet ...) perhaps has more BFO calibration -
because it has separate CW and SSB mode setting(?).  I need to ask Dan about
how split works in CEC - he didn't need that in the contest, but I sure 'had
fun' using split to work some of the same stations after the contest.

73 Curt
just a few miles south of Dan BTW



Curt
 

Dan/Dean

my best effort to sort this out --

1. stock firmware has just ONE bfo calibration to make, because CW and SSB are the same 'mode selection.'  and its the same for LSB/USB because of the unique spectral flip in the RF chain

2. CEC firmware (I am not there yet ...) perhaps has more BFO calibration - because it has separate CW and SSB mode setting(?).  I need to ask Dan about how split works in CEC - he didn't need that in the contest, but I sure 'had fun' using split to work some of the same stations after the contest. 

73 Curt
just a few miles south of Dan BTW

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

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







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

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



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

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

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

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

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

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


--

…_. _._

Jack, W8TEE
 

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

Dean Souleles
 

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