Jumping Jack Flash weblog

Hacking Icaro – centralina GSM – il logger seriale

Posted in minicar elettriche by jumpjack on 13 giugno 2019

Questo primo sketch di prova utilizza una board ESP32 per leggere i dati scambiati tra il microcontrollore e il modem della scheda GSM/GPS della Icaro: vengono letti contemporaneamente i due canali in modo da mantenere la sincronia tra messaggi inviati e ricevuti, e poter meglio ricostruire il dialogo.

Al momento la “registrazione” viene effettuata solo inviando l’output al serial monitor dell’Arduino IDE; una successiva versione memorizzerà i dati o in una SD card, o su un server remoto, in modo che il logger possa essere montato direttamente sul veicolo senza necessità di un PC.

Trattandosi di un generico logger seriale a due canali, può in realtà essere usato per “sniffare” qualunque altra comunicazione seriale tra due dispositivi, o anche per loggare un singolo dispositivo.

Il numero a inizio linea identifica il canale cui si riferisce la linea stessa.


// Greengo/Zhidou/Xindayang GSM logger
// Read data from GSM/GPS logger, from both MCU and MODEM outputs and same time
// using ESP32 board.
// V. 0.1.0 - First working version; logs only to USB/serial port (PC needed).
String tempVal = "";
String row0 = "";
String row1 = "";
int MAXLEN = 50;
void setup() {
// initialize serial:
// Recommendation: use Serial0 and 1 for your duplex devices and serial2 for your debug messages.
// https://github.com/espressif/arduino-esp32/issues/1314
//
// Standard serial pinouts:
// https://circuits4you.com/2018/12/31/esp32-hardware-serial2-example/
// UART RX TX CTS RTS
// UART0 GPIO3 GPIO1 N/A N/A
// UART1 GPIO9 GPIO10 GPIO6 GPIO11
// UART2 GPIO16 GPIO17 GPIO8 GPIO7
// But all 3 HW UARTs can be remapped to any pin.

Serial.begin(9600,SERIAL_8N1, 16, 17); // Input 1 (16 = RX)
Serial1.begin(9600,SERIAL_8N1, 4, 2); // Input 2 (4 = RX)
Serial2.begin(9600,SERIAL_8N1, 3,1); // Standard USB-serial port

Serial2.println("Free heap:");
Serial.println(ESP.getFreeHeap());
Serial2.println("--------------------");

}
void loop() {
// read from port 0, send to port 2:
if (Serial.available()) {
int inByte = Serial.read();
/*
Serial2.print("\t0\t0x");
Serial2.print(inByte,HEX);
Serial2.print("\t");
Serial2.print(inByte,DEC);
if (inByte>31) {
Serial2.print("\t");
Serial2.write(inByte);
}
Serial2.println();
*/
tempVal = String(inByte);
row0 += "\t" + tempVal;
if (row0.length() > MAXLEN) {
Serial2.print("0\t");
Serial2.println(row0);
row0="";
}
}
// read from port 1, send to port 2:
if (Serial1.available()) {
int inByte = Serial1.read();
/*
Serial2.print("\t1\t0x");
Serial2.print(inByte,HEX);
Serial2.print("\t");
Serial2.print(inByte,DEC);
if (inByte>31) {
Serial2.print("\t");
Serial2.write(inByte);
}
Serial2.println();
*/
tempVal = String(inByte);
row1 += "\t" + tempVal;
if (row1.length() > MAXLEN) {
Serial2.print("1\t");
Serial2.println(row1);
row1="";
}
}

}
Tagged with: , , , , , ,

Hacking Icaro – il motor controller o centralina

Posted in minicar elettriche by jumpjack on 12 giugno 2019

Premessa

La mia Greengo/Zhidou/Xindayang Icaro modello A1 monta un motor controller della Kelly di tipo KHB72701C, alimentata dai 12V della batteria di servizio e dai 72V della batteria di trazione, che regge 350A continui e 700A di picco (max un minuto).

Considerando un’alimentazione di 72V nominali (che arriva anche a 80V reali a batteria piena), queste correnti corrispondono a 25-28kW continui e 50-56 kW di picco, a fronte dei 6 kW continui assorbiti dal motore della A1 (8 kW di picco nominalmente, che io ho portato a 12 kW riprogrammando il controller).

 

La comunicazione seriale

Oggi finalmente sono riuscito ad avere dalla Kelly un’informazione davvero preziosa: il protocollo di comunicazione tramite porta seriale RS232!

Normalmente usavo la porta seriale per riprogrammare i vari parametri (corrente massima, velocità massima, frenata rigenerativa), tramite l’apposito SW gratuito della Kelly, ma con queste nuove informazioni diventa ora anche possibile leggere una bella quantità di dati:

  1. current physical switch input status
  2. the current Hall sensor “A” signal status
  3. the current Hall sensor “B” signal status
  4. the current Hall sensor “C” signal status
  5. Copying flash data to ram before flash data reading operation
  6. controller’s model no
  7. controller’s SW version (BCD format)
  8. controller’s Throttle low-end dead zone
  9. controller’s Throttle high-end dead zone
  10. controller’s Brake low-end dead zone
  11. controller’s Brake high-end dead zone

E poi i livelli di questi valori analogici:

Gruppo 1 (comando ETS_A2D_BATCH_READ)

0. Brake (posizione pedale freno)

  1. TPS (posizione pedale acceleratore)
  2. Motor temperature
  3. Control power
  4. Vs (tensione di riferimento di 5V dei sensori di hall)
  5. B+ (tensione batteria di trazione)
  6. Controller’s temperature
  7. Ia
  8. Ib
  9. Ic
  10. Va
  11. Vb
  12. Vc
  13. H_Temperature
  14. V+ (tensione alimentazione motor controller – 12V nominali)
  15. L_Temperature

 

Gruppo 2 (Comando ETS_MONITOR):

0. n/a

  1. n/a
  2. Controller’s temperature in gradi Celsius
  3. B+ (tensione batteria di trazione)
  4. TPSx (?)
  5. BRAKEx (?)
  6. n/a
  7. I (phase current)
  8. zero current (?)

E infine:

  • 9. MSB of controller’s error state
  • 10. LSB of controller’s error state
  • 11. MSB of mechanical speed in RPM
  • 12. LSB of mechanical speed in RPM

La numerazione è quella della stringa di risposta del controller.

I codici di errore

La codifica dei codici di errore è piuttosto complicata, e si basa su questa tabella:

data[9]M 7 6 5 4 3 2 1 0 data[9]L
0x44 0x43 0x42 0x41 0x34 0x33 0x32 0x31
data[10]M 7 6 5 4 3 2 1 0 data[10]L
0x24 0x23 0x22 0x21 0x14 0x13 0x12 0x11

La sua interpretazione è parecchio complicata, ho provato a semplificarla, innanzitutto affiancando le due sotto-tabelle relative a data[9] e data[10], che sono MSB e LSB della word, risultando così questa tabella:

Le istruzioni dicono “if(data[9] << 8) | data[10]=0x4008,The corresponding error code is 0x43and 0x14.”.

Cioè, “se il numero che si ottiene affiancando data[9] e data[10] come nella tabella qui sopra è uguale a 0x4008, vuol dire che il codice di errore è ‘0x43 e 0x14′

Questo perchè 0x4008 si può scomporre in 4 – 0 – 0 – 8, che in binario diventa 0100 – 0000 – 0000 – 1000, e mettendo questa fila di 1 e 0 sotto la tabella, si ottiene che bisogna considerare le sole caselle in coincidenza degli 1, ottenendo quindi appunto 0x43 e 0x14.

Al momento però non dispongo ancora di una tabella che dica cosa significhino questi numeri, vedrò se riesco a farmela dare.

Intanto però ecco un’altra tabella, che riassume tutti i comandi elencati nella nota tecnica che mi hanno mandato:

 

La tabella sopra descrive il formato della stringa di comando da inviare sulla seriale, quella sotto la risposta ricevuta.

