Ostatnie wiadomości

Strony: [1] 2 3 ... 10
1
Dyskusja ogólna / Odp: Mikrotik i oryginalne oprogramowanie
« Ostatnia wiadomość wysłana przez SQ9IWE dnia Czerwiec 30, 2017, 21:46:46 »
Trochę stary opis http://mikrotik.net.pl/wiki/Routing_Layer-2_dla_sieci_typu_Mesh ale liczy że ładnie po polsku i można zobaczyć jak to wygląda wg Mikrotika  8)
2
Dyskusja ogólna / Odp: Mikrotik i oryginalne oprogramowanie
« Ostatnia wiadomość wysłana przez SQ9IWE dnia Czerwiec 30, 2017, 21:31:53 »
Odświeżę trochę temat  8)
Mikrotik z tego co pamięta ma "swój" mesh , zresztą jak to mikrotik lubi iść własną drogą  ;D

Nie zagłębiałem się puki co jest od strony praktycznej ale w teorii nie powinno być z tym problemu.
3
Dyskusja ogólna / Odp: HamNET i wykorzystanie w łącznościach kryzysowych
« Ostatnia wiadomość wysłana przez SP2ONG dnia Luty 04, 2017, 14:33:39 »
Wszystkie moje publikacje sa dostepne w tym watku:

http://forum.hamnet.ugu.pl/index.php?topic=129.0
4
Dyskusja ogólna / Odp: HamNET i wykorzystanie do sytuacji kryzysowych
« Ostatnia wiadomość wysłana przez SQ4BJO dnia Luty 04, 2017, 10:10:51 »
.... Lokalnie tez tu przekazuje informacje kolegom ktorzy sa zwiazani z lacznoscia kryzysowa i dostawali moje prezentacje o mozliwosciach wykorzystania jako dodatkowego elementu w takie komunikacji...

Masz jakąś prezentację w formie elektronicznej (powerpoint (MS) lub presentacja (OOo). Chciałbym przedstawić ją dla naszego (augustowskiego) burmistrza (razem do podstawówki chodziliśmy :)) . Myślę iż mamy szansę nawet na dofinansowanie (może jakiś zalążek systemu wczesnego ostrzegania powstanie, obwód kaliningradzki i ISKANDERY blisko mamy, a nasz rząd skutecznie wujka Władka drażni :)).
5
Dyskusja ogólna / Odp: Alternatywne drogi przesylania poczty
« Ostatnia wiadomość wysłana przez SP2ONG dnia Listopad 06, 2016, 09:48:22 »
ARDOP protokol ktory powstal i byl rozwijany pod katem wykorzystanie wymiany poczty Winlink staje sie popularny tez jako forma komunikacji cyfrowej co widac po powstaniu kolejnej aplikacji do lacznosci typu CHAT. Nowa aplikacje ktora nie jest moze pod wzgledme wygladu jakas wodotryskowa ale jest funkcjonalna dziala na MS Windows/Linux. Tak wiec jesli ktos chce porobic lacznosci z wykorzystaniem ARDOP i karty dzwiekowej jako modem warto sprobowac aplikacji ARIM:

http://www.whitemesa.net/arim/arim.html
6
Dyskusja ogólna / Odp: Alternatywne drogi przesylania poczty
« Ostatnia wiadomość wysłana przez SP2ONG dnia Październik 15, 2016, 10:01:24 »
Mmay nowa wersje 0.81 i warto prpbowac an 7045lub 14066 lub 10146 kHz ARDOP Chat zrobic lacznosci


Cytuj
All,

I have uploaded the latest version that addresses several issues. Below
is a summary of the changes. See the revision histories after the update
for more details.


ARDOP_Win TNC updates:

Mechanism (setting Busy Detect Threshold to 0) to allow operator
disabling of the busy detector. Note indication detector is disabled is
shown on TNC form in place of BUSY indicator.

Change in mechanism for IRS to END connection. Allows faster and
more robust ending when IRS initiates a DISC command. No change for ISS
mechanism which was OK.

Correct error in SearchFor2ToneLeader2 function that used incorrect
interpolation value for fine tuning (thanks John W)

Implement and test BUSYBLOCK mechanism for Server operation with 600 ms
timing window. Note ARDOP Chat does currently not enable BUSYBLOCK.
This would normally be used only in a Server (e.g. BBS) application to
avoid answering a Connect Request when the busy detector identified a
busy channel. ARDOP_Win TNC help now has a diagram of how this works.

Update ARDOP_Win TNC Help.


ARDOP Chat Updates:

Added mechanism (setup menu) for disabling Busy Detect by setting
Threshold to 0. This normally does not have to be used except in
emergency situation or very high local noise conditions.

Modified Busy Channel blocking mechansim (Beacon, FEC, ARQ Con Request)
to queue data on busy channel detection and indicate busy channel blocked.


As usual please report any serious problems. Use the debug log to
capture details when reporting complex issues.


73,

Rick KN6KB
7
Dyskusja ogólna / Odp: Alternatywne drogi przesylania poczty
« Ostatnia wiadomość wysłana przez SP2ONG dnia Październik 12, 2016, 06:50:13 »
A tu clip z lacznosci miedzy stacjami ktore uzywaja ARDOP Chat aplikacji ktora pozwala przeprowadzic typowa lacznosc z wymiana informacji miedzy stacjami.

