Hallo zusammen,

es existiert ein 'Haupt-Thread' (RE: Meldegleis zur Identifikation, ohne Verdrahtung und Schienentrennung), sowie einer für die Entwicklung (RE: Bau- und Entwicklungs-Thread: Drahtlose Identifikation) bereits.
Jetzt möchte ich den Thread für die Software starten, die zum Projekt gehört. Die Grundlage ist RE: Meldegleis zur Identifikation, ohne Verdrahtung und Schienentrennung und wer hier liest, sollte den 1. Artikel dort gelesen haben. Fragen zu den Grundlagen gehören ebenfalls dorthin.

Die Elektronik ist entwickelt und beinhaltet den RFID Reader, sowie 4 konventionelle Melder, die auf kurze Distanz verlegt werden können, oder ignoriert.
Die Elektronik versendet ihre Daten per Bluetooth BLE und bezieht ihre Energie aus dem Gleis oder separater Spannungsversorgung.

Das Gegenstück ist ein Raspberry PI 4 und nur der. Um dessen Software dreht es sich hier, sowie um Software-Fragen um die Empfänger der Daten, welche vom Raspberry erzeugt werden.
Diese Daten sind primär Besetztmeldungen.
Weiterhin kann er Identifikationen abgeben, auch wenn hierfür heute nur bei RocRail gewisse Grundlagen existieren.

Stand heute ist, dass die Software des Raspberry auf der Grundlage von C++ eine Bibliothek einsetzt, die ich vor sehr kurzem gefunden habe und die einen Ansatz hat, der besser ist, als mein letzter Kandidat und viel besser als NOBLE/BLENO.
Zu der Bibliothek (direct-bt) gibt es vor allem auch eine darauf aufsetzende Java Bibliothek.
Das ist der attraktivste Punkt.
Das Projekt konkurriert sozusagen mit dem TinyB von Intel.
TinyB wurde aber seit geraumer Zeit nicht weiterentwickelt, während direct-bt immerhin 2020 in die Öffentlichkeit gelangte und seit kurzem als komplett bezeichnet wird.
Der Autor lebt in Bremerhaven, was zusätzlich attraktiver ist, als Intel.

Nun, wie weit bin ich:
Der Raspberry startet Eclipse und ein Testprogramm und dieses nimmt den Bluetooth Adapter über direct-bt in Betrieb. Klingt nach nichts, aber das bedeutet, dass ich mit meiner Java Entwicklungsumgebung Eclipse arbeite, also volles Quellcode-Debugging auf dem Raspberry machen kann. Ein absolutes Muss.
Die umfangreiche direct-bt ist bereits komplett von mir kompiliert und eingebunden und kommt an die Hardware heran. Also die Zwischenschicht Java Native Interface JNI ist enthalten. Wer das kennt, ahnt was das bereits für ein Aufwand war.
JavaFx ist auch bereits installiert und die Persistenz per Bibliothek 'MicroStream' ebenfalls.

Die entstehende Software werde ich an potente Projektteilnehmer weiter zur Verfügung stellen, werde aber keinerlei Portierungen unterstützen können. An geeigneten Stellen des Systems werde ich Schnittstellen einziehen, die universell sind, ich denke an Pipes, interne Ports und Protokolle darüber.

Also, wer bis jetzt folgen konnte, ist hier richtig. Es wird hier durchaus theoretisch, aus Sicht von Software-Entwicklern praktisch!

Viele Grüße,
Joachim

Hallo Joachim,

ich kann dir folgen.

Endlich kommst du in deinem Projekt an ein Punkt, wo auch ich eine Ahnung habe.

Moin Joachim,
Rocrail geht auf dem P4 meines Wissens (zumindest derzeit) nur unter PiOS11 (bullseye) 32 Bit-Version. Die 64 Bit Version hat, soweit ich das verfolgt habe, noch Probleme.
Auf welchem Betriebssystem und welcher Mindest-Speichergröße setzt Du auf?

Schöne Grüße
Johannes

Hallo Johannes,

Nur zur Klärung: RocRail läuft nicht im Rahmen des Projekts, jedenfalls nicht auf dem Raspi, den ich zum Konzentrator mache.