A me pare che le caselle rosse siano sbagliate, perchè dicono che il comando dovrebbe essere lungo un byte ma io ne vedo 2, quindi dovrò chiedere chiarimenti… anche se al momento lo stato dei sensori di hall è decisamente la cosa che mi interessa di meno.

Le ultime due righe della tabella sotto, anche se si leggono poco, contengono i dati descritti estesamente a inizio articolo.

Adesso devo “solo” o trovare un programma per leggere/scrivere dati grezzi sulla seriale,… o scrivermelo.

La documentazione

Cercando su google il titolo del documento che la Kelly mi ha mandato ho trovato due link utili:

C’è poi anche la risposta a un mio vecchio post su Endlesssphere, che suggerisce che le Kelly aderiscano allo standard SAE J1939-21 , che permetterebbe di leggere questi dati:

[*]The running direction
[*]The high and low speed
[*]Mode selection
[*]Speed low byte (motor rpm)
[*]Speed high byte (motor rpm)
[*]Low power consumption mode
[*]Subtotal mileage. low byte
[*]Subtotal mileage. high byte
[*]Fault code
[*]DC voltage- low byte
[*]DC voltage – high byte
[*]Motor current- low byte
[*]Motor current – high byte

Questo potrebbe essere un dispositivo utile per collegarsi al CANBUS, tramite PC o tramite Arduino:

https://www.cooking-hacks.com/documentation/tutorials/can-bus-module-shield-tutorial-for-arduino-raspberry-pi-intel-galileo

 

Hacking Icaro – puntata 4, il computer di bordo – 22 marzo 2019

Posted in minicar elettriche by jumpjack on 22 marzo 2019

Ho trovato un manuale relativo a un  computer di bordo della Etheria (con l’H) sul sito della Eteria  (senz’H)…. che potrebbe forse essere lontanamente utile anche per il computer di bordo della icaro:

OBC – ONBORD COMPUTER – DigiLance Line – DISPOSITIVO DI CONTROLLO DI BORDO E SUPPORTO REMOTO – ver. 1.80

A vederla è totalmente diversa da quella della Icaro, ma chissà…

Ecco alcuni passi interessanti del manuale:

Il Firmware che gestisce TMI/VT è in costante aggiornamento e gli aggiornamenti sono a disposizione dei
possessori dei dispositivi TMI/VT regolarmente acquistati.
Sono disponibili sul sito http://www.Etheria.it nell’Area di Supporto al Cliente. L’ aggiornamento, una volta
scaricato, va copiato su una chiave USB per i TMI e su una scheda SD per i VT. Dovrebbe essere un file
denominato DE_update.zip. Va copiato nella directory principale della chiave USB/scheda SD.
Gli aggiornamenti permettono di migliorare le prestazioni di TMI/VT e/o di fornire delle nuove funzionalità. Si
consiglia quindi di aggiornare costantemente TMI/VT all’ultima versione disponibile per il proprio dispositivo.
Controllate quindi periodicamente sul sito http://www.Etheria.it o contattate l’assistenza per verificare se sono
disponibili nuovi aggiornamenti.

 

C’è anche qualcosa a proposito di “sequenze speciali” per attivare una “modalità avanzata”, necessaria per aggiornare il firmware, ma anche per salvare in una chiavetta USB il log di tutte le trasmissioni effettuate:

[….]

PREMESSA: per la prossima operazione si deve considerare l’area appena sotto il pulsante MENU come esso stesso un pulsante; cioè sarà necessario premere col dito tale zona come se vi fosse un pulsante; tale zona di seguito sarà chiamato SPAZIO

4) E’ necessario entrare nella schermata di Configurazione Avanzata; per fare ciò è necessario tenere premuto il pulsante finché non viene emesso un segnale acustico ed il pulsante non torna alla colorazione da non premuto; a questo punto premere in rapida sequenza i seguenti pulsanti (la sequenza va completata in meno di 3 secondi da quando è stato emesso il segnale acustico per la pressione prolungata di ):
SPAZIO – MENU – SPAZIO – MENU

Attendere che compaia una schermata con un tastierino numerico ed alcuni altri pulsanti. Se non dovesse apparire ripetere la sequenza precedente, premendo con sufficiente decisione e rapidità.

5) Premere il tasto “Aggiorna” come mostrato in figura

Poi c’è anche:

Le procedure di Ripristino sono attuabili tramite l’avvio del TMI/VT in modalità denominata Safe. Non sono
eseguibili in condizioni di utilizzo normali.

E questa strana procedura:

Seguire questa procedura per arrivare al Menù Avvio e Calibrazione:
1. Spegnere completamente il TMI/VT.
2. Per questo passo è necessaria rapidità di intervento e precisione: leggere quanto segue prima di avviare TMI/VT.
Avviando il TMI/VT da spento compare un primo logo su TMI (aspettare il secondo su VT) .
Quando appare premere lo schermo tempestivamente, in un punto qualsiasi […]
Seguendo le istruzioni premere per 3 volte lo schermo in un punto qualsiasi entro 2 secondi.
Se la procedura è eseguita correttamente apparirà un schermata con 2 pulsanti e la scritta “Premere un pulsante per effettuare la scelta desiderata, oppure cliccare su qualsiasi altro punto per ricalibrare”.

Invece questo potrebbe essere un problema, visto che non rispondono al telefono:

Ripristino: Contattare l’assistenza del prodotto per effettuarla (è un’operazione complessa e delicata).

Molto interessante invece questa parte:

Appendice E. Salvataggio su chiave USB dei log
Avviare il TMI/VT normalmente. Per procedere al salvataggio log seguire i seguenti passi:
1) Seguire la procedura illustrata nell’Appendice A nei punti da 2 a 4
2) Digitare il Codice Ripristino o Installatore, fornito dall’installatore. E’ un codice di 8 cifre che attiva
varie funzioni di configurazione avanzata
3) Premere il pulsante Salva Log e seguire le istruzioni (inserire una chiave USB/scheda SD
nell’apposita fessura ed attendere il salvataggio del file “Logs_TMI.zip”, un file compresso che
contiene i vari log di sistema suddivisi in file)
Se presente il modulo OPZIONALE Modem tra essi ci saranno i file contenenti:
• le chiamate effettuate e ricevute
• gli stati inviati
• i messaggi ricevuti ed inviati.

Tagged with: , , ,

Hacking Icaro GSM – puntata 3 (17/3/2019)

Posted in hacking by jumpjack on 17 marzo 2019

Trovato documento specifico del modulo G600 descrivente in dettaglio la connessione PPP: http://d1.amobbs.com/bbs_upload782111/files_35/ourdev_610405OJVGOK.pdf

PPP spiegato passo passo e campo per campo (ma in cinese): http://www.synrich.com/Download/PIML-PLUS/GPRS_TCP%20Guide.pdf

PPP spiegato in inglese con un (singolo) esempio: http://lateblt.tripod.com/bit60.txt

PPP spiegato in inglese con molti esempi: http://www.powerfast.net/maxtnt/~ascend/MaxTNT/admin/ppprime.htm

Spiegazione molto completa: http://support.huawei.com/enterprise/docinforeader!loadDocument1.action?contentId=DOC1000001581&partNo=10062#sec_vsp_fea_ppp_0007_mMcCpPsS_fig02

Incapsulamento IP/UDP/TCP: http://www.netfor2.com/contents.htm

Esempio di trasmissione reale (forum): https://os.mbed.com/forum/mbed/topic/1551/


Dati grezzi registrati in comunicazione tra microcontrollore (MCU) e modulo GSM (G600)

