schließe mich guyabano an. selbst wenn ich wahrscheinlich nicht alles verstehen werde, würd ich da gerne mal drin rumstöbern
Hallo Ihr beiden und @all,
hatte ich doch oben geschrieben:
Den Hersteller muss ich doch nicht extra noch auffuehren 
Gruss Torro
Hallo Torro,
vielen Dank für den Hinweis auf die Seite der Original-Software.
Ich habe dort (beim Original-Hersteller) die Beschreibung einer DLL für die Schnittstelle zur FHZ gefunden.
Dabei bin ich auf drei sehr bemerkenswerte Hinweise gestoßen:
-
Du hast Recht!
Die FHZ enthält tatsächlich ein Register, das ausschließlich für den Zeitabgleich mit den FHTs zuständig ist. Da die FHZ keine eigene Uhr hat, muss dieses Register mit einer dafür vorgesehenen Funktion mindestens einmal pro Minute aktualisiert werden. Daraus folgt, dass die Uhr der FHTs im Mittel auf eine halbe Minute genau geht (vorausgesetzt der Abgleich hat funktioniert). -
In dem Dokument ist auch der berüchtigte RequestData-Befehl beschrieben.
Es wird darauf hingewiesen, dass dieser Befehl nur nach einem Neustart sinnvoll ist, um schnell an die Daten zu gelangen. Aber es heißt auch, dass der Befehl nicht zu oft verwendet werden sollte, da er länger dauert und sogar die Kommunikation behindern kann. -
Es gibt offensichtlich eine Begrenzung der Sendekapazität (!!)
Um die laut Standard vorgeschriebe 1% Sendezeit zu überwachen gibt es ein Register, das darüber Buch führt. Die FHZ stellt den Sendebetrieb ein, wenn das Kontingent verbraucht ist. Erst nach Ablauf einer Stunde steht wieder die volle Kapazität bereit. Die DLL stellt eine Funktion zur Verfügung, mit der man einmalig das Register rücksetzen kann, um z.B. die noch anstehenden Befehle zu versenden. Die Funktion kann danach frühestens nach 35 Minuten wieder aufgerufen werden.
Aus der Beschreibung geht jedoch nicht eindeutig hervor ob diese Beschränkung in der FHZ oder in der DLL verankert ist.
IPS verwendet ja eine eigene DLL. In dieser ist keine der drei Funktionen (korrekt) implementiert.
Punkt 1 wäre sehr wünschenswert;
Punkt 2 ist wohl nach wie vor eher verzichtbar;
Punkt 3 dagegen birgt unter Umständen versteckte Fallstricke. Hier muss paresy überprüfen, ob eventuell tatsächlich eine Zwangsabschaltung stattfindet.
Gruß
HJH
Mit der Begrenzung hat dummerweise irgendein Gesetztgeber was zu tun 
Nunja, ich kann aber aus eigener Erfahrung aus der Anfangszeit mit IPS sagen, dass diese Begrenzung funktioniert - ein wildgewordenes Timerscript hatte damals meine FHZ über Gebühr strapaziert, bis diese für eine geraume Zeit nicht mehr willig war zu senden…
Ja, es hat mit der 1%-Richtlinie im 868 MHz zu tun. Das Modul darf nur auf 24h während 864 Sekunden lang senden, was bei einem Durchschnitt von 5 Sekunden (mal grob geschätzt) dennoch 172 Meldungen ausmachen. Naja, das ist eigentlich schon grosszügig, soviel FHT’s hat von uns keiner. Es gbt bei der HomeStud*o Software auch einen Befehl, mit dem man das Quota zurücksetzen kann und dann das limit überschreiten kann. Aber man kann das nur einmal alle 24 Stunden machen, glaub ich. Da passt die Software schon auf, sonst gibt es eine Fehlermeldung.
Sowieso, ich bin definitif zur Erkenntnis gekommen, das bei 11 FHT’s schon alleine mit einer FHZ es nicht mehr geht.
Sobald Paresy die WLAN Variante der FHZ am Laufen hat, werde ich deren 2 nachkaufen, und dann die Meldungen aufteilen.
mfG Franz
In der Tat muss man für die Zeitsynchronisation der FHZ PC jede Minute deren Register aktualisieren, sie hat keine Uhr und verwirft die Zeit, wenn die Aktualisierung nicht erfolgt.
Datenmäßig geht die Zeitsynchronisation auf FTD2xx-Ebene so:
SB LL TE BC cc cc cc YY MM DD HH MM
81 0A C9 BF 02 01 61 06 03 04 16 38
SB: Start Byte
LL: Length (es folgen 10 bytes)
TE: Telegramm Type
BC: BlockCheck (einfache Byte-Summe, hängt natürlich von der Uhrzeit ab, BF ist nur hier richtig)
cc: command data
YY: Jahr (zweistellig)
MM: Monat
DD: Tag
HH: Stunden
MM: Minuten
Beispiel also: 4.3.2006 16:38
Die FTD2xx.dll ist dokumentiert. Device suchen, öffnen und mit FT_Write die Daten schreiben, wenn es gar nicht anders geht. Infos zu den Kommandoformaten kann man sich auch ergoogeln mit „FHZ1000 protocol“ als Suchwort.
[EDIT]
Idealerweise würde die das FTDI Modul die Aktualisierung der Zeit jede Minute vornehmen. Nicht synchrone FHTs will ja wohl keiner. Eine API, sprich PHP Kommando braucht es dafür nicht.
[END EDIT]
Cheers, starfarer
Ich wage mal vorsichtig zu behaupten, dass hiermit auch dieses Geheimnis gelüft sein dürfte.
Paresy, ran an die Bouletten ! …nachdem er aber seinen Sonnenbrand am Bondi-Beach gefangen hat !
Hey, wie geheim sind diese Geheimnisse denn? Guckstu hier.
[URL=„FHZ 1000 for Linux : FHZ1000 Protocol“]
Aber davon abgesehen, wer’s wirklich wissen will, schreibt eine kleine DLL, die die gesamte API der FTD2xx.dll implementiert, alle Funktionsaufrufe brav in ein Log schreibt und dann mit den gleichen Parametern die originale API aufruft.
Dazu verschiebt man die originale DLL irgendwohin, tut die neue ins System32 Verzeichnis (oder dahin, wo immer die bei Euch rumfliegt).
Danach in die Steuerungssoftware starten, und der Reihe nach sämtliche Funktionen mal anklicken. Schon weißt Du, welche Bytes fliegen.
Das zusammen mit ein bisschen Interpretationshilfe von Sites wie oben…
Cheers, starfarer
… wenn mich nicht alles täuscht, machen die Funktionen, um die Zeitcounter für 868 MHz Sendungen zurückzusetzen, konkret nix. Auch nicht alle 35 Minuten. Sie greifen zumindest nicht auf das FHZ Device zu (1300 PC).
Desgleichen FHZ_SetHC1 und FHZ_SetHC2. Die machen auch nix. Zumindest nicht am USB-Device. Das sind Funktionen der FHZ1000.dll, die man bei Cxxxs bekommen kann.
Noch ein paar Geheimnisse weniger… Oder mehr… Das liegt im Auge des Betrachters. 
Cheers, starfarer
Hallo starfarer,
das ist aber nicht das Problem. Das Thema hier sind die Beschraenkungen im Funkverkehr, die eingehalten werden muessen. Das dies dort durch die DLL gemacht wird, ist eine Loesung. Die andere ist, einfach den Durchsatz der Befehle hardwaretechnisch einzuschraenken. Wurde diese bei der FHZ1xxxx gemacht? Ich glaube, dass kann keiner von uns sagen.
Entscheidend ist aber, dass wir uns ueber die Beschraenkungen im Funkverkehr nicht hinwegsetzen koennen, dies waere aus meiner Sicht rechtlich sehr problematisch.
Gruss Torro
… könnte man schon, ob das Device hardwaremäßig das Senden beschränkt. Dázu müsste man es nur kontinuierlich senden lassen und schauen, ob es irgendwann aufhört. Das LED leuchtet nur bei Funktraffic. Bei anderen Transfers von Daten an das Device bleibt die LED aus. Man kann das also schön sehen.
Es wäre aber ein Scherz, wenn die Beschränkung der Sendezeit durch die Software erfolgen würde. Wenn’s Beschränkungen für solche Devices gibt, sollte Umgehung schon gerätemäßig unmöglich gemacht werden. Ich bin mir nicht sicher, dass viele von Jungs hier mit den 23 FHTs oder was lieber ein paar davon abschalten als versehentlich ein Sekündchen zu lang zu senden.
Wenn das wirklich von der Software abhängen sollte, dann hat IPS vermutlich keine Sendezeitbeschränkung. Oder sie ist da auch softwaremäßig realisiert. Auf alle Fälle funken dann die Jungs mit Ihrer selbstgebastelten Linux-Variante ohne Limit.
Ich denke mal, das mit den Limitierungen im Funkverkehr ist, wenn das von der Software abhängt, so ähnlich wie mit den Limitierungen der Geschwindigkeit im Straßenverkehr. Die ganzen Blitzen überall aufzubauen, war die größte Fehlinvestition des Jahrhunderts. Ist noch nie jemand zu schnell gefahren.
Ich teste das mal.
Cheers, Starfarer
Die FHZ 1300 begrenzt die Sendezeit hardwaremäßig. Einen Reset bei abgelaufener Zeit habe ich softwaremäßig nicht hingekriegt. Rausziehen und wieder reinstecken ist im Moment die einzige Lösung.
Da gibts doch so ne FS20 Servosteuerung, damit kann man das automatisieren.
Man könnte mal probieren, ob man den USB Port an sich softwaremäßig abgeschaltet und wieder eingeschaltet kriegt, wenn man dafür eine Lösung bräuchte. Ich brauche keine.
Fakt und gelüftetes Geheimnis ist: Die FHZ 1300 begrenzt die Sendezeit unabhängig von der Software, die dranhängt.
cheers, starfarer
Alles was ich weiss, ist, dass die WLAN Variante der FHZ eine „Reboot“ Funktion" hat.
Sowieso ist diese Einschränkung der 1% Richtlinie Blödsinn. Mit jeder weiteren FHZ die du hast, erhöhst du den Verkehr ja sowieso. Ausserdem, wer betreibt schon (abuse) ([finde jetzt das deutsche Wort nicht dafür] !
Ich möchte eigentlich nur, das meine FHT’s mit max 5 minuten Verspätung ihrere Daten bekommen. Das ist alles, und wenn ich dafür eine FHZ aufbohren muss, dann tue ich das ! So, jetzt ist es raus!
Muss ich mich jetzt dafür schlecht fühlen?
mfG Franz
Es ist ja auch die Frage wie die 1% Sendezeit definiert sind:
1% Sendezeit gleichmäßig verteilt auf 24h? Oder wird alle 5 Minuten überprüft? Und wenn ich jetzt eben alle 120 FHTs in 5 Minuten dauersenden bedienen will und dann 24 Funkstille halte, habe ich auch die 1% eingehalten. Die 1% sind also immer relativ zu sehen, je länger das Prüfintervall, desto größer die Freiheit.
Hallo TK6,
also im Moment gehts bei mir noch, weil ich noch nicht alle FHTs (12) staendig aendere, aber das soll ja auch bald losgehen. Sonst lohnt sich ja der ganze Kram nicht, wenn er nur aus Alibi Gruenden installiert ist.
Uebrigens, so sieht im Moment auf meinem Produktivsystem der Funkverkehr aus:
Gruss Torro
… kennt das Reset auch. Auf FTD2xx-Level kannst Du FT_ResetDevice, FT_ResetPort (um den USB Port nach Fehler zu recovern) und FT_CyclePort machen (was unter XP funktioniert und softwaremäßig das Rausziehen und Reinstecken abbilden soll). Alle diese Kommandos beeinflüssen die Sendezeitbegrenzung nicht, es wird nichts zurückgesetzt.
cheers, starfarer
Alle diese Kommandos beeinflüssen die Sendezeitbegrenzung nicht, es wird nichts zurückgesetzt
… wäre auch zu schön gewesen !
mfG Franz
…und was ist, wenn man die Stromversorgung des USB-Kabels vom PC zur FHZ unterbricht?
dann sturtz IPS ab? oder?
IPS stürtzt nicht ab, aber du musst neu starten !