FastClock

Allmäna diskussioner och information
Meddelande
Författare
Robban
Inlägg: 232
Blev medlem: 2014-01-18, 10:07

Re: FastClock

#51 Inlägg av Robban » 2014-04-08, 19:35

Efter att ha testat MR-Clock lite lätt i helgen undrar jag om det är möjligt att få den att fungera över blåtand på 2 androider?
Nu har vi ju haft turen att ha tillgång till WiFi där vi kört, men man vet aldrig var nästa träff blir (eller att man glömmer routern.......)

Robban

AndersB
Inlägg: 453
Blev medlem: 2012-05-09, 02:15

Re: FastClock

#52 Inlägg av AndersB » 2014-04-09, 08:58

Robban skrev:Efter att ha testat MR-Clock lite lätt i helgen undrar jag om det är möjligt att få den att fungera över blåtand på 2 androider?
Nu har vi ju haft turen att ha tillgång till WiFi där vi kört, men man vet aldrig var nästa träff blir (eller att man glömmer routern.......)

Robban
Jag har fört frågan/önskemålet vidare till programmeraren.

En variant är om telefonerna har "wifi-hotspot". Lite klurigt dock - vi fick det att fungera endast då klockservern kördes på den telefon som INTE var hotspot OCH bara då vi använde ip-adress (alltså inte multicast).

mvh/anders

Användarvisningsbild
FredrikB
Inlägg: 134
Blev medlem: 2012-05-09, 02:16
Ort: Drammen, Norge

Re: FastClock

#53 Inlägg av FredrikB » 2014-05-05, 12:52

daniel skrev:Här är källkoden till DBFastClock om du har någon nytta av det. Koden för multicast ligger i filen "src/dbfastclock/MulticastClient.java".
Råkade av en tillfällighet se att denna klient kollar att den rad som tidigare användes för version 1 av protokollet nu skall innehålla texten "fastclock" och inget annat för meddelanden som tas emot över UDP.

Finns det några krav på vilken information en server med stöd för både version 1 och 2 måste presentera i version 2-delen av meddelanden som går på TCP? Skall alla version 2-servrar presentera en fullständig bild i version 2-delen av meddelandet?

Körs det fortfarande version 1-servrar över huvud taget?

Mvh

Fredrik, på god väg.

Användarvisningsbild
daniel
Inlägg: 2961
Blev medlem: 2012-05-08, 10:15

Re: FastClock

#54 Inlägg av daniel » 2014-05-05, 18:44

DBFastClock funkar så att jag börjar med att ge variablerna förvalda värden och sedan tolkar jag meddelandet som kommer. Om vissa data uteblir så används de förvalda värdena. Å andra sidan så finns ju både klock-typ, dag, timme, minut och hastighet med i version_1-meddelandet, så det kommer ju alltid med, även om hastighet då saknar decimaler. Jag har byggt DBFastClock så att alla värden i version 2 av protokollet är frivilliga. Protokollet är ju utbyggbart, dvs om servern skickar saker som klienten inte förstår så ska klienten bara bortse från det. Och därför är det nog lämpligt att klienten även ska klara av en server som bara skickar begränsat urval av parametrar.

Att första raden i multicast-meddelandena nu har "fastclock" beror på att vi inte längre "äger" förbindelsen. Om det är någon tredje part som råkar använda samma multicast-adress och port som vi gör så är det bra att våra program inte försöker tolka den felaktiga informationen. Så därför kollar jag först att första raden är exakt "fastclock" innan jag försöker tolka resten av meddelandet.

Servrar som kör enbart version 1 används nog inte längre. Däremot är det inte otänkbart med klienter som bara kör version 1. Det finns numera t ex WiFi-kort till Arduino så man skulle kunna tänka sig en klient i en Arduino-dator.

Jag har för mig att AndersB uppdaterade protokollet så att "day" ska vara ett veckonummer och inte en textsträng, men jag tror inte jag har sett en uppdaterad server än. Men jag kan ha missat det. Men Anders får svara på det.

