Re: uBITX CW offset woes
Gordon Gibby
You are very gracious.
toggle quoted messageShow quoted text
I think the real issue is that my other rigs know if you are in CW mode or in single side band mode, and so they can’t offset the beat frequency oscillator appropriately The MicroBid X with Stock software does not know; if you push the mic button you are single side band if you push the key you are CW., and until you do that it doesn’t know. By merely adding a way for it to know which technique (SSB vs cw) you prefer this could be solved.
On Dec 14, 2019, at 09:34, Bill Cromwell <wrcromwell@...> wrote:
|
|
V Zecchinelli
Good Afternoon,
I don't know if this has already been discussed. I found one message with same issues but no answers. Could someone point me in the right direction? When I plug 3.5mm cable into PTT/Mic my V5 uBitx immediately goes into transmit. I tried stereo cable, mono cable and even just a bare plug with no cable attached. CAT works fine and so does audio but I can't get past the radio going into TX. Using Windows 10 on Acer PC, WSJTX V2.12. CEC V1.08. Thank you, Vince N1VIN
|
|
Re: Let's Minimize the Library problems.
Cory King
And sorry to double reply, “good ide support” I mean something other than Arduino IDE. VSCode or JetBrains CLion. Both have much better syntax highlighting, auto-completion, git integration and oh so much more.
|
|
Re: bitx v6 is here
Rick, We have one on order for testing and fitting of the AGC just to be sure it fits and works as it should. We will keep the group updated with our findings. 73 N8DAH
|
|
Re: Let's Minimize the Library problems.
Cory King
In my personal projects that use Arduino stuff (or in my case ESP32/8266) I have been using platform.io. In addition to really good IDE integration, it has a way to express library dependencies.
|
|
Re: Sidebands reversed after Memory Manager Used
Anthony Gomes
Bill, I had the same issue with SSB (LSB & USB getting inverted) with my scratch build. I don't like any software which does code changes magically, I like "Breaking the Magician's Code" maybe it just me. Don't get wrong the Memory Manager has it's own benefits, I would have taken a backup of the config before using the Memory Manager and doing any changes. I use the Memory manager to backup and restore my best tuned config and make another Arduino nano clone.
I think the best option will be to start with the CEC recommend factory reset and calibration process. 73 Anthony VU3JVX
|
|
Re: Frequency calibration V5
Cory King
“Replacement frequency source”.
|
|
Re: bitx v6 is here
Hans Summers
> Respectfully, the on-board decoder on the K3 works well. The decoder in the QCX CW transceiver http://qrp-labs.com/qcx works well too. Of course, nothing works as well as the human brain. CW Skimmer probably does better than embedded decoders because an awful lot of dedicated effort has gone into that function alone and because it has a lot of PC computing power available to it that is not available in an embedded processing system. 73 Hans G0UPL
|
|
Sidebands reversed after Memory Manager Used
Bill Meara
Thanks to all who offered advice on how to get my uBITX to display transmit frequency on CW. I went to Memory Manger and changed the settings. Unfortunately this seems to have seriously messed up my software. I cleared the EEPROM, and loaded CEC version 1.20. It looked good, but the sidebands were reversed -- I had to put 40 meters in USB to copy the sideband signals (which are on LSB). I even tried to go back to 1.071. But I have the same problem with the sidebands. It is as if the BFO is being placed in the wrong spots. Any suggestions on how to fix this? It is not a hardware problem -- I had it working fine until I tried to make changes with Memory Manager. Thanks 73 Bill N2CQR
|
|
Re: bitx v6 is here
Jerry: I agree that the type specifier should be a capital 'L': #define INIT_USB_FREQ (11059200L) and I use them, not for the compiler's benefit, as you're right that the compiler can figure that out. I do it as a form of documentation. Therefore, if I use the constant in a complex expression of mixed data types, the compiler uses the correct data type (e.g., a long, not a long long or an unsigned long) after the parse. (There are tools that let you see the source after the preprocessor pass and it can be helpful there.) Another change I would make on Farhan's new code is to change all of the *.INO files except ubitx_v6.3_code,ino (because it contains setup() and loop() in it) to *.cpp files. If you use a bunch of *.ino files, the compiler must gather all of the files into one "super" ino file before it can compile the code. If you have only one *.ino file, the compiler can perform incremental compiles. The time savings can be substantial. The JackAl code was 11,000+ lines of source code spread over 19 files. The first compile in the morning would take about a minute on a pretty fast machine. Then, since I tend to end up working on just one file most of the day, the compiler can see that the dirty flag is only set on the file I'm editing. Therefore, it only compiles that one file and let's the linker splice the other (previously-compiled) files into the executable. This can cut the compile time by 90%. For me, this could save a half hour each day of unnecessary thumb-twiddling. Making the change involves some work, since it usually means a header file with extern data declarations in it and the actual data defintions in INO file. I did this for Farhan on the V5 code, but he never released it. It probably would have just confused people. Still, if you plan on messing around with the code to any extent, using *.cpp files will end up saving you a lot of time in the long run. Jack, W8TEE
On Saturday, December 14, 2019, 2:34:59 PM EST, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:
Farhan wrote > If your board has 12 mhz, you have to just edit that one line to change the second IF. That would probably be this line in ubitx_v6.3_code.ino: #define INIT_USB_FREQ (11059200l) Older code has this line instead: #define INIT_USB_FREQ (11996500l) Note that the final character is a lower case L (for long integer), not a one. This has caused confusion in the past, would be better to change that letter to upper case, here and many instances elsewhere in the code. Better in my opinion is to remove the L entirely, the compiler is perfectly capable of figuring out how many bits are needed. I'm seeing two routines in ubitx_v6.3_code.ino, One is named setTXFilters(), this one gets used down in setFrequency() The other is named setTXFilters_v5(), has identical code in the function body, does not get used. I believe v5 and v6 have an identical configuration for the filter relays. However v3 and v4 uBitx hardware will want to replace setTXFilters() with the older version of that routine. Code for the ILI9341 display is in v6, the old v3,v4,v5 code using the LiquidCrystal library for the old 2x16 display has been removed. Would be nice if this was if-def'd so code could be compiled for either. So "you have to just edit that one line" applies to changing the IF frequency, but you have a fair bit more work to do if planning to use v6 code on v3,v4,v5. Jerry, KE7ER On Fri, Dec 13, 2019 at 06:58 PM, Ashhar Farhan wrote: We have left the old traces, connectors etc in exactly the same place. The software is backwards compatible with the previous versions. If your board has 12 mhz, you have to just edit that one line to change the second IF. -- Jack, W8TEE
|
|
Re: Which version of the XPT2046_Touchscreen library is used by the V6 ?
GM4CID
Farhan, thank you.
73, Bob GM4CID
|
|
Re: bitx v6 is here
Jerry Gaffke
Farhan wrote
toggle quoted messageShow quoted text
> If your board has 12 mhz, you have to just edit that one line to change the second IF. That would probably be this line in ubitx_v6.3_code.ino: #define INIT_USB_FREQ (11059200l) Older code has this line instead: #define INIT_USB_FREQ (11996500l) Note that the final character is a lower case L (for long integer), not a one. This has caused confusion in the past, would be better to change that letter to upper case, here and many instances elsewhere in the code. Better in my opinion is to remove the L entirely, the compiler is perfectly capable of figuring out how many bits are needed. I'm seeing two routines in ubitx_v6.3_code.ino, One is named setTXFilters(), this one gets used down in setFrequency() The other is named setTXFilters_v5(), has identical code in the function body, does not get used. I believe v5 and v6 have an identical configuration for the filter relays. However v3 and v4 uBitx hardware will want to replace setTXFilters() with the older version of that routine. Code for the ILI9341 display is in v6, the old v3,v4,v5 code using the LiquidCrystal library for the old 2x16 display has been removed. Would be nice if this was if-def'd so code could be compiled for either. So "you have to just edit that one line" applies to changing the IF frequency, but you have a fair bit more work to do if planning to use v6 code on v3,v4,v5. Jerry, KE7ER
On Fri, Dec 13, 2019 at 06:58 PM, Ashhar Farhan wrote: We have left the old traces, connectors etc in exactly the same place. The software is backwards compatible with the previous versions. If your board has 12 mhz, you have to just edit that one line to change the second IF.
|
|
Re: bitx v6 is here
SOTABeams has a nice (and small) DSP filter. There's also a really nice DSP package described in Microcontroller Projects for Amateur Radio that lets you define the filter parameters: Oh, never mind...that book's not out yet! :>) Jack, W8TEE
On Saturday, December 14, 2019, 12:02:58 PM EST, John AE5X <ae5x@...> wrote:
On Fri, Dec 13, 2019 at 03:41 PM, Dave Dixon wrote: just ordered my V6 looking forward to receiving it next year..Im hunting around for a variable cw filter..any ideas guys.,Dave G0AYDI'll probably be ordering one of these: https://qrpguys.com/qrpguys-active-600hz-audio-filter Here's another option if you want to spend more: https://www.sotabeams.co.uk/variable-bandwidth-filter-modules-ssb-cw/ John AE5X https://ae5x.blogspot.com/ -- Jack, W8TEE
|
|
Let's Minimize the Library problems.
This is a common problem for many homebrew projects. Frankly, I don't know which library to use either, so let's agree to try and make things simpler: I always use this format for any non-standard library, where non-standard means the library is not distributed as part of the Arduino IDE: #include <XPT2046_Touchscreen.h> // https://github.com/PaulStoffregen/XPT2046_Touchscreen The comment on the line gives the URL where the reader can go and download the library. This simple change would help people find the correct library to use. (I don't know which one is correct, I'm just using Paul's as an example of how to document it in the code.) Jack, W8TEE
On Saturday, December 14, 2019, 1:03:47 PM EST, GM4CID <gm4cid@...> wrote:
Hi, there seem to be several XPT2046_Touchscreen libraries on Github, wondering which one is correct to use ? 73, Bob GM4CID -- Jack, W8TEE
|
|
Re: Audio isolation w/ digital modes
#ubitx
Don - KM4UDX
The computer audio controls can easily adjust for moderate mismatches. Use the $7 sound card direct to the uBITX speaker and mic jack. Your computer's sound control, plus controls in wsjtx/Fldigi, will make all the adjustments.
I've used 1:1 isolation transformers with DC blocking caps. And also i've gone straight to the sound card. Both work. Simplicity suggests go direct to the USB sound card. Adjust levels in the PC/app. No complicated audio i/o interface is required. Don
|
|
Re: Frequency calibration V5
Jerry Gaffke
Apparently, V6 firmware can be used on earlier rigs, making a minor adjustment if you have a 12mhz IF.
Searching for "set_calibration" in ubitx_setup.ino for V6, it appears that this new code is using the algorithm of https://groups.io/g/BITX20/message/71281 Which is most welcome. The V6 code adjusts the si5351bx_vco in steps of 875 hz. All three si5351 outputs (and consequently the rig operating frequency) are locked into ratios of that 875mhz VCO. So if operating at 10mhz, the operating frequency is 875mhz/87.5=10mhz, and the calibration granularity is 875hz/87.5 = 10hz. And if operating at 30mhz, then the calibration granularity is 30hz, given the 875hz step size of the code in ubitx_setup.ino. A step size of 875 should be fine for most, but there is nothing special about it. You could change the value of 875 in ubitx_setup.ino to anything you want, and recompile. Larger step sizes will make calibration proceed faster, smaller step sizes will allow you to set the frequency more accurately. Though to be very accurate, you will need to monitor the audio with a scope, and hope any DC blocking caps in the audio chain will pass low enough frequencies. (I haven't looked too hard at the code yet, I assume he is moving the BFO into the center of the IF filter passband so you can hear a proper zero beat at very low audio frequencies.) Calibrate using a signal source at the highest frequency for which it is convenient. Calibrating to WWV at 10mhz will be 10 times more accurate than calibrating to an AM broadcast station at 1mhz. Most AM shortwave broadcasting stations have a carrier within a hz or two of a 5khz increment. If unsure how accurate that station is then verify by checking calibration against a different station. This procedure was outlined in post 35235 over 2 years ago, when the uBitx was first announced. Rather distressing to see all the posts in the forum from folks spending days trying to figure out how to calibrate. Jerry, KE7ER
|
|
Re: bitx v6 is here
Laurence Oberman
@David W9PH
toggle quoted messageShow quoted text
If you want to add simple morse decoder without building it https://www.amazon.com/Doradus-Reader-Decoder-Translator-Essential/dp/B01D2UEGFO 73 KB1HKO
On Sat, Dec 14, 2019 at 1:21 PM Ashhar Farhan <farhanbox@...> wrote:
|
|
Re: Which version of the XPT2046_Touchscreen library is used by the V6 ?
Ashhar Farhan
Lemme check. It will take me 24 hours as I am out of town right now
On Sat 14 Dec, 2019, 11:33 PM GM4CID, <gm4cid@...> wrote: Hi, there seem to be several XPT2046_Touchscreen libraries on Github, wondering which one is correct to use ?
|
|
Re: bitx v6 is here
Ashhar Farhan
Aah, i havent tried that out. I did try the kx3 cw reader though. Just getting it to read was voodoo. The user interface was erratic, the way settings worked was opaque and the tuning indicator was inaccurate. Maybe I didn't get a proper hang of the thing. - f
On Sat 14 Dec, 2019, 11:14 PM Eric Thielking, <ewthielking@...> wrote:
|
|
Which version of the XPT2046_Touchscreen library is used by the V6 ?
GM4CID
Hi, there seem to be several XPT2046_Touchscreen libraries on Github, wondering which one is correct to use ?
73, Bob GM4CID
|
|