Jumping Jack Flash weblog

Hacking Hayabusa 2 ;-)

Posted in astronomia by jumpjack on 29 settembre 2018

La pagina del simulatore di Hayabusa 2 contiene tantissimi dati ma per la maggior parte di scarso interesse (alba e tramonto di H2 sulle antenne DSN, frequenze usate,…).

C’è però una piccola, insospettabile parte della pagina che contiene un’informazione molto importante: il box che rappresenta in modo stilizzato come Hayabusa appare nel campo visivo (FOV) della telecamera grandangolare ONC-W1:

 

Esaminando il complicatissimo codice sorgente si scopre che il box è un oggetto che si chiama “onc-w1__screen”, che contiene al suo interno un oggetto “onc-w1__target”, cioè il dischetto che rappresenta Ryugu stilizzato.

Le dimensioni di quest’oggetto sono fissate mediante codice HTML5 come percentuale delle dimensioni dell’oggetto padre onc-w1__screen. Questa percentuale è ottenuta tramite una serie di complessi calcoli, implementati tramite un codice Javascript estremamente complicato da decodificare; tuttavia, usando il debugger di chrome ho scoperto che la pagina carica continuamente questo file: http://haya2now.jp/data/data.json ; inserendolo in un convertitore JSON/XML per facilitarne la lettura, e incrociandone il contenuto con alcune parti del codice javascript, ho scoperto questa struttura dati nel file:

 <status>
      <connections>
         <MLG>
            <band>Ka</band>
            <endAt>2018-09-29T22:00:00.000Z</endAt>
            <pass>180929-0200</pass>
            <startAt>2018-09-29T14:00:00.000Z</startAt>
         </MLG>
      </connections>
      <spacecraft>
         <Bus-P>703.391</Bus-P>
         <CMDBitrate1>1000</CMDBitrate1>
         <CMDBitrate2>15.625</CMDBitrate2>
         <COH>COH</COH>
         <CSAS>
            <element>13.009</element>
            <element>-0.128</element>
            <element>0.019</element>
            <element>-nan</element>
         </CSAS>
         <MGA>
            <element>-85.003</element>
            <element>-66.000</element>
         </MGA>
         <ModIndex>1.25</ModIndex>
         <ONC_A>297</ONC_A>
         <ONC_XY>
            <element>262</element>
            <element>260</element>
         </ONC_XY>
         <RNG_LIDAR>52</RNG_LIDAR>
         <RX-ANT1>XMGA</RX-ANT1>
         <RX-ANT2>XLGA-A</RX-ANT2>
         <RX1-Lock>CRR+DEM</RX1-Lock>
         <RX2-Lock>CRR</RX2-Lock>
         <RXLv1>-97.836</RXLv1>
         <RXLv2>-99.381</RXLv2>
         <THR>
            <element>60.561523</element>
            <element>24.645508</element>
            <element>0.759766</element>
            <element>23.698242</element>
            <element>6.846680</element>
            <element>37.575195</element>
            <element>13.926758</element>
            <element>32.855469</element>
            <element>0.926758</element>
            <element>59.537109</element>
            <element>56.843750</element>
            <element>61.607422</element>
         </THR>
         <TLMBitrate>8192</TLMBitrate>
         <TX-AMP>KaPA</TX-AMP>
         <TX-ANT>KaHGA</TX-ANT>
         <TX-XTRP>XTRP1</TX-XTRP>
         <TxMode>TLM</TxMode>
         <generatedAt>2018-09-29T16:28:14.138Z</generatedAt>
         <receivedAt>2018-09-29T16:46:16.895Z</receivedAt>
      </spacecraft>
      <updatedAt>2018-09-29T16:50:07.000Z</updatedAt>
   </status>

Si ha cioè un oggetto status che contiene le proprietà:

  • connections
  • spacecraft
  • updatedAt

La proprietà spacecraft contiene una molteplicità di sottoproprietà; ho evidenziato quella che mi interessa, cioè l’oggetto ONC_A, che quindi in javascript risponde al nome di status.spacecraft.ONC_A .

