[Joa]

Hallo Alf,

da ich derzeit im "off lable mode" die Daten von zwei GGMS-Geräten in SiDiary einpflege was mit den Werten des Sensorstroms (ISIG) schon eigentlich Massendaten für 3 Systeme wären, führt diese Datenflut bei mir dazu, dass nach 10 bis 13 Tagen die Syncronisation mit SDO, sowohl vom PC aus, als auch aus Richtung SDA zum Zusammenbruch bringt.

Du hattest da den Timout-Rahmen höher gesetzt, was aber keinen Erfolg brachte.
Nun habe ich mal den SD_P&P von einem anderen Zugang aus gesynct wo es ging.

Die Ursache liegt also sehr vermutlich im Upload-Stream des Zuganges begründet, der lt. Fritz!Box bei 448 kBit/s liegt. Beim SDA-Handy ist er sicherlich nicht höher.

Ein weiteres Problem mit Massendaten von CGM-Systemen liegt darin, dass diese nach wenigen Tagen eines Monats grundsätzlich die Leistungfähigkeit mobiler Geräte an die Grenze sinnvoller Nutzung treiben.

Schon die Daten des Freestyle Navigators alleine, der mit nur der Hälfte der Messwerte der anderen Systeme daher kommt, verlangsamen deutlich. Wer mit dem Medtronic-System arbeitet und sowohl die IG als auch den ISIG (was sinnvoll ist) trackt, hat die vierfache Datenflut des Navigators in SiDiary zu verwursten.

Um die Arbeitsfähigkeit mobiler Systeme unter CGMS-Bedingung zu erhalten wäre es somit schon sinnvoll, eine Möglichkeit zu schaffen, Massendaten von der Syncronisation mit mobilen Geräten auszunehmen. In den mobilen Systemen lassen sie sich ja sowieso nicht verwerten. Der permanente Sync dieser Daten ist nutzloser Overhead, der zudem auch noch die Speicherkapazität vieler mobiler Geräte verhältnismäßig schnell erschöpfen dürfte.

Gruß
Joa

[Alf]

Hallo Joa,
 
klar die Massendaten verlangsamen das Handling auf den nicht so schnellen mobilen Geräten natürlich deutlich, gerade wenn man gleich Daten von 2 oder 3 CGMS-Systemen in der Datenbank hat.
 
Leider lassen sich die CGMS-Daten nicht so ohne weiteres aus den Monats-Files herauslösen, denn genau dort werden sie wie alle Tagebuch-Datensätze gespeichert. Wir haben deshalb ja wenigstens schon den Vorteil, dass man über die Zeitraumbeschränkung in den Sync-Einstellungen die Datenmenge etwas steuern kann und z.B. "Altdaten" nicht auf ein mobiles Gerät packen muss aber innerhalb eines Monatsfiles lässt sich ein "CGMS-Filter" derzeit nicht bewerkstelligen und das würde auch größere Umbauten an der kompletten Sync-Architektur erfordern, so dass wir das allenfalls für eine V7 angehen können.
 
Viele Grüße, Alf.

[Joerg Moeller]

Leg dir doch einfach einen zweiten Pat. an. Also einen mit dem du normal arbeitest und einen mit dem du rumspielen kannst. Und dann sync nur den normalen mit SDO/SDA

Viele Grüße,
Jörg

[Joa]

Leider lassen sich die CGMS-Daten nicht so ohne weiteres aus den Monats-Files herauslösen ...

Da steckt wohl mal wieder der alte Konflikt Kalkulationstabellen- vs. Datenbankstruktur mit drin.

Wobei das Handling als Kalkulationstabelle, soweit ich sehe, die flexible Nutzung auf div. mobile Devices möglich macht.

das würde auch größere Umbauten an der kompletten Sync-Architektur erfordern, so dass wir das allenfalls für eine V7 angehen können.

Dann harren wir mal einer kommenden V7 entgegen.

Leg dir doch einfach einen zweiten Pat. an. Also einen mit dem du normal arbeitest und einen mit dem du rumspielen kannst. Und dann sync nur den normalen mit SDO/SDA

Das ist schon mal eine Idee. Zum Rumspielen ist das auch noch machbar. Als Standard-Work-Flow für die Nutzung von Massendatensystemen eher nicht so sehr.

Nehmen wir mal den Spielbetrieb:

Konto 1 = ohne CGMS (mit Sync zu SDO und mobilen Geräten)
Konto 2 = mit CGMS (Ohne Syncanbindung, reines Importkonto)

Es müsste dann ein Export von Konto 1 nach Konto 2 erfolgen, um die Daten in Konto 2 komplett zu halten. Ergibt natürlich wieder ein paar Fragen hinsichtlich Dubletten, aber die sind nicht anders, als sie bei SiDiary immer sind.

Alternative wäre ein Importfilter, der SDO, bzw. das jeweilige moblie Gerät ausliest und nur wählbare Datentypten direkt in ein Konto einliest.
Das mobile Gerät würde dann zum reinen Zulieferer von Ergänzungsdaten, hätte selber aber keine vollständige Datenhaltung mehr. Auch das mobile Gerät die auf den Weg über SDO angewiesen sind, dürften dann nur von SDO importiert werden.

