d-star en Condors C16/46

[Remco]

A priori: ik weet (nagenoeg) niks van d-star.

Naar aanleiding van mijn herschrijven/aanpassen van de OZA-software sprak
iemand mij gisteren tijdens de clubbijeenkomst aan inzake gebruik van
d-star in combinatie Condors C16/46.

Wat bleek: Condors C16/46 zouden 'niet geschikt zijn' voor d-star vanwege
de tx-timeout van 30 seconden. Er zouden al volksstammen bezig zijn geweest
met 'het geschikt maken van deze Condors voor d-star', maar tot op heden,
aldus de vragensteller, zonder 'resultaat'.

Ik was enigszins verbaasd om te vernemen dat het de Nederlandse Condor 'peek & poke'
guru's -die nieuwe 'releases' openbaren- niet was gelukt om dit zeer eenvoudige issue
op te lossen. Of dit ook zo is, verneem ik hier graag ;- )

Van wat ik gisterenavond begrepen heb, schijnt het wel zo te zijn dat er sprake is van een
(optionele) 'wurger' in d-star repeaters en hot spots.
Deze wurger zou na drie minuten in werking gaan.

Mij werd verteld dat de gebruiker zelf niets merkt van de tijdslimiet, in die zin, hij wordt
tijdens het zenden niet vooraf geinformeerd dat zijn tijdslimiet in aantocht is.
Het gevolg zou zijn, van wat ik heb begrepen, is dat vele gateways a.g.v. doorgangtimeout
uitschakelen en dat de gebruiker tijdens zijn (te lange?) doorgang daar niet van op de hoogte
is/wordt gebracht. 'Deze optie' zou niet in de 'Icom apparatuur' zitten, aldus de aanspreker.

Ik vond dit nogal een rigoreus effect en vroeg hem of er hier dan geen protocollen/standaarden
voor waren. Het is me gisterenavond uit het gesprek niet helder geworden of er inzake d-star
en watchdogs een standaard/protocol is en googlen leverde me niet veel informatie op, anders
dan dat er gatewaysoftware is waar een wurgeroptie inzit.

De volgende optie heb ik als experiment (voor de persoon die mij aansprak) ingeprogrammeerd:

In 'de packet mode' is de watchdog timer ingesteld op ~180 seconden.
Vanaf vijf seconden vóór het aflopen van de watchdog wordt de gebruiker per seconde middels
een piepje geinformeerd dat de watchdog in aantocht is.

Na aflopen van de watchdog schakelt de zender uit, maar de set blijft (vooralsnog) in TX-mode
hangen totdat de PTT is losgelaten.

Is dit handig? Moet het anders?
B.v. 10 seconden vooraf gewaarschuwd worden voor de watchdog?
Moet de set -met nog actieve PTT- op ontvangst gaan na aflopen van de watchdogtimer?


Remco PA3FYM

[PA3BAS]

Voorzover ik weet is die TOT een optie die je aan of uit kan zetten in de software. Ik heb in gewoon gebruik in ieder geval niets gemerkt van een time-out-timer. En ik ben regelmatig over die limiet heengegaan....

Voor de goede orde, dit is in spraak allemaal.

[Remco]

OK, zit dus in de software.

Maar er is dus geen 'meer hardwarematige' aanpak in de zender zelf?

In die zin, wanneer b.v. je PC crasht dat dan de zender aan kan blijven?

[PA2LAD]

OK, zit dus in de software.

Maar er is dus geen 'meer hardwarematige' aanpak in de zender zelf?

In die zin, wanneer b.v. je PC crasht dat dan de zender aan kan blijven?

Als je set zelf een begrenzing heeft op 4 minuten = 240 seconden kan je vrijwel altijd hiermee uit de voeten. Daarmee voorkom je dat een sluiting in de bedrading of zendschakelaar je zender dagenlang in de lucht houdt. Een standaard condor kan ook nog wel eens spontaan in de noodoproepmodus springen. Staat hij ook te zenden om de 20-30 seconden zonder dat je aan de buitenkant iets kan zien. Let daar op.

[Remco]

@PA2LAD:

Ik weet niet wat een 'standaard Condor' is, maar als ik het schema bekijk,
kan ik niet begrijpen waarom dit apparaat 'spontaan' in de noodoproepmodus
zou kunnen springen en dan om de 20-30 seconden staat te zenden
zonder dat je iets kan zien. Hiervoor moet je 'moeite' doen én er moet firmware zijn
die deze moeite 'beloont'.

Op de processorprint:
1. Pin 14 van J13 (P71) is actief laag, dus default hoog. Hierdoor komt V1 in geleiding
waardoor de 78L05 geen ingangsspanning krijgt en er dus ook geen spanning
op de uitgang staat die de processor (via diode en 10k naar pin40) zou kunnen voeden.
2. Aan de uitgang van de 78L05 hangt een PNP-tor (V3) die, zoals hij geschakeld is, P26
van de processor (pin 37) hoog of laag kan schakelen.

