ScanDoc για Προγραμματιστές

Προδιαγραφή J2534 και αναφορά λειτουργιών ›
Προδιαγραφή ELM327 και αναφορά εντολών ›

Η διεπαφή ELM327 είναι διαθέσιμη στο Nano ET. Οι υπόλοιποι προσαρμογείς ScanDoc χρησιμοποιούν το πρωτόκολλο J2534 PassThru.

Νέα για προγραμματιστές

Αλλαγές στο J2534 DLL, στο ELM327 και στο υλικολογισμικό των προσαρμογέων ScanDoc που αφορούν την ενσωμάτωση: νέες λειτουργίες, πρωτόκολλα και παράμετροι - με παραδείγματα χρήσης.

Οι βιβλιοθήκες διατίθενται σε ένα αρχείο. Πλατφόρμες: Windows x86/x64/ARM64 (ξεχωριστά build για Windows 7), macOS (universal), Linux (x64, x86, ARM, ARM64), Android (arm64-v8a, armeabi-v7a, x86, x86_64), iOS (XCFramework). Στον φάκελο docs/ βρίσκεται η τεκμηρίωση του SDK: πρώτα βήματα, αναφορά API, διαμόρφωση, χειρισμός σφαλμάτων, DoIP, ενημέρωση υλικολογισμικού, μορφή καταγραφής, Android, iOS.

J2534 DLL 2.0.0.225, υλικολογισμικό build 85 23.09.2026

Λήψη βιβλιοθηκών J2534 2.0.0.225

Υλικολογισμικό, build 85

Νέα

Λίστα ζεύξεων BLE και διαγραφή ζεύξης από την εφαρμογή. Μέχρι τώρα οι ζεύξεις ρυθμίζονταν μόνο από τη διαδικτυακή διεπαφή της συσκευής, ενώ μόλις συμπληρωθεί το όριο η συσκευή απορρίπτει κάθε νέα ζεύξη, χωρίς η εφαρμογή να μπορεί να ελευθερώσει θέση. Πλέον τη λίστα επιστρέφει η ConfigRead και τη ζεύξη διαγράφει η ConfigWrite. Δεν προστέθηκαν νέες κλήσεις στη βιβλιοθήκη γι' αυτό. Παράδειγμα
```
char json[2048];
if (ConfigRead(dev, json, sizeof(json)) == STATUS_NOERROR) {
    /* στην απάντηση, μαζί με τις υπόλοιπες ρυθμίσεις:
       "ble_bonds":[{"name":"WS-07","mac":"A4:C1:38:11:22:33"}] */
}
ConfigWrite(dev, "{\"ble_bond_del\":\"A4:C1:38:11:22:33\"}");
/* ισχύει αμέσως, δεν χρειάζεται ConfigReboot */
```

Διορθώσεις

Φίλτρα BLOCK στη γραμμή K. Το μοτίβο του φίλτρου ορίζεται πάνω στο πλαίσιο όπως ταξιδεύει στη γραμμή, μαζί με το άθροισμα ελέγχου όταν το πρωτόκολλο το μεταφέρει, ενώ η συσκευή συνέκρινε το μοτίβο με πλαίσιο από το οποίο το άθροισμα είχε ήδη αφαιρεθεί. Μοτίβο τριών byte με το άθροισμα δεν ταίριαζε ποτέ σε μήνυμα δύο byte και το φίλτρο δεν ενεργοποιούνταν: σε Renault ISO8 η εφαρμογή απέκρυπτε την απάντηση στο δικό της περιοδικό μήνυμα, η απάντηση περνούσε δίπλα από το φίλτρο, τα ζεύγη αίτησης και απάντησης μετατοπίζονταν κατά μία θέση και στη ροή δεδομένων εμφανίζονταν τιμές άλλων παραμέτρων. Η λειτουργία χωρίς άθροισμα ελέγχου παραμένει ίδια.
TP2.0: χαμένη ή επαναλαμβανόμενη επιβεβαίωση διέκοπτε τη σύνδεση. Κατά την επανάληψη ενός τηλεγραφήματος μετά από επιβεβαίωση που δεν ήρθε, ο αριθμός ακολουθίας του δεν επανερχόταν, οπότε η επανάληψη έφευγε με αριθμό κατά ένα μεγαλύτερο από αυτόν που περίμενε ο εγκέφαλος, η επόμενη επιβεβαίωση δεν ταίριαζε πλέον και το κανάλι έκλεινε με λήξη χρόνου. Χωριστά, επιβεβαίωση που έφτανε στο διάστημα ανάμεσα σε δύο τηλεγραφήματα προσμετρούνταν στο επόμενο ως απάντησή του και η προσπάθεια χανόταν. Στην καταγραφή της συσκευής αυτό φαινόταν ως δύο διαδοχικές γραμμές για ένα μήνυμα: reciv ack end single msg timeout SG και κατόπιν reciv ack counter error SG.
Γραμμή K. Μετά από αποτυχημένη αρχικοποίηση πέντε baud το κανάλι δεν έβγαινε πια στον δίαυλο: τα επόμενα αιτήματα δεν έφταναν στον εγκέφαλο, η συσκευή απαντούσε σε αυτά TX_FAILED και μόνο η επανασύνδεση του καναλιού το επανέφερε.