Alternativ wäre der Verzicht auf das mobile Tracken mit SiDiary und eine Oktavheft als Protokoll.   

Gruß
Joa

[Alf]

Da steckt wohl mal wieder der alte Konflikt Kalkulationstabellen- vs. Datenbankstruktur mit drin.
Wobei das Handling als Kalkulationstabelle, soweit ich sehe, die flexible Nutzung auf div. mobile Devices möglich macht.

Nein. Da scheinst Du hier beim Mitlesen und vor allem in meinen EMails leider nicht aufgepasst zu haben: SiDiaryV6 basiert auf einem klassischen Datenbankmodell - jeder Eintrag, der visuell in einer EINGABEtabelle erscheint, ist defakto ein einzelner Datensatz, was ich Dir ja auch schon wirklich mehrfach erklärt habe. Nebenbei: Nur ein Datenbankmodell erlaubt überhaupt das flexible Handling mit eigenen Datentypen.
 
Wir haben aber zusätzlich nicht nur eine Gesamt-Datenbank pro Patient, sondern eine für jeden Monat, was die Einschränkung der Datenflut und der Datenmenge ermöglicht.
 
Das ändert aber auch immer noch nichts an der SYNC-ARCHITEKTUR, die für das komplette Herausfiltern bestimmter Datentypen einfach nicht eingerichtet ist.
 
Und für Dich lieber Joa empfehle ich in der Tat ein Oktavheft und zwar ein sehr langes und sehr großes und zusätzlich einen richtig großen Bleistift, so dass Du dann ganz viele Zahlen von Deinen 3 CGMS-Systemen malen kannst...
 
Ich frage mich wirklich, wer es Dir Recht machen kann...ich habe es lange versucht aber inzwischen aufgegeben...aber spielt das überhaupt eine Rolle?

[Joerg Moeller]

Leg dir doch einfach einen zweiten Pat. an. Also einen mit dem du normal arbeitest und einen mit dem du rumspielen kannst. Und dann sync nur den normalen mit SDO/SDA

Das ist schon mal eine Idee. Zum Rumspielen ist das auch noch machbar. Als Standard-Work-Flow für die Nutzung von Massendatensystemen eher nicht so sehr.

Du meinst sicher Joa-Workflow. Ich kann mir irgendwie nicht so recht vorstellen daß die breite Masse der Diabetiker mehr als ein CGMS nutzt.

Und die, die sich nur eins leisten können scheinen das Problem ja nicht zu haben.

[LordBritish]

Du meinst sicher Joa-Workflow. Ich kann mir irgendwie nicht so recht vorstellen daß die breite Masse der Diabetiker mehr als ein CGMS nutzt.

Ich wüßte auch nicht warum man gleichzeitig mehrere CGMS nutzen müßte,
würde mich mal interessieren

Viele Grüße
Markus

[Joa]

Du meinst sicher Joa-Workflow. Ich kann mir irgendwie nicht so recht vorstellen daß die breite Masse der Diabetiker mehr als ein CGMS nutzt.

Und die, die sich nur eins leisten können scheinen das Problem ja nicht zu haben.

Die, die sich nur ein CGMS leisten (können), hätten das Problem auch, wenn sie ein Medtronic-System benutzen und auch die Sensorstromverläufe darstellen (möchten). Ansonsten aber nutzt die breite Masse der Diabetiker selbstverständlich nicht 2 GGM-Systeme, sondern eher einfach Metformin. 

Aber ich nutzt natürlich auch nicht 2 CGMS. Aktuell geht/ging es mir um den Vergleich zwischen Navigator und Veo-Enlite. Zielsetzung dabei die Klärung der Frage, ob für mich das Medtronic-Sys als Alternative zum Abbott-Sys in Betracht kommt, nachdem ich ja seit einiger Zeit als Monitor für den Medtronic Sensor die Veo im Pumpenmodus betreibe.

Ebenfalls gab es ja auch von diabetologischer Seite ein gewisses Interesse an der Darstellung solcher Vergleiche.

Ich denke, dass ich nun die mit SiDiary machbaren Möglichkeiten soweit auch eingrenzen konnte, Dank Alf's und Deiner unermüdlichen Unterstützung.  Und das, was machbar ist, ist schon eine ganze Menge.   

Auch herumliegende Stolpersteine (Kompressionsschalter) sind ausgemacht und lassen sich auch umschippern. Natürlich bleibt beim tracken von Systemvergleichen einige Handarbeit offen. Soweit es alleine um die Darstellung der Kurvenverläufe geht, ist das ohne besonderen Aufwand zu machen.

@Alf: Sorry. Die Bezeichnung "Kalkulationstabelle" für das strukturierte Datenbankmodell von SiDiary ist despektierlich ausgefallen.   

Sicher ist das eine Datenbank, und enthält je Datum selbstverständlich mehr Informationen, als das 2-dimensionale Array einer x-y Kalkulationstabelle.

Gruß
Joa