score software middels App; sorgV4

Je kunt met PHP ook de SQL database uitlezen en scores berekenen. Dan heb je geen XLS nodig. Hoe minder componenten hoe beter, lijkt me. Excel is in mijn ogen onnodig (en ongewenst)
Via PHP kun je ook zorgen dat de App data in de SQL database kan schrijven.

Ik kan je daar niet mee helpen (want: geen PHP kennis) maar er zijn best veel PHP hobby-programmeurs.

 

Automatische score verwerking

Dag allemaal,

Bij Soarist in Turkije hebben ze een perfect werkende omgeving.
Deze wordt jaarlijks gebruikt voor F3J en heeft zijn goede werking bewezen op EK en WK F3J.
Dit systeem werkt via WIFI op het terrein.
Serdar Sualp kan gecontacteerd worden via ssualp@soarist.com

Gunther

 

Small update:
* opzetten van een SQL database blijkt een fluitje van een cent: aan de hand van een voorbeeld database.sql alle gewenste tabellen definieren (en je bepaalt zelf welke info je wil opslaan - voor het editen gebruik trouwens de uitstekende freeware Notepad++). Vervolgens naar myPHPadmin, nieuwe database aanmaken en importeren van de F3J_database.sql
* de SORG RSE (RemoteScoreEntry) app had ik al reverse-engineered naar leesbare code. Ik ben er gedeeltelijk achter hoe de app de data naar de database stuurt: er wordt een commando gestuurd dat op de server het rsein.php script aanroept om data in de database in te voegen. Alleen heb ik de parameters nog niet goed. Komend weekend krijg ik dat vermoedelijk voor mekaar en dan heb ik eindelijk het samenspel app/database voor mekaar.

@Wubbe: F3J score software legacy is xls. In 2013 heb ik die software grondig onder handen genomen en alle F3J spelregels en berekeningen in VBA gegoten (achteraf naar volle tevredenheid). Het kan idd ook met PHP maar dan moet ik alle forms & berekeningen volledig opnieuw maken. Dus blijk ik liever bij mijn xls interface. (is vooral een kwestie van waar de (hobby)programmeur best mee uit de voeten kan).

@Gunther: vermoedelijk gebruiken ze SORG of Gliderscore.
Een belangrijk bezwaar van deze kant-en-klare pakketten is IMHO dat ze gesloten zijn: je kunt niet in de code kijken wat er precies gebeurt/hoe resultaten berekend zijn, laat staan dat je het kunt aanpassen aan lokale regels. Een ander bezwaar is dat de SW zonder serieuze user manual komt: het heeft me nu flink wat tijd gekost om uit te vissen hoe ik SORG op een lokale laptop/hotspot kan laten draaien.
Mijn streven is dat ik alles middels free Open Source software & leesbare code voor mekaar krijg zonder enige dll/.exe etc. Of ik de tijd vind om het te documenteren is dan wel weer een open punt.

 

Deze avond hou ik me ff bezig met de database structuur: wat voor tabellen wil ik allemaal in de SQL database? Met F3J als uitgangspunt:

NK_contest_list: lijst van alle wedstrijden in de database

• contest_ID
• contest_name
• contest_type
• no_of_pilots
• multilanguage (SORG optie - voor het geval dit tzt internationaal gaat. Ik hou 'm nog even aan)
• no_of_teams
• description

NK_contest_type: lijst van ondersteunde wedstrijdtypes
te beginnen met F3J, maar ik vul alvast F3B, F3K, F3F en F5F in

Pilot_list: lijst met data van de piloten:

• (KNVvL) licentie
• voornaam
• familienaam
• geboortedatum (kwestie van juniors te identificeren?)
• frequentie
• kanaal1 (35MHz)
• kanaal2 (35MHz)
• voorkeurskanaal (35MHz)
• checked
• land

RSE input (data van de app naar de database)

• contest_ID
• ronde
• groep
• startplek of piloot naam (alternatief: ID piloot uitlezen via QR code)
• vliegtijd
  • minuten
  • secondes
• landingsscore (alternatief: QR code uitlezen van landingtape)
• F5J: hoogte

 

Database ontwerp

Een eerste reactie

NK_contest_list

Ik mis:

• discipline (F3K, F3B, etc.)
• Locatie Lat/Long
• Datum

Het aantal piloten hoef je niet in te vullen, Je weet welke piloot aan een contest meedoet (contest_id is ingevuld). Dan kun je heel eenvoudig bepalen hoe veel piloten aan een wedstrijd meedoen.

Ik zou zelf een tussentabel maken (Deelname) die piloten en contests koppelt. Dan kunnen piloten aan meerdere contests gekoppeld worden omdat ze van tevoren inschrijven. Later kun je dan ook de uitslag nog opvragen.

Pilot_list

Wat is 'checked'?

RSE input

Ik mis:

• strafpunten
• aantal laps (F3B afstand)
• score in punten (in ronde)

Ik zou van ronde een aparte tabel maken. Een wedstrijd bestaat uit meerdere rondes en piloten kunnen aan meerdere rondes meedoen (en een ronde bestaat uit meerdere vluchten). Op deze manier kun je van tevoren de indeling in rondes maken.

(Ik kan er ook niets aan doen. Dit is mijn werk :teacher

 

THX voor het meedenken Wubbe!

NK_contest_list: lijst van alle wedstrijden in de database

• contest_ID
• contest_name
• contest_date
• contest_location
• contest_type (=discipline)
• no_of_pilots
• multilanguage (SORG optie - voor het geval dit tzt internationaal gaat. Ik hou 'm nog even aan)
• no_of_teams
• description

Pilot list: checked = aanmelding bevestigd (o.a. inschrijvingsgeld )

RSE input:

• strafpunten: er moet ongetwijfeld een veld komen voor penalties, maar ik heb op dit moment nog geen idee hoe ik dit best vorm kan/zal geven. Het liefst heb ik een keuzelijst, maar die moet dan wel in de app verwerkt worden.
• aantal laps (f3b): ik richt me nu ff op f3j (/f5j), ik ga tzt het meertaken reglement nalezen om te zien hoe dit in te passen is
• score: de RSE app (en database) bewaren in principe alleen de ruwe vliegresultaten. Het is de bedoeling dat de xls de uiteindelijke scores doorrekent.

In principe heb ik aan de NK_contest_list, pilot_list en RSE_input genoeg om middels xls een wedstrijd door te rekenen. In xls komt dan de wedstrijdindeling te staan en wordt de uiteindelijke score berekening gedaan (de xls doet een query op de SQL database om de ruwe resultaten binnen te halen en berekent vervolgens de groepsscore en verdere scores - geinteresseerden kunnen een copietje krijgen om alvast even in te kijken hoe dit geprogammeerd is)

 

Aha, de indeling, inschrijving en dergelijke wordt in XLS geregeld. Ook goed.
Vreemd dat dan toch in de pilot-tabel opgenomen wordt dat de piloot betaald heeft. Toch?