Βιβλιοθήκες J2534, 2.0.0.225

Νέα

Ρυθμίσεις της συσκευής από την εφαρμογή. Οι ConfigRead, ConfigWrite, ConfigReboot και ConfigReset (στα Windows ordinals @52-@55) εξάγονταν και πριν, όμως δεν υπήρχαν στην τεκμηρίωση και δεν μπορούσε κανείς να τις χρησιμοποιήσει από έξω. Τώρα στο docs/API_REFERENCE.md περιγράφονται τα πρωτότυπα και η συμπεριφορά, ενώ στο docs/CONFIGURATION.md δίνεται ο πίνακας των κλειδιών με τα εύρη που ελέγχει το υλικολογισμικό. Η συσκευή επεξεργάζεται αυτές τις εντολές πριν από τη δρομολόγηση J2534, επομένως λειτουργούν σε κάθε μεταφορά: LAN/WLAN, BLE και USB. Παράδειγμα
```
char json[2048];
ConfigRead(dev, json, sizeof(json));           /* όλες οι ρυθμίσεις ως ένα αντικείμενο JSON */
ConfigWrite(dev, "{\"ble_name\":\"WS-07\"}");  /* αλλάζουν μόνο τα κλειδιά που δόθηκαν */
ConfigReboot(dev);                             /* οι ρυθμίσεις ισχύουν μετά την επανεκκίνηση·
                                                  το device_id παύει να ισχύει, άνοιγμα ξανά μετά ~10 s */
```
Στο Android οι ίδιες τέσσερις συναρτήσεις είναι διαθέσιμες στο επίπεδο JNI: ptConfigRead, ptConfigWrite, ptConfigReboot και ptConfigReset. Παράδειγμα
```
external fun ptConfigRead(devId: Int): String?   // null σε σφάλμα
external fun ptConfigWrite(devId: Int, json: String): Int
external fun ptConfigReboot(devId: Int): Int
external fun ptConfigReset(devId: Int): Int

val json = j2534.ptConfigRead(devId) ?: return           // αιτία: ptGetLastError()
j2534.ptConfigWrite(devId, """{"ble_name":"WS-07"}""")
j2534.ptConfigReboot(devId)
```
Η έκδοση απαιτεί υλικολογισμικό build 85 ή νεότερο. Η βιβλιοθήκη και το υλικολογισμικό κυκλοφορούν ως ζεύγος και σε παλαιότερο υλικολογισμικό η συμπεριφορά της βιβλιοθήκης δεν είναι εγγυημένη. Η PassThruOpen σκόπιμα δεν ελέγχει την έκδοση, ώστε να μην προστίθεται επικοινωνία με τη συσκευή σε κάθε άνοιγμα: το εγκατεστημένο build το επιστρέφει η PassThruReadVersion, ενώ η απόκλιση φαίνεται στο .qlog στη γραμμή firmware build N is older than build 85 required by DLL ….

Διορθώσεις