RocRail verwende ich selbst, an meiner Anlage, derzeit auf einem SUN Blade mit viel zuviel Energie (und 4 Display Ports).
Das ist einfach eine der Steuerungen, die ich unterstützen will.

RocRail ist noch nicht im Fokus.

Ich arbeite mit ab 4Gbyte RAM, Bullseye 64 Bit Raspbian OS und Mengen an installierten Paketen.
Eclipse verlangt nun nach 64 Bit Adressraum.
Das ist für mich das optimale Taschenmesser, für alles.

Viele Grüße,
Joachim

Hallo zusammen,

Heute kam der nächste Schritt:
Ein Programm, das die umgebenden BLE devices namentlich erkennt, also deren Advertisements sieht und darstellt.
Zumindest in der Konsole.
Der Raspi hat den Adapter nun also voll in Betrieb und ich kann nach Herzenslust Java Programme dafür schreiben.
Wenn nicht irgendwann ein sehr fetter Brocken kommt, sieht das schon richtig gut aus.

Es kann produktiv losgehen, in für Programmierer angenehmer Umgebung.

Viele Grüße,
Joachim

Zitat von joachimkr im Beitrag #4

---

Hallo Johannes,
Ich arbeite mit ab 4Gbyte RAM, Bullseye 64 Bit Raspbian OS und Mengen an installierten Paketen.
Eclipse verlangt nun nach 64 Bit Adressraum.
Das ist für mich das optimale Taschenmesser, für alles.

---

Hallo Johannes,

Auf dem Raspberry läuft nur mein Zeugs, nichts weiteres.
Ich liefere ein Image aus, im Zweifelsfall eine SDHC Karte.
Vorbereitung wäre höchstens, dass Du den HDMI Port mit Display bestückst, wenn Du willst.

WLAN ist übrigens für diesen Raspberry tabu. Nur LAN per Kabel.

Viele Grüße,
Joachim

Moin Joachim,
ok, LAN ist ebenso wie Display am HDMI angeschlossen.

Schöne Grüße
Johannes

Hallo Johannes,

Zitat von Pirat-Kapitan im Beitrag #8

---

Moin Joachim,
ok, LAN ist ebenso wie Display am HDMI angeschlossen.
Schöne Grüße
Johannes

---

Hallo zusammen,

die von mir adoptierte Bibliothek wird Zug um Zug in Betrieb genommen.
Da sind offenbar auch Prüfungen enthalten, ob der Datenstrukturaufbau der GATT Spezifikation entspricht.
Mit Smartphone kann ich bisher das meiste testen.
Alles hat bisher funktioniert.

Nebenher habe ich wegen des Gefühls der Langsamkeit des Raspberry mal die SDHC Karte getauscht. Ein spürbarer Unterschied!
Eine 32 GB Karte wird reichen.

Viele Grüße,
Joachim

Hallo zusammen,

Die Bibliothek hat offenbar eine gewisse Abstimmung auf die Medizinprodukte, für die sie entwickelt wurde.
Die von mir verwendeten Android-Apps decken sich im Verhalten und erlauben eine schrittweise Iteration der GATT Dienste, Properties etc., bis man eine Annotation abonniert. Bei der Bibliothek ist das nicht sauber getrennt und Abhängigkeiten von Sicherheitsmaßnahmen enthalten, die ich nicht implementiert habe, das sinnfrei.

Ich muss nun deren Spezialmaßnahmen erkennen, auswerten, ersetzen. Deren Logging führt zu Verzögerungen, die der Performance abträglich sind und zugleich kryptisch, jedenfalls für mich.

Aber auf der Habenseite ist bereits eine super funktionierende Kommunikation innerhalb der GATT Layer von Bluetooth BLE zwischen meiner Readerplatine und dem Raspberry. Anstelledes Smartphones ist nun meine Readerplatine die Gegenstelle. Sie offenbart nur die gleichen Probleme, wie die Smartphone Apps.
Es wird mehr Aufwand, an anderer Stelle als gedacht, aber ich komme voran.

Viele Grüße
Joachim

Hallo zusammen,