In invio (MCU –> G600)

  1. 7E 3F 7D 23 3F 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 25 7D 26 65 67 6C 6A 7D 27 7D 22 7D 28 7D 22 3F 6D 7E
  2. 7E 3F 7D 23 3F 21 7D 22 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 23 7D 24 3F 23 7D 27 7D 22 7D 28 7D 22 3F 3F 7E
  3. 7E 3F 23 01 02 47 50 52 53 7E
  4. 7E 3F 7D 23 3F 21 7D 21 7D 23 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 2A 3F 7E
  5. 7E 3F 23 01 04 7E
  6. 7E 3F 21 01 05 7E
  7. 7E 3F 21 01 06 2F 7E
  8. 7E 3F 21 01 07 03 06 7E
  9. 7E 3F 21 02 01 7E
  10. 7E 3F 21 01 08 3F 3F 7E
  11. 7E 21 45 3F 04 5F 6E 3F 16 04 2D 07 3F 01 02 08 09 28 08 3F 61 7E
  12. 7E 21 45 3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6C 73 7E
  13. 7E 21 45 30 3F 16 04 02 20 3F 3F 7E
  14. 7E 21 45 7D 5D 3F 04 5F 6E 3F 16 04 12 34 56 78 02 04 05 3F 01 01 04 02 4A 67 7E
  15. 7E 21 45 6E 3F 16 04 70 02 20 3F 3F 7E
  16. 7E 21 45 06 7B 3F 04 5F 6E 3F 16 04 12 34 56 78 7E
  17. 7E 21 45 5F 6E 3F 16 04 04 02 3F 3F 7E
  18. 7E 21 45 0B 3F 12 34 56 78 7E
  19. 7E 21 45 04 5F 6E 3F 16 04 01 04 02 3F 3F 7E
  20. 7E 21 45 3F 71 7E
  21. 7E 21 45 3F 04 5F 6E 3F 16 04 3F 01 01 04 02 49 3A 7E
  22. 7E 21 45 04 7E
  23. 7E 21 45 74 3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6F 2E 7E
  24. 7E 21 45 30 3F 16 04 02 20 3F 7E

In ricezione (MCU <– G600)

(C021 = LCP, C023 = PAP, autenticazione, 8021 = IPCP,  02 10 = ?!?)
  1. 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 23 7D 24 C0 23 7D 27 7D 22 7D 28 7D 22 DD 94 7E
  2. 7E FF 7D 23 C0 21 7D 24 7D 21 7D 20 7D 2A 7D 25 7D 26 65 67 6C 6A 60 85 7E
  3. 7E FF 7D 23 C0 21 7D 22 7D 23 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 7D 34 BC 7E
  4. 7E   C0 23   02 04 00 05 00   AA 5E    7E
  5. 7E   80 21   03 05  0003  06 00 00 00 00   C6 A1   7E
  6. 7E   80 21   03 06  0003  06 00 00 00 00   C1 77   7E
  7. 7E   02 10   10 10 00 4B B9 9   7E
  8. 7E  80 21   03 07  0003  06B506E6   8583   7E        
  9. 7E  80 21   02 08  0003  06B506E6   8A39   7E

 

Decodifica di un pacchetto PPP singolo

Il carattere 7d è un carattere di escape: se è presente, significa che per il byte successivo bisogna fare uno XOR con 0x20 (in pratica sottrarre 0x20) ; quindi 7d 20 diventa 00, oppure 7d 38 diventa 18, e così via.

Ricezione

7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 23 7D 24 C0 23 7D 27 7D 22 7D 28 7D 22 DD 94 7E

Decodificato

  • 7E FF 03 C0 21 01 01 00 12 02 06 00 00 00 00 03 04 C0 23 07 02 08 02 DD 94 7E

Raggruppato per campi

  • 7E FF 03   C0 2101 01 00 12   02 06 00 00 00 00   03 04 C0 23   07 02   08 02   DD 94   7E

Commentato

  • 7E  – Inzio pacchetto PPP
  • FF – Destinatario (FF=tutti)
  • 03 –  Sempre 03 (?)
  • C0 21       –  Protocollo LCP (negoziazione iniziale)
  • 01 01 00 12   02 06 00 00 00 00   03 04 C0 23   07 02   08 02 – Contenuto del pacchetto LCP
  • DD 94   – Checksum (chiamata “FCS”)
  • 7E         – Terminatore PPP

 

Decodifica del pacchetto LCP (protocollo descritto in RFC1661)

  • 01 – Richiesta
  • 01 – Id della  richiesta (arbitrario)
  • 00 12 – Lunghezza totale della richiesta, inclusi questi 2 byte e i due precedenti (decimale 14)
  • 02 06 00 00 00 00  – Prima opzione da configurare. Decodifica:
    • 02 – xxxx
    • 06 – Lunghezza, incluso questo byte e il precedente
    • 00 00 00 00 – Payload
  • 03 04 C0 23   – Seconda opzione da configurare. Decodifica:
    • 03 – xxx
    • 04 – Lunghezza, incluso questo byte e il precedente
    • C0 23 – Payload
  • 07 02   – Terza opzione da configurare. Decodifica:
    • 07 – xxx
    • 02 – Lunghezza, incluso questo byte e il precedente; quindi il payload ha lunghezza nulla
    • Payload vuoto –> usare valore di default per questa opzione
  • 08 02 – Quarta opzione da configurare. Decodifica:
    • 08 – xxx
    • 02 – Lunghezza, incluso questo byte e il precedente; quindi il payload ha lunghezza nulla
    • Payload vuoto –> usare valore di default per questa opzione

Pacchetti decodificati

INVIO

  1. 7E 3F 03 3F 21 01 01 00 14 02 06 00 00 00 00 05 06 65 67 6C 6A 07 02 08 02 3F 6D 7E
  2. 7E 3F 03 3F 21 02 01 00 12 02 06 00 00 00 00 03 04 3F 23 07 02 08 02 3F 3F 7E
  3. 7E 3F 23 01 02 47 50 52 53 7E
  4. 7E 3F 03 3F 21 01 03 00 0E 02 06 00 00 00 00 07 02 08 02 2A 3F 7E
  5. 7E 3F 23 01 04 7E
  6. 7E 3F 21 01 05 7E
  7. 7E 3F 21 01 06 2F 7E
  8. 7E 3F 21 01 07 03 06 7E
  9. 7E 3F 21 02 01 7E
  10. 7E 3F 21 01 08 3F 3F 7E
  11. 7E 21 45 3F 04 5F 6E 3F 16 04 2D 07 3F 01 02 08 09 28 08 3F 61 7E
  12. 7E 21 45 3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6C 73 7E
  13. 7E 21 45 30 3F 16 04 02 20 3F 3F 7E
  14. 7E 21 45 7D 3F 04 5F 6E 3F 16 04 12 34 56 78 02 04 05 3F 01 01 04 02 4A 67 7E
  15. 7E 21 45 6E 3F 16 04 70 02 20 3F 3F 7E
  16. 7E 21 45 06 7B 3F 04 5F 6E 3F 16 04 12 34 56 78 7E
  17. 7E 21 45 5F 6E 3F 16 04 04 02 3F 3F 7E
  18. 7E 21 45 0B 3F 12 34 56 78 7E
  19. 7E 21 45 04 5F 6E 3F 16 04 01 04 02 3F 3F 7E
  20. 7E 21 45 3F 71 7E
  21. 7E 21 45 3F 04 5F 6E 3F 16 04 3F 01 01 04 02 49 3A 7E
  22. 7E 21 45 04 7E
  23. 7E 21 45 74 3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6F 2E 7E
  24. 7E 21 45 30 3F 16 04 02 20 3F 7E

Ricezione

  1. 7E FF 03 C0 21   01 01 00 12 02 06 00 00 00 00 03 04 C0 23 07 02 08 02   DD 94 7E
  2. 7E FF 03 C0 21   04 01 00 0A 05 06 65 67 6C 6A   60 85 7E
  3. 7E FF 03 C0 21   02 03 00 0E 02 06 00 00 00 00 07 02 08 02   14 BC 7E
  4. 7E C0 23   02 04 00 05 00   AA 5E 7E
  5. 7E 80 21   03 05 00 03 06 00 00 00 00   C6 A1 7E
  6. 7E 80 21   03 06 00 03 06 00 00 00 00   C1 77 7E
  7. 7E 02 10   10 10 00   4B B9 97
  8. 7E 80 21   03 07 00 03 06 B5 06 E6   85 83 7E
  9. 7E 80 21   02 08 00 03 06 B5 06 E6   8A 39 7E