Dai sorgenti si intuisce che questo dato rappresenta l’area del dischetto che rappresenta Ryugu, e viene utilizzato per calcolare le dimensioni del dischetto in percentuale rispetto al box.

E’ possibile verificarlo osservando che nei giorni in cui H2 era in orbita di parcheggio a 20.000 metri di distanza dalla superficie, il valore di ONC_A oscillava intorno a 297, e quello della percentuale intorno a 3.76%. Sapendo che il diametro di Ryugu è di circa 900 metri, con un po’ di matematica e trigonometria si può calcolare che l’angolo sotteso da Ryugu nella telecamera è pari a beta = 2 * arctan (Diam/2  / Alt) = 2 * arctan (450/20.000) = 2 * arctan (0,0225) = 2,57788°

Dividendo quest’angolo per il campo visivo di 60° della telecamera si ottiene una percentuale pari al 4.2%, molto vicina al 3.76% visibile nella pagina web.

Questo significa che è possibile procedere a ritroso: noto il diametro di Ryugu e il valore di ONC_A, si può calcolare la distanza di H2 dalla superficie.

I calcoli non sono per niente banali, e sono illustrati in questa figura:

Cioè in breve:

Con l’argomento della tangente espresso in gradi.

Usando i radianti, invece:

calcolo-finale-rad

In termini più generici, validi cioè per un corpo celeste di qualunque diametro D e una telecamera con qualunque angolo visuale FOV che genera immagini larghe W pixel:
calcolo-finale-gen.png

Non essendo specificata l’unità di misura del FOV, la formula va bene sia per gradi che per radianti.

 

Grazie a questo semplice calcolo e a molta trigonometria sto allestendo una pagina che permetterà di seguire in tempo reale le varie prossime discese di H2 durante il rilascio di MASCOT, durante le prove di atterraggio, ecc..

Il suddetto file .json contiene anche altre due sottoproprietà di spacecraft:

 <generatedAt>2018-09-29T16:28:14.138Z</generatedAt>
 <receivedAt>2018-09-29T16:46:16.895Z</receivedAt>

Vista la distanza di circa 20 minuti  tra i due orari, dovrebbero essere gli orari di invio dati e di ricezione a terra.

 

Infine, questa tag nei sorgenti lascia supporre che la pagina venga aggiornata ogni 8 ore:

<meta http-equiv=”refresh” content=”10800″>

In realtà osservando l’esecuzione si vede un aggiornamento ogni pochi secondi, e il file viene ricaricato, stando al timestamp dell’url di chiamata, ogni 5 minuti:

http://haya2now.jp/data/data.json?1538249547553

http://haya2now.jp/data/data.json?1538249622621


In realtà la distanza di H2 da Ryugu è calcolata nella pagina in un altro modo, ma usando un codice Javascript complicatissimo che non sono riuscito a decodificare.

Se qualcuno vuole cimentarsi nell’impresa, il calcolo è nel codice racchiuso nella riga 155 del file http://haya2now.jp/js/app.js

var calcDistance = function (x, i1, i2) {
   return Math.sqrt(
      Math.pow(i1.x.interpolate(x) - i2.x.interpolate(x), 2) + Math.pow(i1.y.interpolate(x) - i2.y.interpolate(x), 2) + Math.pow(i1.z.interpolate(x) - i2.z.interpolate(x), 2)
   );
};

