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]
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…
… 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.
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.
… 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.
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.
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?
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.
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:
… 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.
…nachdem er aber seinen Sonnenbrand am Bondi-Beach gefangen hat ! 