Η απόρριψη ζεύξης BLE δεν μοιάζει πλέον με σιωπή του εγκεφάλου. Λανθασμένο PIN ή ζεύξη που διαγράφηκε στο τηλέφωνο δεν ξεχώριζαν από έλλειψη απάντησης: η κλήση περίμενε ολόκληρο τον χρόνο λήξης και ανέφερε απώλεια επικοινωνίας με τον εγκέφαλο, ενώ μη προσβάσιμος ήταν ο σαρωτής. Πλέον η απόρριψη ζεύξης επιστρέφει ERR_FAILED και η PassThruGetLastError δίνει το κείμενο BLE pairing rejected (wrong PIN or not paired). Ο κωδικός ERR_FAILED επιλέχθηκε σκόπιμα, επειδή στο ERR_DEVICE_NOT_CONNECTED οι εφαρμογές συνήθως δεν ζητούν το κείμενο του σφάλματος. Ισχύει σε όλες τις πλατφόρμες: Android, macOS, Windows και Linux. Οι υπόλοιπες αστοχίες BLE εξακολουθούν να δίνουν ERR_DEVICE_NOT_CONNECTED, τώρα όμως με τον κωδικό της μεταφοράς: παλαιότερα ο κωδικός αυτός τυπωνόταν ως αριθμός σφάλματος POSIX και η απόρριψη εγγραφής έβγαινε ως 0x7 - Argument list too long.
Android: η εφαρμογή κατά καιρούς κατέρρεε στην ptClose μέσω BLE. Κατά το κλείσιμο σύνδεσης BLE η βιβλιοθήκη έκλεινε τον περιγραφέα αρχείου 0, παρότι σε λειτουργία BLE δεν υπάρχει socket. Συνήθως έτσι έκλεινε σιωπηλά το stdin, αν όμως εκείνη τη στιγμή το fd 0 ανήκε σε αντικείμενο της JVM, το fdsan τερμάτιζε τη διεργασία: attempted to close file descriptor 0 … owned by native object. Γι' αυτό η κατάρρευση ήταν ακανόνιστη.
Android: κάθε ptClose μέσω BLE διαρκούσε ένα δευτερόλεπτο παραπάνω. Η βιβλιοθήκη απέρριπτε την απάντηση της συσκευής στο κλείσιμο, περίμενε τον χρόνο λήξης λήψης 1 s και έγραφε στην καταγραφή 0x6E - Connection timed out, σαν να μην είχε απαντήσει η συσκευή. Πλέον το κλείσιμο ολοκληρώνεται με την απάντηση της συσκευής. Σε macOS, Windows και Linux το σφάλμα αυτό δεν υπήρχε.
Android: κατάρρευση της ptOpen μέσω BLE, όταν η συσκευή δεν απαντούσε στο άνοιγμα. Η εφαρμογή τερματιζόταν με SIGSEGV. Σε άλλες αποτυχίες ανοίγματος (απόρριψη ζεύξης, λήξη χρόνου σύνδεσης) η βιβλιοθήκη δεν αποδέσμευε την καθολική αναφορά JNI στον BLEManager, και με τις επαναλαμβανόμενες προσπάθειες οι αναφορές συσσωρεύονταν.
FAST_INIT. Η απάντηση της συσκευής αντιγραφόταν στη δομή pt_msg_t της εφαρμογής χωρίς έλεγχο μήκους: κοντύτερη απάντηση οδηγούσε σε ανάγνωση μη αρχικοποιημένης μνήμης, ενώ υπερβολικό μήκος στην απάντηση σε εγγραφή έξω από τη δομή που έδωσε η εφαρμογή. Στο Android η ίδια κλήση έστελνε αλλοιωμένο πλαίσιο στον δίαυλο και σε αστοχία τερμάτιζε βίαια την εφαρμογή. Διορθώθηκε και ο έλεγχος του μεγέθους εισόδου: δεχόταν τιμές NumOfBytes της τάξης του 0x20000000.
FIVE_BAUD_INIT. Η είσοδος περιορίζεται σε ένα byte διεύθυνσης, όπως απαιτεί το §11.3.3.3· προηγουμένως γινόταν δεκτό μπλοκ οποιουδήποτε μήκους και η εφαρμογή που έστελνε περισσότερα έπαιρνε κωδικό επιτυχίας αντί για απόρριψη.
Android: δεν δημιουργούνταν το αρχείο .qlog. Την καταγραφή άνοιγε μόνο η PassThruOpen, ενώ η κλήση ptOpen την παρακάμπτει. Έτσι σε εφαρμογή Android τρίτου ο φάκελος sdlogs έμενε άδειος σε κάθε επίπεδο καταγραφής, οι εγγραφές πήγαιναν μόνο στο logcat και δεν ήταν δυνατό να ληφθεί καταγραφή συνεδρίας από τον πελάτη.
Καταγραφή αρχικοποίησης της γραμμής K. Στις γραμμές FIVE_BAUD_INIT και FAST_INIT τυπωνόταν μόνο > ok: ούτε η διεύθυνση αρχικοποίησης ούτε η απάντηση του εγκεφάλου έφταναν στην καταγραφή και μια αποτυχημένη αρχικοποίηση δεν μπορούσε να αναλυθεί από αυτήν. Τώρα η γραμμή περιέχει και το αίτημα και την απάντηση: io 1 FIVE_BAUD_INIT 33 > 8F6F 2850ms.

DLL 2.0.0.213, υλικολογισμικό build 84 24.08.2026

Λήψη βιβλιοθηκών J2534 2.0.0.213 - Windows x86/x64/ARM64 (ξεχωριστά builds για Windows 7), macOS (universal), Linux (x64, x86, ARM, ARM64), Android (arm64-v8a, armeabi-v7a, x86, x86_64), iOS (XCFramework)· στον φάκελο docs/ βρίσκεται η τεκμηρίωση του SDK (ξεκίνημα, αναφορά API, διαμόρφωση, χειρισμός σφαλμάτων, DoIP, ενημέρωση υλικολογισμικού, μορφή αρχείου καταγραφής, Android, iOS). Στατικά αρχεία .a παρέχονται μόνο για iOS και για το server build Linux x64· οι υπόλοιπες πλατφόρμες φορτώνουν τη βιβλιοθήκη δυναμικά.

