开云体育

Hello everyone, I realize I'm late to the topic, but after a course by the ARI Parma association on the uBITX V5, I wanted to try my hand at designing a single-sided PCB for the receiver part only using Kicad and TH components. I actually created two versions, the first educational, with well-spaced components and the second more compact and more suitable for being placed in a container. Both involve the use of Raduino and the low frequency part, separately. I also created the PCB for these two modules. I'll make them available in case anyone wants to create the RX part only and suggestions are welcome. Soon, I hope to be able to create the TX part too. Thank you and 73 de IU7SUX /g/BITX20/files/IU7SUX

I have a new sBitxV3 board only. Everything is working except the Mic input. I started experimenting with some microphone I had and the recorded transmission has lots of noise and very low audio. I measure 2.1v on mic input tip. I think it should be 5v. Can anyone guide me as to what the issue may be and where I should look. Here are my measurements/ calculations.

I've been using my sBitx v3 for one and a half months and am pretty happy with it. However, I noticed strange behavior. When I try to start QSO with a station that uses nonstandard callsign (e.g., longer than usual or prefixed or suffixed with something), its callsign is displayed as <...>. The same "<...>" is output to the log. This form seems to be used even in responses, so the recipient does not accept them, and the QSO gets broken. Up to now, I'm simply limiting my QSOs to the stations with standard callsigns. However, spring and summer approach, and I hope to use my site v3 in SOTA and POTA activities or use it during my holidays abroad. In those cases, my callsign will need to be suffixed (e.g., with "/P") or prefixed (e.g., with "OE/" when in ?sterreich). Is my sBitx v3 going to handle that situation properly, or I won't be able to make any QSO? How can I fix that issue? 73, Wojtek SP5DAA

I hate starting a new thread for this, however, I think it will be easier to contain Q&A, feedback, and update announcements in a single area.. History: When I first used my sBitx, I noticed it was missing some features that I was used to on my other transceivers, such as direct frequency entry, memory bank access, and remote rig control options for mode, bandwidth, AGC, etc. I quickly learned that the sBitx software doesn't fully support standard third-party, remote rig control applications. I searched for an existing app to add these features but found none available for the sBitx. This left me with limited options, such as developing web control interface or using telnet commands. As a result, I took on the project of developing my own application, sBITX Manager. I was pleased with how it turned out, and that inspired me to develop more apps. Along the way, I got a lot of helpful feedback from the sBitx community, and that led me to develop even more apps to make their experience better. But as the number of apps grew, so did the complexity – more things to install, more commands to remember, more repositories, and more things to keep updated. It was time to streamline and simplify the way that sBitx owners interact with my applications, so sBITX Toolbox was born. Here are some challenges that I sought out to conquer. Centralized Access: The toolbox will serve as a single point of entry for all the apps that have been developed. This means you won't have to search for individual apps, manually install, or manage multiple shortcuts. Everything will be readily accessible in one place. Ease of Use: Adding, removing, and launching applications will become more straightforward. The launcher will provide an intuitive interface where you can easily add, select, and use any of the apps without navigating through complex menus or file structures. Improved Organization: With a growing number of applications, it becomes essential to keep them well-organized. The launcher will offer features like improved touchscreen compatibility and possibly even customization, allowing you to manage the apps in a way that suits your needs. Seamless Updates and Maintenance: Integrating all apps into a single launcher will make it easier to roll out updates and maintenance patches. You will benefit from a more consistent and reliable experience. Feedback and Evolution: As with all my applications, community feedback will be beneficial in advancing the toolbox. Its design and functionality will evolve based on what I and the sBitx community find most helpful and efficient in managing and using the apps. All of my other repositories have been taken down to focus on sBITX Toolbox. This new repository contains an extensive user guide, release notes, and version validation. I've also included an uninstaller to remove the previous apps that I developed. The Windows version of sBITX Manager and sBITX Scanner are now contained here as well. Feel free to try it out and let me know what you think. https://github.com/drexjj/sBITX-toolbox - JJ

I was doing POTA yesterday with the V.5 shown in my avatar, when a caller asked me if I was [intentionally] running double sideband. He was really cool about it and volunteered to send a short video capture of my signal. I've included a still from that. I haven't adjusted anything for at least 2 years and it's spot on frequency, so I'm loathe to change anything too quickly. I also have forgotten or am unaware that any if the VFO or tuning parameters alter the transmit side of things. Again, it's been a while and I shall be re-reading the tuning methodology today. That said, i apparently misinterpreted or missed something before, unless it's a part failure. Would anyone whose good on the earlier models be able to suggest a good methodology for placing all of my RF energy into just one 3kc channel? I'm doing about 20 watts on 40m, so getting the full benefit - and not occupying more space than I need - would be an improvement. Tnx, K3RTA

Is the anyone running a Xiegu XPA125B with there Sbitx v4.4 with Jeff's QRO board? If so can you give me the "run down" do's/don'ts? Drive power ect ect... The QRO board should be here today ?

For the CW operators here ... have you had any problems with the sBitx CW keyer? The timing seems off for me when keying at higher speeds, and the TX isn't quite right even using an external keyer. I took a couple of videos showing what I mean: Using an external keyer at 25 wpm, the dits are much more staccato than they should be and sometimes entirely cut off. The TX is bad enough that the RBN will not pick up my call when using the external keyer: https://youtu.be/GHbw9GroKAU Using the sBitx internal keyer at 25 wpm, there are many keying mistakes introduced by the software, for example when keying the word "POTA", which is a word many of us will be keying of course: https://youtu.be/dtnPlcLXmdQ Keying using a small keyboard or a save message seems to work fine, so that's good :) I noticed the code polls the GPIO associated with the key only about 10-20 times per second, which I think is much too slow for faster keying, so I was thinking about rewriting it to use GPIO interrupts to change the CW flags instead of repeatedly polling the GPIO. Does anyone have thoughts on this as a possible approach? Thanks, Steve W4SGN

Thank you so much!