Hier ein Schnappschuss aus dem Log des Testprogramms. der einen echten Fortschritt für die Software des Raspberry darstellt, um nun ein detaillierter auf die wirklichen Bedürfnisse abgestimmtes Programm aus dem Rahmen abzuleiten - also abspecken und Aktionen mit diversen Uhren, Lampen etc zu unterbinden. Anmerkung: Ein Characteristic ist ein Begriff in Bluetooth Low Energy BLE, das die Übertragung von Werten ermöglich. Gelesen, wie hier ADC Value 2, oder, wichtiger: Characterictic-Notification, bei den Melde-Ereignissen.

[ 29.104] ** - - - - - - - - - - - - - - **
[ 29.105] **[03.02] Characteristic-Notify: UUID 15005991-b131-3396-014c-664c9867b917, td 1 ******
[ 29.106] **[03.02] Characteristic: Char[handle 0x001e, props 0x12 [read, notify], 'ReadableNfcId', descr[handle 0x0020, handle 0x0021], ccd-idx 0, enabled[notify 1, indicate 0], value[type 0x15005991-b131-3396-014c-664c9867b917, handle 0x001f]] ******
[ 29.102] [03.03] Char[handle 0x0022, props 0x02 [read], 'ADC Value 2', descr[handle 0x0024], ccd-idx -1, value[type 0x6eb675ab-8bd1-1b9a-7444-621e52ec6823, handle 0x0023]]
[ 29.107] **[03.02] Value R: size 17, ro: 3030313132323333343435353636373700 ******
[ 29.110] **[03.02] Value S: 0011223344556677 ******
[ 29.112] ** - - - - - - - - - - - - - - **

Im Log sind weitere Kleinigkeiten zu sehen, wie ein gelesenes Characteristic 'ADC Value 2'
Jenes ist nur ein Testwert, der bei 2-Leiter-Anwendungen den Stromwert am Gleis (einen der 4) spiegeln soll.

Ich bin mit Erfolgserlebnis gesegnet, also schmeiße ich jetzt alles schnell in die Ecke und mache

Frohe Ostern!

Viele Grüße,
Joachim

Zitat von joachimkr im Beitrag #12

---

Ich bin mit Erfolgserlebnis gesegnet, also schmeiße ich jetzt alles schnell in die Ecke und mache

Frohe Ostern!

---

Hallo zusammen,

das Hauptprogramm für die Grundlagen von allem macht inzwischen folgendes:
- alle Bluetooth-Devices in der Umgebung werden gesucht
- die relevanten Geräte werden ausgefiltert
- ein geeigneter Sicherheits-Kontext wird für jedes Gerät angelegt
- es wird die Connection aufgebaut
- verfügbare Services des Geräts (meiner Platine und ihrer Software) werden ermittelt
- Attribute, für die es das Angebot für automatische Benachrichtigung gibt (Notifications) werden in der Platine, dem RFID Leser abonniert
(In diesem Moment wird die RFID Antennenleistung eingeschaltet)
- Wenn ein TAG in Leser-Reichweite kommt, wird sein UID (eine extrem lange Nummer) durch den RFID Leser geschickt, durch den Raspberry empfangen
- Quittung durch Raspberry gesendet

Mir fehlen ja nun weitere Leser, um ein Komplettsystem zu testen. Die werden bald (dehnbarer Begriff) gefertigt.
Bis die da sind, werde ich die Software so erweitern, dass sie ihren Job möglichst komplett kann.
So kann ich die Zeit nutzen.

Für die Programmierer:
Die genutzte Bibliothek spielt auf einem ganz anderen Niveau, als es mit BLENO/NOBLE möglich wäre. JavaScript Krüppel sind also raus aus dem Spiel.
Die Alternative von IBM basiert auf dem als unzuverlässig gescholtenen BlueZ von Linux mit einem unglaublichen Umfang von IBM Funktionalität, die uninteressant ist.
Die genutzte Bibliothek besteht aus 2 groben Schichten: C++ für Treiber-Betrieb am Linux D-BUS, dem heute üblichen Fundament vernünftiger Treiber. mit C++ werden Bibliotheken gebaut (shared object so Datei)
Darauf aufbauend kommt Java, über den heute üblichen JNI (Java native interface) wie für Java11 vorgesehen.
Meine Software wird also komplett (!) in Java laufen, die C++ Anteile fasse ich nicht an.
Alle Schnittstellen werden direkt aus Java betrieben. Schöner (effizienter) geht's nicht.