Υλικολογισμικό - build 84

Διορθώσεις

CAN_PS, ISO15765_PS, J1939_PS και ρύθμιση ακίδων στα κανάλια _PS - η σύνδεση αυτών των τριών πρωτοκόλλων απορριπτόταν από τη συσκευή· τώρα λειτουργούν όπως τα TP2_0_PS και ISO9141_PS. Η ρύθμιση ακίδων ευθυγραμμίστηκε με το J2534-2 σε τρία σημεία:
- Το φυσικό επίπεδο ενεργοποιούνταν ήδη στο PassThruConnect στις προεπιλεγμένες ακίδες, ενώ ένα κανάλι _PS οφείλει να σιωπά μέχρι το SET_CONFIG(J1962_PINS). Τώρα το κανάλι βγαίνει στον δίαυλο μόνο μετά τη ρύθμιση των ακίδων.
- Επαναλαμβανόμενο SET_CONFIG(J1962_PINS) μετέφερε ενεργό κανάλι σε άλλες επαφές στη μέση της συνεδρίας. Κατά το πρότυπο οι ακίδες ορίζονται μία φορά ανά κανάλι: η επανάληψη επιστρέφει ERR_CHANNEL_IN_USE, άλλες ακίδες μόνο μετά από PassThruDisconnect.
- Οι ζητούμενες ακίδες δεν ελέγχονταν με την καλωδίωση της συσκευής - το κανάλι μεταγόταν ό,τι ζητούσαν. Συνδυασμός που δεν υπάρχει στην καλωδίωση απορρίπτεται τώρα με ERR_PIN_NOT_SUPPORTED.
Παράδειγμα
```
uint32_t ch;
pt_config_t      pins = { J1962_PINS, 0x0000060EU };   /* ακίδες 6 και 14 */
pt_config_list_t cfg  = { 1, &pins };

PassThruConnect(dev, ISO15765_PS, 0, 500000, &ch);
/* το κανάλι δεν είναι ακόμη στον δίαυλο */
if (PassThruIoctl(ch, SET_CONFIG, &cfg, NULL) != STATUS_NOERROR) {
    /* ERR_PIN_NOT_SUPPORTED - ο συνδυασμός δεν υπάρχει στην καλωδίωση της συσκευής */
}
/* μόνο τώρα PassThruWriteMsgs / PassThruReadMsgs·
   επανάληψη SET_CONFIG(J1962_PINS) - ERR_CHANNEL_IN_USE */
```
TP1.6, TP2.0, UART-E, HSFZ, ISO13400 - μηδενικό διάστημα μεταξύ τηλεγραφημάτων (έγκυρη τιμή που σημαίνει «χωρίς ελάχιστο διάστημα») σταματούσε οριστικά την αποστολή: το κανάλι σιωπούσε μέχρι την επανασύνδεση, ενώ το PassThruWriteMsgs επέστρεφε επιτυχία, το PassThruReadMsgs τίποτα και η ένδειξη CONNECTION_LOST δεν εμφανιζόταν ποτέ. Ο προγραμματισμός ECU μέσω TP2.0 επιβεβαιώθηκε στον πάγκο δοκιμών.
TP1.6 και TP2.0 - τα εσωτερικά φίλτρα του καναλιού δεν αφαιρούνταν μετά από αποτυχημένο REQUEST_CONNECTION: δέκα περίπου προσπάθειες προς σιωπηλό ECU κατανάλωναν όλες τις θέσεις φίλτρων και σίγαζαν το κανάλι· το TEARDOWN_CONNECTION στο TP1_6_PS απορριπτόταν - η σύνδεση δεν μπορούσε να κλείσει από την εφαρμογή· το TP2.0 δεν δεχόταν σύνδεση που ξεκινούσε το ECU και δεν παρέδιδε στην εφαρμογή πλαίσια εκτός σύνδεσης (§19.3.1 J2534-2).
DoIP και HSFZ - τα φίλτρα σε αυτά τα κανάλια καταργήθηκαν: ο κανόνας «χωρίς φίλτρο PASS δεν υπάρχει λήψη» έπνιγε τις απαντήσεις του ECU - το routing activation πετύχαινε, αλλά η απάντηση δεν έφτανε ποτέ στο PassThruReadMsgs. Η σύνδεση εδώ είναι σημείο προς σημείο, η διεύθυνση του tester καταχωρείται στο routing activation, δεν υπάρχει τίποτα να φιλτραριστεί: το κανάλι παραδίδει κάθε μήνυμα στην εφαρμογή και το PassThruStartMsgFilter απαντά ERR_NOT_SUPPORTED. Σφάλμα στον οδηγό CAN επανεκκινούσε τη συσκευή στη μέση συνεδρίας DoIP. Το watchdog της εργασίας λήψης αυξήθηκε από 5 σε 30 s - η εγκαθίδρυση σύνδεσης DoIP διαρκεί κανονικά έως 20 s.
CAN - ένα πλαίσιο που δεν επιβεβαιώθηκε από τον δίαυλο απενεργοποιούσε τον πομποδέκτη μέχρι την επανεκκίνηση της συσκευής: η ουρά αποστολής δεν ελευθερωνόταν στο όριο της συνεδρίας και το επόμενο PassThruConnect έπαιρνε υπερχείλιση ουράς από το πρώτο μήνυμα. Τα βασικά CAN και ISO15765 πήγαιναν στον άλλο ελεγκτή CAN και δεν έφταναν στον δίαυλο. Η ανάγνωση της ουράς λήψης δεν επανερχόταν μετά από κατεστραμμένη εγγραφή - η ένδειξη ελεγχόταν λανθασμένα σε όλα τα πρωτόκολλα που βασίζονται σε CAN.
GET_NDIS_ADAPTER_INFO - υπό STATUS_NOERROR επιστρέφονταν μη αρχικοποιημένα δεδομένα. Τώρα έρχονται το αναγνωριστικό του προσαρμογέα, η MAC, η διεύθυνση IPv4 με την οποία το ECU βλέπει τη συσκευή και η κατάσταση της γραμμής ενεργοποίησης· σε συσκευή χωρίς Ethernet - ERR_NOT_SUPPORTED.
GET_PROTOCOL_INFO - απαντούσε μόνο για μέρος των πρωτοκόλλων και σε λάθος μορφή. Τώρα λειτουργεί σε κάθε ανοιχτό κανάλι: ανάλυση χρονοσφραγίδας (1 µs), υποστηριζόμενη ισοτιμία, bits δεδομένων UART. Παράμετρος στην οποία η συσκευή δεν μπορεί να απαντήσει επισημαίνεται στο πεδίο supported, ενώ η ίδια η κλήση επιστρέφει STATUS_NOERROR.
PassThruDisconnect - η πρόσβαση σε ήδη τερματισμένη εργασία καναλιού κατέστρεφε τη μνήμη της συσκευής.
BLE - η ένδειξη ενεργής σύνδεσης καθαριζόταν από την αποσύνδεση της προηγούμενης συνεδρίας, που έφτανε αφού η νέα είχε ήδη συνδεθεί. Η αποθήκη ζευγών δεν εκτοπίζει πλέον το παλαιότερο ζεύγος όταν συμπληρωθεί το όριο: το νέο ζεύγος απορρίπτεται, τα αποθηκευμένα μένουν ανέπαφα, ο χώρος ελευθερώνεται από τη διεπαφή web της συσκευής. Το όριο ζευγών εμφανιζόταν στις ρυθμίσεις ως 5, ενώ η συσκευή κρατούσε στην πράξη το πολύ 3 - η στοίβα BLE δέχεται τώρα και τα 5.
USB - κομμένο πρώτο πλαίσιο μετά από τυχαία επαναφορά του προσαρμογέα χαλούσε τον αναλυτή και η δυαδική συνεδρία δεν επανερχόταν μέχρι την επανεκκίνηση της συσκευής.
WLAN - το σημείο πρόσβασης του Nano ET άλλαξε από εύρος 40 MHz σε 20 MHz: στη ζώνη 2,4 GHz τα 40 MHz διπλασιάζουν το εύρος θορύβου - περίπου 3 dB ευαισθησίας και αντίστοιχα μικρότερη εμβέλεια - και καταλαμβάνουν τη μισή ζώνη, ώστε σε συνεργείο με γειτονικά σημεία πρόσβασης το κανάλι ζούσε σε συνεχείς συγκρούσεις. Κέρδος ταχύτητας δεν υπήρχε: η συσκευή φτάνει το πολύ περίπου 20 Mbit/s, ενώ η κίνηση J2534 είναι εκατοντάδες kbit/s. Από την πλευρά της εφαρμογής δεν αλλάζει τίποτα. Η αποκατάσταση της ζεύξης DevHub μετά την αποσύνδεση πελάτη BLE διέκοπτε την ενεργή συνεδρία.