Ulteriore decodifica

Pare che, terminata la negoziazione LCP, si possano “snellire” i pacchetti omettendo l’ “FF 03” iniziale (o 3f 03 in invio) e mettendo subito il protocollo; per qualche motivo questa centralina per i codici di protocollo usa “3f” al posto di “80”, quindi FORSE   3f21 sarebbe C021 (LCP, negoziazione iniziale) ,  3f23 sarebbe C023 (PAP, autenticazione), ma il 3f03 in riga 4 non so cosa sia, mi sa che è un errore e va tolto… quindi lo tolgo:

INVIO

  1. 3F 21   01 01 00 14      (richiesta LCP di 20 byte)
    • 02 06  00 00 00 00
    • 05 06  65 67 6C 6A
    • 07 02
    • 08 02
    • 3F 6D
    • 7E
  2. 3F 21   02 01 00 12    (risposta a richiesta LCP, 18 byte)
    • 02 06   00 00 00 00
    • 03 04   3F 23
    • 07 02
    • 08 02
    • 3F 3F
    • 7E
  3. 3F 23
    • 01 02 47 50 52 53 7E     –    Binario per “GPRS”???
  4. 3F 21   01 03 00 0E
    • 02 06 00 00 00 00
    • 07 02
    • 08 02
    • 2A 3F
    • 7E
  5. 3F 23   01 04    7E
  6. 3F 21   01 05    7E
  7. 3F 21   01 06 2F    7E
  8. 3F 21   01 07 03 06    7E
  9. 3F 21   02 01    7E
  10. 3F 21   01 08 3F 3F    7E
  11. 21 45   3F 04 5F 6E 3F 16 04 2D 07 3F 01 02 08 09 28 08 3F 61 7E
  12. 21 45   3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6C 73 7E
  13. 21 45   30 3F 16 04 02 20 3F 3F 7E
  14. 21 45   7D 3F 04 5F 6E 3F 16 04 12 34 56 78 02 04 05 3F 01 01 04 02 4A 67 7E
  15. 21 45   6E 3F 16 04 70 02 20 3F 3F 7E
  16. 21 45   06 7B 3F 04 5F 6E 3F 16 04 12 34 56 78 7E
  17. 21 45   5F 6E 3F 16 04 04 02 3F 3F 7E
  18. 21 45   0B 3F 12 34 56 78 7E
  19. 21 45   04 5F 6E 3F 16 04 01 04 02 3F 3F 7E
  20. 21 45   3F 71 7E
  21. 21 45   3F 04 5F 6E 3F 16 04 3F 01 01 04 02 49 3A 7E
  22. 21 45   04 7E
  23. 21 45   74 3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6F 2E 7E
  24. 21 45   30 3F 16 04 02 20 3F 7E

Ricezione

  1. 7E FF 03   C0 21   01 01 00 12    02 06 00 00 00 00     03 04 C0 23     07 02     08 02   DD 94 7E – Opzione 2: 0 0 0 0; Opzione 3 (protocollo): C0 23 (CHAP); Opzioni 7 e 8: default confermato
  2. 7E FF 03   C0 21   04 01 00 0A 05 06 65 67 6C 6A   60 85 7E
  3. 7E FF 03   C0 21   02 03 00 0E    02 06 00 00 00 00     07 02     08 02   14 BC 7E
  4. 7E   C0 23   02 04 00 05 00   AA 5E 7E
  5. 7E   80 21   03 05 00 03 06 00 00 00 00   C6 A1 7E
  6. 7E   80 21   03 06 00 03 06 00 00 00 00   C1 77 7E
  7. 7E   80 21 01 01 00 00   4B B9 97  (corretto a mano, forse mancava l’8)
  8. 7E   80 21   03 07 00 03 06 B5 06 E6   85 83 7E
  9. 7E   80 21   02 08 00 03 06 B5 06 E6   8A 39 7E

Eliminando quindi i marcatori di inizio e fine pacchetto, e l’FCS finale, e sostituendo il codice del protocollo col nome del protocollo, abbiamo:

  1. LCP 01 01 00 12   – Risposta a richiesta LCP:
    • 02 06   00 00 00 00 – Ok, opzione 02 va bene a 0 0 0 0
    • 03 04   C0 23 – Risposta a richiesta protocollo di autenticazione: C0 23, PAP
    • 07 02 – Ok, default accettato
    • 08 02 – Ok, default accettato
  2. LCP 04 01 00 0A – Configurazione richiesta non accettata, controproposta per opzione 5:  65 67 6C 6A
    • 05 06   65 67 6C 6A
  3. LCP 02 03 00 0E – Risposta a richiesta LCP n.03
    • 02 06 00 00 00 00
    • 07 02
    • 08 02
  4. CHAP 02 04 00 05 00
  5. IPCP  03 05 00 03 06 00 00 00 00
  6. IPCP  03 06 00 03 06 00 00 00 00
  7. IPCP  01 01 00 00
  8. IPCP   03 07 00 03 06 B5 06 E6
  9. IPCP   02 08 00 03 06 B5 06 E6

Esame di una negoziazione PPP di esempio raffrontata con quella registrata sulla centralina GSM

La MCU invia al G600 questa richiesta; il fatto che sia una richiesta si capisce dal primo “21” dopo “c0 21”, che si traduce in “01” e vuol dire appunto “richiesta”:

esempio: 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 2A 7D 20 7D 20 7D 23 7D 24 C0 23 F3 4D 7E – Config-Req

recmio:                                        7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 23 7D 24 C0 23 7D 27 7D 22 7D 28 7D 22 DD 94    (4 byte in più, in fatti la lunghezza è 0x32 invece che 0x2e)

Contenuto, eliminando header PPP/LCP, footer e 7D e sottraendo 0x20:

esempio: 01  01  00  0E    02  06  00  0A  00  00    03  04 C0 23 F3 4D  (lunghezza tot : 0x0e, dec 14; lunghezza 1: 6, payload = 0 0 0 0; lunghezza 2: 4, paylolad = C0 23)

recmio1:   01  01  00  12 0  2   06  00  00  00  00     03 04 C0 23   07 02   08 02   DD 94 (lunghezza tot: 0x12, dec 18; lunghezza 1: 6, payload= 0 0 0 0; lunghezza 2: 4, payload= C0 23; lunghezza 3: 2, payload vuoto (=default); lunghezza 4: 2, payload vuoto (=default))

recmio2: 04 01 00 0A 05 06 65 67 6C 6A 60 85  – Proposta rifiutata (cod. 04) e controproposta: opzione 05, payload 65 67 6C 6A

recmio3: 02 03 00 0E 02 06 00 00 00 00 07 02 08 02 14 BC – Proposta accettata, opzione 02 vale 0 0 0 0 , opzione 08 impostata a default.

 

Significato:

01 – Packet code: Configure request (direzione: uscita; la risposta ha codice 02)
01 – Packet identifier (a scelta dell’operatore)
000E – Packet length (14 caratteri)
The data field of the build request:
02 – Configuration option being configured; 02 =Asynchronous Control Character Mapping
06 – Length (02 06 00 0A 00 00)
00 0A 00 00 – Configuration value for ACCM
03– Configuration option being configured; 03=Type of authentication protocol
04 – Length (03 04 C0 23)
C023 – CHAP Certification agreement
F34D – FCS
7E – PPP Terminator Flag

 

Il G600 risponde con questo (il fatto che è una risposta è indicato dal valore “22” dopo C0 21, che va letto come  “02”):

7EFF7D23C0217D227D217D207D2E7D227D267D207D2A7D207D207D237D24C023CDCE7E LCP – Config-Ack

Senza intestazione, senza 7d e senza XOR 0x20:
02 01 00 0E 02 06 00 0A 00 00 03 04 C0 23 CD CE
Agree to the option to build a chain request.