var distHaya2Ryugu = calcDistance(now.valueOf(), __WEBPACK_IMPORTED_MODULE_4__Util_js__[\"a\" /* default */].getInterpolators('hayabusa2'), __WEBPACK_IMPORTED_MODULE_4__Util_js__[\"a\" /* default */].getInterpolators('ryugu'));

AGGIORNAMENTO 2 OTTOBRE 2018

Ho scoperto che da quando è iniziata la discesa di Hayabusa per il rilascio del rover MASCOT, il dato RNG_LIDAR, che prima conteneva valori insensati intorno a 50, ha iniziato a contenere valori compatibili con la quota di Hayabusa, come facilmente verificabile confrontando i valori con quelli comunicati via via tramite account twitter dalla JAXA.

La pagina interattiva, quindi, durante la discesa mostra la “quota LIDAR” anzichè quella dedotta dal valore di ONC_A.

SIMULATORE


Aggiornamento 3 ottobre 2018

Ho scoperto altri dati utili nel f ile .json: vengono fornite le coordinate di Hayabusa, Terra e Ryugu nello spazio; quelle di Hayabusa in questa fase sono poco utili perchè rilevate da terra e quindi approssimate di +/-200 km (dichiarato da JAXA da qualche parte), ma sarà interessante usarle per seguire il rientro a terra a fine missione, quando Hayabusa riporterà i campioni analizzati; chissà fino a che quota da terra continueranno ad aggiornare i dati: se non sbaglio, la sonda si sfracellerà nell’atmosfera poco dopo aver rilasciato la capsula di rientro, che sarà l’unico pezzo a tornare a terra sano e salvo.

Non è però molto chiaro QUALI coordinate tenere in considerazione, perchè ci sono 7 gruppi di coordinate ma 6 stazioni, boh…:

  • data.geometry[i].hayabusa2.x
  • data.geometry[i].hayabusa2.y
  • data.geometry[i].hayabusa2.z

“i” varia da 0 a 6.

Un altro dato interessante è la distanza in secondi-luce tra hayabusa e la terra; qui ce n’è uno per ognuna delle 6 stazioni: data.geometry[x].obs[y].hayabusa2.delay_from ; in realtà c’è anche il tempo di ritorno (data.geometry[x].obs[y].hayabusa2.delay_to), ma ovviamente è identico; forse durante il viaggio terra-ryugu ad alta velocità però cambia per effetto doppler? “x” può valere da 0 a 6 e non so cosa significhi; y varia da 0 a 5 e ogni “obs” è un “observer”, cioè una stazione DSN.

Gli altri dati elencati in precedenza sono:

ONC_A: area in pixel^2 del cerchio che rappresenta Ryugu in un quadrato 1024×104:

  • data.status.spacecraft.ONC_A

RNG_LIDAR: distanza in metri di Hayabusa dalla superficie di Ryugu in metri; il LIDAR però non è sempre attivo; funziona per certo durante le operazioni di discesa sotto i 20.000:

  • data.status.spacecraft.RNG_LIDAR

Ci sono infine i “tempi cumulativi dei 12 thrusters di bordo”; forse potrebbero essere utili per simulare i cambiamenti di assetto di Hayabusa… ma solo sapendo dove si trova e dove punta ogni thruster! Comunque i dati sono:

  • data.status.spacecraft.THR[i]

Con “i” che va da 0 a 11.

In teoria, esaminando il log nei momenti di accelerazione/decelerazione, dovrebbe essere possibile capire almeno quali sono i thrusters che puntano in alti e quelli che puntano in basso.

BMS con intercomunicazione a infrarossi

Posted in auto elettriche, batterie, scooter elettrici by jumpjack on 12 settembre 2018

La Lion Smart ha avuto un’idea geniale: il BMS a infrarossi! (o forse esisteva già, ma io l’ho scoperto adesso)

Quest’idea comporta l’enorme vantaggio di non dover più costruire batterie come questa!

 

Cioè niente più fili di segnale che svolazzano dappertutto, ma solo massicci collegamenti di potenza.

Questo comporterà probabilmente anche una grossa riduzione dei prezzi di fabbricazione delle batterie, rendendo il processo molto più automatizzabile: basta infatti un braccio robotico che infila nel contenitore/batteria tanti moduli quanti ne servono per raggiungere l’amperaggio e la  tensione desiderati, e la batteria è pronta. Molto meglio di dover saldare 200 fili con precisione millimetrica.

Considerando che nella batteria di un’auto possono esserci anche 100-150 celle in serie (sulle auto le batterie sono da 300 o 400V e ogni singola cella è da 3 o 4 V), e che ognuna deve essere collegata al BMS per poter essere bilanciata, e considerando per ognuna un filo di lungezza media di 1 metro per collegarla al BMS, parliamo di quasi 200 metri di filo in meno.

E nessun problema di interferenza nelle trasmissioni tra celle, essendo chiuse in una scatola buia e non essendo una trasmissione nè WiFi nè Bluetooth.

Chissà se una tecnologia del genere potrà mai arrivare nei BMS amatoriali a cifre ragionevoli (ne dubito, visto che un BMS “discreto”, cioè con un circuito per ogni cella, costa 400 euro invece che 100).

 

Una batteria Lion Smart a infrarossi è stata installata per prova su una BMW i3 (link a inizio articolo).

 

 

Tagged with: , , , ,

Auto elettriche e riscaldamento globale

Posted in auto elettriche, fotovoltaico by jumpjack on 7 settembre 2018

Il 100% dell’energia estratta dalle batterie di un’auto elettrica finisce per diventare, sempre e comunque riscaldamento globale dell’atmosfera:

  • il calore disperso dai freni riscalda l’aria;
  • il calore prodotto dalle ruote che toccano la strada scalda l’asfalto che a sua volta scalda l’aria;
  • il movimento stesso dell’auto nell’atmosfera scalda l’aria aumentandone l’agitazione delle molecole.

Quindi è bene che l’energia delle batterie venga dal sole, perchè se viene dai combustibili fossili è come se viaggiasse nel tempo da 1 miliardo di anni fa ad oggi: sempre di energia solare si tratta, ma accumulata 1 miliardo di anni fa da piante e animali che poi sono diventati petrolio.

Penso che sia come se oggi risplendessero migliaia soli invece che uno solo; cioè, se per formare 1 litro di benzina ci sono volute, che so, 10 tonnellate di piante marcite, putrefatte e diventate petrolio, che erano cresciute in 6 mesi, e poi bruciamo questo litro in 1 giorno , vuol dire che è come se in quel giorno risplendesse l’equivalente di 6 mesi di sole, o che risplendesse un sole 180 volte più intenso.

 

Ma proviamo ora a fare un calcolo un po’ spericolato:

1)il mix energetico italiano ha raggiunto il 40% di rinnovabili e 60% di fossili;
2) una centrale a combustibili fossili ha efficienza del 50% invece che 25% come un’auto;
3) con un litro di benzina (10 kWh) un’auto a benzina fa 15km, un’elettrica fa 70km.

