Re: uBITX40 : power to IRF510
Yes. Spend? a little time at the ubitx.net site.
Jack, W8TEE
On Monday, May 14, 2018, 12:32:47 PM EDT, Toni Cossio <a.cossio@...> wrote:
I have already built your BITX40 which I am using with great satisfaction.
I have just received your "Micro BITX40".
I ask you if I can feed the two IRF510s separately with a higher voltage to get a higher output power as expected in the project of the previous BITX40.
Thanks for your kind response.
?73 de IV3XHM, Toni Cossio
?
|
Re: 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.
Jack, W8TEE
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
functions in the code?
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
have to do?
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
see.
tim ab0wr
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.
>
> Jack, W8TEE
>
>
>? ? 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:
>
>? ?
>
> 1.?????? CAT
>
> 2.?????? WSPR
>
> 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.
>
>? ?
>
> Just a thought¡
>
>? ?
>
>? ?
>
> 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!
>
>? ?
>
>
|
uBITX40 : power to IRF510
I have already built your BITX40 which I am using with great satisfaction.
I have just received your "Micro BITX40".
I ask you if I can feed the two IRF510s separately with a higher voltage to get a higher output power as expected in the project of the previous BITX40.
Thanks for your kind response.
?73 de IV3XHM, Toni Cossio
?
|
Re: boosting the power on 28 MHz
#ubitx
Hi Allison
The?KSP10BU looks like a twin of the MPSH10.? It is available from DigiKey for $0.19, quantity of 1.
toggle quoted message
Show quoted text
On Sun, May 13, 2018 at 10:49 am, Henning Weddig wrote:
Allison,
concerning the bifilar balun choke to supply the DC voltage to the drains of the IRF510 is one big step forward in equalizing the gain!
I got a large improvement on the famous 20W G6ALU amp for my PIC A STAR after inserting this choke.?
I also agree that the ft of the 2N3904 for a high gain stage is not sufficient-- my LTSPICE simulations already show that the W7ZOI bidi amp in the receive chain drops by about 3 dB @45 MHz i.e. the first If.? So the MPSH10 or its SMD equivalent may be the better solution.
I just have ordered this transistor from a chinese supplier.
Henning Weddig
DK5LV
?
Am 13.05.2018 um 19:36 schrieb ajparent1/KB1GMX:
Seems like the variation between radios is significant.
For certain I nee to look at the power chain.? My breadboard is better behaved but there are a handful of significant
differences.? The first of which is that based on other radios I've built the 2n3904 is not adequate above 20mhz.? I've
used 2n2369 for the first two stages and 2n2222A for the driver.? I think the MPSH10 in the driver might help further
but I'm waiting for some..? Significantly different transformers for t10 and t11 and used? a bifilar balun at l8/l9.
That amp is standalone and for a given output power (enough for 10W at 80M) that same input power at 10M
gets me 6w, thats ok but I know it needs more work.? That was the point it was at about 2 years ago. I got side
tracked by other projects so now it the time to revisit.
Generally the firmware makes no difference unless you have moved the various oscillator frequencies out of range.
Allison
|
Re: Should we adopt the KD8CEC firmware?
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 functions in the code? 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 have to do? 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 see. tim ab0wr On Mon, 14 May 2018 14:18:46 +0000 (UTC) "Jack Purdum via Groups.Io" <jjpurdum@...> wrote: 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.
Jack, W8TEE
On Monday, May 14, 2018, 10:05:13 AM EDT, K9HZ
<bill@...> wrote:
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:
?
1.?????? CAT
2.?????? WSPR
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.
?
Just a thought¡
?
?
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!
?
|
We need a bit more information in order to help troubleshoot your uBITX.
?
?1)? Which opto-coupler on the schematic drawing are you referring to as being inoperative?
????? Is it the manufacturer provided mechanical rotary encoder that you say is not working?
?2)? What test equipment do you have available?
?3)? What troubleshooting steps have you already taken, and what were the results?
?4)? Which schematic (URL) are you using to troubleshoot your uBITX?
?5)? Is it just the VFO frequency adjustment that does not work, or are there other configuration
?????? and adjustment options that do not work properly?
?6)? Have any modifications been applied to your uBITX build?
Arv? K7HKL
_._
On Sun, May 13, 2018 at 8:32 PM, kj6etl <pa1zz@...> wrote: Today I completed the build of my uBitx.
Unfortunately the Opto coupler / VFO is unresponstive. No matter what I do it stuck at LSB A : 7150.00
I tried to push the the reset button on the small board behind the display to no avail.
On closer inspection of the manual I noticed a discrepency between the text and the picture. The text tells that the brown wire has to be connected to the Pin B of the opto coupler while the picture shows a purple wire.
Earlier in the manual it states that the purple wire from the Raduino board is redundant so I removed it...
Looking forward to your input!
|
Re: CONTEST!!!! New Board Naming Contest
#ubitx
Me-O-My-O I/O board.
Jack, W8TEE
On Monday, May 14, 2018, 11:54:51 AM EDT, Jim Sheldon <w0eb@...> wrote:
Regarding this contest, I forgot to mention -- you may enter as many times as you like (different name for each entry though).? In case the winning entry is duplicated by another person, the earliest date/time on the submitted entry will determine the winner.
Should NO entry be deemed suitable to name the board (we reserve the right to accept or reject any/all entries), the contest will be extended for another time period (to be decided if necessary) and that will be announced.? Remember, no entries submitted to this list or to any email address other than the one listed in the initial announcement ( jrg.qrv (at) gmail dot com ) will be eligible to win the prize.
Jim - W0EB
|
|
|
Re: BITX QSO Afternoon/Evening, Sunday, May 13, 3PM & 7PM Local Time, 7277 kHz in North America, 7177 kHz elsewhere.
|
Re: CONTEST!!!! New Board Naming Contest
#ubitx
Regarding this contest, I forgot to mention -- you may enter as many times as you like (different name for each entry though).? In case the winning entry is duplicated by another person, the earliest date/time on the submitted entry will determine the winner.
Should NO entry be deemed suitable to name the board (we reserve the right to accept or reject any/all entries), the contest will be extended for another time period (to be decided if necessary) and that will be announced.? Remember, no entries submitted to this list or to any email address other than the one listed in the initial announcement ( jrg.qrv (at) gmail dot com ) will be eligible to win the prize.
Jim - W0EB
|
Re: Should we adopt the KD8CEC firmware?
I think it's a great idea to see what we can squeeze out of the existing Raduino with it's Nano by using the KD8CEC code. No changes other than a HEX download for existing uBITX machines (if you keep the existing 2x16 display) and we're all (or most) "on the same page".?I just read through the 1.07 manual....I assume that's the latest one.
73 Kees K5BCQ
|
Re: Variable uBitx IF bandwidth question
As I've posted elsewhere, I built a K2 a few years back.? It has a variable bandwidth IF filter that looks kind of similar to the ladder filter in the uBitx.? Each node has a 100k pull-up resistor and variable capacitor diode (1sv149).? Voltage to the pull-up resistor can be varied under processor control.? I honestly don't know enough about filter design to have an opinion regarding how hard it would be to adapt the uBitx to add this feature.? One would think that instead of using an output pin from the processor, a variable resistor or selector switch with different series resistors might work.??
Rich - KE1EV
|
Re: Should we adopt the KD8CEC firmware?
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.
Jack, W8TEE
On Monday, May 14, 2018, 10:05:13 AM EDT, K9HZ <bill@...> wrote:
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: ? 1.?????? CAT 2.?????? WSPR 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. ? Just a thought¡ ? ? 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@... ? ?
From: [email protected] [mailto:[email protected]] On Behalf Of ajparent1/KB1GMX
Sent: Monday, May 14, 2018 8:53 AM
To: [email protected]
Subject: Re: [BITX20] Should we adopt the KD8CEC firmware? ? Having done a SD interface with Arduino I can say the SD library is huge.? The reason is
the typical SD is used with the FAT filesystem and it takes a bit of code to navigate that.
If one treats the SD as just a lot of addressable blocks then the code space needs
drop greatly but its not without some cost in program space and IO.? Either way its likely
too costly in program space for a few bytes of data.
Again myself I can't see that as being a big issue as there is 1024 bytes and cal settings
eat a small number of them.??The other issue is IO needed to do SD makes a SPI display?
desirable.
Some seem to feel added features are too much stuff.? Myself if the code is structured
well its easy enough to add or subtract things as desired.? My pet peve is Arduino
sketches run the gamut of styles and readability.
Myself I prefer a system with less menus ( how do I live with a FT817) and more buttons
dedicated to a set of operations.? I have to try it.?
Allison
|
Re: Should we adopt the KD8CEC firmware?
Allison is right, the SD library is bloated. Perhaps someone can put it on a diet like Jerry did for the Si5351 library. Another point to be made is that, in my experience, it's not the flash memory that constrains things, it's the SRAM. While there are things that can be done to reduce the strain on SRAM (e.g., the F() macro), knowing what's going on with SRAM at runtime is problematic. I've blown up sketches that show only a 72% utilization of SRAM. The reason is because SRAM holds the stack, a memory resource that ebbs and flows as the program executes. Obviously, I flowed a little too much during runtime. While Allison is also right that we could use some additional EEPROM space for some things, you probably don't want to stick things there that might need frequent or fast updates. I also understand the statement:
????????My pet peve is Arduino sketches run the gamut of styles and readability.
C is over 40 years old and its freestyle syntax is one of its benefits and part of the reason it's lasted this long. I think what you and I both really wish for is that everyone wrote their code with the same style I do. Not gonna happen... I would suggest, however, that anyone posting source code anywhere at least use Ctrl-T on the source while it's still in the IDE before posting. At least the formatting would be more consistent.
Jack, W8TEE
On Monday, May 14, 2018, 9:53:29 AM EDT, ajparent1/KB1GMX <kb1gmx@...> wrote:
Having done a SD interface with Arduino I can say the SD library is huge.? The reason is
the typical SD is used with the FAT filesystem and it takes a bit of code to navigate that.
If one treats the SD as just a lot of addressable blocks then the code space needs
drop greatly but its not without some cost in program space and IO.? Either way its likely
too costly in program space for a few bytes of data.
Again myself I can't see that as being a big issue as there is 1024 bytes and cal settings
eat a small number of them.??The other issue is IO needed to do SD makes a SPI display?
desirable.
Some seem to feel added features are too much stuff.? Myself if the code is structured
well its easy enough to add or subtract things as desired.? My pet peve is Arduino
sketches run the gamut of styles and readability.
Myself I prefer a system with less menus ( how do I live with a FT817) and more buttons
dedicated to a set of operations.? I have to try it.?
Allison
|
Re: Should we adopt the KD8CEC firmware?
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: ? 1.?????? CAT 2.?????? WSPR 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. ? Just a thought¡ ? ? 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 ajparent1/KB1GMX
Sent: Monday, May 14, 2018 8:53 AM
To: [email protected]
Subject: Re: [BITX20] Should we adopt the KD8CEC firmware? ? Having done a SD interface with Arduino I can say the SD library is huge.? The reason is
the typical SD is used with the FAT filesystem and it takes a bit of code to navigate that.
If one treats the SD as just a lot of addressable blocks then the code space needs
drop greatly but its not without some cost in program space and IO.? Either way its likely
too costly in program space for a few bytes of data.
Again myself I can't see that as being a big issue as there is 1024 bytes and cal settings
eat a small number of them.??The other issue is IO needed to do SD makes a SPI display?
desirable.
Some seem to feel added features are too much stuff.? Myself if the code is structured
well its easy enough to add or subtract things as desired.? My pet peve is Arduino
sketches run the gamut of styles and readability.
Myself I prefer a system with less menus ( how do I live with a FT817) and more buttons
dedicated to a set of operations.? I have to try it.?
Allison
|
Re: Should we adopt the KD8CEC firmware?
Having done a SD interface with Arduino I can say the SD library is huge.? The reason is
the typical SD is used with the FAT filesystem and it takes a bit of code to navigate that.
If one treats the SD as just a lot of addressable blocks then the code space needs
drop greatly but its not without some cost in program space and IO.? Either way its likely
too costly in program space for a few bytes of data.
Again myself I can't see that as being a big issue as there is 1024 bytes and cal settings
eat a small number of them.??The other issue is IO needed to do SD makes a SPI display?
desirable.
Some seem to feel added features are too much stuff.? Myself if the code is structured
well its easy enough to add or subtract things as desired.? My pet peve is Arduino
sketches run the gamut of styles and readability.
Myself I prefer a system with less menus ( how do I live with a FT817) and more buttons
dedicated to a set of operations.? I have to try it.?
Allison
|
Re: Should we adopt the KD8CEC firmware?
A quick suggestion: the idea "up the top of EEPROM" should be defined as a specific offset from the EEPROM base. My reasoning is because I expect different ?C's to come into play over time. This means different ?C's will have differing "tops" for EEPROM, ranging from 512 to 4K. For example, JackAl uses almost 100 bytes of Teensy EEPROM for variables that get read/set on power-up. Because the big thing about JackAl is experimentation, those 100 bytes are also maintained in a different 100 byte segment and never changed. These are used as a "factory reboot" if things go South for the experimenter and they want to reset everything. Originally, because we also use the same 32 bytes of symbolic constants in our own list, we simply redefined Farhan's offsets. However, because of the discussion here, I think we should preserve those 32 bytes even though it means duplicating them in our EEPROM. Therefore, it would be nice if Ian and/or Farhan could peg the base EEPROM address for the 32 bytes so people who like to muck about in the EEPROM aren't stomping in the wrong places.
Jack, W8TEE
On Monday, May 14, 2018, 9:33:39 AM EDT, W2CTX <w2ctx@...> wrote:
I do not see any issues with the EEPROM.? Everyone protects the first 32 bytes as "stock" delivered
from factory.? All calibration routines place new values there.? Maybe the factory should store a copy
of the delivered calibration up the top of EEPROM.? Each? developer's firmware uses the EEPROM as they
need it.? That is accepted.
rOn
On May 14, 2018 at 9:04 AM "Jerry Gaffke via Groups.Io" <jgaffke@...> wrote:
It will be easier to switch between different firmware if there's an easy way
to set different offsets to the EEPROM address region each flavor of firmware uses.?
For example, Farhan's stock firmware takes 32 bytes, starting at EEPROM address 0.
We could make it 32 bytes starting at EEPROM address 0x124 as follows:
#define EEPROM_OFFSET? 0x124
#define MASTER_CAL (EEPROM_OFFSET +?0)
#define LSB_CAL (EEPROM_OFFSET +?4)
#define USB_CAL (EEPROM_OFFSET +?8)
...
Firmware should give an easy way to initialize that EEPROM region to default values.?
There's a total of 1024 bytes of EEPROM available in the ATMega328P.
Jerry
|
That was amazing, Allard! I will be passing that on to some friends.
Thanks for sharing that with us!? N5KNG
|
Hi Tom,
Is it possible for you to provide a sketch of the circuit, so we can be sure to understand what you've done and get it right when we hook it up on the board?
If not, then perhaps a little more detail on the connections to the pot, RX and TX voltages, 4.7k voltage control resistors, and 510k bleeder resistor?
I think this would be a fantastic addition to the uBitx operation - thank you for posting!
|
Re: Should we adopt the KD8CEC firmware?
Dear Konstantinos,
We need about 4 months of lead time to change the circuitry, given the lead times for the PCBs, availability of the SMD pick and place, etc. Instead, we are looking at what we can achieve with the base hardware. It is a software that will be available to everybody who has a ubitx as 'cost-free' upgrade (that is, it won't need you to modify the radio in anyway).
- f
On Mon, May 14, 2018 at 10:38 AM, Konstantinos Konstas <constantine170@...> wrote: Ashhar,
I am fully in favor of Dr. Lee's software and developments.
When I first got uBitx and fired it up, I was fully disappointed with the poorness of its firmware.
Just to mention the stock Split operation. I am sure more fellow users will agree with me.
Frankly speaking, it is thanks to CEC software that I decided to keep uBITx and play with it.
Memory Manager is a very useful tool, especially if you come to things like the S-meter calibration or the recovery of factory calibration that has been added in version 1.075
I do share some of the concerns of the published responses about the size and perhaps the too many features, but I am convinced about Dr. Lee's ingenuity and I am sure he can come up with a good start up version that can be helpful to beginners and? feature upgradeable.
Also if I may suggest, please consider using an I2C LCD that leaves a certain number of ports free for further experimentation and use. The cost of a I2C adapter for the LCD is minimal and I am sure you can purchase the I2C ready LCD cheaper.? A 20 by 4? LCD would make uBITx more attractive marketing-wise.
Konstantinos, SV1ONW
|
kj6etl
Jim Sheldon
K9HZ