02 – Configurazione ricevuta (e di seguito viene ripetuta)

 

MCU invia a G600:

7EFF7D23C0217D217D227D207D2A7D227D267D207D207D207D205FAD7E LCP – Config-Req

Senza intestazione, senza 7d e senza XOR 0x20:
01 02 00 0A 02 06 00 00 00 00 5F AD

CMNET’s build request.

Accettazione:

7EFF7D23C0217D227D227D207D2A7D227D267D207D207D207D2036D97E LCP – Config-Ack
Remove 7d:
02 02 00 0A 02 06 00 00 00 00 36 D9

——–

PAP (RFC1334)
PAP is a password authentication protocol, and its handshake process is consistent with the LCP protocol.
Config-Req
7E FF 03 C023 0100000D0753796E7269636800233C 7E – PAP – Config-Req
7E FF 03 C023 0200000D084C6F67696E204F4B3259 7E – PAP – Config-Ack

————-
IPCP (RFC1332)
The IPCP protocol is a process for obtaining an IP address from CMNET.

  1. Caso 1: IP dinamico
    >>>> 7E FF 03 8021  01 05  00 0A 03 06 00 00 00 00 F6 7D 37 7E – Codice 3: propongo IP 0.0.0.0, cioè chiedo un IP dinamico; la risposta è al punto 4, si riconosce dall’ID che è uguale a questo (05): il server propone un suo IP, il client lo ritrasmette per accettazione (punto 5) e il server lo re-invia per accettazione finale (punto 6).
  2. Caso 2: IP statico
    >>>> 7E FF 03 8021   01 01  00 0A 03 06 C0 C8 01 15   66 81 7E – Il client propone un suo IP prefissato (C0 C8 01 15, 192.200.1.15)
  3. <<<< 7E FF 03 8021   02 01 00 0A 03 06 C0 C8 01 7D 35 0F F5 7E – Il server accetta l’IP rispondendo con l’IP stesso, ma c’è un errore nel documento: il “15” finale è indicato col carattere di escape, quindi è diventato “7d 35”.
  4. <<<< 7E FF 03 80 21 03 05 00 0A 03 06 0A 67 CC A2 4C FF 7E – In risposta alla richiesta di IP dinamico, il server ne propone uno:  0A 67 CC A2  (10.103.204.162)
  5. >>>> 7E FF 03 80 21 01 05 00 0A 03 06 0A 67 CC A2 02 A7 7E – Il client ritrasmette l’IP in segno di accettazione.
  6. <<<< 7E FF 03 80 21 02 05 00 0A 03 06 0A 67 CC A2 6B D3 7E – Il server ri-ritrasmette l’IP per conferma finale.

 


Significato “command code” o “packet code” (v. anche link)

  • 01 Configure-Request
  • 02 Configure-Ack
  • 03 Configure-Nak
  • 04 Configure-Reject
  • 05 Terminate-Request
  • 06 Terminate-Ack
  • 07 Code-Reject
  • 08 Protocol-Reject
  • 09 Echo-Request
  • 10 Echo-Reply
  • 11 Discard-Request

Elenco protocolli (evidenziati quelli più usati)

  • 00 21 – Internet Protocol (IP)
  • C0 21 – Link Control Protocol (LCP)
  • C0 23 – Password Authentication Protocol (PAP)
  • C2 23 – Challenge Handshake Authentication Protocol (CHAP)
  • 80 21 – IP Control Protocol  (da non confondere con “IP” semplice! )
  • 80 29 – Appletalk Protocol
  • 80 2B – Novell’s Internetwork Packet Exchange (IPX)
  • 80 31 – Bridging PDU
  • 80 FD – Compression Control Protocol (CCP)

 

Scopo dei protocolli:

Link Control Protocol (LCP) checks among other things the condition of the line by sending a large (4 byte-hex) randomly chosen number (Magic Number) which needs to be returned by the receiving part.

Password Authentication Protocol (PAP) or Challenged Authentication Protocol (CHAP) checks the password either sent in clear (PAP) or encrypted (CHAP).

Internet Protocol Control Protocol (IPCP) is utilized to assign an IP address to the PC, to determine if compression will be used and to setup the configuration of the packets
encapsulated within PPP frames.

Nota: l’IPCP non è l’IP: con l’IPCP si stabilisce qual è l’indirizzo da usare per il protocollo IP.


Opzioni LCP configurabili (RFC 1661)

  • 01 – Dimensioni massime pacchetto
  • 03 – Protocollo di autenticazione (PAP oppure CHAP)
  • 04 – Link quality protocol
  • 05 – Magic number – Usato per verificare che durante la trasmissione i dati non siano alterati
  • 07 – Protocol field compression
  • 08 – Address and control field compression

Opzioni protocollo IPCP

0x03: Negoziazione indirizzo IP  (http://www.uniroma2.it/didattica/netsec/deposito/1_ppp.pdf , pag. 38)

Statico: client comunica il suo IP e server conferma

Dinamico: client invia IP 0.0.0.0 e server invia rifiuto (nack) e propone IP; client allora invia richiesta con l’IP appena ricevuto, e server accetta (ack).

Tutte:

1 IP-Addresses (deprecated). RFC 1332
2 >= 14 IP-Compression-Protocol. RFC 1332RFC 3241RFC 3544
3 6 IP-Address. RFC 1332
4 6 Mobile-IPv4. RFC 2290
129 6 Primary DNS Server Address. RFC 1877
130 6 Primary NBNS Server Address. RFC 1877
131 6 Secondary DNS Server Address. RFC 1877
132 6 Secondary NBNS Server Address. RFC 1877
Tagged with: , , , ,

Hacking Icaro: centralina GSM – puntata 2 (16/3/2019)

Posted in hardware by jumpjack on 16 marzo 2019

Puntata precedente: https://jumpjack.wordpress.com/2019/03/10/esame-della-centralina-gsm-gps-greengo-icaro/

Sostituendo la SIM originale della movistar con una generica SIM Wind, sono riuscito ad ottenere l’aggancio alla rete GPRS!

Purtroppo il comando di connessione non è molto chiaro:

AT+CGDCONT=1,”IP”,”%1?….4.?..b#”

Il terzo parametro dovrebbe essere l’indirizzo IP dell’APN dell’operatore…. ma sembra scritto in codice binario invece che come stringa, quindi non si capisce a chi tenti di collegarsi.

In binario: 25 31 3F 10 10 06 04 34 07 3F 01 02 62 23

La buona notizia è che però a questo comando della MCU, e al successivo ATD*99***1# ,  il modulo GSM risponde con CONNECT, quindi l’aggancio avviene di sicuro.

…dopodichè non si capisce più niente: tutta la comunicazione passa da testuale (comandi AT) a binaria!

Leggendo come testo quello che la MCU invia al modem… si vede questo:


~?}#?!

}!}!} }4}"}&} }

 } } }%}&eglj}'}

"}(}"?m~

~?

}#?!}"}!} }2}"}&

} } } } }#}$?#}

'}"}(}"??~

~?#GPRS~?}#?!}!}#

} }.}"}&} } } }

 }'}"}(}"*?~

~?#~

~?!~?!/~

~?!~?!~?!??~

~!E?

_n?-? (?a~

~!E

?

_n?x?ls~

~!E0? ??~

~!E

}]

?

_n?4Vx?Jg~

~!En?p ??~

~!E