Med vänlig hälsning
Daniel
Ordförande i ModulSyd

AndersB
Inlägg: 453
Blev medlem: 2012-05-09, 02:15

Re: FastClock

#55 Inlägg av AndersB » 2014-05-06, 08:32

Har precis suttit och försökt formulera protokollspecen på engelska efter önskemål från fremofolk i tyskland.
Utgick dels från ett dokument som Daniel skrivit och dels av vad senaste servern spottar ur sig. Såg då att det är en mismatch just på "day/weekday" som vi inte rett ut än. Det är weekday i senaste servern medan det står day i det dokument jag kikade på. Måste utreda lite mer kring "day/weekday".

Det här är vad jag fick ihop:
----------------------------

There are two ways for the client to communicate with the server.
1) Listen to multicast messages with all information from the server.
2) A client, that can not use Multicast, can contact the server through tcp/ip.

Tcp/ip can also be used by more specialized clients, that require two-way communication, see "level 3".

A complete server should provide both multicast messages and tcp/ip level 1 and 2.
Level 3 is under development.

The messages are text based coded with UTF-8.
TCP/IP
"Level 1" was the first implementation and was one line of info. A client can still use just "level 1" which is the first line of communication.
"Level 2" is for normal clock clients.
"Level 3" is more for remote control of the clock (i.e. the game leader could control the clock server from an app on his own telephone, etc.)
Level 3 is under development and not covered here.

The client contact the server on a address/port, receives a message and then disconnects.

The first line in the message is the level 1 part. The oldest clients only reads this line and then disconnects.
---
First line - Level 1
<is_active> <hour> <min> <speed>

Example: 0 08 45 5

<is_active>: 0 = clock stopped, 1 = clock runs
<hour>: Hour, two digits
<min>: Minute, two digits
<speed>: Speed, one or two digits

Between each , ascii-tecken 32.
---
Following lines - Level 2
Each line consist of a key=value
The keys can come in random order.
Not all keys have to be present, depends on the version of the server.
A key that the client does not recognise is just ignored.

Example (first line is for level 1):
1 19 3 5
text=Lunch to 13.00
clocktype=fastclock
active=yes
speed=5
clock=19:03:25
weekday=none
version=3


Keys:

clocktype=fastclock|realclock

Shows if "clock" is model time(fastclock) or real time (realclock).

clock=<hour>:<min>:<sec>

The time that clients should use. All values are 2 digits, 24 hour format.

active=yes|no

Show the status for the clock, if it is running or is stopped. For "realclock" this is ignored.
For ”realclock” this should be ignored.

weekday=none|0|1|2|3|4|5|6|7

Day of week. When value is 0 or none, day of week is not used.
Value 1 is monday.

speed=<speed>

Speed for clock. <speed> Speed is a value between 0.1 och 99.9. Dot between integer and fractions. For "realclock" this is ignored.

text=<message>

Text message that can be shown on the client. If <message> is empty the previous message should be removed.

version=<version number>

Version number for the protocol level that is supported.

----------------------------
Multicast messages

Multicast group 239.50.50.20:2000

The first line in the message is always "fastclock".
The following lines are key=value in the same manner as with the Tcp/ip protocol level 2.
The keys can come in random order.
Not all keys have to be present, depends on the version of the server.
A key that the client does not recognise is just ignored.

Example:
fastclock
version=2
name=DT-14
ip-address=192.168.8.26
ip-port=2500
text=Lunch until 14:00
clocktype=fastclock
active=yes
speed=5
clock=10:32:35
weekday=none
interval=2



clocktype, clock, active, weekday, speed, text, version is the same as in the tcp/ip-messages.

name=<clockname>

Name of the current setup. We often run H0 and N in the same hall. To distinguish two clocks in the same network, a clock could be named, e.g. "N-RE Prauge".

ip-address=<ipnumber>

IP number to the clock server. Used for clients that need to contact the server on "level 3".