Dovrebbe significare:
1) 0.6 * 6 = 3.6 mesi di sole invece che 6
2) 0.5 * 3.6 = 1.8 mesi di sole invece che 3.6
3) 15/70 * 1.8 = 0.38 mesi di sole invece che 6, cioè 1/16

Cioè, se ho fatto bene i conti, vorrebbe dire che un’auto elettrica riscalda il pianeta 16 volte meno di un’auto a benzina.
Sarà vero? Sono calcoli decisamente strampalati… 🙂

Raduno Elettrico Romano – sabato 22 settembre 2018 – 16:00-20:00

Posted in auto elettriche, minicar elettriche, scooter elettrici by jumpjack on 3 settembre 2018

Pagina ufficiale:

https://autoguida.wordpress.com/2018/09/03/raduno-elettrico-romano-sabato-22-settembre-2018-1600-2000/

NOTA: E’ necessario iscriversi tramite apposito modulo di iscrizione per permettere al Comune di organizzare preventivamente gli spazi.

Batterie al litio a stato solido

Posted in auto elettriche, batterie by jumpjack on 27 agosto 2018

Ultimamente si sente parecchio parlare di batterie al litio a stato solido, e di svariati milioni di dollari investiti da varie aziende sulla loro ricerca e sviluppo; queste batterie occuperebbero infatti metà spazio (e metà peso) di quelle attuali, scatenando quindi una vera rivoluzione nella mobilità elettrica, quanto lo ha fatto l’introduzione delle Li-NCM da 250 Wh/kg al posto delle LiFePO4 da 100 Wh/kg.

Ecco un interessante grafico riassuntivo delle capacità gravimetriche e volumetriche di varie tecnologie  attualmente esistenti (a livello di cella; dentro una batteria le densità diminuiscono per la presenza di separatori, condizionatori, elettronica,…):

Fonte: https://www.researchgate.net/publication/320425585