{

?

_n?4Vx~!

E_n???~

~!E?4Vx~

!E

_n???~

~!E?q~!E?

_n??I:~

~!E~

~!Et

?

_n?x?o.~

~!E0? ?~

Espresso in esadecimale non è che sia molto più chiaro…:
7E3F7D233F21
7D217D217D207D347D227D267D207D
207D207D207D257D2665676C6A7D277D
227D287D223F6D7E
7E3F
7D233F217D227D217D207D327D227D26
7D207D207D207D207D237D243F237D
277D227D287D223F3F7E
7E3F230102475052537E3F7D233F217D217D23
7D207D2E7D227D267D207D207D207D
207D277D227D287D222A3F7E
7E3F2301047E
7E3F2101057E3F2101062F7E
7E3F21010703067E3F2102017E3F2101083F3F7E
7E21453F04
5F6E3F16042D073F0102080928083F617E
7E2145
3F04
5F6E3F160478053F010104026C737E
7E2145303F160402203F3F7E
7E2145
7D5D
3F04
5F6E3F1604123456780204053F010104024A677E
7E21456E3F16047002203F3F7E
7E214506
7B
3F04
5F6E3F1604123456787E21
455F6E3F160404023F3F7E
7E21450B3F123456787E
214504
5F6E3F16040104023F3F7E
7E21453F717E21453F04
5F6E3F16043F01010402493A7E
7E2145047E
7E214574
3F04
5F6E3F160478053F010104026F2E7E
7E2145303F160402203F7E
Tutta roba incomprensibile, però qui c’è qualche indizio su cui investigare:
https://www.embeddedrelated.com/showthread/comp.arch.embedded/40457-1.php
Potrebbe cioè trattarsi di una comunicazione su protocollo PPP; devo quindi o studiarmi il protocollo a basso livello, o trovare un decodificare automatico.

Questo è invece quello che risponde il modem subito dopo aver risposto CONNECT:
~ÿ}#À!}!}!} }2}"}&} } } } }#}$À#}'}"}(}"Ý”~~ÿ}#À!}$}!} }*}%}&eglj`…~~ÿ}#À!}"}#} }.}"}&} } } } }'}"}(}"}4¼~~À#
In hex:

7EFF7D23C0217D217D217D207D327D227D267D207D207D207D207D237D24C0237D277D227D287D22DD947E7EFF7D23C0217D247D217D207D2A7D257D2665676C6A60857E7EFF7D23C0217D227D237D207D2E7D227D267D207D207D207D207D277D227D287D227D34BC7E7EC0230204000500AA5E7E7E8021030500
030600000000C6A17E7E8021030600
030600000000C1777E7E802101010004BB997E7E8021030700
0306
B506E685837E7E8021020800
0306
B506E68A397E

Tutto questo avviene al banco, con la centralina scollegata dalla icaro.


Alcuni link utili:
Protocollo PPP:
http://www.powerfast.net/maxtnt/~ascend/MaxTNT/admin/ppprime.htm
http://www.netfor2.com/ppp.htm
Decoder:
https://hpd.gasmi.net/  – hex decoder generico – 1
http://packetor.com/ – hex decoder generico – 2

 

Tagged with: , , , ,

Hacking Icaro: centralina GSM/GPS – puntata 1 (3/3/2019)

Posted in hacking, hardware, minicar elettriche by jumpjack on 10 marzo 2019

L’anno scorso ho provato a smontare ed esaminare la centralina GPS/GSM che rende(va) la Icaro (o meglio i.car.0) una “interconnected car”, inviando a una centrale di monitoraggio remoto decine e decine di telemetrie, come descritto in questo thread:

https://www.forumelettrico.it/forum/centralina-gsm-gps-t2437.html

Alcune foto della centralina.

Qui si vede il contenitore dell SIM card e un connettore a pettine a 12 pin:

Questo è il modulo GPS, un “GA71 V4.0 SiRF star III” a 20 canali:

 

Alcune marcature utili per l’identificazione:

Visione d’insieme; in alto la batteria-tampone ricaricabile al NiMH da 3.6V:

Questi pin, apparentemente interessanti… si sono rivelati completamente muti e inutili:

 

 

Quelli che invece si sono rivelati molto interessanti sono quelli dello strip maschio a 12 pin: collegandolo a un adattatore TTL/seriale per il PC, sono riuscito a dare una sniffata, scoprendo questo:

Per il momento non sono riuscito ad agganciare la rete, nemmeno togliendo la SIM originale e mettendo la mia, ma farò ovviamente altre prove.

Probabilmente, infatti, solo una volta che la scheda riesce ad agganciare la rete fa un tentativo di agganciarsi ai server remoti che un tempo leggevano queste telemetrie; bisogna vedere poi:

  • se la scheda aspetta una risposta dal server prima di inviare dati, o se li invia “a fondo perduto”
  • se è possibile riprogrammare a mano l’indirizzo a cui la scheda tenta di collegarsi
  • varie ed eventuali

Comandi AT:

Hex editors con evidenziazione sintassi

Posted in Uncategorized by jumpjack on 22 luglio 2018

Flex Hex

http://www.flexhex.com/product/features.phtml

Permette di:

  • Definire strutture complesse di dati tramite costrutti in linguaggio C, anche di dimensioni variabili a seconda di valolri nel file
  • Effettuare ricerche multiple contemporanee con risultati multipli
  • Evidenziare intervalli
  • Evidenziare pattern
  • Definire segnalibri
  • Salvare e ricaricare da file le suddette definizioni

 

FRHED

Ne esistono almeno tre varianti diverse, indipendenti e ferme in vari stadi di sviluppo:

  • SourceForce (kimmov)- Ultimo aggiornamento: 2009
  • GITHUB (alistairmcmillan)- Ultimo aggiornamento: 2012
  • Bitbucket (jtuc)- Ultimo aggiornamento: giugno 2018

Il programma è stato creato nel 1998. Sembra che dal 2008 sia stato incluso dentro a Winmerge, che si trova su BitBucket. Però WinMerge è presente anche su SourceForge, dove la versione stabile più recente sembrerebbe essere la 2.14.0 del 2013, mentre quella in lavorazione è del 2018. Nella versione del 2013 però Frhed non c’è, e il changelog dice che è stato rimosso dalla GUI nel 2009.

Nella maggior parte delle distribuzioni manca il file di esempio che definisce le struttre/template/pattern identificate dal programma, sample.tpl , ma si tratta di un semplice file di  testo che contiene queste tre righe:

BYTE filetype
WORD version
DWORD filelength

La prima parola indica quanti byte accorpare, la seconda indica il nome dato a quell’accorpamento.

Altri valori possibili sono solo “float” e “double”, quindi complessivamente le parole chiave possibili, con la rispettiva lunghezza in byte, sono:

  • BYTE  – 1
  • WORD – 2
  • DWORD – 4
  • float – ???
  • double – ???

 

Sembra che le uniche versioni compilate per Windows disponibili per download siano quelle su soruceforge, la cui ultima è la 1.6.0 del 2009 (o una 1.7.1 definita “instabile”):

http://frhed.sourceforge.net/en/

Richiesta di chiarimento

 

 

WxMEdit

https://wxmedit.github.io/downloads.html (3.1, anno ignoto)

https://sourceforge.net/projects/wxmedit/ (3.1, 2016)

 

 

 

WxHexEditor

https://github.com/EUA/wxHexEditor

I  template/pattern/structure vengono chiamati “tags”.

E’ piuttosto acerbo e con diversi bug, ma evidenzia correttamente le tag e mostra in un unico pannello le posizioni (cliccabili) di tutte le ripetizioni dei risultati di ricerca (ma non delle tag…)

 

Preon

https://github.com/preon/preon

(da compilare)

 

 

Kaitai Struct

http://kaitai.io/

 

Hex Editor Neo

https://freehexeditorneo.com/

 

 

Binary Viewer

http://www.proxoft.com/binaryViewer.aspx

Chiama i pattern “hexadecimal sequences”, stanno nella finestra di dialogo della ricerca.

 

Hexinator

(già noto come “Synalyze It!”, nato inizialmente su Macintosh, forse a pagamento)

https://hexinator.com/

 

Signatures database

https://www.filesignatures.net/index.php?search=jpg&mode=EXT

Tagged with: , ,

Diario elettrico GreenGo Icaro: più velocità

Posted in minicar elettriche by jumpjack on 1 aprile 2018

La mia Icaro “A1” 6kW è venduta per 65 km/h, ne segna 60 sul cruscotto e ne fa 55 di GPS.
Sto cercando di capire se questa velocità può essere aumentata; per il momento ho scoperto che il limite non dipende dalla centralina Kelly KHB72701, perchè all’acquisto era già tarata su massima velocità del motore e massima corrente dalla batteria e al motore.

