|
Hello Antionio,
the signal just above 1200Hz is most likely WSPR (by counting pixels I estimate its length at 110 seconds, a JT9-2 transmissions takes only 98 seconds).
Either someone transmitting outside the WSPR band, or a strong station in the WSPR band with too much 100Hz sidebands.
In regard with UTC: looks like you computer clock is on daylight saving time. In SlowJT9 you have to set the difference between your computer clock and UTC: click on "Settings", then on "Station", now set the correct UTC differece (in your case UTC+2).
About the no (de)coding: so far there has been very little JT9-2 activity in Europe. I have seen nothing either last night.
73, Rik ON7YD - OR7T
problem on the JT9-2 system I see no coding I have been in rx 2 hours nothing .... in the system JT9-1 worked very well on 5 hours last night I think it's an important problem to carefully put in the spotlight to track down crashes right now. It's better
to continue the tests and see if it's time to continue the project.
73 ik1hgi Antonio
problema sulla sistema JT9-2 vedo non codifica sono stato in rx 2 ore nulla.... nel sistema JT9-1 ha funzionato molto bene su 5 ore ieri sera penso sia qualche problema importante mettere con attenzione nel prosimo relax rintracciare crash in questo
momento. Meglio continuare i test e vedere se va beme di continuare il progetto.
73 ik1hgi Antonio
Hello Paul,
decoder.txt seems OK.
I am sorry if I gave the impression that I thought you were complaining.
Certainly not, all reports on crashes are abnormal behaviour are welcome.
But these rare crashes are very difficult to trance down.
As you stated, for now I will focus on testing and improving SlowJT9.
At a later stage I will try to intercept possible crashes.
Thanks for your help!
73, Rik ON7YD - OR7T
________________________________________
Van: [email protected] <[email protected]> namens N1BUG <[email protected]>
Verzonden: maandag 12 november 2018 20:40
Aan: [email protected];
[email protected]
Onderwerp: Re: LF: Re: MF JT9-2 report
Hello Rik,
> A new version of SlowJT9, with correct reports and the cycle bug
> fixed, will be uploaded later today.
v0.9.02 installed and monitoring 630m JT9-2 here.
> Regarding the drift: keep in mind that in the JT9-2 -> JT9
> conversion process frequencies are doubled, so any drift also
> will inevitably be doubled in that process.
Yes of course. The drift I measured was the actual RF drift of the
signal, measured visually with a high resolution waterfall external
to SlowJT9. The actual drift passed to the decoder would be double
the amount I reported.
> About the crash: what was the content of the decoded.txt file?
> Maybe that will give me a clue what happened.
Contents of the file:
0359 18 -15 0.3 2188. 0 CQ WB4JWM EM83 JT9
> I have SlowJT9 (in
> JT9-2 mode) running since 9 Nov 20 UTC and it was still running
> this morning (12 Nov 6 UTC). It is running side by side with
> WSJT-X and Google Chrome, no other apps. I must admit that I
> haven't paid much attention to intercepting errors so far,
> another item to add to my to-do list.
I was not complaining! It ran all night the previous night on JT9-1
and for at least 8 hours last night on JT9-2 prior to the crash. I
don't think it is important to put too much work into tracking down
the reason for a few crashes right now. Better to continue testing
and see if it will be worth continuing the project.
Thank you again for your work! I look forward to more testing and I
hope SlowJT9 can help with trans-Atlantic QSOs on both 630m and
2200m. As I have said several times before, we are in need of some
help on 2200m. JT9-1 requires quite strong signals and there are few
or no alternatives aside from DFCW/QRSS.
73,
Paul N1BUG
--
Salve Antonio ik1hgi
RISERVATEZZA (ai sensi D.Lgs n. 196/03)
|