Βιβλιοθήκες J2534 - 2.0.0.213

Νέα

Παράδοση iOS: XCFramework με δημόσιες κεφαλίδες - το libj2534.xcframework περιέχει slices για συσκευή (arm64) και προσομοιωτή (arm64/x86_64), ελάχιστη έκδοση iOS 12.0. Κάθε slice φέρει τις κεφαλίδες j2534.h και j2534_ota.h, module map (Swift import J2534, αυτόματη σύνδεση CoreBluetooth) και privacy manifest. Τα πρωτότυπα του Pass-Thru API δηλώνονται στο ίδιο το j2534.h - σε όλες τις πλατφόρμες. Το mbedTLS είναι ενσωματωμένο, δεν υπάρχουν εξωτερικές εξαρτήσεις. Ρύθμιση στο Xcode: Embed = Do Not Embed (η βιβλιοθήκη είναι στατική), -lc++ στα Other Linker Flags, τα κλειδιά NSBluetoothAlwaysUsageDescription (BLE) και NSLocalNetworkUsageDescription (WLAN) στο Info.plist - χωρίς αυτά το iOS τερματίζει την εφαρμογή στην πρώτη χρήση της μεταφοράς.
Παράδειγμα
```
import J2534

var deviceId: UInt32 = 0
// Το PassThruOpen δέχεται mutable char* - περνάμε αντίγραφο της συμβολοσειράς
var cstr = Array("ScanDoc;b:N4999".utf8CString)   // BLE κατά πρόθεμα ονόματος
let ret = cstr.withUnsafeMutableBufferPointer { PassThruOpen($0.baseAddress, &deviceId) }
if ret == 0 {
    var fw  = [CChar](repeating: 0, count: 80)
    var dll = [CChar](repeating: 0, count: 80)
    var api = [CChar](repeating: 0, count: 80)
    PassThruReadVersion(deviceId, &fw, &dll, &api)
    PassThruClose(deviceId)
}
/* τα ID πρωτοκόλλων και IOCTL είναι μακροεντολές με μετατροπή τύπου, δεν εισάγονται στη Swift:
   δώστε τα ως αριθμούς, let CAN: UInt32 = 5, let ISO15765: UInt32 = 6 */
```

