Re: [wsjt-devel] Bug Report (WSJT-X v1.7.0 r7405 on Mac OS X) (Keith Laaks) (Bill Somerville)
On 18/02/2017 20:44, DI Siegfried Hanisch wrote:
> Does anyone know if there is a way I can see the messages which are
> generated in the source code (Q_EMIT) in some console? Or do I have to
> build the code to add or enable debug output?
> Q_EMIT error (tr ("An error opening the audio output device has
> occurred."));
Hi Seigfried,
those SoundOutput::error signals are processed in the WSJT-X MainWindow
code and will cause a critical error message box to be popped up. The
relevant code is:
mainwindow.cpp:383 connect (m_soundOutput, &SoundOutput::error, this,
&MainWindow::showSoundOutError);
and
mainwindow.cpp:1448
void MainWindow::showSoundOutError(const QString& errorMsg)
{
if (m_splash && m_splash->isVisible ()) m_splash->hide ();
MessageBox::critical_message (this, tr ("Error in Sound Output"), errorMsg);
}
73
Bill
G4WJS.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bug Report (WSJT-X v1.7.0 r7405 on Mac OS X) (Keith Laaks) (Bill Somerville)
On 18/02/2017 20:34, Keith Laaks wrote: > Anyhow, I implemented your suggestion here and uninstalled the Silicon Labs > driver, then rebooted. > I then repeated experimentation with WSJTX working through some TX->RX->TX > cycles. > > It breaks in a similar manner - after 4-6 cycles, audio out switches to the > MacBook speakers. > And WSJTX then stops receiving completely. > Need to close and reopen - then receive works properly again. Hi Keith, your reply above was to Ulde IK2TYL's comments not mine although I did suggest that his proposed test was a good thing to try. The loss of Rx audio at the same time as Tx audio is an interesting data point. What I assume is happening is that both the speaker and mic/line in audio devices are being reset or switched spontaneously. I am fairly certain this behaviour is not due to anything we do in WSJT-X or even that the Qt framework we use for audio, this dual effect is consistent with that since at the level that Qt and hence WSJT-X interacts with the audio devices they are separate and apparently unrelated. Only at the lower levels of the Mac OS X Core Audio services or the device driver are the two audio devices tied to a single physical device. The logical conclusion is that there is nothing we can do until the driver or operating system authors sort out whatever the issue is. This needs more users to report the issue to SiLabs and Apple. I also suggest that fldigi users get involved as well as I gather it suffers the same problem. 73 Bill G4WJS. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Bug Report (WSJT-X v1.7.0 r7405 on Mac OS X) (Keith Laaks) (Bill Somerville)
Hi Keith
I know it is only a workaround until another solution is found, but on my
machine the hack with creating a new Audio Device in the "Audio-MIDI-Setup“
application works 100% reliably now,
I run WSJTX all evening without the need to restart. Just name the new Audio
Device (which needs to contain the real USB audio device then) so that it is
alphabetically first (like „A..“).
Does anyone know if there is a way I can see the messages which are generated
in the source code (Q_EMIT) in some console? Or do I have to build the code to
add or enable debug output?
Q_EMIT error (tr ("An error opening the audio output device has
occurred."));
Siegfried
> Am 18.02.2017 um 21:34 schrieb Keith Laaks :
>
> Hi Bill,
>
> Regarding: “
>>> Reading the emails on this issue, it looks like a low level USB reset
>>> due to I/O errors. And this causes the audio devices to change order
>>> or so, right? Then, why do you think it is the Silicon Labs driver
>>> that causes this? Isn't that driver only used to interface the CP210
>>> UART to USB bridge chip (the serial port for CAT stuff), not the
>>> overall low level USB protocol and the audio channels?"
>
> I was not aware that MacOS natively came with the driver for the USB audio.
> At some point in the past I was not able to get the audio working till I
> installed the Silicon Labs driver and I guess that why I just assumed they
> also did the audio part.
>
> Anyhow, I implemented your suggestion here and uninstalled the Silicon Labs
> driver, then rebooted.
> I then repeated experimentation with WSJTX working through some TX->RX->TX
> cycles.
>
> It breaks in a similar manner - after 4-6 cycles, audio out switches to the
> MacBook speakers.
> And WSJTX then stops receiving completely.
> Need to close and reopen - then receive works properly again.
>
> I even tried upgrading to 10.12.4 Beta - makes no difference.
>
> I do not see the 'IOUSBHostHIDDevice: IOUSBHostHIDDevice::interruptRetry:
> resetting device due to IO failures’ messages in the dmesg logs any more.
>
> When I run windows 7 within a VM on the Mac, and map the USB port natively to
> the Windows VM, WSJTX does not give this problem. It never ‘freezes’ like
> this.
> But its not really usable for me like this since the audio has a slight
> ‘buffering’ effect with a very small ‘pause’ in the TX audio every second or
> so.
> Anyhow this does tend to eliminate any issues with my USB port, cable or
> radio. Cable + Radio + WSJTX worked 100% on older OS X 10.11 before I
> upgraded.
>
> Very frustrated at this point….
>
> 73’s
> Keith
>
>
>
>>
>>
>>
>> --
>>
>> Message: 1
>> Date: Thu, 16 Feb 2017 22:16:48 +
>> From: Bill Somerville
>> Subject: Re: [wsjt-devel] Bug Report (WSJT-X v1.7.0 r7405 on Mac OS X)
>> (Keith Laaks)
>> To: wsjt-devel@lists.sourceforge.net
>> Message-ID: <4e7496d6-cbf4-3a41-914e-f08b9a449...@classdesign.com>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>
>> On 16/02/2017 22:00, Ulderico Arcidiaco wrote:
>>> Reading the emails on this issue, it looks like a low level USB reset
>>> due to I/O errors. And this causes the audio devices to change order
>>> or so, right? Then, why do you think it is the Silicon Labs driver
>>> that causes this? Isn't that driver only used to interface the CP210
>>> UART to USB bridge chip (the serial port for CAT stuff), not the
>>> overall low level USB protocol and the audio channels?
>>>
>>> You can indeed uninstall the Silicon Labs driver and still use the USB
>>> connection for audio I/O with your rig. In fact, if you suspect the
>>> Silicon Labs driver, you should actually try removing it, and using
>>> the USB for audio only, using vox to TX with your rig. If this works,
>>> then maybe the Silicon Labs driver is the bad guy in town, otherwise
>>> it is a different problem.
>>
>> Hi Ulde & all,
>>
>> this is good advice and is consistent with at least one Mac OS X user
>> solving this issue of unprompted USB audio device switches by installing
>> an older VCP driver. Note that the SILabs VCP driver is not the problem
>> in isolation, there is definitely an o/s version dependency as well
>> since this issue only started from OS X 10.10 onwards.
>>
>> 73
>> Bill
>> G4WJS.
>>
>>
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Greetings
Siegfried Hanisch
mailto:siegfried.hani...@hanisch.com
http://www.hanisch.com
--
Check out the vibrant tech community on one o
Re: [wsjt-devel] Bug Report (WSJT-X v1.7.0 r7405 on Mac OS X) (Keith Laaks) (Bill Somerville)
Hi Bill, Regarding: “ >> Reading the emails on this issue, it looks like a low level USB reset >> due to I/O errors. And this causes the audio devices to change order >> or so, right? Then, why do you think it is the Silicon Labs driver >> that causes this? Isn't that driver only used to interface the CP210 >> UART to USB bridge chip (the serial port for CAT stuff), not the >> overall low level USB protocol and the audio channels?" I was not aware that MacOS natively came with the driver for the USB audio. At some point in the past I was not able to get the audio working till I installed the Silicon Labs driver and I guess that why I just assumed they also did the audio part. Anyhow, I implemented your suggestion here and uninstalled the Silicon Labs driver, then rebooted. I then repeated experimentation with WSJTX working through some TX->RX->TX cycles. It breaks in a similar manner - after 4-6 cycles, audio out switches to the MacBook speakers. And WSJTX then stops receiving completely. Need to close and reopen - then receive works properly again. I even tried upgrading to 10.12.4 Beta - makes no difference. I do not see the 'IOUSBHostHIDDevice: IOUSBHostHIDDevice::interruptRetry: resetting device due to IO failures’ messages in the dmesg logs any more. When I run windows 7 within a VM on the Mac, and map the USB port natively to the Windows VM, WSJTX does not give this problem. It never ‘freezes’ like this. But its not really usable for me like this since the audio has a slight ‘buffering’ effect with a very small ‘pause’ in the TX audio every second or so. Anyhow this does tend to eliminate any issues with my USB port, cable or radio. Cable + Radio + WSJTX worked 100% on older OS X 10.11 before I upgraded. Very frustrated at this point…. 73’s Keith > > > > -- > > Message: 1 > Date: Thu, 16 Feb 2017 22:16:48 + > From: Bill Somerville > Subject: Re: [wsjt-devel] Bug Report (WSJT-X v1.7.0 r7405 on Mac OS X) > (Keith Laaks) > To: wsjt-devel@lists.sourceforge.net > Message-ID: <4e7496d6-cbf4-3a41-914e-f08b9a449...@classdesign.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 16/02/2017 22:00, Ulderico Arcidiaco wrote: >> Reading the emails on this issue, it looks like a low level USB reset >> due to I/O errors. And this causes the audio devices to change order >> or so, right? Then, why do you think it is the Silicon Labs driver >> that causes this? Isn't that driver only used to interface the CP210 >> UART to USB bridge chip (the serial port for CAT stuff), not the >> overall low level USB protocol and the audio channels? >> >> You can indeed uninstall the Silicon Labs driver and still use the USB >> connection for audio I/O with your rig. In fact, if you suspect the >> Silicon Labs driver, you should actually try removing it, and using >> the USB for audio only, using vox to TX with your rig. If this works, >> then maybe the Silicon Labs driver is the bad guy in town, otherwise >> it is a different problem. > > Hi Ulde & all, > > this is good advice and is consistent with at least one Mac OS X user > solving this issue of unprompted USB audio device switches by installing > an older VCP driver. Note that the SILabs VCP driver is not the problem > in isolation, there is definitely an o/s version dependency as well > since this issue only started from OS X 10.10 onwards. > > 73 > Bill > G4WJS. > > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT65 HF bands capacity, spectra allocation and software support
Hi Igor, some comments in line below. On 18/02/2017 19:12, Игорь Ч wrote: There is simple answer why users prefer operate JT65 on the overloaded HF bands while there is underused JT9 subband. I am not sure it is simple, there are many factors, here are some of them: * Many users persist with JT65-HF variants despite it not having JT9 capability and a very old JT65 decoder tuned for EME that has had no improvements for many years. The driving forces are probably familiarity, inertia and to some extent stubbornness, * Many users have set goals based on available awards or simply self defined goals like HF DXCC in JT65, they will tend to shun JT9 until the JT65 based goals are achieved, * Large numbers of users do not set up rig control so dual mode JT9+JT65 is not practical for them, this is compounded by many older rigs with fixed crystal filters of less than 3kHz width, * The large amount of JT65 activity is self-propagating, many stations with JT9 capability will only call on JT9 when there is nothing un-worked from the JT65 callers, * Some users just prefer the musical tones rather than the somewhat annoying, to the human ear, JT9 micro-warble, * ... . Anyone from DX location, let's say for instance from New Zealand, have frequently met scenario where multiple signals coming back to his CQ call. Agreed but until JT9 occupancy justifies, it doing the improvements for, multi-pass decoding in JT9 it is unlikely to be implemented, we must hope that until then operators are smart enough to spread out when a needed station is busy, after all it is not hard when there is plenty of space available. . Due to the nature of JT9 protocol&modulation neither one of two JT9 signals on the same frequency will be decoded in most cases, things getting worse if there are more than two signals on the same frequency. To make QSO possible experienced JT9 users call DX stations with frequency split and DX station in response has to use split operation or frequency hopping. You can't argue your case both ways on this. It is a technical challenge to decoding overlapping signals but until band occupancy is much greater for JT9 simply spreading out solves this problem. For sure experience with both WSPR and JT65A show that multi-pass decoding can be implemented successfully for JT9 when necessary. . Now one could imagine if there is propagation open between Europe and New Zealand and at least 10 operators calling one DX station using frequency split, this way JT9 spectral benefit versus JT65 is almost eliminated. That doesn't scale, you assumption is only correct if every QSO involves a rare wanted station. The bulk of HF JT mode QSOs are relatively routine with a single station or maybe two replying to a single caller with a strong signal. . Multipass decoding will only work if at least one JT9 signal is decoded on the frequency, otherway there is nothing to subtract. Well obviously! If there are no overlapping signals then there is no need for the complexity and processing overhead of multi-pass decoding. Given the fact that JT9 uses less bandwidth and is amenable to multi-pass decoding when band occupancy warrants it, there can be no argument that JT9 does not allow more QSOs per kHz then JT65A. This should not be a surprise, JT9 was designed to do a similar job to JT65 without having to use the extra bandwidth required for EME above 144MHz, JT65 has to work with Doppler spreading and TRX instability which are not generally significant on HF. The high occupancy of JT65A is more due to user factors than technical ones IMHO, making the pitch to play on bigger would just continue the illusion that JT65A is preferable. Have you considered that pressure on the space for JT65A on HF might be a good thing as it will entice more users to the superior JT9 mode or even to try other bands that are more challenging. Having everyone following the herd to the band with the best propagation on HF where signals are rarely weak is almost defeating the point of weak signal modes. You predict race to higher powers above, that may happen and it will be very sad if it does. Let's hope that common sense prevails and operators get smarter and maybe even reduce power a few dB which is just as likely to fix the occupancy problems! There is surely plenty of resolution headroom available on HF JT modes judging by the bulk of signal reports I see exchanged. 73 Bill G4WJS. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT65 HF bands capacity, spectra allocation and software support
With all due respect "weak signal" does not always equal "low power" (most of the time, sure, but a signal can be pretty weak even at 1.5 KW in poor conditions). Can you supply actual data to support your supposition that "high power usage is a common behavior" in the PSK areas (i.e. Something OTHER than just what is based on what you see on the spectral display)? Case in point here, the last time I worked PSK31, I received a severely worded email from another op who probably had the best of intentions dressing me down for "running too much power" saying that he could "tell I was pushing close to legal limit"based on "what he saw" and going on about how rude I was being, etc... I politely responded with a picture of my station at that time which was an Elecraft KX3 running on a battery on my picnic table set to 0.5 watts into a home brewed vertical antenna next to an IMD meter monitoring my outgoing signal. The saying "a picture paints a thousand words" isn't always applicable to what you see on the waterfall. A lot less ops are "running power" than current common perception seems to state. Again, this is with all due respect. Jim S. > On Feb 18, 2017, at 2:12 PM, Игорь Ч wrote: > > Hello All, > > There is simple answer why users prefer operate JT65 on the overloaded HF > bands while there is underused JT9 subband. > . > Anyone from DX location, let's say for instance from New Zealand, have > frequently met scenario where multiple signals coming back to his CQ call. > . > Due to the nature of JT9 protocol&modulation neither one of two JT9 signals > on the same frequency will be decoded in most cases, things getting worse if > there are more than two signals on the same frequency. To make QSO possible > experienced JT9 users call DX stations with frequency split and DX station in > response has to use split operation or frequency hopping. > . > Now one could imagine if there is propagation open between Europe and New > Zealand and at least 10 operators calling one DX station using frequency > split, this way JT9 spectral benefit versus JT65 is almost eliminated. > . > Multipass decoding will only work if at least one JT9 signal is decoded on > the frequency, otherway there is nothing to subtract. > . > Now back to JT65 HF subband capacity, for evenly distrubuted JT65 signals > between -01 and -26dB SNR to the Gaussian noise, maximum JT65 current subband > capacity is around 100...110 decoded signals if tested with 200 simulated > signals in the .wav file. These decoded signals have SNR to the Gaussian > noise in range from -01 to -14 dB, week signals gone unless DX operator using > 1kW power to try getting through. > . > For last 45 days number of JT65 HF users raised 25% up, and it is now usual > event to get 35..40 decoded JT65 messages for single RX interval. Going with > such increase rate monthly we will get out of the current JT65 HF bands > capacity within 6 months, and similar to PSK modes, high power usage will > became as common behaviour. > . > Hence there no other way to save HF JT weak signal communication but an > increase of the occupied bandwidth and it should be good idea to act now, > until we got to QRO JT communication instead of the weak signal one. > . > 73 Igor UA3DJY > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT65 HF bands capacity, spectra allocation and software support
On Fri,2/17/2017 11:47 PM, Игорь Ч wrote: > Due to the current explosive growth of HF activity in JT65a mode we > are getting close to a date when existing JT65 bandwidth will be fully > utilized leaving no possibility for weak signal communication but > local contacts. There's a much simpler solution -- JT9 has one tenth the occupied bandwidth. 73, Jim K9YC -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT65 HF bands capacity, spectra allocation and software support
Hello All, There is simple answer why users prefer operate JT65 on the overloaded HF bands while there is underused JT9 subband. . Anyone from DX location, let's say for instance from New Zealand, have frequently met scenario where multiple signals coming back to his CQ call. . Due to the nature of JT9 protocol&modulation neither one of two JT9 signals on the same frequency will be decoded in most cases, things getting worse if there are more than two signals on the same frequency. To make QSO possible experienced JT9 users call DX stations with frequency split and DX station in response has to use split operation or frequency hopping. . Now one could imagine if there is propagation open between Europe and New Zealand and at least 10 operators calling one DX station using frequency split, this way JT9 spectral benefit versus JT65 is almost eliminated. . Multipass decoding will only work if at least one JT9 signal is decoded on the frequency, otherway there is nothing to subtract. . Now back to JT65 HF subband capacity, for evenly distrubuted JT65 signals between -01 and -26dB SNR to the Gaussian noise, maximum JT65 current subband capacity is around 100...110 decoded signals if tested with 200 simulated signals in the .wav file. These decoded signals have SNR to the Gaussian noise in range from -01 to -14 dB, week signals gone unless DX operator using 1kW power to try getting through. . For last 45 days number of JT65 HF users raised 25% up, and it is now usual event to get 35..40 decoded JT65 messages for single RX interval. Going with such increase rate monthly we will get out of the current JT65 HF bands capacity within 6 months, and similar to PSK modes, high power usage will became as common behaviour. . Hence there no other way to save HF JT weak signal communication but an increase of the occupied bandwidth and it should be good idea to act now, until we got to QRO JT communication instead of the weak signal one. . 73 Igor UA3DJY -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT65 HF bands capacity, spectra allocation and software support
That's been discussed b4.there are two primary reasons...#1 is that not all JT65 software does JT9. #2 is the chicken-and-egg situation which is exacerbated by #1.Also...a lot of people don't know about or understand split mode operation so may be transmitting out of their bandpass. I've been doing both modes for over 2 years. There has been an increase in JT9 but not a significant one that I've noticed. Don't know that I ever see more JT9's going than JT65's at any time. de Mike W9MDB From: Guy To: 'WSJT software development' Sent: Saturday, February 18, 2017 8:27 AM Subject: Re: [wsjt-devel] JT65 HF bands capacity, spectra allocation and software support The simple solution to this problem is JT9. I just cannot understand why this mode is so underutilised. 73 de Guy G4DWV/4X1LT -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT65 HF bands capacity, spectra allocation and software support
The simple solution to this problem is JT9. I just cannot understand why this mode is so underutilised. 73 de Guy G4DWV/4X1LT -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT65 HF bands capacity, spectra allocation and software support
To add to Bill's very well written response, there are many pre-established operations on 40 meters around the JT mode watering hole. Using my Flex 6300, I can see many SSB Phone QSO's going on on 7.072-3 and 7.080 from Canadian and some other ITU Region 1 entities. Even though the band may seem dead in one place, the HF bands are already quite crowded (this is less evident to those with compromise antennas who may not be receiving these other stations but rest assured, they're there). The increasing popularity of JT65 means we need to be agile operators who change our operation style to move around with band conditions which also includes how crowded the band is at any given time). Weak signal operation is still very much alive! 73, Jim S. N2ADV > On Feb 18, 2017, at 8:16 AM, Bill Somerville wrote: > >> On 18/02/2017 07:47, Игорь Ч wrote: >> Due to the current explosive growth of HF activity in JT65a mode we >> are getting close to a date when existing JT65 bandwidth will be fully >> utilized leaving no possibility for weak signal communication but >> local contacts. >> . >> It might be right time now to act towards the new concept for JT65 HF >> usage and spectra allocation, considering latest SDR technology for >> handling 20kHz bandwidth in the software. > > HI Igor, > > although this is technically possible with average PC sound card sample > rates it would tend to exclude those with SSB only rigs who would have > to move around just to see which stations are active. I believe this > would create a DX cluster type herd mentality with most stations landing > on the band segment that has the rare station on. One of the things I > really like about JT modes on HF is that QSOs are almost exclusively > initiated from on air calls, the ability of everyone to potentially copy > everyone is fantastic. Even though it is all about computers and the > Internet adds huge benefits, the fundamental principles of listening on > air for QSO partners is one reason for the success of the JT modes on HF > IMHO. > > Another matter to consider is that on most HF bands there is simply not > enough bandwidth available to spread the JT modes out by a factor of > five. Take 40m for example, here in the EU we are operating in the phone > band which itself is busy as the solar minimum is approaching (a solar > minimum that is forecast to be longer and deeper than most operators > have experienced), pressures on spectrum space will undoubtedly increase > if the hobby is to succeed and proposals to grab more for any operating > mode will not be well received. > > If a few more stations shifted to JT9 on HF, the potential spectrum > utilization gains are similar without requiring many to buy new rigs. > Admittedly JT65A on HF has reasonably good overlapping signal decoding > which is greatly enhanced by two pass decoding. This is an area that has > not been taken advantage of for JT9 yet, when the utilization of JT9 > becomes high enough to justify it I'm sure that a win is there to be had > by using two pass decoding. > > Perhaps the near capacity JT65A utilization at times will encourage more > to experiment with new bands and JT9 on HF. There is still a lot of > space for us all within a conventional SSB bandwidth (plus a bit if you > have 4 or 5kHz Rx capability) on each band. Imagine what might happen if > everyone who uses JT65A on HF switched to JT9, I doubt we would be > looking for more spectrum space for some time. > > Just my 2c > 73 > Bill > G4WJS. > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT65 HF bands capacity, spectra allocation and software support
On 18/02/2017 07:47, Игорь Ч wrote: > Due to the current explosive growth of HF activity in JT65a mode we > are getting close to a date when existing JT65 bandwidth will be fully > utilized leaving no possibility for weak signal communication but > local contacts. > . > It might be right time now to act towards the new concept for JT65 HF > usage and spectra allocation, considering latest SDR technology for > handling 20kHz bandwidth in the software. HI Igor, although this is technically possible with average PC sound card sample rates it would tend to exclude those with SSB only rigs who would have to move around just to see which stations are active. I believe this would create a DX cluster type herd mentality with most stations landing on the band segment that has the rare station on. One of the things I really like about JT modes on HF is that QSOs are almost exclusively initiated from on air calls, the ability of everyone to potentially copy everyone is fantastic. Even though it is all about computers and the Internet adds huge benefits, the fundamental principles of listening on air for QSO partners is one reason for the success of the JT modes on HF IMHO. Another matter to consider is that on most HF bands there is simply not enough bandwidth available to spread the JT modes out by a factor of five. Take 40m for example, here in the EU we are operating in the phone band which itself is busy as the solar minimum is approaching (a solar minimum that is forecast to be longer and deeper than most operators have experienced), pressures on spectrum space will undoubtedly increase if the hobby is to succeed and proposals to grab more for any operating mode will not be well received. If a few more stations shifted to JT9 on HF, the potential spectrum utilization gains are similar without requiring many to buy new rigs. Admittedly JT65A on HF has reasonably good overlapping signal decoding which is greatly enhanced by two pass decoding. This is an area that has not been taken advantage of for JT9 yet, when the utilization of JT9 becomes high enough to justify it I'm sure that a win is there to be had by using two pass decoding. Perhaps the near capacity JT65A utilization at times will encourage more to experiment with new bands and JT9 on HF. There is still a lot of space for us all within a conventional SSB bandwidth (plus a bit if you have 4 or 5kHz Rx capability) on each band. Imagine what might happen if everyone who uses JT65A on HF switched to JT9, I doubt we would be looking for more spectrum space for some time. Just my 2c 73 Bill G4WJS. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT65 HF bands capacity, spectra allocation and software support
On 02/18/2017 08:47 AM, Игорь Ч wrote: Hi Igor & all, In my opinion, this growth of HF activity is a good thing. Often the use of these modes is a tentative to compensate for antenna and power limitations. There exists a general problem related to the band plans. Often there is to many space reserved for less used modes, while the allocated space is to small for more popular modes, especially digital modes. The 30 m and 60 m bands are good examples. Often, I'm asking me if the people which decide about the band plans are really QRV. We need more space for digital modes and more realistic band plans. Just my opinion. Best 88 de Claude (DJ0OT) > Due to the current explosive growth of HF activity in JT65a mode we are > getting close to a date when existing JT65 bandwidth will be fully > utilized leaving no possibility for weak signal communication but local > contacts. > It might be right time now to act towards the new concept for JT65 HF > usage and spectra allocation, considering latest SDR technology for > handling 20kHz bandwidth in the software. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] JT65 HF bands capacity, spectra allocation and software support
Hello Joe and All, . Due to the current explosive growth of HF activity in JT65a mode we are getting close to a date when existing JT65 bandwidth will be fully utilized leaving no possibility for weak signal communication but local contacts. . It might be right time now to act towards the new concept for JT65 HF usage and spectra allocation, considering latest SDR technology for handling 20kHz bandwidth in the software. . 73 Igor UA3DJY -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