Adesso sto cercando di fare due cose:
– trovare un modo per conoscere gli RPM del motore in tempo reale
– capire se anche il BMS impone limiti su tensione e/o corrente


Un po’ di teoria

La velocità di un motore elettrico è proporzionale alla tensione ad esso applicata, in base a una costante Kv che dipende da come è costruito il motore stesso, e che quindi non può essere variata. Quindi la velocità massima di un motore è:
V = Kt * G
Con G = Giri al minuto, epsressi in RPM

Un motore funziona sempre in modo duale: gira se gli si invia una corrente, produce una corrente se fatto girare a mano. Purtroppo, questa seconda cosa la fa sempre… anche mentre riceve corrente che lo fa girare! Mentre gira, infatti, produce una Forza Contro Elettro Motrice (f.c.e.m), cioè una tensione, che si oppone alla tensione che gli viene fornita; quando la f.c.e.m., che è =0 a motore fermo, diventa uguale alla V fornita, il motore smette di accelerare, cioè raggiunge la sua velocità massima intrinseca.

Questo valore viene indicato sul datasheet come “rated speed” o “maximum speed” (in realtà devo ancora capire bene quale delle due…).

Ora, c’è questo problema:

Sono dati che ho raccolto faticosamente in giro per siti cinesi.
La penultima riga è quella che ci interessa: si vede che i motori usati nelle varie versioni di Icaro/Zhidou si sono evoluti negli anni, passando dai primissimi installati sulla versione al piombo, da 3100/3600 RPM, ai più recenti montati sulla ZD D2 da 15 kW, con 4200/5000 rpm.
Nella riga in alto, “Maximum speed”, si vede come anche la velocità massima è progredita di pari passo nei vari modelli; riporto nella lista qui sotto i km/h, gli rpm e il rapporto kmh/rpm:

ZD311D (piombo): 45/3100/0.014
ZD311B (piombo): 50/3000/0.017
ZD311A/Icaro_A1: 60/3000/0.020
E20/H1: 80/4200/0.019
ZD D1/D2/D2S: 85/4200/0.020

Questo rapporto potrebbe forse coincidere, o essere proporzionale, con il “rapporto al ponte” o “rapporto di trasmissione”, cioè il rapporto dell’unica “marcia” della icaro; nei primi tre modelli è andato aumentando (probabilmente stavano ancora “facendo esperimenti”), poi si è stabilizzato su 0.020 (probabilmente la E20/H1 era limitata elettronicamente per non eccedere gli 80 km/h di legge, decaduti e passati a 90 nel 2016 con la nuova normativa).

Ecco invece una tabella che elenca i motori di quello che potrebbe essere il fornitore: anche se non è possibile leggere etichette o datasheet sul sito, questa immagine li tradisce perchè è il VMS montato sulla mia ICaro!

In quella tabella, gli rpm nominali e massimi dei motori sono:

  • 4/8kW: 3100/3600
  • 5/10kW: 3000/3500
  • 6/12kW: 3000/3600
    9/18kW: 5000/5700
  • 15/35kW: 5000/7000 (motore da 96V invece che 72)
  • 15/30kW: 5200/7200 (motore da 114V invece che 72)

Quelli delle varie icaro sono:

  • ZD311D – 4/8kW: 3100/3600
  • Z301B – 5/10kW: 3000/3500
  • ZD311A – 6/12kW: 3000/3600
  • E20/H1/D1 – 9/18kW: 5000/5700
  • D2/D2S – 15/30kW: 4200/5000 (batteria da 144V invece che 72)

Le motorizzazioni a 72V sono cioè esattamente identiche nella mia tabella e in quella del fornitore, che quindi sembrerebbe proprio essere confermato.


Osservazioni pratiche

Durante i miei viaggi ho notato una cosa: in pianura il tachimetro non va mai di neanche mezzo mm oltre i 60 km/h, ma in discese ripide, con l’acceleratore a tavoletta, sono arrivato anche a 75. Solo che, appunto con l’acceleratore a tavoletta… si innesca la rigenerazione in frenata! E la tensione di batteria sale fino a 80V, contro i 74-75 in pianura. Questo sembra voler dire che a 70-75 km/h la velocità del motore supera quella che la tensione di batteria può indurgli, quindi la f.c.e.m. supera la V, e quindi il comportamento da generatore prevale su quello da motore.


Conclusioni ipotetiche

Quanto sopra potrebbe significare che attualmente la mia Icaro è configurata non solo elettronicamente, ma anche meccanicamente per non poter fisicamente andare più veloce.

Ci sarebbero quindi tre modi per andare più veloce:

  1. Aumentare la tensione che arriva al motore
  2. Cambiare il rapporto al ponte
  3. Cambiare motore
  • Il primo modo è purtroppo impensabile, perchè tutta l’elettronica di bordo è tarata su un massimo di 90V, che lasciano solo 3,6 V di margine rispetto agli 86,4V che la batteria raggiunge probabilmente durante la ricarica (3.65V/cella), per poi scendere a 80 quando la batteria è bilanciata e pronta; c’è una remota speranza che il BMS forzi la batteria a non arrivare nemmeno a 80V, perchè leggo questo valore solo durante la frenata rigenerativa, però non sono ancora riuscito ad accedere al BMS.
  • Il secondo modo sarebbe fattibile: la GLCar di Modena fornisce un kit di modifica da inserire nel differenziale, che cambia il rapporto al ponte permettendo di raggiungere i 75 km/h di GPS; costa 550E + IVA
  • Il terzo modo non è ancora chiaro se sia fattibile: pare che lo sia sicuramente sui modelli “A1+”, mentre “forse sì forse no” sui modelli “A1”, che non tollererebbero l’albero più lungo del motore da 9kW (mentre sulle A1+ avrebbero già in fabbrica adattato il differenziale per ospitare il nuovo albero motore). Se fosse fattibile, diventerebbe possibile portare la velocità agli 85 km/h della D1, ancora compatibili con l’omologazione L7e della Icaro (max 90 km/h). Però il numero del motore è riportato sulla carta di circolazione. E poi temo che il motore da 9 kW costi più di 1000 euro, a cui andrebbero aggiunti differenziale, manodopera e spedizione a Modena…. Immagino si arrivi a 2000 euro e rotti… che corrisponderebbero a 20.000 km percorsi in elettrico (2000 euro di benzina in meno), contro i 5500 necessari per il kit del differenziale, 5500 km che potrei  fare in meno di un anno. 🙂  Vedremo…

RPM da recuperare

C’è un’ultima faccenda: la “rated speed” e la “maximum speed”: devo capire se a 60 km/h il motore gira a “rated speed” o a “maximum speed”, perchè se  fosse il primo caso, forse con la fantomatica funzione “boost”, attivabile sulla centralina aggiungendo un pulsante, potrei recuperare quei 500 RPM che “mi mancano”. Per capirlo devo riuscire ad accedere al computer di bordo (ECU o VMS che sia), forse tramite OBD, forse tramite Arduino+CANbus shield, chissà.

 

 

Diario elettrico hoverboard – 4 gennaio 2018: le modifiche

Posted in ambiente, hoverboard, scooter elettrici by jumpjack on 4 gennaio 2018

Sono ormai parecchi mesi che ho comprato un simil-segway, cioè un “hoverboard col manico”.

Hoverboard Go!Smart

Hoverboard Go!Smart

Lo trovo decisamente utile per le escursioni turistiche cittadine, anche se purtroppo in alcuni posti iniziano a vietarmi l’ingresso…. tipo un paio di musei, o i supermercati dei centri commerciali.

