Nu de hardware blijkt te werken wordt het tijd om de schotel automatisch te laten sturen door een programma.
Uiteindelijk, en als eerste toepassing, zou ik de maan willen volgen .Echter ik heb nog geen gepaste software daar voor gevonden , ttz ik heb er één maar dit moet nog uitgebreid uitgetest worden .
Neen , het is simpelder om eerst een bekend werkend programma te gebruiken en kijken of ik een satteliet of bv het ISS kan tracken weliswaar in mijn bereik van de zuiderlijke hemisfeer.
Hoe het één en ander aan elkaar moet geknoopt worden heb ik in een blokschema gezet.
Het was lange tijd zoeken hoe nu Gpredict zich gedroeg.
Was het nu een server of een client ? Wat was het protocol en moest ik nu HAMlib gebruiken of niet ?
Door wat te snuisteren op Github in de sourcen van Gpredict kwam ik erachter dat het een clientmodel was en dat deze de letter commando's van Hamlib nabootste maar dat Hamlib niet echt nodig was .
Gpredict gebruikt wel de standaardpoort van Hamlib zijnde 4533 en het protocol is TCP/IP
Hamlib KAN je gebruiken als je een interface wilt tussen een bekende rotor ( bv ene van Yaesu) en de bestaande controller ervan , maar daar ik hier alles zelf heb samengestoken , doe wat ik wil.
Ik moet nu een server socket schrijven op de RPI en luisteren op inkomende clientaanvragen , in dit geval enkel en alleen van Gpredict.
Eénmaal de connectie tot stand gekomen ( wordt allemaal afgehandeld door de socket) kan ik in mijn eigen RPI soft de letter commando's verwerken en antwoorden sturen naar Gpredict.
De eerste testen zijn al gebeurd en na wat zoekwerk hoe nu juist die lettercommando's moesten doorgestuurd worden zijn deze premature testen veelbelovend.
Volgende keer , de instellingen langs de Gpredict kant en over de firewall.
Interessant
BeantwoordenVerwijderen