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
Search
bitx v6 is here
|
Hi
This is very exciting. I have been thinking a long time but have not purchased one because I was afraid that the soldering and wiring instructions would be confusing. There have been many posts by confused builders. This sounds great. Is there a morse code decoder built in or coming soon ? Your earlier post said " I have added a morse reader already. I shall finish integration to the user interface soon." Please let us know when that is incorporated. I am unlikely to upgrade the software-firmware once it is working and that would be a very nice feature. Great idea on the calibration with a known station signal for people without test equipment. Thank you very much for this great upgrade ! David W9PH |
|
By morse reader, I actually meant software that reads out the screen in morse code. I had fooled around with many morse decoders. Nothing really works on the bands. CW skimmer is the only thing that works under contest conditions. So, if you want a morse code decoder that really works well, can adapt to any radio and needs no special hardware, then, spend a month, 20 minutes a day and practice at 30 wpm.? - f On Sat 14 Dec, 2019, 9:56 PM splat1956, <dnrabin7@...> wrote: Hi |
|
Respectfully, the on-board decoder on the K3 works well.? On Sat, Dec 14, 2019 at 12:38 PM Ashhar Farhan <farhanbox@...> wrote:
|
|
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:
|
|
Laurence Oberman
@David W9PH
toggle quoted message
Show quoted text
If you want to add simple morse decoder without building it 73 KB1HKO On Sat, Dec 14, 2019 at 1:21 PM Ashhar Farhan <farhanbox@...> wrote:
|
|
Jack, W8TEE
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: Here's another option if you want to spend more: John AE5X -- Jack, W8TEE |
|
Farhan wrote
toggle quoted message
Show 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. |
|
Jack, W8TEE
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 |
|
> Respectfully, the on-board decoder on the K3 works well.? The decoder in the QCX CW transceiver 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 |
|
Ooh¡a thing that reads the screen in morse? That¡¯s half the battle toward eyes-free operation. The other half, of course, is some additional way to control besides the built-in touch screen interface, like a programmable keypad. Seems to me there were a couple of implementations of this floating around. Do please elaborate.
toggle quoted message
Show quoted text
Buddy Brannan, KB5ELV - Erie, PA Email: buddy@... Mobile: (814) 431-0962 On Dec 14, 2019, at 12:38 PM, Ashhar Farhan <farhanbox@...> wrote: |
|
Buddy, All the user interface is usable without needing touch. If you tap on the tuning knob for a second, you can move the focus from one button to the next and then click in the button to select again. Each button has text associated with it that can be read out. I have taken care to see to it that all features are accessible with and without touch. For?example, the ability to enter a new frequency using the touch pad is replicated in fast tune where if you hold down the button while on one of the vfos , you can now quickly move across the bands in 50 khz steps. Jack, The function names are confusing as well..many variables are declared and not used any more. There is a large amount of code that is commented out as well. I have to clean that up, refactor reassemble. I will hopefully do this after Christmas. The graphics library should really be called just a user interface library. The ILI9341 uses a SPI interface where it can fill a rectangle with a 16-bit colour. I used this to draw vertical lines, horizontal lines and pixels. No other graphical primitives have been used. The text characters are plotted pixel by pixel. The entire graphics routines are less than 100 lines. An often reused routine is the drawText routine that draws text centered inside a rectangle with a border. That makes all the buttons trivial. Almost all the user interface is just buttons, very much inspired by the jackal. While tuning, i observed that only one digit if the frequency read out changes most of the time. So, the displayVFO routines figures which digits need to be repainted and updates only those. This routine is probably what makes the interface usable with the 8 bit power of the Arduino Nano. - f On Sun 15 Dec, 2019, 5:43 AM Buddy Brannan, <buddy@...> wrote: Ooh¡a thing that reads the screen in morse? That¡¯s half the battle toward eyes-free operation. The other half, of course, is some additional way to control besides the built-in touch screen interface, like a programmable keypad. Seems to me there were a couple of implementations of this floating around. Do please elaborate. |
|
Oh wow¡thanks Farhan! That¡¯s pretty useful information to have. I think that putting keypad control together will be useful still, especially for direct frequency entry, but glad to hear that all functions can still be activated without the touch screen. With morse output, it really could be used eyes-free. Great news, and I¡¯ll pass it on.
toggle quoted message
Show quoted text
Vy 73, Buddy Brannan, KB5ELV - Erie, PA Email: buddy@... Mobile: (814) 431-0962 On Dec 14, 2019, at 9:44 PM, Ashhar Farhan <farhanbox@...> wrote: |
|
I managed to download the v6 code from github.com/afarhan a couple days ago.
toggle quoted message
Show quoted text
Today I no longer see the v6 code I assume it has been removed while a bug or two gets fixed, and a new version will be posted when it's ready. Jerry, KE7ER On Mon, Dec 16, 2019 at 01:40 AM, Matt 9V1MH / VK3AMH wrote: Hi Farhan |
N8DAH
Matt 9V1MH/VK2AMH/YF2AAH
Joel Caulkins/N6ALT
to navigate to use esc to dismiss