https://www.youtube.com/watch?v=QHBRxtmBRjw&feature=youtu.be

ARDOP virtual TNC mzona wiec uzyc z aplikacja ARDOP Chat to lacznosci klawiatura <-> klawiatura oraz z systemami Winlink ktore uzywja ARDOP to transferu poczty miedzy uzytkownikami an serweramia CMS Winlink droga radiowa
8
Dyskusja ogólna / Odp: Alternatywne drogi przesylania poczty
« Ostatnia wiadomość wysłana przez SP2ONG dnia Październik 11, 2016, 13:41:23 »
Now wersja 0.8:

Cytuj
All,

Although the changes are modest this update causes an incompatibility
with prior versions as noted below. Please all switch to the new
version. Let me know if any serious difficulties. I have tested this
out pretty thoroughly but not over the air.

Major functional changes: (see ARDOP_Win TNC Revision History.pdf for
details)

Changes in minimal distance decoders making ACK/NAK and other control
and data frames decodeable down to about -12 dB S/N . Now control
frames have as good or better robustness as 25 baud nFSK data modes.

Change in ID frame from 2 RS error correction bytes to 4 (increased
robustness of ID frame)

Change in Con Req frames (total of 8) from 2 RS error correction bytes
to 4 (increased robustness in Con Req)

In Test mode (normally not user visible) can now select added Gaussian
noise from -20 to + 30 dB (used for testing) With this feature can
conduct back to back sound card ARQ connections with select able
Gaussian noise (0-3 KHz) on the same computer.

First pass optimization at new Gear shift algorithm (Gearshift_8) to
require:

a) 2 Consecutive ACKs AND have reported average received quality

    > shift threshold (a function of data mode) to shift UP to faster but

less robust mode.

b) 2 Consecutive NAKs will cause shift down to more reliable mode.

c) An ACK zeros out NAK count, a NAK zeros out ACK count.

Reduction of 1 dB in threshold for early leader detection. Squelch
values of 4 or 5 should be near optimum.


I will be heading back home to Florida tomorrow. Probably no new updates
until I get back Thursday unless someone finds a serious latent bug
before I leave!

I will post source for developers on the Developer web site.

73,

Rick KN6KB
9
Dyskusja ogólna / Odp: Alternatywne drogi przesylania poczty
« Ostatnia wiadomość wysłana przez SP2ONG dnia Październik 09, 2016, 11:01:09 »
Prace na rozwojem ADOP ostatnio mocno ruszyly i dosc sporo stacji mozna uslyszec na 14066 lub 7045 kHz. Kilka dni temu wyszal nowa wersja testow 0.7.2.2 :

Cytuj
Rick Muething

All,

This is a trial version to check out a new version of the Gearshift
algorithm (Gearshift_8). This has some simplification and other
mechanisms to what I hope will improve the gears shifting (summarized
below). I am still here in North Carolina and have no acccess to the
radios or HF simulator so I am unable to evaluate this over the air or
simulator but it does seem to work fine via a back to back audio
connection.

If you want to try this please do the following:

1) Take the current revision of the ARDOP_Win TNC and back it up.
(Rename to another name or put in a separate directory....this important
so you can go back to the other version if necessary)

2) Download ARDOP_Win TNC Trial 0.7.2.2 .zip from the users files area
on the reflector.

3) Unzip and save the resultant files (ARDOP_Win TNC.exe and Revision
history) back into your ARDOP Chat directory.


Here is a brief explanation of how the modified gear shift works:

1) Each mode for each bandwidth now carries a specific quality threshold
(0 to 100) used to shift up. (Before this was a constant). I determined
this threshold (usually between 70 and 90) using decoding threshold S:N
and Quality scores at THAT S:N. This all done using "Pink" Gaussian
noise channel (0 to 3 KHz) noise. If necessary we can easily tweak
these threshold values based on actual on-air experience.

2) A shift Up to a faster but less robust mode will now ONLY occur when:

a) Two successive ACKs are received by the ISS from the IRS. (note
missing an ACK altogether is not counted but a received NAK resets the
successive count back to 0).

AND

b) the average quality (as computed by received ACKs and NAKs at
the ISS) is greater than the mode specific threshold in 1) above. When
the shift occurs the new average quality is started over with the next
ACK or NAK.

3) A shift down to a slower but more robust mode will now occur when:

a) Two successive NAKs are received independent of average quality.
(again a missed ACK or NAK is not counted but a received ACK will reset
the successive NAK count)

I think this should minimize thrashing of modes yet still allow fully
automatic operation. Since the threshold shift point is now specific to
each mode we can easily adjust any specific switch point if needed.

This change won't affect compatibility with other versions but I am
working on some other changes in some frame type code assignments and
the minimal distance decoder that might. But first lets see if this
change offers any improvement.

73,

Rick KN6KB
10
Dyskusja ogólna / Odp: Wyklad o HamNET na zjezdzie w Burzeninie
« Ostatnia wiadomość wysłana przez SQ9IWE dnia Wrzesień 11, 2016, 09:17:42 »
Do ogarnięcia  8)
Strony: [1] 2 3 ... 10