On 8/28/21 3:56 AM, William Smith via wsjt-devel wrote: > Interesting idea, a couple of thoughts come to mind (not that you haven't > already considered them): > > When you are only listening, you have a good idea of who else is transmitting > when/where, but as soon as you start transmitting, you lose visibilty into > your timeslot. I use a combination of visual inspection and a Python program > that grinds through the last couple of minutes of ALL.TXT to pick an empty > transmit frequency, and while it works, it's a bit of a kludge.
This is true. One possibility is to randomize your transmission slot along with your frequency, i.e., use another bit of the hash to determine whether you transmit on the even or odd slot. It wouldn't matter for those who are listening since they hear all frequencies and both time slots, but I'd have to think about how this might be adapted to existing software that expect you to transmit on only the even or odd slots. I like your method of surveying everything and building a channel occupancy map. You're right, it's probably the best you can do right now. My idea extends that, though it would admittedly break your current scheme because the transmitting frequencies would be pseudo-randomized. How many are already doing what you're doing? BTW, another good reason to randomize your transmit frequency is for the benefit of stations who may be plagued by narrowband interference. It seems like every grid load is now a switching device of some kind, and eliminating or cleaning them all up seems a Sisyphean task. > > There's no good answer to "How wide is someone else's rx bandwidth?". While > some have fancy SDR rigs with 5KHz or more, others have voice rigs (or don't > know how to set their filters), so attempting a QSO at 200Hz or 4KHz is only > going to work for some random subset of operators. Also true. I keep thinking maybe the best long-term answer is the separate, wideband receive SDR. They are getting cheaper and better all the time. And it's what I'm developing myself. It's a Airspy HF+ followed by my own software that feeds components of wsjtx with a purely digital path (no audio cables, virtual or real!) and a very flat, tuneable filter. It can run on a RPi with an optional user interface so you don't have to tie up your desktop PC. At some point the wsjtx software components would have to be modified to accept a wider bandwidth. I/Q input would also be very nice. Phil _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