Witziges Detail: Beim Kompilieren und Binden der Bibliotheken ist mir der Raspberry 4 eigentlich regelmäßig abgestürzt, hat keinen Mucks mehr gemacht. Immerhin läuft der ganze make Prozess etwa 6 Minuten.
Als Hardware-Mensch habe ich den Braten gerochen, denn ein Finger als Thermometer ergab: CPU zu heiß. Das cmake und make startet alle 4 Prozessor-Kerne zugleich - eines der Qualitätsmerkmale der Software, der Bibliothek.
Bisher hielt ich Kühlkörper für Raspberry für Blödsinn, Schnickschnack. Jetzt nicht mehr!
Im Normalbetrieb ist der lauwarm, aber wenn es hoch her geht, wie 4 Compiler-Prozesse, reicht die Kühlung der Platine allein nicht aus.

Mein geliebtes Eclipse läuft erstaunlich rund. (Entwicklungsumgebung, die jetzt alles unter Kontrolle hat)

Viele Grüße,
Joachim

Moin Joachim,
Ich verwende beim Kompilieren über alle 4 Kerne einen RasPi mit im Gehäuse eingebauten Lüfter. Der senkt die Temperatur bei mir unter den kritischen Wert. Ich habe dabei den Temperaturmonitor als Daueranzeige aktiviert.

Schöne Grüße Johannes

Moin Johannes,

So ist das bei mir auch gelöst, für einen normalen Raspi.
Für die Module CM4 werde ich mir was einfallen lassen, mal sehen, ob die Last im Normalbetrieb überhaupt so hoch wird, dass es fühlbar wird.

Compiler auf 4 Kernen von 4 sind schon heftig.

Viele Grüße,
Joachim

Hallo zusammen,

Stabilitätstests mit Raspberry 4 sehen inzwischen sehr gut aus. Die Erfassung der Meldungen erfolgt mit hohem Tempo, ohne dass Exceptions auftreten.

Es gab im Beispiel-Programm eine Fülle von möglichen Abläufen, deren Varianten ich abknipsen konnte, um an die Netto-Substanz zu gelangen.

Die Anwendung Eclipse, mit ihrer visuellen Darstellung lastet bei laufendem Beschuss mit Meldungen, Darstellung auf Xorg die CPU zu 30 bis 40% aus, davon sind lediglich 6 bis 13% die Java-Applikation für Bluetooth BLE Transfers.
Jetzt werden die Meldungen ja noch nicht im eigentlichen Sinne verarbeitet, da kommt also noch ein mehrfaches an Verarbeitung hinzu. Aber das betrifft nur den Java-Anteil.

Ich lege hier ein Bild bei, das im seit einer Stunde laufenden Betrieb geschossen ist. Der Speicherbedarf steigt nicht an. Der Rechenaufwand für die laufenden Ausgabe der Texte ist erkennbar dominierend, diese Ausgaben werden zukünftig ja entfallen.
Im Text sind 2 der 3 Tags zu sehen.

P.S. Nach einem Tag Laufzeit brauchte ich die Komponenten zum nächsten Schritt. Keine Fehler aufgetreten.

Hallo zusammen,

Die Aktivität konzentriert sich auf die Speicher-Technik. Es kommt nach Stand 'Microstream`zum Einsatz und ich hatte erfolgreiche Vorversuche. Die haben inzwischen eine neue Version rausgebracht, die läuft bei mir partout nicht. Ich werde dran bleiben, denn die Microstream Grundimplementierung ist mehr als gut.
Zur Not gehe ich auf eine 'alte' zurück und lasse die laufen, bis die Probleme bei denen gelöst sind.
Ich stelle nur wieder fest, wie sehr und warum ich Maven hasse.

