turbo XTR -- <3200

ZXNet echo conference «hardware.zx»

From Dmitry Lomov To Kirill Frolov 23 November 2001

Hello, Kirill! Once, Thu Nov 22 2001 15:19, Kirill Frolov wrote to Dmitry Lomov: KF>>> Use Manchester encoding. Already accelerating DL>> Manchester is bad for this purpose - the fronts are shaking too much. KF> What does shaking mean? Where are they going anyway? Probably in the comparator? KF> Explain more specifically. in order for the comparator with a zero threshold to operate at the right moments (or at t=0, or at t=T/2), it is necessary to implement the “correct” frequency response of the channel (which it should be for Manchester, I don’t remember now). if everything is wrong, then intersymbol interference appears (the meanings of the previous bits affect the “shape” current). in particular, if many ones are followed by many zeros (or on the contrary), then at the moment T/2 there will be no first zero transition, it will happen a little later. This is what I call the “shaking” of the fronts. DL>> now, if only the correct correction of the frequency response was done before the comparator... KF> Which one is correct? I'll find out one of these days and I'll tell you. KF> Well, in general it is necessary, otherwise the square signals from XTR ring beautifully KF> long telephone wires don't care. if there is no nonlinearity, all this will be cut off by ATS filters. KF> How does an iron comparator react in general, what is its principle KF> work? Specifically in XTR. ? there is a regular comparator with a zero threshold. DL>> and if the percentage in the Spectrum were ten times faster, you can DL>> it would be possible to adjust the correct PLL, but this is unrealistic. KF> You can first synchronize more than one last one KF> pulse, and calculate based on the last few. this will be the “correct” PLL. only in a good way you also need the size take deviations into account, and add inertia. KF>>> There was such a program Fast Modem (C) Lomov and someone else. DL>> it seems there are 2400 :( KF> Yes. DL>> but it worked quite steadily after the lows up DL>> the comparator was stabbed to death. KF> Doesn't XTR do this at all? he doesn't do it so fiercely;) he has a linear frequency response region, below which there is a cut. for FastModem I cut at a high frequency, therefore the whole working the frequency response zone had a slope of 6 dB/octave. maybe this is the right correction for Manchester ;) KF> Because of AOH ? yes. KF>>> Do you want to echo? DL>> yes. very interesting. if possible - in zipped text ;) KF> STORM rulez 4ever. Such a terrible rule that now KF> there is nothing to decode... there is also export to text ;) All the best. Dmitry. [ZX] [Quake] np: silence