Android: ενημέρωση υλικολογισμικού της συσκευής από την εφαρμογή - στο επίπεδο JNI προστέθηκαν τα ptOtaUpdate(devId, firmwarePath, callback) και ptOtaAbort(devId)· πριν τα OtaUpdate/OtaAbort ήταν διαθέσιμα μόνο μέσω του C API. Η πρόοδος παραδίδεται στο onProgress(current, total) - μπλοκ, αρίθμηση από το 1.

// Το update.bin έχει ήδη αντιγραφεί στον αποθηκευτικό χώρο της εφαρμογής.
// Η κλήση μπλοκάρει - εκτελέστε την εκτός main thread.
val res = j2534.ptOtaUpdate(devId, file.absolutePath,
    object : OtaProgressListener {
        override fun onProgress(current: Int, total: Int) { /* γραμμή προόδου */ }
    })

if (res.status == 0) {
    // το υλικολογισμικό γράφτηκε, η συσκευή επανεκκινεί: το devId δεν ισχύει,
    // επανασύνδεση με νέο ptOpen (μέσω BLE - αναμονή ~10 s)
}
// res.status < 0 - κωδικός ota_result_t (βλ. j2534_ota.h)
// Το ptOtaAbort(devId) διακόπτει την ενημέρωση χωρίς επανεκκίνηση της συσκευής

Έλεγχος καταγραφής από την εφαρμογή - το επίπεδο καταγραφής ορίζεται με το κλειδί log_level στο j2534.json: -1 απενεργοποιημένη, 0 σφάλματα, 1 +προειδοποιήσεις, 2 +info, 3 +debug, 4 +verbose· προεπιλογή 3, δηλαδή χωρίς ρύθμιση η καταγραφή γράφεται πλήρως. Στο επίπεδο -1 δεν δημιουργούνται ούτε ο φάκελος sdlogs ούτε το αρχείο .qlog, τίποτα δεν γράφεται στον δίσκο. Στο Android το επίπεδο ορίζεται και από τον κώδικα - ptSetLogLevel(int)· επίπεδο που ορίστηκε έτσι υπερισχύει του αρχείου διαμόρφωσης, οπότε σε release build η καταγραφή δεν μπορεί να ενεργοποιηθεί απ' έξω.
Παράδειγμα
```
// Android: κλήση πριν το ptOpen
j2534.ptSetLogLevel(-1)   // release build - καταγραφή απενεργοποιημένη
j2534.ptSetLogLevel(3)    // αίτημα υποστήριξης - πλήρης καταγραφή

// Υπόλοιπες πλατφόρμες: j2534.json στον φάκελο διαμόρφωσης
//   macOS   ~/Library/Application Support/Quantex/
//   Linux   ~/.config/quantex/
//   Windows %APPDATA%\Quantex\
{ "log_level": -1, "devices": [] }
```

Διορθώσεις