Op de 'Sender'print:
3. Zit een crowbar mbv een thyristor (V9) en een integrator.
De crowbar schakelt in wanneer er een positieve puls op
'Not' (Duits voor 'Nood' ;; -) komt, waarmee wat logica richting de eindtrap wordt geschakeld.

Gezien 1. moet actief vanuit de software J13/P71 laag gemaakt worden om zo 'Not' hoog te maken
en de 78L05 van ingangsspanning te voorzien, de crowbar zijn werk te laten doen etc.

Gezien 2. moet de software P26 pollen om deze gecreëerde situatie tenminste te kunnen detecteren/bevestigen.

Gezien 3. moeten glitches etc. zijn onderdrukt i.v.m. de tijdsconstante van de integrator. Een vlugge
kijk, levert t = RC = 470k * 1 uF = ~0.47 seconden als tijdsconstante.
Dat is wel een heel lange glitch en kan geen 'spontaniteit' of toeval zijn.

M.a.w. op basis van het bovenstaande concludeer ik dat de 'noodmodus' een software optie is.

In de source die ik gebruik, zie ik geen 'actieve' verwijzing naar J13/P71, noch naar P26 van de processor.

[pa5cal]

kijk hier voor een deel van de spec van d-star:

http://www.jarl.com/d-star/shogen.pdf

[pe1hzg]

Er zit geen hardware watchdogvoorziening in de Condor 16/46. Ik weet dat de originele firmware dit wel heeft, en ik weet niet wat de OZA software doet; mijn Condors draaien code die ik zelf gemaakt heb uit het reverse-engineeren van een Condor (da's alweer 20 jaar geleden dat ik dat gemaakt heb).
Van de OZA software is de broncode inmiddels beschikbaar dus als je apparaat die code gebruikt dan lijkt me het verwijderen van deze timer vrij eenvoudig.

In de originele software had dit ook een belangrijke toepassing: als de microfoon een keer klem komt en de zendsleutel vast komt te zitten, is het kanaal na 30 seconden weer vrij.
Zo af en toe gaat dat mis ook bij amateurapparatuur, ik zou willen dat ieder zo iets heeft, soms blijft zo'n carrier dagen staan!

Er zijn wel andere problemen. De koeling van de eindtrap is onvoldoende behalve voor hele lage duty-cycles, dus alleen af en toe, korte, uitzendingen met veel lange pauzes waarin de boel weer af kan koelen. Omdat er bij D-star vaak gekoppeld wordt met dingen waar de hele dag QSO's lopen, zou de zender dan ook permanent aanstaan. Dat overleeft een Condor alleen op laag vermogen, en zelfs dan wordt het veel te heet allemaal.

Als je dus een toepassing hebt met lange uitzendingen zou ik een apparaat pakken wat mechanisch heel anders opgebouwd is. Ik bouw zo iets alleen met apparatuur die zo gemaakt is dat het 24 uur aan kan staan zonder dat het warmer als handwarm wordt; als het spul warmer wordt, uitzet, en krimpt, gaan er allerlei dingen stuk vanwege thermische veroudering. In de packet-BBS tijd hebben we zo heel wat transceivers letterlijk versleten..

Ik zie niet wat lange uitzendingen met D-star te maken hebben, maar bij lange uitzendingen is de Condor een ongelukkige keuze.

Ik heb een foto gemaakt van de zender van PI7CWE. Dat ding is 3x per dag 30 minuten in de lucht (morsecursus) en bovendien is het een van de zenders van PI4AA en dat zijn ook uitzendingen van minimaal 30 minuten (de PI8CWG-poort is nu voor PI4AA, de foto is ouder). De kast zijn 2 eurokaart-rekken op elkaar gemaakt; het grote koelblok linksonder is de koeling voor de eindtrap (zo'n 8W uit op dit moment).

Geert Jan

[PA0ETE]

De condor's die problematisch warm worden, zijn vaak condor's die oorspronkelijk niet nabij een amateurband gewerkt hebben. Omdat ze relatief ver moeten worden omgetrokken loopt het rendement kennelijk nogal terug. Ik heb er twee gehad, bij eentje was de temperatuur niet geschikt voor een repeater. Bij een tweede, die exact hetzelfde uitgangsvermogen gaf viel de warmte-ontwikkeling reuze mee.

@remco: we hadden het hier gisteren over, maar ik had de topic ook daarvoor wel gelezen hoor Ik heb momenteel vaak geen tijd om hier te reageren, maar ik lees veel dingen wel geïnteresseerd mee.

[Remco]

@John: klopt ;- )

Ik vroeg me gewoon af of er een protocol was, even onafhankelijk van (de geschiktheid van) de hardware.

Maar, ik begrijp dat de boel, zoals ik 't had geprogrammeerd, werkbaar is.
De enige suggestie die hier vandaan kwam, was om 't 240 ipv 180 seconden te laten zijn.

Het 'waarschuwen voor naderende 'hardware watchdog' wordt door anderen als zinvol ervaren.

Ik wacht de feedback van degene voor wie ik de boel heb veranderd wel af.