Maven ist die Antwort auf die Frage, "wie kann ich ohne wirkliche Kontrolle des Benutzers meine Fehler beheben und ausliefern ? (Oder ihm welche unterjubeln, ohne dass ich das merke)" Das kollidiert mit allen in Java verankerten Mechanismen zur Gestaltung von Systemen und verletzt bei sicherheitskritischen Systemen alles! Wer Atomkraftwerke oder Waffen mit Software beliefert, dem muss man Maven stehlen. Ich kann dieses vernichtende Urteil begründen, lasse mich aber nicht hier auf Diskussion darüber ein.

Also Microstream: Der Kernmechanismus schließt ein durch Sun & Oracle hinterlassenes Loch. Objects im Speicher werden auf der 'Festplatte' abgelegt, bei Neustart des Systems setzt es idealerweise so fort, als ob es nicht ausgeschaltet worden wäre. Programmierung ist voll überschaubar und die Transaktionen sicher. Performance super!
Ich werde mich hier wieder melden, wenn ich das wieder zum Laufen bekommen habe.

Viele Grüße,
Joachim

Hallo zusammen,

Alle Einzel-'Komponenten' haben jeweils laufende Fragmente, Apps mit jeweiligen Funktionen. Also auch MicroStream. Der Hersteller hat aus für ihn vielleicht nachvollziehbaren Gründen Maven als Erzeugungswerkzeug genommen und als Konsequenz kollidiert das derzeit gewaltig bei Versuchen, nun auch JavaFx einzubinden, also zwei große Pakete zugleich. JavaFx ist inzwischen auch als Maven-Projekt am laufen. Nur nicht beides zugleich.

Das Werkzeug sollte vom Planeten geschafft werden!

Ich erinnere, dass ich mal bei einem Kunden saß, er mir einen Arbeitsplatz einrichtete. "Maven ist zentral gesteuerte Auslieferung, das ist gut!" war die Devise.
Bis mein Arbeitsplatz alle Bibliotheken hatte, war eine volle Arbeitswoche versenkt! Ursache: Maven hat ständig neue Versionen geladen, es war ein eigenes Repository errichtet worden, dass nicht kontrolliert lief und täglich passte irgendwas nicht zueinander. Irgendein Konflikt blieb immer. Der Projektleiter hat später seinen Job verloren.

Ich beiße mir an dem Konzept Maven die Zähne aus, weil MicroStream seinerseits andere (große) Projekte inkludiert, die mir nichts bringen, aber in deren Steuerdateien (pom.xml) nicht eliminiert werden können, zu sehr verwoben, inzwischen.

Sobald ich etwas funktionierendes habe, werde ich Maven aus-bauen, die in seinem lokalen Repository abgelegten Bibliotheken (JARs) herausholen und ohne die Kontrolle von Maven direkt in den Java Classpath einbinden um meine Kontrolle wiederzukriegen! Nur so kriege ich das Zeug auf dem Raspberry dauerhaft etabliert.

Nun, der Job als Software-Entwickler hat auch seine dunklen Seiten.

Bis demnächst!
Viele Grüße, Joachim

Hallo zusammen,

auf dem PC, unter Windows, habe ich nun ein Projekt lauffähig, mit dem gewählten Microstream in neuester Version, das OHNE Maven erzeugt wurde. Die kochen auch nur mit Wasser, aber eben mit zuviel davon.
Ich habe mich durch die Bibliotheken gewühlt, meine lauffähigen Maven-Beispiele durchgesehen und die Bibliotheken identifiziert, aus meinem Maven Repository herausgeholt und direkt in ein Verzeichnis für Eclipse gelegt, aus dem der Compiler und der Debugger genutzt und - keine Überraschung - es geht.
Aus 500 Dateien im Repository, mit 300 MByte wurden nun 11 Dateien, die wirklich genutzt werden. Da die Gebrauch von dynamischem Class-Loading machen, könnte da noch etwas wachsen, aber jetzt ist es definitiv eine bessere Grundlage für Embedded Computing! Der große Umfang des Repositories ist nur durch die gleichen Beispiele entstanden, aber der freizügige Gebrauch von Maven POM Datei-Inhalten hat zu der Explosion von Ressourcen geführt, die ich von Maven kenne und ablehne.
Der umständliche Weg über Maven war notwendig, weil der Hersteller sich darauf fixiert hat und eine 'Auslieferung' praktisch nur über Maven möglich ist. Hat sich gelohnt.