Έκδοση βιβλιοθήκης στο Android - το PassThruReadVersion και η κεφαλίδα του .qlog επέστρεφαν 2.0.0.0: ο αριθμός build δεν περνούσε στο build Android. Η έκδοση προσδιορίζεται τώρα με τον ίδιο κανόνα όπως στις άλλες πλατφόρμες· αυτός ο αριθμός αναφέρεται στα αιτήματα υποστήριξης.
Σύνδεση (linking) της βιβλιοθήκης iOS - το build της εφαρμογής αποτύγχανε σε εννέα ανεπίλυτα σύμβολα serial_*: η μεταφορά USB εξαιρείται από το build iOS, αλλά οι κλήσεις προς αυτήν παρέμεναν. Η μεταφορά αντικαταστάθηκε από stub - σύνδεση με συμβολοσειρά c: επιστρέφει κανονικό σφάλμα ανοίγματος θύρας.
Περικοπή δεδομένων στο αρχείο .qlog - τα δεδομένα μηνύματος γράφονταν μόνο έως 125 bytes και η εγγραφή ομάδας μηνυμάτων από μία κλήση PassThruReadMsgs ή PassThruWriteMsgs περιοριζόταν από σταθερή προσωρινή μνήμη. Το μήνυμα και ολόκληρη η ομάδα γράφονται τώρα πλήρως - σημαντικό για μακριές απαντήσεις, π.χ. λίστα DTC.
Αποκωδικοποίηση πεδίων στο αρχείο .qlog - η βιβλιοθήκη και η συσκευή παρήγαγαν το κείμενο καταγραφής με δύο ανεξάρτητες υλοποιήσεις και η αποκωδικοποίηση των ίδιων τιμών διέφερε. Την ένδειξη εγκατεστημένης σύνδεσης TP2.0 και TP1.6 στο πεδίο RxStatus η βιβλιοθήκη τύπωνε ως CONNECTION_ESTABLISHED, η συσκευή ως CONN_OK· τα ονόματα IOCTL διέφεραν σε 22 σημεία. Τα ονόματα πρωτοκόλλων, ενδείξεων TxFlags και RxStatus, IOCTL και των παραμέτρων τους παράγονται τώρα από μία υλοποίηση, ώστε η καταγραφή της εφαρμογής και της συσκευής για την ίδια ανταλλαγή να διαβάζονται δίπλα-δίπλα.

DLL 2.0.0.200, υλικολογισμικό build 83 04.08.2026

Λήψη βιβλιοθηκών J2534 2.0.0.200 - Windows x86/x64/ARM64 (ξεχωριστά builds για Windows 7), macOS (universal), Linux (x64, x86, ARM, ARM64), Android (arm64-v8a, armeabi-v7a, x86, x86_64), iOS.

Υλικολογισμικό - build 83

Νέα

DoIP (ISO 13400) και BMW HSFZ - νέα πρωτόκολλα ISO13400_PS (0x8FFD) και HSFZ_PS (0x8FFC). Δεν ανήκουν στο πρότυπο SAE J2534 - είναι ιδιόκτητη επέκταση ScanDoc: διάγνωση μέσω Ethernet - εντοπισμός οχημάτων στο δίκτυο (VIN, λογική διεύθυνση), σύνδεση TCP, routing activation, ανταλλαγή UDS. Η διεύθυνση tester είναι προεπιλεγμένα 0 - ορίστε το ISO13400_SOURCE_ADDR πριν από το routing activation, αλλιώς η πύλη θα αρνηθεί· η διεύθυνση του ECU μεταδίδεται σε κάθε μήνυμα ([TA][SA][UDS]), το ISO13400_TARGET_ADDR δεν ορίζεται μέσω Set/GetConfig. Η αποστολή σειριοποιείται με P2: ένα εκκρεμές αίτημα UDS κάθε φορά, το NRC 7F xx 78 παρατείνει την αναμονή έως P2*max (6 s). Νέα παράμετρος καναλιού ISO13400_P3_DOIP (0x8108) - παύση μεταξύ μηνυμάτων.
Παράδειγμα
```
uint32_t ch, code = 0;
pt_config_t sa  = { ISO13400_SOURCE_ADDR, 0x0E80 };
pt_config_list_t cfg = { 1, &sa };

PassThruConnect(dev, ISO13400_PS, 0, 0, &ch);
PassThruIoctl(ch, SET_CONFIG, &cfg, NULL);                 /* SA - πριν από το routing activation */
PassThruIoctl(ch, ISO13400_DISCOVER_VEHICLES, NULL, NULL); /* η IP του ECU απομνημονεύεται αυτόματα */
PassThruIoctl(ch, ISO13400_CONNECT_TCP, NULL, NULL);
PassThruIoctl(ch, ISO13400_ACTIVATE_ROUTING, NULL, &code); /* 0x10 = επιτυχία */
/* έπειτα PassThruWriteMsgs / PassThruReadMsgs - κανονικό UDS */
```
Διάγνωση διαύλου - το bus-off (κομμένη καλωδίωση/βραχυκύκλωμα, χωρίς ACK) και η λανθασμένη ταχύτητα CAN επιστρέφουν πλέον κατατοπιστικό κείμενο σφάλματος με το baud rate αντί για γενικό κωδικό αποτυχίας.
Μία θύρα TCP για J2534 και ELM327 - η ξεχωριστή θύρα 35000 του ELM327 καταργήθηκε, και τα δύο πρωτόκολλα εξυπηρετούνται στη θύρα εντολών 53983. Το πρωτόκολλο αναγνωρίζεται από το πρώτο byte της σύνδεσης: 0x55 (δείκτης πλαισίου J2534) - J2534, οτιδήποτε άλλο (εντολή AT σε κείμενο) - ELM327.
BLE - εναλλασσόμενη διεύθυνση MAC (RPA): οι σαρωτές βλέπουν τυχαία διεύθυνση, οι συζευγμένες συσκευές την επιλύουν μέσω IRK· γίνονται δεκτές μόνο συνδέσεις Secure Connections.

