Loading ...
Sorry, an error occurred while loading the content.

AW: [V4Protocol] Re: V4Chat client v 0.3.0.0 endlessly transmitting 16 characters

Expand Messages
  • Siegfried Jackstien
    ..... not to forget the time on receive and transmit if someone uses an sdr radio .... that also would ad in the calculation time Dg9bfc Sigi
    Message 1 of 10 , Jun 26, 2011
    • 0 Attachment
      ..... not to forget the time on receive and transmit if someone uses an sdr radio .... that also would ad in the calculation time
      Dg9bfc
      Sigi


      > -----Ursprüngliche Nachricht-----
      > Von: V4Protocol@yahoogroups.com [mailto:V4Protocol@yahoogroups.com] Im
      > Auftrag von la7um
      > Gesendet: Sonntag, 26. Juni 2011 12:22
      > An: V4Protocol@yahoogroups.com
      > Betreff: [V4Protocol] Re: V4Chat client v 0.3.0.0 endlessly transmitting
      > 16 characters
      >
      >
      >
      > Rick. Interesting descriptions of the "round trip calculations, starting
      > by measurements". I recognize your ideas. By the way nice & informative
      > PPT. 73 La7um Finn
      >
      > --- In V4Protocol@yahoogroups.com <mailto:V4Protocol%40yahoogroups.com> ,
      > "Rick Muething" <rmuething@...> wrote:
      > >
      > > Bernie,
      > >
      > > I looked at the document and while it is aimed at typical network type
      > timing there are some areas for adapting to use a variable timer. The next
      > revision of software will include a mechanism that measures the round trip
      > delay and use that to optimize the timer value. What I call the round trip
      > delay is this:
      > > Start Round Trip measurement when the ISS station releases its PTT
      > signal
      > > Measure time (true resolution about 10 ms) until the ACK or NAK of the
      > responding station is received. There is still a timeout on this (larger
      > than any normal reply value) in case there is a lost ACK or NAK.
      > > Use that measured time to create a new more optimum (shorter) ARQ repeat
      > interval. This interval will be used for the duration of the ARQ session
      > and will have some safety guard band (in the order of 100-200 ms or so)
      > >
      > > This should work because the primary elements affecting the round trip
      > delay measurement are:
      > > 1) RF Transit time (both directions) generally pretty small but could be
      > over 100 ms
      > > 2) Leader time at the station sending the ACK/NAK (Leader length is a
      > function of VOX or non VOX operation)
      > > 3) OS and sound card latency at both ends (Captured sound card data is
      > buffered at least 1 symbol (~ 21 ms) at each end but can occasionally
      > (Windows is not a true Real time OS) be a couple symbols longer than that.
      > > 4) CPU Processing speed. After a full frame is received by the IRS it
      > must be decoded (Viterbi Decoder) and the correct reply composed and
      > queued to the sound card. Depending on the CPU this adds some time but
      > normally < 50 ms.
      > >
      > > While Items 3 and 4 are somewhat variable depending on the CPU loading
      > They can be handled with a fairly small margin of 100 to 200 ms and still
      > be safe (that pad or margin has a relatively small impact on net
      > throughput ...perhaps 3-5 %).
      > >
      > > The next release will include an automatic calculation of this delay
      > (calculate independently for each end) and use those values during the ARQ
      > session. A new optimum delay will be computed for each end on each ARQ
      > connect.
      > >
      > > FYI WINMOR uses a similar procedure to measure and adjust for round trip
      > delay.
      > >
      > > Now as for your comment on “Adaptive timers become very important when
      > there are multiple stations on the same frequency.” I don’t think this
      > really applies to those modes that do not share frequency (Pactor, Amtor,
      > V4, WINMOR etc). Those mode unlike Packet are not designed to run
      > simultaneous connections on the same frequency. Supporting multiple
      > connections on one frequency adds a large amount of overhead (e.g. HF
      > Packet for example) and was never intended for V4. Trying to run two
      > connections on the same frequency results in total chaos for the protocol
      > as it does for most single connection ARQ protocols above.
      > >
      > > 73,
      > >
      > > Rick KN6KB
      > >
      > >
      > >
      > > From: ham
      > > Sent: Friday, June 24, 2011 1:28 PM
      > > To: V4Protocol@yahoogroups.com <mailto:V4Protocol%40yahoogroups.com>
      > > Subject: [V4Protocol] Re: V4Chat client v 0.3.0.0 endlessly transmitting
      > 16 characters
      > >
      > >
      > >
      > >
      > > Rick:
      > >
      > > I had a QSO with Robert last night and we both had the issue with the
      > constant repeats. Also, please consider using adapter timers as I
      > suggested in a previous post.
      > >
      > > Have a look at:
      > > http://www.icao.int/anb/Panels/ACP/ATNP/Meetings/wg2/wps/w2wp345.pdf
      > >
      > > Adaptive timers become very important when there are multiple stations
      > on the same frequency.
      > >
      > > Regards,
      > > Bernie
      > >
      > > --- In mailto:V4Protocol%40yahoogroups.com, "Rick Muething" <rmuething@>
      > wrote:
      > > >
      > > > Robert,
      > > >
      > > > The fix is that the software should prevent you from ever sending data
      > in ARQ mode unless connected. That will be in the next release. In ARQ
      > mode there is always a timeout while connected.
      > > >
      > > > Thanks for the feedback.
      > > >
      > > > Rick KN6KB
      > > >
      > > >
      > > > From: Robert Belize
      > > > Sent: Friday, June 24, 2011 10:55 AM
      > > > To: mailto:V4Protocol%40yahoogroups.com
      > > > Subject: [V4Protocol] Re: V4Chat client v 0.3.0.0 endlessly
      > transmitting 16 characters
      > > >
      > > >
      > > > Rick,
      > > >
      > > > the reason I have set the ARQ time out timer to 30 sec was, to check
      > if there was any routine in your code what would stop the transmitter
      > sending 16 Character endlessly ( there is no watchdog ) , resulting
      > finally in overheating.
      > > > I have seen those 16 characters sent by other stations, unaware of it.
      > > >
      > > > In my opinion, the client should not provide the possibility by
      > mistake, to send out (transmit) 16 characters, without being connected.
      > > >
      > > > 73'
      > > > Robert V31AE
      > > >
      > > > --- In mailto:V4Protocol%40yahoogroups.com, "Robert Belize"
      > <robertbelize@> wrote:
      > > > >
      > > > > Rick,
      > > > >
      > > > > I should have added that ARQ timeout is set to (30) sec, and AutoId
      > is off. I started the sequence 5 minutes ago, and it is still
      > repeating/transmitting the 16 characters.
      > > > >
      > > > > Robert V31AE
      > > > >
      > > >
      > >
      >
      >
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.