Hi Reino +I think your answer is the closest to the target +
We agree that if the computer clock is close to 15seconds time difference EVEN and ODD would be crossed. If that happened with 2 computers and for 10+ days, it is explained, but it is a big coincidence. I would expect a variable clock difference and not a steady one. Regarding the QSO being completed by Hounds sending reports above 1000Hz with WSJTx, it is new to me. I thought the QSY down below 1000Hz was mandatory. I need to read JT's paper about F/H again. However in my mind I was led to believe that the QSY below 1000Hz was mandatory. Anyway now it is explained. In reality the clock issue produced the following issues: - With the FOX transmitting in ODD and with continuous advertising by Pilots that it was F/H, people turned-on their F/H in their WSJT software and transmitted blindly on ODD, the same period FOX was transmitting. WSJTx does not allow FOXes to use EVEN. Lots of QSOs were lost because of that and produced a big increase of QRM. - Those who used JTDX and understood the situation, could TX F/H in EVEN periods and were OK. However it was not obvious at first glance. - Those who used normal FT8 were eventually successful like me . But because the report was transmitted in the same calling frequency (above 1000Hz), which could be occupied by other callers , it is likely that Qs were also lost. The bottom line is: FT8 QSO numbers in 3Y0J DXP were not maximized. On the contrary. Many did not work them. DXPs in the future must pay good attention to 3Y0J's lessons in order to avoid low FT8 QSOs rate and loss of QSOs. Fred PY2XB Hi Fred, I am using only general information about these issues. a) If the PC cock is really off by 14 s, then simply odd and even sequences are crossed. No possibility to see that within wsjt-x. b) The QSy below 1000 Hz is only improving possibility to have less QRM, but the program itself does not care where you are sending your messages. 73, Reino OH3mA Em qua., 15 de fev. de 2023 às 14:05, Fred Carvalho <fred.py...@gmail.com> escreveu: > I have read the answers. Thanks to all. > > Commenting posts and/or answering questions: No I have not worked Pirate, > although I have seen them. I have always looked at antenna direction and > FOX behavior before calling. So my QSOs were confirmed correctly. > To 5p1kzx Michael: We all assumed that they were using Multistream with > another program - MSHV for instance, but one 3Y0J operator, after returning > to the boat, informed me that they were using WSJTx. > I also think that a 750K DXpedition could afford a GPS sync device that > costs a few dollars. > Yes, other operations that will do "real" F/H need to learn from these > lessons, indeed. > > > However I would like to stick on why and how things happened that caused > so much confusion: > > - Exactly 15 seconds time shift would explain the Fox transmitting in > ODD. However they had two computers and would the time difference be the > same and constant on both computers for 10+ days ? As I stated, the worst > sync I saw was 0.4s. > It is very strange time difference to stay constant exactly 15s during > 10+ days. > On the other hand, erratic time sync would lead to bigger messes because > people would not be able to decode them. They were decodable every time I > heard them and I heard them everyday since they started FT8. > > - Why/How Fox accepted reports above 1000Hz and concluded QSO? I did my > QSOs without using the F/H function. I was in NORMAL FT8 all the time. I > sent reports in different offsets above 1000Hz. Others did the same. In > fact many of us were sure they were not using WSJTx. However it was > confirmed that they were.. <== this one nobody commented > > Any thoughts ? Fred PY2XB > > > > Em qua., 15 de fev. de 2023 às 10:15, Fred Carvalho <fred.py...@gmail.com> > escreveu: > >> GM to all >> >> *This concerns F/H operation in 3Y0J* >> >> During the DXpedition the team announced multiple times that they were >> using WSJT DXPedition Mode (F/H). However, FOX was most of the time in ODD >> periods and accepted reports in any spot in the channel. QSY below 1000Hz >> was not necessary. My QSOs with them were always like that. It took me some >> time to understand how to work them, which I think was the same to most of >> the callers. BTW, I have never seen FOX out of sync. The worst that I can >> remember was 0.4s. >> >> Many thought – myself included- that they were not using WSJTx, but some >> other multistream DXP mode application. However one of the operators >> confirmed to me that they have used WSJT software. >> >> After the expedition they have stated that : “ *We had issues with the >> FT8 due to we did not have any device to sync against, and our clock was 14 >> seconds off - which meant we at some time were TX odd, while we thought it >> was even.*” >> >> Well a simple GPS device connected to one of their notebooks would have >> prevented the problem above. >> >> So my questions to the developers are: >> >> a) Is it really possible that lack of sync would lead them to TX in >> ODD periods as FOX ? >> >> b) How come QSY below 1000 HZ was not necessary for the Hound to >> finalize the QSO with them? >> >> This is very intriguing to many of us. Some clarification on what >> happened is very much appreciated >> >> Thanks Fred PY2XB >> >> -- >> Fred - PY2XB >> >> PY2FXH, PY2FXH/W2, PY2FXH/9, PY2XB/0, F/PY2XB, ZX2XB, PT7BXB, PY2XB/PY0F, >> PQ0F <https://www.qrz.com/db/pq0f>, VP5/PY2XB, PW2IO >> <https://www.qrz.com/db/pw2io>(SA-071), ZX8W >> <https://www.qrz.com/db/zx8w> (SA-060), PY2XB/1 (SA-029), 8P9XB >> <https://www.qrz.com/db/8p9xb>, PQ8XB <http://www.qrz.com/db/pq8xb> >> (SA-045), ZX2S <http://www.qrz.com/db/zx2s> (SA-028), PR7XB W4/PY2XB, >> 3D2XB <http://www.qrz.com/db/3d2xb>, PY22XB >> <http://www.qrz.com/db/py22xb>,PY0FX, W2/PY2XB, W9/PY2XB, VE3/PY2XB, >> PY2XB/5 >> >> *Team member** :* PW2M <https://www.qrz.com/db/pw2m> (SA-071), PX8J >> <http://www.px8j.com/> (SA-041), T30PY - T30SIX >> <http://www.mdxc.org/t30py/>, PT0S <http://www.pt0s.com/>, 9M0W >> <http://www.yt1ad.info/9m0w/> >> >> > > -- > Fred - PY2XB > > PY2FXH, PY2FXH/W2, PY2FXH/9, PY2XB/0, F/PY2XB, ZX2XB, PT7BXB, PY2XB/PY0F, > PQ0F <https://www.qrz.com/db/pq0f>, VP5/PY2XB, PW2IO > <https://www.qrz.com/db/pw2io>(SA-071), ZX8W <https://www.qrz.com/db/zx8w> > (SA-060), > PY2XB/1 (SA-029), 8P9XB <https://www.qrz.com/db/8p9xb>, PQ8XB > <http://www.qrz.com/db/pq8xb> (SA-045), ZX2S <http://www.qrz.com/db/zx2s> > (SA-028), > PR7XB W4/PY2XB, 3D2XB <http://www.qrz.com/db/3d2xb>, PY22XB > <http://www.qrz.com/db/py22xb>,PY0FX, W2/PY2XB, W9/PY2XB, VE3/PY2XB, > PY2XB/5 > > *Team member** :* PW2M <https://www.qrz.com/db/pw2m> (SA-071), PX8J > <http://www.px8j.com/> (SA-041), T30PY - T30SIX > <http://www.mdxc.org/t30py/>, PT0S <http://www.pt0s.com/>, 9M0W > <http://www.yt1ad.info/9m0w/> > > -- Fred - PY2XB PY2FXH, PY2FXH/W2, PY2FXH/9, PY2XB/0, F/PY2XB, ZX2XB, PT7BXB, PY2XB/PY0F, PQ0F <https://www.qrz.com/db/pq0f>, VP5/PY2XB, PW2IO <https://www.qrz.com/db/pw2io>(SA-071), ZX8W <https://www.qrz.com/db/zx8w> (SA-060), PY2XB/1 (SA-029), 8P9XB <https://www.qrz.com/db/8p9xb>, PQ8XB <http://www.qrz.com/db/pq8xb> (SA-045), ZX2S <http://www.qrz.com/db/zx2s> (SA-028), PR7XB W4/PY2XB, 3D2XB <http://www.qrz.com/db/3d2xb>, PY22XB <http://www.qrz.com/db/py22xb>,PY0FX, W2/PY2XB, W9/PY2XB, VE3/PY2XB, PY2XB/5 *Team member** :* PW2M <https://www.qrz.com/db/pw2m> (SA-071), PX8J <http://www.px8j.com/> (SA-041), T30PY - T30SIX <http://www.mdxc.org/t30py/> , PT0S <http://www.pt0s.com/>, 9M0W <http://www.yt1ad.info/9m0w/>
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
