Topics

The SAGA is COMPLETE!

Daniel Flanagan
 

Hello All,

I want to thank everyone who helped me figure out how to update my uBITX V5,

I practiced it on a spare Arduino Nano that I purchased... and this
morning successfully uploaded KD8CEC's V1.2 firmware to my radio.

However, this did not happen smoothly (Murphy's Law). My first few
attempts failed, but I discovered that the baud rate needed to be
57600 instead of 115200 that I was using on the spare Nano.

Thanks to all...

73 Dan (W3DF)

Dean Souleles
 

Dan,

That is awesome! Now, before you make any other changes go make some contacts!

73,
Dean
KK4DAS

Daniel Flanagan
 

Thanks Dean,

The only change I made was to add an external push button in place of
the encoder switch. I couldn't push the encoder switch without
changing the setting I was trying to adjust. No other changes are
planned. I got the radio to operate QRP, not continuously tinker with
it and upgrade it.

I made a contact which HB9DCL on 20M shortly after I uploaded the new
firmware. I also worked VP2MSS. The rig works CW much nicer with
this firmware. With the delay set to zero, the first dit is not
truncated like the stock firmware did and the TX to RX delay time is
much easier to adjust. The stock firmware timing was way off.

The only issue I have with the rig is that there is no speaker audio.
I traced a dead short back to the speaker connector next to the encode
connector on the front panel PCB. All of the 1/8" plugs on the front
panel work OK, I get plenty of audio out of the phone jack, so I just
plug a speaker in there instead.

Regards,
Dan (W3DF)

On 2/14/20, Dean Souleles <dsouleles@...> wrote:
Dan,

That is awesome! Now, before you make any other changes go make some
contacts!

73,
Dean
KK4DAS



Dean Souleles
 

Dan -

Fantastic! Glad you are on the air. I'm with you - I love being able to experiment - but primarily want to use the rig for QRP and it has been fun!  I assume by the mention of the front panel PCB you have the Amateurradiokits.in case.  That is the one I have and I had a similar problem with the PCB- but the short was in the mic in input. I think there may have been a problem with a run of those PCBs.  Sunil was good enough to send me a replacement PCB - but for the speaker it should be fairly straightforward to wire around it.  I have an AGC mod sitting on the bench but haven't gotten around to installing it.  That's probably the only additional thing I will do for now.

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.)

I really enjoy getting on the air with the uBitX - I'm in Northern Virginia, near Washington DC.  Last week had good SSB phone QSO with the El Salvador Dxpedition, Portugal, Nicaragua, Canada and Italy.   Using WSPR and heard and been heard in Antarctica, South Africa and New Zealand. It was my first kit of any kind - and it got me over the hump of building things.  I'm working on a completely homebrew 40 meter transceiver now.

73,
Dean - KK4DAS

Daniel Flanagan
 

Hi Dean,

Yes, I bought the Amateurradiokits case for my uBITX.

I did a simple test with the uBITX V5 stock firmware on CW a while
back. I assumed that when I changed the CW tone that the frequency
would shift by the amount that I changed it. I like the tone around
500 Hz, but I did not detect any change in the transmit frequency
after I made the change. Now that I think about that.... once while
listening to a LSB SSB signal I changed to the upper sideband to see
how good the rejection was but I still heard a normal LSB SSB signal.
I then discovered that I had to change the vfo frequency (just one
tick) before the change took affect. This is probably what was
happening on CW also.... this was with the stock V5 firmware. I'll
have to check the V1.2 firmware.

I found a manual online for KD8CEC's V1.072 firmware, hoping that I
would learn about the firmware's features in detail, but it was not
very detailed and sections of the manual were incomplete. I am hoping
to find a manual for KD8CEC V1.2 firmware.

73, Dan (W3DF)

On 2/15/20, Dean Souleles <dsouleles@...> wrote:
Dan -

Fantastic! Glad you are on the air. I'm with you - I love being able to
experiment - but primarily want to use the rig for QRP and it has been fun!
I assume by the mention of the front panel PCB you have the
Amateurradiokits.in case.  That is the one I have and I had a similar
problem with the PCB- but the short was in the mic in input. I think there
may have been a problem with a run of those PCBs.  Sunil was good enough to
send me a replacement PCB - but for the speaker it should be fairly
straightforward to wire around it.  I have an AGC mod sitting on the bench
but haven't gotten around to installing it.  That's probably the only
additional thing I will do for now.

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.)

I really enjoy getting on the air with the uBitX - I'm in Northern Virginia,
near Washington DC.  Last week had good SSB phone QSO with the El Salvador
Dxpedition, Portugal, Nicaragua, Canada and Italy.   Using WSPR and heard
and been heard in Antarctica, South Africa and New Zealand. It was my first
kit of any kind - and it got me over the hump of building things.  I'm
working on a completely homebrew 40 meter transceiver now.

73,
Dean - KK4DAS



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


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

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


--

…_. _._

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

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

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

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
 

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

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
 

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

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







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

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

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



Martin Potter
 

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