Re: ubitx raduino issue/AKA the radio doesn't receive
Here is a link to the info:
Hope this helps,
Marco - KG5PRT?
John, You will need to do the front end diode protection mod before you transmit near your bitx40 or you can blow the front end...? I will look for the info and will post it here.
Marco - KG5PRT?
On Mon, May 14, 2018, 10:01 PM John Knoper < knoperj@...> wrote: thank you, I'll try to track all that info down.??
|
Re: Should we adopt the KD8CEC firmware?
Tim... I think that's where we are today...with the base level, bare bones code shipped from the factory. An increasing number of people are gravitating to the CEC firmware and that gives you an idea of what is desirable in a base-level firmware for the radio. If you really want data on this issue, Arv can set up a poll...and we can vote to see which firmware is being used.
Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ
Owner - Operator
Big Signal Ranch ¨C K9ZC
Staunton, Illinois
Owner ¨C Operator
Villa Grand Piton ¨C J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com
Like us on Facebook!
Moderator ¨C North American QRO Group at Groups.IO.
email: bill@...
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] [mailto: [email protected]] On Behalf Of Tim Gorman Sent: Monday, May 14, 2018 4:42 PM To: [email protected]Subject: Re: [BITX20] Should we adopt the KD8CEC firmware? Think of it this way. I want to add a Tune item to the menu. The item will send a CW signal and monitor an i2c peripheral for reverse power indication while the CW key is held down. Do I duplicate the CW transmit functionality in my code in case someone wants to use my code to add the Tune functionality to their program? If I don't do that then it won't work for someone who doesn't operate CW and has deleted the CW function from the software. And the code gets bloated from two different menu items duplicating the same functionality for those that do operate CW. Or do I wind up having to maintain two versions, one for software that has CW functionality and one for software that doesn't? It's my opinion that we *need* a base load with a set of common functionality that experimenters can build on. The current software that Ashar provides seems to fit that bill. If someone wants to load other software then it is up to them to manage all the complexity. tim ab0wr On Mon, 14 May 2018 16:38:39 +0000 (UTC) "Jack Purdum via Groups.Io" <jjpurdum@...> wrote: I think it could be done without too much confusion by using
preprocessor directives. That way, you don't actually mess with the
code; you only change the symbolic constants you wish to affect. For
example, if you don't use CW or CAT, then
#define CWINTERFACE false // Set this to true if you
want to use CW #define CATINTERFACE false // Set this
to true if you wish to use a CAT interface
and so on. The burden of getting everything right then falls on the
programmer, not the user. The user would, however, be responsible for
their own code additions/deletions.
As to how much space this saves will depend upon the programs
kept/deleted and what you mean by "very much program space". For some
users, 50 bytes might be enough to add something they want at the cost
of deleting some existing feature. The answer to that's really a
try-it-and-see answer.
Jack, W8TEE
--- This email has been checked for viruses by AVG.
|
Re: ubitx raduino issue/AKA the radio doesn't receive
John, You will need to do the front end diode protection mod before you transmit near your bitx40 or you can blow the front end...? I will look for the info and will post it here.
Marco - KG5PRT?
On Mon, May 14, 2018, 10:01 PM John Knoper < knoperj@...> wrote: thank you, I'll try to track all that info down.??
|
Re: using the BITX on RTTY
Hello Tim,
At 45.45 baud and 170 Hz shift it would not be an issue to do it all by software to meet the frequency and timing accuracy requirements.
Writing the frequency for the next RTTY bit to be sent can be triggered by a single byte write over I2C in less than 1/10th of a milisecond as only the last register write activates the clock change.
The CW keyer function of KD8CEC's software could be re-cast for sending canned RTTY messages/beacons.
73, John (VK2ETA)
|
Re: ubitx raduino issue/AKA the radio doesn't receive
thank you, I'll try to track all that info down.??
|
Re: Should we adopt the KD8CEC firmware?
I hope at least this sort of thing gives Ian ideas on how to better structure the firmware for different types of operators.? I could see myself redefining the radio (changing conditional compile variables, recompiling and reloading the firmware) many different ways and times for various operations.? Example:? Field day.? Just CW QRP radio. ? ? Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ ? Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois ? Owner ¨C Operator Villa Grand Piton ¨C J68HZ Soufriere, St. Lucia W.I. Rent it: Like us on Facebook! ? Moderator ¨C North American QRO Group at Groups.IO. ? email:? bill@... ? ?
toggle quoted message
Show quoted text
From: [email protected] [mailto:[email protected]] On Behalf Of Jack Purdum via Groups.Io
Sent: Monday, May 14, 2018 11:39 AM
To: [email protected]
Subject: Re: [BITX20] Should we adopt the KD8CEC firmware?? I think it could be done without too much confusion by using preprocessor directives. That way, you don't actually mess with the code; you only change the symbolic constants you wish to affect. For example, if you don't use CW or CAT, then ? #define CWINTERFACE ? ??????? false??????? // Set this to true if you want to use CW #define CATINTERFACE????????? false??????? // Set this to true if you wish to use a CAT interface ? and so on. The burden of getting everything right then falls on the programmer, not the user. The user would, however, be responsible for their own code additions/deletions.
As to how much space this saves will depend upon the programs kept/deleted and what you mean by "very much program space". For some users, 50 bytes might be enough to add something they want at the cost of deleting some existing feature. The answer to that's really a try-it-and-see answer.
On Monday, May 14, 2018, 12:10:53 PM EDT, Tim Gorman <tgorman2@...> wrote: This is where problems will begin to occur. Are you going to add in functionality to modify ubitx_menu.ino on the fly? Or are you going to break up ubitx_menu.ino into a lot of little pieces that can be included/excluded at compile time? How do you tie including/excluding menu items to controlling the actual compile of If you just inhibit access to the alignment software after it is used it doesn't lower the amount of memory used for the program unless you do so with a recompile and reload. Is that really what we want the user to Does deleting a mode actually save very much program space? Most functions are common between modes, you still have to transition between receive and transmit, only some variables change value. Does doing all this actually make it harder for the experimenter to modify the code because it makes it more difficult to lay out all the interactions between the code that might be affected? I know it's hard enough for me already to trace through all the code when I want to change something. Making it more difficult is not what I would want to On Mon, 14 May 2018 14:18:46 +0000 (UTC) > This is a good idea and might make it easier to peel off those > features not desired. The source already lends itself to this > approach. I have not studied it closely enough to know whether > specific files (e.g., ubitx_keyer.ino, ubitx_cat.ino) can be taken > out of the compile chain as it currently stands. >? ? On Monday, May 14, 2018, 10:05:13 AM EDT, K9HZ > In fact, to expand on this¡ I think Ian should consider block defines > for sections of the code that people want or don¡¯t want.? He has > already done this in selecting the type of display (2 line or 4 > line).? Some of the things to block define might be: > 3.?????? Alignment ?(if you¡¯ve done it once, why do it again?) > 4.?????? CW? (some people only use SSB) > 5.?????? SSB? (some people only use CW). > I¡¯m sure there are others.? This way there is plenty of room if you > want to experiment.? Just shut stuff off.? In fact, there could be an > experiment define that turns on or shuts off your experiments too. > Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ > Big Signal Ranch ¨C K9ZC > Villa Grand Piton ¨C J68HZ > Soufriere, St. Lucia W.I.
|
Re: Should we adopt the KD8CEC firmware?
This sort of answers my concerns about documentation and software engineering practices...sigh... Brian K9WIS ---- Tim Gorman <tgorman2@...> wrote: ============= John, If I am writing a function that others might want to use, how do I know which analog input to look at for a trigger by the CW key? Does my function need to look at both A3 and A6 just in case? Or do I use one or the other and let the user worry about fiddling with my code to make it work? It's important to have a *standard* to write to. tim ab0wr On Mon, 14 May 2018 13:54:44 -0700 "John" <vk2eta@...> wrote: I disagree that the original software is a good starting point for
building on as its tuning and keying section need work.
I think the uBitx should be shipped with a software that best
promotes it's capabilities. That way the user can enjoy it fully
without having to go through an upgrade process that he may not be
willing to go through.
Making room for later software changes is easy if, as said above, the
software is segmented and shows the "memory cost" of each option.
As an example below is the start of the my ubitx_20.ino file, based
on Ian's 1.061 version.
It is easy to make room by commenting out options to insert one's own
code if desired, or simply enable "extra features".
//================== Compile options for adding/removing features and
saving memory =====================
//When there are no hardware modifications (i.e. wired as per the
HfSignals web-site) // If UNdefined, or commented OUT, assumes that
the CW key is connected to the PTT input (A3) to free-up A6 for //
the handsfree option here. (note that A6 could also be used for SWR
or supply voltage monitoring). No memory impact.
|
You should have more than three millivolts. There is about 5K of resistance between the TX voltage and the positive lead going to the microphone element. With no more current than an electret pulls you should be seeing several volts between the positive lead on the electret and the ground on the electret (which is usually the case). If the mic is unhooked you should be seeing full voltage on the connector, whatever you are feeding into the ubitx, probably somewhere between 11.5v and 14v. Three millivolts isn't enough to get much output from the electret mic. You need to check the voltage at the mainboard (use a piece of wire poked down into the second connector pin if necessary). If you don't see more voltage than 3mv there then measure at the junction of C60 and R60 to see what voltage you have. tim ab0wr On Mon, 14 May 2018 15:05:32 -0700 t.h.mills@... wrote: I get 3.0 mV to the connector with good continuity to the microphone.
|
Re: using the BITX on RTTY
A 45 baud FSK RTTY signal changes frequency each 22mS.? The shift for RTTY is 170Hz. From my limited experience (not consulting the datasheet) I expect the si5351 would handle this easily.? ?The trick would be getting the timing of the changes right.? ?A software timer such as the Arduino delay()? may not work as it is pretty inaccurate with small arguments.? ?A hardware timer that generates interrupts should do the trick.??It would be easy to try.?
73 Paul VK3HN.?
|
Re: ubitx raduino issue/AKA the radio doesn't receive
Ok thanks, then I would say your click generator is working fine, and most likely your receiver chain.
I would double check the calibration and more likely the BFO frequency.
There may be better methods, but I would reload the factory default sw, disconnect the PA power cable,? press and hold the push button at startup, do a factory calibration using your other Trx, then go in the setup menu and do a calibration and BFO frequency alignment as they return to defaults under that software.
Hope that helps,
73, John
|
Re: using the BITX on RTTY
Am I missing something? If you don't have a real RTTY machine why not use the free fldigi program like I do?
Bo W4GHV?
Missing my old Model 15 machine and CW rig with a varicap.
|
Re: Should we adopt the KD8CEC firmware?
John, If I am writing a function that others might want to use, how do I know which analog input to look at for a trigger by the CW key? Does my function need to look at both A3 and A6 just in case? Or do I use one or the other and let the user worry about fiddling with my code to make it work? It's important to have a *standard* to write to. tim ab0wr On Mon, 14 May 2018 13:54:44 -0700 "John" <vk2eta@...> wrote: I disagree that the original software is a good starting point for
building on as its tuning and keying section need work.
I think the uBitx should be shipped with a software that best
promotes it's capabilities. That way the user can enjoy it fully
without having to go through an upgrade process that he may not be
willing to go through.
Making room for later software changes is easy if, as said above, the
software is segmented and shows the "memory cost" of each option.
As an example below is the start of the my ubitx_20.ino file, based
on Ian's 1.061 version.
It is easy to make room by commenting out options to insert one's own
code if desired, or simply enable "extra features".
//================== Compile options for adding/removing features and
saving memory =====================
//When there are no hardware modifications (i.e. wired as per the
HfSignals web-site) // If UNdefined, or commented OUT, assumes that
the CW key is connected to the PTT input (A3) to free-up A6 for //
the handsfree option here. (note that A6 could also be used for SWR
or supply voltage monitoring). No memory impact.
|
Re: ubitx raduino issue/AKA the radio doesn't receive
raduino functions- those visible.? That is to say, tune up/down, menu select.? Receiver does not receive, static can be heard, some birdies can be heard, noise level goes down when antenna disconnected.
|
Re: ubitx raduino issue/AKA the radio doesn't receive
Sorry John, but when you say all functions work, you mean the display functions AND receiving or just display functions?
73, John
|
Re: using the BITX on RTTY
I noticed in one of the alternate versions of the uBITX software the WSPR mode was implemented by sending the frequency shifts to the SI5351 chip registers. Have not looked into if the SI5351 chip, and the related uBITX software, can reliably change the frequency at the rate needed for RTTY, but if so, adding a RTTY mode to the software could shift the frequency digitally using the CW key jack to make the mark/space frequency shifts.?
|
Re: ubitx raduino issue/AKA the radio doesn't receive
thanks for the info, John.? I'll take a look at what you've listed, but, as per usual, I left a couple of things out of my problem description that might help diagnose my issues.? I was able to load CEC 1.06 to the raduino, and it appears all functions work, so far as I've taken it.(no transmitting)? Does that add any applicable info?
Thanks
|
The microphone has a polarity I read. The lead connected to the case is ground.
|
Re: CONTEST!!!! New Board Naming Contest
#ubitx
You didn't read the instructions fully and your entry is disqualified. ?You are NOT to post your entry here but send it to the specified email address.
Sorry, W0EB
toggle quoted message
Show quoted text
On May 14, 2018, at 6:14 PM, Daniel Conklin < danconklin2@...> wrote: if/and/but/or/i/o
|
Re: ubitx raduino issue/AKA the radio doesn't receive
Awww maaaaaaaan-? Thanks Jerry- I'll see if my 735 will pick it up!? And it does!!? right smack dab at 11996.5
|
Re: ubitx raduino issue/AKA the radio doesn't receive
Jerry and I were replying at the same time. Do his test first.
73, John (VK2ETA)
|
K9HZ
VK3HN
Jim Sheldon