Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- BITX20
- Messages
Search
|
Re: [Bitx-20] special session at hamfests to teach the neophytes re latest firmware
¿ªÔÆÌåÓýYou gentlemen seem to have such a great time discussing all of these changes and ?what should/could be a standard load from the start. ?I have been studying my Arduino starter kit and one of Jacks books but still have a long way to go. Possibly next year at FDIM and at Hamcation, Hamvention and even Ozarkon one or two of you could put on a seminar about this issue and maybe even help some of us upgrade our rigs (both of them) in a special session. ?We would bring our radios, laptops if necessary, etc., and go step by step installing the latest code and then have an explanation on how to make it work. ?I would even pay a fee for such a class. ?It could be like in my past medical conferences where it was early in the morning before the rest of the session started or during the afternoon when the rest are out seeing the sights. ?These sessions were called "special interest groups". I just need to see someone do it the first time (load in new code) with a step by step explanation and then the light might go on. Is something like this possible? Dave K8WPE,_._,_
|
|
Re: Core for Output Transformer
That the BN43-302 core is getting warm is no surprised? ?Its not enough for more than 10w
based on other amps I've made.? Two end to end or the 6802 (over an inch long) have worked? much better at the 20W and higher level.? The turns radio and what wire used can have a big difference at the higher end of the range.? Thin wire will heat significantly from the RF current.?? If the core is getting warm at low frequencies it may not be the core but the lack of enough inductance.? that is hard to fight as more turns may be moving further away from optimum at 30mhz.? The solution is a bigger core, two is series making it longer may be enough? or the 6802 core. Its also possible to use two fb43-4852 (amidon) .200id, .375OD, 1" tall.? Two of those run to 100W as a side by side pair using tube and strap construction.?? The 3312, I've run that to 65W in the WA2EBY amp during testing and it didn't get warm. Its a big core.? I did have heating issue with the wire.? The 3 turn winding was revised to 7 strands of #30 kynar wire (used for wire wrap) in parallel and that also brought the 10M power up. I still think the 2n3904s are the bottle neck for bandwidth and the mods are just trying to push them higher. Watching the input current to output power is a good thing to do as then you see the efficiency of the? amp and less than 40% bears inspection and higher 45-55% is definitely better. Allison |
|
Re: MAX9812
I can't speak for on air. I just put an SSM2167 red board and a "2V-9V MAX9812 with Mic element" on the myDAQ oscilloscope. Fed them 5V from a 4 AA holder.
Max9812 had 40mV of noise on the scope channel (laptop fan was running, might matter). Would ramp up to 250mV-400mV anytime I spoke from about a foot away. By comparison the stock SSM2167 (at work or I would give actual resistor values and settings) gave 400mV pretty constantly when I talked into an M138 (5mV output), M133 (5mV output), and a cheap dynamic mic (25mV-40mV) at 2 inches from my mouth Did not have time last night to dig out and set up the supplied Bitx electret mic element. Next time I'll measure the supplied mic and a cheap computer mic. I also need to make recordings to hear what they sound like. I believe all I need to do is hook the output of these boards into a potentiometer with a DC blocking cap on the wiper feeding the Bitx mic line. Then I can set the 400mV peak voltage down into the 35mV-40mV range the Bitx rigs are expecting. I expect with reduction of output that the effective noise out of the Bitx using the Max9812 will be negligible. I am doing all this measuring to see if that assumption is false based on what I hear. The ssm2167 seems easier to set with it's compressor being very constant around 400mV. |
|
Digital communications with a USB sound card - dumb mistake
#ubitx
Bo Barry
Whoops, a USB sound card gives you stereo sound output. Plugged into the mike connector for digital work it activates the PTT line with the audio!
The CAT interface works find for PTT and frequency control. It took me forever to realize the orange PTT wire needs to be disconnected for digital work. I made a bit of progress, getting a copyable RTTY signal with fldigi on my nearby rig. I couldn't get FT8 to copy. Experimenting with proper audio levels is driving me crazy but I'll figure it out. The receiver surprised me, with me copying PA & NY on FT8 WHILE CONNECTED TO A DUMMY LOAD. I hope my transmitted signals didn't get out too. I happened to have a 5v fan that fit the 3d printed panels I bought. I used a 7805 to drop the voltage down. Kinda noisy, going to drop it down to 3 volts. or so. One awkwardness - the rig runs off of 12 volts which runs thru the power switch. However the usb interface activates the LCD whenever it is plugged in. How many times have I scratched my head with it when it wouldn't transmit even tho the display said it was, because the power switch was off. A solution would be to cut the +5v lead in a USB cable I guess. In the meantime, a simple CW QSO is in order. Bo W4GHV |
|
Re: Should we adopt the KD8CEC firmware?
Jack Purdum
Tim:
With the same amount of respect, I was not talking about coding style as in brace placement. I was referring to good standard C coding practices. In your example, if you want a TUNE feature and know that it needs a CW feature that has been turned off, it's your problem to make a non-standard change. The conditional compiles would state the impact: "If you turn this off, all CW features are turned off". Since your example assumes you don't want CW features, but you do want a TUNE feature, perhaps your solution is to figure out how to use the Tone library to send a constant note through the transmitter chain when the TUNE feature is needed. Perhaps you can bypass the CW demands with some alternative approach. But again, your demands are non-standard (not the conditional compile where CW is either ON/OFF), so the ball's in your court to solve. Where you state: ??? If they add my functionality what's the first thing they are going to see happen? It won't work. Who then gets to ????figure out why and then who gets to fix it? That answer's simple: You do. If you added your functionality and stated it will work without the CW features compiled into the code and it doesn't work, clearly there's a bug in your software. The key there is "...they added my functionality...". If that means they used your code and it fails, I think they rightly can expect you to tell them where they went wrong. If they modified your code, that now becomes their problem. Also, I think you're overstating the regression testing demands. True, they may be a bit wearisome, but they are not difficult. Again, if someone wants to modify the stock software, it's up to them to make the changes. Well-designed conditional compiles are either ON or OFF, even with multiple options only one option should be active and the end of the preprocessor pass. The user can always revert to the stock software if they can't get it to meet their special needs. My guess is that you will see the same evolution for the stock software that you saw here: Users will supply code for non-standard enhancements, like your TUNE feature. Jack, W8TEE
On Tuesday, May 15, 2018, 10:49:58 AM EDT, Tim Gorman <tgorman2@...> wrote:
Jack, Respectfully, you missed my point. I probably wasn't clear. I didn't mean a "coding" standard. I meant a standard software load with defined functionality. Trying to add functionality that others might want to use, in an environment of multiple conditional compiles, becomes a true nightmare of regression testing to insure the added functionality works with all combinations of the conditional compiles. Not doing such regression testing and throwing a software modification out into the wild means many users are going to find that their individual software load no longer works as intended if they try to use the software modification. For instance, your mention of deleting keyer code if you never use CW. If I develop functionality like a "Tune" option that requires the CW transmit module and some kind of a CW key to transmit a carrier, it won't work with someone that has deleted the keyer code using their conditional compile. If they add my functionality what's the first thing they are going to see happen? It won't work. Who then gets to figure out why and then who gets to fix it? tim ab0wr On Tue, 15 May 2018 13:25:23 +0000 (UTC) "Jack Purdum via Groups.Io" <jjpurdum=[email protected]> wrote: > I agree with Ron, here. Tim's statement: > >? ????It's important to have a *standard* to write to. > > would be nice, but as we all know, there is a difference between > coding style and functionality. Cut-and-paste code is also nice to > have, but any code may be useful if you can read and understand it. > To me, the litmus test of good code is code that can be read and > understood easily. When that's true, it becomes much easier to adapt > it to your needs. Simple things like using #define's instead of > "magic numbers" make it easier to read and adapt code. (If the IDE > had a symbolic debugger, I might use constants, although symbolic > constants are typeless and that can be a huge benefit in writing > reusable code.) Writing "clever" code is rarely a benefit. Which > would you rather read: > > ?? a = b >> 1; > > or > > ?? averageVoltage = baseVoltage / 2;?? // Voltage divider derives > average voltage that's applied to pin AVERAGEVOLTAGE > > Perhaps the only real reason the first version might make sense is to > cause some speed gain in the executed code, or perhaps save some > memory. Even that, however, often makes no sense because the Gnu > compiler is quite good at optimizations. Indeed, my guess is that the > two forms above generate exactly the same code. You can examine the > *.lst file to get a feel for the final answer. > > The final step before making it available to the public is to ask > yourself: What can I do to make it easier to read and understand this > code? If you cannot find changes that enhance readability, it's read > for prime time. Even then, readers will have difference preferences > on the way they would write the code...that's to be expected. > However, the fact they have preferences means they can read, > understand, and hopefully use the code. > > For reasons most can guess, I have not read Ian's code recently, but > I'm sure it's readable. The fact that Farhan has even suggested using > it as the standard means he's happy with it. If it's possible to > conditionally compile the code (e.g., why have a keyer if you know > you'll never use CW, leaving some room for additions you know you > want), it seems to me to be a moot question. > > And to those who argue: "But conditional compiles means the users > have to be able to change the code!" Yeah, so what? If you can't > change the code, you still have several options: 1) accept the radio > "as is", 2) learn enough programming to make the changes you want, or > 3) pay a programmer to implement the changes you want. Trying to get > a boo-hoo from me for people who don't want to invest a weekend in > learning how to make such changes is pretty much going to fall on a > deaf set of ears. Besides, this kind of programming is going to get > more important down the road, not less. May as well bite the bullet > and jump on board...you may even find you like it! > > Jack, W8TEE > > > >? ? On Monday, May 14, 2018, 11:53:47 PM EDT, W2CTX > <w2ctx@...> wrote: > > Tim > > > > > > ?? When I write software I don't have reuse as part of my mindset.? I > try to make something work that is > > > broken or develop something new that does not exist.? Once it is > tested it is given to the community to > > > use. > > > > > > ?So if I don't care if others use my code how does that advance the > radio?? Well one case comes to mind in that > > > my keyer code had iambic A/B working correctly.? After I published > the firmware I believe Ian looked at it.? Now > > > he could not cut-n-paste my code into his firmware because he used > different timing and different hardware pins. > > > As he stated in his description of his keyer routine, he looked at my > logic and? adapted my code into his. > > > And as all good programmers do gave me acknowledgement in his header > of his keyer module. > > > > > > So you don't have to create code that can be cut-n-paste to be > useful. > > > > > > rOn > > > On May 14, 2018 at 10:32 PM Tim Gorman 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" 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. > > Groups.io Links: > > You receive all messages sent to this group. > > View/Reply Online (#49147): /g/BITX20/message/49147 > View All Messages In Topic (64): > /g/BITX20/topic/19183012 Mute This Topic: > /mt/19183012/141851 New Topic: > /g/BITX20/post -=-=- > The original BITX > BITX40 by HFSignals > uBITX by HFSignals > BITX Store by Sunil > BITX Web Site of Mike ZL1AXG > /g/BITX20/wiki/home Wiki > -=-=- > Change Your Subscription: /g/BITX20/editsub/141851 > Group Home: /g/BITX20 > Contact Group Owner: BITX20+[email protected] > Terms of Service: /static/tos > Unsubscribe: /g/BITX20/leave/defanged<hr > style="height: 0; border: 0; border-top: 1px solid #aaa; margin: 8px > 0;"> |
|
Re: Should we adopt the KD8CEC firmware?
Vince Vielhaber
You, like Tim, are looking at it from an experimenter's point of view as an experimenter's platform. Not everyone who purchases one is an experimenter or plan to use it as an experimenter's platform. The idea of standardizing on the CEC firmware will (IMO) appeal to the greatest number of hams. That's the goal, attract as much interest as possible.
toggle quoted message
Show quoted text
As atouk said earlier, "uBITX should be targeted at new hams, not new coders. New hams already have enough to be confused about." I don't know if you've been paying attention to the general population of hams these days, a great number of them aren't the slightest bit technical and having a radio that they can plug their computer in to for $109 plus a bit of connecting wires would be rather attractive to them. Vince. On 05/15/2018 03:25 PM, Laurence Oberman wrote:
Or the other way around --
Michigan VHF Corp. |
|
Re: Should we adopt the KD8CEC firmware?
Gordon Gibby
toggle quoted message
Show quoted text
|
|
Re: Should we adopt the KD8CEC firmware?
Jerry,
Oh noes, Boeing or Lockweed...? It would cost millions and likely not work till block 3. From what I've tested on my brassboard the stock firmware is functional.? But to throw rocks at it, no, its a fine piece of work as delivered. It may not be my cup of tea, but that is the nature of Bitx,? make mods till it suits me.? ?That we can change it to suit and improve it is something special.? None of the big names (exception I know of Tentec Rebel and Patriot, maybe SDR)? expose their internal firmware.? That is an important feature.? That it is reasonably priced and approachable is unusual beyond any i've seen. The fact that there is a connector to separate the two and allow one or the other to change is remarkable.? They make a effective system and yet allow for growth unlike any out there. We can argue what is best, we should and we will anyway.? ;-) But in the end its an available option for all that participate, I have strong feelings about that availability.? It is the single thing in amateur radio that separates it from every other radio service.?? Allison/KB1GMX |
|
Re: Core for Output Transformer
Here is my experience:
I went back to IRF510s and used a BN43-3312 as the single 302 was getting warm on the low frequencies and I could not put more than 2/3 turns in the core. I tried both 1/2T and 2/4T in the 3312 and settled on the last one due to better efficiency. The 1/2T was drawing too much current at 80M. Plenty of gain and power at 14MHz and below on 16.8V for the PA (4S lithium battery) but have to resort to gain control for flattening the power curve despite 330pF caps in all 6 drivers emitter resistors, 22uH inductor in base feedback of pre-driver, 330 pF across primary of finals transformer and 820ohms finals feedback resistors. I haven't tried some of Ashhar's other mods yet. 73, John (VK2ETA) |
|
Re: Should we adopt the KD8CEC firmware?
Laurence Oberman
Should have read
toggle quoted message
Show quoted text
"and a note about KD8CEC possibilities" On Tue, May 15, 2018 at 3:25 PM, Laurence Oberman <oberman.l@...> wrote:
Or the other way around |
|
Re: Should we adopt the KD8CEC firmware?
Laurence Oberman
Or the other way around
toggle quoted message
Show quoted text
Nobody is stuck with stock firmware, update to the KD8CEC firmware if you choose :) I would be fine with the units coming with latest stock firmware and a not about KD8CEC possibilities. Just my 2c Laurence KB1HKO On Tue, May 15, 2018 at 12:38 PM, Vince Vielhaber <vev@...> wrote:
Simple solution. Download the original firmware, modify it and load it onto |
|
uBitx
toggle quoted message
Show quoted text
|
|
Re: Should we adopt the KD8CEC firmware?
Hello Tim,
We have to look at this from different perspectives: 1. From Ashar's perspective, it is important to provide a unit that is attractive to the whole range of users from appliance users to experimenters, and the current software does, in my opinion, fall short in some areas: functionally as you said it needs upgrading and from a kit builder's perspective I believe it should have more basic built-in diagnostics. 2. From the new experimenter's perspective I am convinced that it would be much easier if I wanted to add say an SWR function to change a one line define statement and connect the described hardware that having to get into the intricacies of even the current factory software to implement the code. How do I know this? Because I had to go through it, and I would have been very happy to start from a base with existing code rather than start from scratch. 3. For the more savvy experimenter the beauty of the conditional compile is that by following the ifdef enclosed blocks I can immediately get to the core of the code in question and can if I so desire modify it. From that point, by the way, I consider that the responsibility form fixing any software problem is 100% mine. I break it, I fix it, simple. I can get help, but the responsibility is mine. As far a regression testing it has to be taken in context: a] the rate of release is not like in a daily software release so how often do they expect to have to perform it, probably once only and b] It is not mission critical and c] There is help at hand here.? Now as to a comparison with a commercial rig I don't think that is the point since my FT-817 does *not* have a built-in tuner, a low battery alarm, a digital VOX or the option to plug a handsfree ear piece as a microphone to name a few. It does have a lot of other features I don't care about and that are clogging the user interface from my perspective.? One of the thrills of kit building is the possibility to customize it as per your own needs. 73, John (VK2ETA) |
|
Re: Should we adopt the KD8CEC firmware?
Maybe this thread has wandered a bit off topic.? Instead of the merits of a basic firmware versus a feature rich one as the stock firmware shipped with the units, it seems to have turned into a pissing contest on software methods and practices.
Individual and experienced developers are more than free to develop outside the stock offerings, and share, or not share as they see fit.? The question is what would be best for inexperienced or new hams as a starting point. uBITX should be targeted at new hams, not new coders.? New hams already have enough to be confused about. |
|
Re: Should we adopt the KD8CEC firmware?
Perhaps you could send this out for bid with Boeing and/or Lockheed.? ?;-)
toggle quoted message
Show quoted text
Demanding regression testing of various convenience factors for us to hack the stock firmware of a $109 radio seems a bit over the top.? All I ask is that the stock firmware be usable. On Tue, May 15, 2018 at 10:54 am, Tim Gorman wrote:
In complicated software like Ian's regression testing is a requirement. |
David Wilcox K8WPE
atouk
to navigate to use esc to dismiss