Ich werde das auf den Raspberry hinüberkopieren und dort ausprobieren, mit der schon laufenden Bluetooth-Bibliothek koppeln. Jetzt will ich ein Konzept machen, wie ich eine Bedienoberfläche mit JavaFx dort anflansche, ohne Abhängigkeiten zu schaffen. Die soll Option bleiben, keine Abhängigkeiten schaffen. Sowas habe ich schon einmal gemacht, es gibt mehrere Wege.

Viele Grüße,
Joachim

..... ich glaube die Fertigstellung dieses Projektes übersteigt meine Restlebenserwartung.

nix für ungut
Hubert

Hallo Hubert,

So ein Projekt macht sonst auch nur ein solides Unternehmen mit mehreren Mitarbeitern für so eines. Die Technik ist anspruchsvoller, als ein Lokdecoder.

Wem das zu lange dauert, der bastelt und schnitzt weiter und baut Kabelbäume, kauft kiloweise Sekundärtechnik wie Loconet, Protokollwandler oder ähnlich.

Mir schwebt jedenfalls etwas bestimmtes vor und das ziehe ich bis zum Ende durch, dann wird es auch gut!
Da bin ich eigen, Qualität & Funktionalität geht vor. Außerdem soll der Endpreis stimmen.

Viele Grüße,
Joachim

P.S. man muss auch nicht als Anwender jeden technischen Mist lesen, den ich schreibe. Nur weil es komplexe, moderne Technik ist, ist das keine Aussage über die Dauer.

Hallo zusammen,

inzwischen sind die 3 Säulen-Projekte, Prototypen auf dem Raspberry fertig.
1. Die Bluetooth Kommunikation, inklusive dem Ausfiltern meiner RFID-Applikations-Daten, der RFID Reader und deren Initialisierung, sowie Übernahme von RFID Ereignissen
2. Eine Applikation mit der Fähigkeit, beliebige Java Objekte (Daten!) auf der SD Karte zu speichern, während die Applikation läuft. Also die bekannten RFIDs, deren letzter Aufenthaltsort (und die davor)
3. Eine Bedienoberfläche die lose angekoppelt wird, um sie nicht zwangsweise einzubinden

Alles ist vom Laptop auf den Raspberry portiert. Nun kann die beherzte Phase 'Happy coding' losgehen, in der die Funktionen miteinander vernetzt werden, zu einer Gesamt-Applikation, bestehend aus zwei unabhängigen Programmen. Dem Kernstück, dass bei Start des Raspberry seinen Job macht und der Bedienoberfläche, mit der ein Einblick und ggf. Konfigurationsdetails eingesehen, modifiziert werden können.
Die Kommunikation zur Central Station (und anderen) benötigt keinen Prototypen, das ist so locker programmiert, ohne weitere Abhängigkeiten, das läuft easy.

Viele Grüße,
Joachim

Hallo zusammen,

Die Integrationsphase der 3 Säulen ist 'durch'. Die Anwendung kommuniziert auf dem Raspberry mit Bluetooth und hat nun zusätzlich ein sauberes, performantes Datenbank-Gebilde eingebaut, um Abschaltungen zu erlauben.

Viele Grüße,
Joachim

Hallo zusammen,

Derzeit arbeite ich mich in die Persistenz ein, in Microstream. Im Prinzip läuft schon einiges, Datenstrukturen sind aufgebaut, es werden Elemente, die man schon mal sah, wiedererkannt, auch wenn der Raspberry stromlos war.

Die Bluetooth-Bibliothek läuft gut. Ein kleines Hindernis ist, dass bei hohem Datenaufkommen die Log-Ausgabe zu langsam wird und an der Funk-Schnittstelle dann Timeouts zur Trennung führen. Da wird derzeit viel geloggt, das kann ich drastisch zurückfahren. Aber die Persistenz soll ja auch mithalten.

Momentan werde ich durch meinen kranken Vater schwer belastet. Daher ist hier alles etwas ausgebremst.
Der Elektronik-Fertiger meldet sich nicht, aber das heißt ja nur, dass er auf eine Lücke wartet. Alles im Lot, bisher.

Viele Grüße,
Joachim