ip-port=<portnumber>

Port number to the clock server. Used for clients that need to contact the server on "level 3".

interval=<seconds>

The interval between two messages. Used by clients that wants to show when they have lost contact with the server.
Note the this interval can change during a session. E.g. there can be a longer interval when the clock is stopped or when "real time" is used.

--------------------------------------------------------------------------------

AndersB
Inlägg: 453
Blev medlem: 2012-05-09, 02:15

Re: FastClock

#56 Inlägg av AndersB » 2014-05-06, 08:55

Som Daniel skrev:
Klienterna skall inte förutsätta att enskilda parametrar finns med. Enskilda parametrar har kommit till efterhand som vi utvecklat protokollet, så beroende på server och serverversion så variera det vilka parametrar som finns med.

Vad gäller day/weekday (vilket det nu ska vara) så är det inte implementerat i någon (känd) server.
"mrclockserver" skickar med parametern med värdet "none". Kommer dock att lägga in dagen (1-7, 1=måndag) när som helst...
En vanlig klockklient är nog inte så intresserad av parametern för dag och använder den förmodligen inte. Däremot kan den vara viktig för t.ex. ett system för tåganmälan där tidtabeller förmodligen är dagberoende.

mvh/anders

Användarvisningsbild
FredrikB
Inlägg: 134
Blev medlem: 2012-05-09, 02:16
Ort: Drammen, Norge

Re: FastClock

#57 Inlägg av FredrikB » 2014-05-06, 11:11

Tackar för specifikationen, den benade ut en del oklarheter.

Posta gärna här när ni bestämt om det är "day" eller "weekday" som gäller, eller om protokollet ändras på något annat vis.

Mvh

Fredrik

Användarvisningsbild
FredrikB
Inlägg: 134
Blev medlem: 2012-05-09, 02:16
Ort: Drammen, Norge

Re: FastClock

#58 Inlägg av FredrikB » 2014-05-06, 11:25

En grej till... skulle vi kunna spika namnet på protokollet nu när det finns en skriftlig spec? Alla klienter kan ju inte heta "mrclock", så jag måste kunna skriva Något Bra i beskrivningen av appen så att folk hittar den när de söker efter den i App Store (när den dagen kommer).

Mvh

Fredrik

Användarvisningsbild
daniel
Inlägg: 2961
Blev medlem: 2012-05-08, 10:15

Re: FastClock

#59 Inlägg av daniel » 2014-05-06, 17:29

Det finns ett fel i översättningen:
Between each , ascii-tecken 32.
Denna bör vara:
Between each value is ascii character 32 (the space character).

Jag föreslår att vi ändrar till "day" och låter 0 <= day <= 7. Dvs att "none" tas bort helt. Det underlättar om en parameter antingen är text eller tal. Har man text så måste man ha en "switch"-sats för att tolka värdet, men är det ett tal slipper man det. Ändrar vi parametern till "day" istället för "weekday" så bryter vi inte mot protokollet.

Med vänlig hälsning
Daniel
Ordförande i ModulSyd

Användarvisningsbild
FreddePettersson
Inlägg: 666
Blev medlem: 2012-05-09, 02:16
Ort: Värnamo

Re: FastClock

#60 Inlägg av FreddePettersson » 2014-11-29, 18:41

Skulle testa/ visa danskarna i Kolding i höstas, försökt få igång allt på en Win7 maskin.
Nu är jag inte hemma på Win7 , men det blev lite bekymmer här och där.

Jag ringde AndersB och försökte få igång det hela på en stand alone PC .

Har någon möjlighet att testa i Win7?

/fredde
Medlem i Värnamo Modelljärnvägsförening
Medlem i FREMO
Medlem i ModulSyd

Bygger modelljärnväg i modulform:
Byggtrådar:
Kristineberg Lastplats område

Skriv svar

Återgå till "Allmänt"

Vilka är online

Användare som besöker denna kategori: 3 och 0 gäster