Comunque, nel frattempo ho apportato alcune modifiche/migliorie al prodotto:

  • spostamento display: nativamente il display per la ricarica si trova sulla pedana, in mezzo ai piedi, ed è scomodissimo da consultare; ma il manico è cavo e il manubrio è di plastica, anch’esso cavo, quindi non ci è voluto molto a “trasferire” il display nel manubrio, rendendolo così molto più leggibile; il cavo di collegamento è un cordone a spirale del telefono, che così può assecondare allungamenti e accorciamenti del manico telescopico.
  • Posizione iniziale del display, al centro della pedana

     

     

    Nuova posizione del display

  • rinforzo sul manubrio: il punto di attacco del manubrio all’hoverboard è molto sollecitato a causa della leva lunga un metro, quindi stavano saltando alcuni punti di saldatura: niente di drammatico, perchè comunque il manico è avvitato con due viti, però iniziava ad avere troppo “gioco”: forse 1 grado… che a un metro di distanza significava spostare il manubro di 5-10 centimetri a destra o a sinistra senza che il mezzo effettivamente svoltasse; così, ho aggiunto un piastrino di alluminio che blocca il gioco del manubrio.
  • antifurto: visto che probabilmente sempre più spesso mi vieteranno di entrare da qualche parte, ma che comunque il mezzo è impagabile per coprire la distanza dal parcheggio al luogo di interesse, ho aggiunto alla pedana un anello d’acciaio, dentro al quale posso far passare un antifurto da bici, e legare così l’aggeggio a un palo proprio come si fa con una bici. Il telaio è di alluminio quindi non è stato difficile forarlo.
  • Anello antifurto

 

Collegamento di un CellLog8S/8m ad Arduino o a ESP8266

Posted in auto elettriche, batterie, hardware, scooter elettrici by jumpjack on 2 gennaio 2017

L’utente pa.hioficr sul forum https://endless-sphere.com/forums/viewtopic.php?f=14&t=20142 ha scoperto che è possibile leggere in tempo reale i dati di log di un CellLog (sia 8S con memoria che 8S senza memoria) semplicemente “agganciandosi” al pin TX dell’Atmel montato sul CellLog.

Questo significa che invece di spendere 40-50 euro per comprare un CellLog8S con memoria e infilarlo nel sottosella per poi aspettare di arrivare a casa per scaricare i dati letti, è in linea di principio possibile collegare al CellLog8M da 15 euro un ESP8266 da 8 euro che tramite Wifi invia dati a uno smartphone che li mostra in tempo reale sullo schermo durante la marcia; probabilmente è anche possibile scrivere un SW che legge i dati da più di un celllog contemporaneamente, sfruttando l’emulatore di porte seriali.

Questo è lo schema elettrico originale dell’autore:

celllog-000

 

Questa è una sua successiva modifica per implementare anche avvio del logging e reset del CellLog:

celllog-001

Di seguito la spiegazione del funzionamento che ho dedotto io dallo schema, inserita anche nella seconda edizione del mio libro “Guida alla costruzione di una batteria al litio per mezzi elettrici”, di imminente pubblicazione:

 

8.1.2. Materiale occorrente
Q1 = 2n3906 o altro PNP
R1 = R4 = R6 = R7 = 220 ohm
R2 = R5 = 330 ohm
R3 = 4700 ohm
U1 = U2 = optocoupler/fotoaccoppiatore a 2 canali, 5V, 8 pin, uscita a fototransistor di tipo NPN (es. Vishay ILD615, Fairchild MCT61, Isocom ISP827,… )
8.1.3. Spiegazione del funzionamento
Il circuito può essere suddiviso in 4 parti: le prime due ricevono dati dal CellLog tramite il primo fotoaccoppiatore e li inviano al microcontrollore esterno; le altre due ricevono invece dati dal microcontrollore e li inviano al CellLog tramite il secondo fotoaccoppiatore.
8.1.3.1. Rilevamento accensione
In Figura 127 è riportata la parte dedicata al rilevamento dell’accensione; notare che nella figura il transistor è stato capovolto rispetto allo schema originale reperito su internet, per renderlo coerente con la notazione standard di avere la corrente che scorre dall’alto verso il basso; inoltre lo schema è stato semplificato e ripulito, per facilitarne la comprensione, lasciando però inalterati i collegamenti e i componenti.
Il microcontrollore (MCU) è programmato per leggere sul pin MCU_CL8.1_DETECT lo stato del CellLog: quando il pin è “basso” (0V), vuol dire che il CellLog è acceso; normalmente questo pin è invece a 5V perché connesso all’alimentazione dell’MCU tramite R5 (che serve a limitare a 15mA la corrente Collettore-Emettitore quando il transistor è in conduzione); quando però il CellLog viene acceso, i suoi 5V arrivano, tramite la resistenza R4 (che limita la corrente a 23 mA) sul pin 4, e mettono in conduzione il fotodiodo 3-4, che mette a sua volta in conduzione il fototransistor 5-6, che mette a massa il pin MCU_CL8.1_DETECT.
celllog-002
Figura 127 – Rilevamento accensione
8.1.3.2. Lettura dati
Dobbiamo far “riflettere” sul piedino RX del microcontrollore esterno lo stato del pin TX del CellLog, tramite il fotoaccoppiatore; per farlo, usiamo il pin TX del CellLog per controllare la base di un transistor collegato all’ingresso del fotoaccoppiatore; il transistor serve a far sì che basti prelevare dal CellLog una piccolissima corrente (1 mA grazie a R3 da 4300 ohm) per attivare il fotodiodo, che richiede invece alcune decine di mA; in pratica è un transistor di disaccoppiamento, che cioè rende indipendenti gli assorbimenti di corrente di CellLog e fotoaccoppiatore.
celllog-003
Figura 128 – Circuito TX-RX con transistor PNP o NPN
Il progettista ha scelto di usare un transistor di tipo PNP, che viene acceso da una tensione di base negativa rispetto all’emettitore; l’emettitore va quindi collegato stabilmente alla tensione di alimentazione 5V, in modo che il transistor entri in conduzione quando TX va a 0V. Quando questo accade, succederà quanto segue, in sequenza:
1. Q1 si accenderà
2. Passerà una corrente nel fotodiodo 1-2
3. Si accenderà il fototransistor 7-8
Dobbiamo ora fare in modo che tutto ciò risulti in una tensione di 0V sul piedino RX del microcontrollore esterno, corrispondente al piedino 8 del primo fotoaccoppiatore, che è il collettore del fototransistor di uscita; per farlo, dobbiamo fare in modo che il piedino 8 si trovi normalmente a 5V, e venga portato a 0V solo quando si accende il fototransistor 7-8; bisogna quindi tenere il pin 8 costantemente collegato ai 5V del microcontrollore esterno, e il pin 7 alla sua massa; in questo modo, l’accensione del fototransistor 7-8, che avviene quando TX del CellLog va a 0, collegherà il pin 8 a massa tramite il 7, cioè metterà RX del microcontrollore esrerno a 0, riflettendo così esattamente lo stato del pin TX del CellLog.
Se non dovessimo avere disponibile un transistor PNP ma solo un NPN, occorrerà invertire la logica del circuito.
8.1.3.3. Reset
Il “cervello” del CellLog, un microcontrollore ATMEL, è dotato di un piedino di reset, che possiamo controllare tramite il nostro microcontrollore esterno; per farlo, al pin di reset colleghiamo il collettore del fototransistor 5-6 del secondo fotoaccoppiatore (pin 5); controlliamo questo fototransistor tramite il rispettivo fotodiodo 3-4, collegato al pin MCU_CL8.1_RESET del nostro microcontrollore esterno; basterà quindi mettere alto questo pin per mettere in conduzione il fotodiodo e il fototransistor e quindi resettare il CellLog.
celllog-005
8.1.3.4. Avvio log
Per far partire il logging è necessario premere per 3 secondi il pulsante 2 del CellLog (SW2); possiamo farlo fare al nostro microcontrollore esterno collegando l’interruttore in parallelo a un’uscita del secondo fotoaccoppiatore: quando sull’ingresso ci sarà una tensione di 5V (impostata via software), il fototransistor di uscita entrerà in conduzione chiudendo l’interruttore e avviando così il logging.

celllog-004