Ecco una ricerca recentissima (2018) che descrive molto tecnicamente come sono fatte e funzionano (o funzioneranno) le  batterie al litio a elettrolita solido (Solid State Electrolite – SSE, o Solid State Battery – SSB), di cui esistono molteplici varianti, ma per ora tutte soltanto a livello di laboratorio: A Brief Review of Current Lithium Ion Battery Technology and Potential Solid State Battery Technologies – Andrew Ulvestad

Le uniche fuori dal laboratorio sono installate sulle auto elettriche Bollorè, ma hanno la densità gravimetrica delle LiFePO4 (100 Wh/kg) e devono lavorare a 80 °C.

La ricerca non parla però della nuova tecnologia inventata dal prof. Goodenough, inventore delle batterie al litio 30 anni fa, che ora (nel 2017), alla tenera età di 94 anni, le ha “perfezionate” inventando quelle a elettrolita solido vetroso.

In genere se una tecnologia per le batterie funziona, ci vuole una decina d’anni perchè arrivi sul mercato delle auto elettriche, forse qualcuno in meno perchè arrivi sui modellini telecomandati, più sacrificabili, e sui cellulari, perchè tanto la gente li comprerebbe anche se funzionassero a nitroglicerina…

Quindi non resta che aspettare, e intanto ringraziare questo simpatico vecchietto se la rivoluzione della mobilità elettrica è diventata possibile.

Prof. Goodenough

 

 

Come convertire un “panorama dinamico Samsung” in “panorama standard

Posted in varie, VR360 by jumpjack on 26 agosto 2018

Il Samsung S7 (e, immagino, anche i modelli successivi S8, S9,…) è in grado di catturare “panorami cilindrici a 360°”, ottenendo immagini tipo questa:

Come si nota, il lato sinistro e il lato destro dell’immagine non corrispondono, bensì si sovrappongono leggermente, forse di 10-15°, ossia è una sorta di “panorama a 375°”:

Si tratta ovviamente di un  formato fuori standard; per riportare la foto a un formato standard, si può caricarla su Facebook, che individuerà nelle tag EXIF del file i dati necessari a interpretarla come immagine panoramica cilindrica, e la ritaglierà “opportunamente” (leggasi “come gli pare”) in modo da creare un panorama standard:

Poichè però l’allineamento è, come detto, sbagliato (essendo il panorama scattato a mano), Facebook non permette la rotazione continua a 360°, ma si interrompe nel punto di congiunzione, che viene lasciato sfumato:

 

Questi sono i metadati che Facebook scrive nell’immagine (estratti con Exif Fixer):

-xmp:ProjectionType=cylindrical
-xmp:CroppedAreaLeftPixels=0
-xmp:CroppedAreaTopPixels=-554
-xmp:CroppedAreaImageWidthPixels=5809
-xmp:CroppedAreaImageHeightPixels=1109
-xmp:FullPanoWidthPixels=5809
-xmp:UsePanoramaViewer=true

 

Questi erano invece i metadati dell’immagine originale (ma ridotta al 30%):

-xmp:ProjectionType=cylindrical
-xmp:CroppedAreaLeftPixels=0
-xmp:CroppedAreaTopPixels=-554
-xmp:CroppedAreaImageWidthPixels=6269
-xmp:CroppedAreaImageHeightPixels=1109
-xmp:FullPanoWidthPixels=6269
-xmp:UsePanoramaViewer=true

 

L’immagine “nuda e cruda”  non ridimensionata, invece, ha questi metadati:

-xmp:ProjectionType=cylindrical
-xmp:CroppedAreaLeftPixels=0
-xmp:CroppedAreaTopPixels=-1848
-xmp:CroppedAreaImageWidthPixels=20896
-xmp:CroppedAreaImageHeightPixels=3696
-xmp:FullPanoWidthPixels=20896
-xmp:UsePanoramaViewer=true

Invece, i metadati di un’immagine sferica creata tramite apposita telecamera sono:

-xmp:ProjectionType=equirectangular
-xmp:CroppedAreaLeftPixels=0
-xmp:CroppedAreaTopPixels=0
-xmp:CroppedAreaImageWidthPixels=4096
-xmp:CroppedAreaImageHeightPixels=2048
-xmp:FullPanoWidthPixels=4096
-xmp:FullPanoHeightPixels=2048
-xmp:UsePanoramaViewer=true

Questa è l’immagine:

Ottenuta tramite telecamera sferica, in realtà è stata convertita in formato equirettangolare dall’applicazione XDV360, altrimenti di per sè apparirebbe così:

 

Invece i metadati di una foto sferica scattata col Samsung S7, ma che non contiene l’intera sfera ma solo una porzione:

-xmp:ProjectionType=cylindrical
-xmp:CroppedAreaLeftPixels=0
-xmp:CroppedAreaTopPixels=-672
-xmp:CroppedAreaImageWidthPixels=1056
-xmp:CroppedAreaImageHeightPixels=1344
-xmp:FullPanoWidthPixels=1056
-xmp:UsePanoramaViewer=true
-xmp:PoseHeadingDegrees=195.0

oppure:

-xmp:ProjectionType=cylindrical
-xmp:CroppedAreaLeftPixels=0
-xmp:CroppedAreaTopPixels=-1294
-xmp:CroppedAreaImageWidthPixels=896
-xmp:CroppedAreaImageHeightPixels=2588
-xmp:FullPanoWidthPixels=896
-xmp:UsePanoramaViewer=true
-xmp:PoseHeadingDegrees=199.3

L’Ecojumbo 5000 con 150 km di autonomia

Posted in batterie, scooter elettrici by jumpjack on 26 agosto 2018

L’Ecojumbo 5000 della Ecomission nasce con batterie al piombo da 60V/45Ah, che garantiscono un’autonomia reale di 35 km per 300 cicli prima di dover cambiare le batterie.

Ma sono altri tempi, parliamo del 2010 o giù di lì.

Nel frattempo la tecnologia delle batterie si è evoluta: dal piombo si è passati al litio, prima con la tecnologia LiFePO4 (100 Wh/kg), ora con la tecnologia Li-NCM (200 Wh/kg).

Ecco che diventa quindi possibile avere un Ecojumbo con 150 km di autonomia: praticamente 5 volte l’originale! E non solo per 300, ma per 1000 cicli, a detta della Westart (ma anche fossero 300, significherebbe una vita utile di 45.000 km contro i 9000 dell’Ecojumbo al piombo).

E’ possibile con le batterie “Shenzhen Westart”, che esistono in vari tagli e misure; qui ipotizzo di costruire la batteria usando 16 celle prismatiche da 125 Ah (WS-NCM125Ah), da 3.7V nominali e 4.2V volt massimi, per un totale di 7.5 kWh.

Usando Sketchup e conoscendo le dimensioni del vano batterie è possibile simulare varie disposizioni delle celle, tenendo conto che lo spazio disponibile non è esattamente un parallelepipedo:

 

Disposizione celle NCM da 125 Ah in vano batterie Ecojumbo 5000

Non conosco con precisione millimetrica l’entità del “restringimento” anteriore dovuto alla piega dei tubi del telaio, ma più o meno si può dedurre da questa vecchia foto, che mostra due batterie Ecoitalmotor inserite nel vano:

Le dimensioni del vano motore dell’Ecojumbo 5000 sono:
Base di 210×670 mm
Altezza di 210 mm senza togliere la vecchia centralina e la 5a batteria al piombo, altrimenti si arriva a 390 mm.
A circa 370 mm dal retro del vano c’è un restringimento dei tubi del telaio, che nelle figure sopra è stato un po’ stilizzato; la distanza interna tra i due tubi, nel punto più stretto, è di 150 mm, contro lo spazio disponibile di 210mm prima del restringimento.

 

Possiamo quindi idealmente dividere il vano in una parte inferiore e in una superiore:

  • Inferiore: 670x210x210mm
  • Superiore: 670x150x180 mm

 

Diario elettrico GreenGo icaro – 3 agosto 2018 – Modifiche elettriche

Posted in Diario elettrico GreenGo Icaro by jumpjack on 4 agosto 2018