Διορθώσεις

Φίλτρα CAN κατά bytes δεδομένων - το PassThruStartMsgFilter συνέκρινε μόνο τα 4 bytes του CAN ID, αγνοώντας το δηλωμένο μήκος φίλτρου. Πλέον το πλαίσιο συγκρίνεται σε όλο το μήκος, όπως απαιτεί το πρότυπο: τα PASS/BLOCK κατά περιεχόμενο πλαισίου λειτουργούν.

/* Καταστολή απαντήσεων TesterPresent (07E8 02 7E ...) στην ουρά λήψης */
pt_msg_t mask = {0}, pattern = {0};
mask.protocol_id = pattern.protocol_id = CAN;
mask.data_size   = pattern.data_size   = 6;   /* 4 bytes CAN ID + 2 bytes δεδομένων */
memcpy(mask.data,    "\xFF\xFF\xFF\xFF\xFF\xFF", 6);
memcpy(pattern.data, "\x00\x00\x07\xE8\x02\x7E", 6);
uint32_t fid;
PassThruStartMsgFilter(ch, BLOCK_FILTER, &mask, &pattern, NULL, &fid);

J2534 - κάθε ληφθέν πλαίσιο παίρνει ατομική χρονοσφραγίδα τη στιγμή της λήψης, όπως απαιτεί η προδιαγραφή (πριν - κοινή ανά δέσμη)· η ηχώ του απεσταλμένου πλαισίου CAN επιστρέφεται μόνο σε επιτυχή αποστολή - η ηχώ σε αποτυχία TX παραπλανούσε τον host για την κατάσταση του διαύλου.
ELM327 - η εντολή AT SH σε ενεργό κανάλι CAN χαλούσε το Flow Control (το FC έφευγε χωρίς padding, DLC=3 - η πύλη δεν έστελνε Consecutive Frames) και αντικαθιστούσε το φίλτρο λήψης με το δικό της TX ID (η λήψη χωρίς AT CRA χαλούσε). Σύμφωνα με το datasheet, το AT SH ορίζει μόνο την κεφαλίδα αποστολής - το φίλτρο λήψης ελέγχεται πλέον μόνο από τα AT CRA/CF/CM.
Σύζευξη BLE με Android 14+ (Pixel) - αποτύγχανε όταν το Fast Pair / Find My Device του συστήματος ξεκινούσε σύζευξη παράλληλα με τη συσκευή.
K-Line/KWP - χανόταν το τελευταίο byte της απάντησης σε πυκνή κίνηση· το μπλοκ ACK έφευγε ~70 ms αργότερα και διέκοπτε την αναγνώριση· το κανάλι κολλούσε μετά από αποτυχημένη σύνδεση.
Το PassThruStopPeriodicMsg μπορούσε να στείλει ένα επιπλέον πλαίσιο μετά τη διακοπή.
TP2.0/TP1.6 _PS - η επιλογή ακίδων μέσω SET_CONFIG(J1962_PINS) δεν εφαρμοζόταν, τα πλαίσια δεν έφταναν στον δίαυλο.
Χειρισμός εσφαλμένων δεδομένων - επικύρωση κατεστραμμένων πλαισίων (ISO15765 First/Single Frame, μήκος πακέτου DoIP, συναρμολόγηση TP2.0/TP1.6) και παραμέτρων host (ReadMsgs, IOCTL): αντί να κολλάει ή να αλλοιώνει τη μνήμη, η συσκευή επιστρέφει κανονικούς κωδικούς σφάλματος J2534.

Βιβλιοθήκες J2534 - 2.0.0.200

Διορθώσεις

Το timeout των εντολών ελέγχου μέσω WLAN/LAN αυξήθηκε στα 1000 ms - σε αργά ή φορτωμένα δίκτυα οι εντολές ελέγχου προς τη συσκευή έληγαν με timeout.