Oggi ho avuto modo di esaminare l’elettronica del cruscotto, per l’esattezza i vari collegamenti dietro alla pulsantiera del cambio.

Controllo volume

L’obiettivo era verificare la fattibilità di separare il controllo del volume dal controllo delle marce, visto che è inverosimile rischiare di mettere in folle per sbaglio mentre si alza il volume della radio.

Risposta breve: sì, è fattibile.

Inizialmente sembrava una cosa complicatissima, perchè questo è quello che c’è dietro a quei 3 pulsanti:

encoder (1)

Non capisco il perchè di tutta questa circuiteria, comunque quello che conta è il gruppetto di 6 pin a destra: è completamente indipendente dal resto del circuito, e fa capo all’encoder con interruttore, cioè la manopola che si usa per accendere la radio e cambiare il volume; quindi bastano 6 fili per spostare il “pericoloso” volume in un posto più sicuro: per esempio, al posto della terza manopola, accanto alle due di areazione e riscaldamento, che di serie nella Icaro A1 è inutilizzata.

Ora devo cercare di capire se quell’ “affare” è effettivamente un “encoder”, e come si usa.

Possibile che sia questo?

71to2bx8xkzl-_sl1200_

Se è lui, come identifico i pin CLK, DT e SW su quello della Icaro? Avranno posizionamento standard?

 

 

L’antenna

Continuando l’esame dei fili, ho  fatto un’altra scoperta:

Queste erano le drammatiche condizioni del connettore dell’antenna della radio! Ecco spiegato perchè prendeva tre stazioni e pure male! Il collegamento tra calza del cavo e involucro del connettore è completamente tranciato! Guida d’onda aperta, onde radio che se ne vanno a spasso invece di entrare nella radio!

Ma quello che è più strano è che, a vederlo, questo connettore era fatto male pure quando era sano, con solo una misera linguetta a unire la calza al connettore: rotta  o non rotta, interrompe la guida d’onda, e l’antenna diventa completamente inutile!

Il venditore mi ha regalato un’antenna esterna come questa. Notare la profonda differenza del connettore, che è un tutt’uno col cavo!

Adesso la radio prende stazioni che nemmeno sapevo esistessero! 🙂 ne prende una ogni 0.10 MHz

E sono anche riuscito a trovare un punto dove fissare l’antenna… talmente perfetto che probabilmente è fatto apposta: sui montanti anteriori, alla congiunzione col cofano, ci sono due coperchietti di plastica, fermati da una vite nascosta sotto al cofano; bè, la vite stessa può essere usate per fissare l’antenna, togliendo la vite con cui essa viene fornita; il filo si fa passare sotto al coperchietto di plastica (da cui bisogna però segare via una piccola tacca per non incidere il cavo, ed è fatta:

 

Connettore misterioso

Ma l’esame dell’impianto elettrico continua: rimontando i connettori, che sono tutti diversi e quindi non c’è rischio vengono scambiati… mi sono accorto che invece due sono identici! Doh! Però per  fortuna sopra c’è una targetta: “Gear” è il cambio; e “Mode switch” a che diavolo serve?? Un connettore “segreto” di servizio per accedere alla configurazione della macchina.

Può darsi… ma collegarlo non è stato sufficiente, e premere a vanvera i tasti del cambio nemmeno: ci sarà sicuramente anche una combinazione segreta dei tasti…. Infami!

 

SD card con mappe

Ultima scoperta: la SD Card nel navigatore.

Sostituire il navigatore semi-funzionante con uno funzionante era l’obiettivo principale di tutto lo smontaggio… ma non ho potuto portarlo a termine perchè ANCHE questo navigatore ha connessioni diverse! ALCUNE sono uguali, ma non tutte… quindi nisba, non ho potuto collegarlo.

PERO’ per puro caso sono riuscito a scovare la microSD card di cui a volte il navigatore lamenta la mancanza o malfunzionamento, nascosta DIETRO al navigatore, sul bordo, quasi invisibile; mentre invece in quello nuovo che mi hanno dato non c’è. Mah? Comunque ho approfittato per fare un backup delle mappe, non si sa mai.

 

 

Bocchette di areazione

Un’ultima osservazione non riguarda l’impianto elettrico ma le bocchette di areazione… che diventeranno parte dell’impianto elettrico quando ci metterò dentro delle ventole aggiuntive; beh’, ho scoperto che la griglia di cui sono dotate posteriormente non solo è flessibile abbastanza da poter alloggiare anche potenti ventole spesse 20mm (che arrivano a 50 m3/h invece dei 9 di quelle da 10mm che ho comprato…), ma secondo me la griglia può tranquillamente essere rimossa senza danneggiare esteriormente le bocchette; anzi, non capisco proprio cosa ci stia a fare… come non capisco cosa ci stavano a fare i riduttori di flusso dietro alle bocchette. Boh, misterio dell’areazione-logia, io tolgo tutto e ci piazzo 4 ventole. 🙂

 

Tensioni di massima e minima carica batterie al litio

Posted in batterie by jumpjack on 28 luglio 2018

Ho trovato in rete dell’insolito e inaspettato materiale che mi ha permesso di aggiornare un vecchio post sulle tensioni tipiche di cella; “insolito e inaspettato” perchè il materiale è frutto di esperimenti dannosi e pericolosi effettuati su celle al litio, caricandole e scaricandole oltre le soglie-limite. Soglie che peraltro sono molto discusse in rete, e apparentemente soggettive.

Questi esperimenti oltre-limite sembrano finalmente gettare un po’ di luce sulla faccenda.

La fonte dei grafici originale è https://www.powerstream.com/lithium-phosphate-charge-voltage.htm , ma non il linko il sito perchè contiene informazioni pericolose.

LiFePO4

Nel primo grafico (LiFePO4) si vede che caricare una cella a 3.1V (curva in basso a sinistra) comporta un incremento minimo di energia (4-5%), quindi si può supporre che 3.0V sia ragionevolmente la tensione minima oltre la quale è inutile  scendere, per non danneggiare la cella; analogamente, caricando oltre i 4.16V “tipici”, si ha un incremento minimo di carica, ma si stressa la cella riducendone la vita utile.

Per una cella LiFePO4, quindi, l’intervallo di sicurezza (Safe Operating Area) può essere individuato fra 3.0 e 3.25V.

 

li-ion/LiPO/LiCoO2/NCM/NMC

Da osservazioni analoghe sul secondo grafico si può dedurre che per le li-ion/LiPO/LiCoO2/NCM l’intervallo di sicurezza (Safe Operating Area) può essere individuato fra 3.4V e 4.16V; notare che questo secondo tipo di cella è molto più sensibile alle tensioni errate, che possono portare a incendi ed esplosioni.

In caso di carico

Tutti questi valori sono validi in assenza di carico; con un carico applicato, bisogna tener conto che più alta è la corrente erogata, maggiore è l’abbassamento di tensione, che quindi può scendere sotto la soglia di sicurezza anche se a riposo la tensione ben più alta; utilizzare quindi la cella solo finchè a riposo si trova nella SOA garantisce che, anche sotto carico, la tensione non scenda sotto i livelli critici.

 

Tabella delle tensioni

Segue una tabella coi valori dedotti, oltre che dai suddetti grafici, anche da altre fonti:

Tensione
danneggiamento
Tensione
minima utile
Tensione nominale Tensione
batteria
carica
Tensione
di ricarica
Li-Ion/LiPo 3,0 3,4 3,6 4,16 4,20
NMC/NCM 3,0 3,4 3,7 4,16 4,20
LiFePO4 2,8 3,0 3,3 3,6 3,65

Da notare che:

  • li-ion/LiPO e NMC/NCM usano chimica simile a base di cobalto, quindi hanno all’incirca le stesse tensioni, ma le NCM/NMC sono intrinsecamente più sicure perchè vanno più difficilmente in fuga termica (incendio o esplosione) in caso di abuso, rispetto alle LiPO.
  • La tensione di ricarica NON coincide con la tensione di batteria carica: dopo la fine della carica, infatti, la tensione si abbassa di qualche puto decimale anche senza essere usata, assestandosi sulla tensione nominale.

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: , ,