Recent Posts

Pages: [1] 2 3 ... 10
1
PERIODO DI PROVE / Aggiorniamo
« Last post by I2NOS on April 06, 2019, 07:39:57 PM »
Sono passati più di 5 anni dall'inizio delle prove.
2
PROBLEMI & MIGLIORAMENTI / Anomalie riscontrate
« Last post by I2NOS on April 06, 2019, 07:38:18 PM »
Ciao, come promemoria metto le anomalie riscontrate sul sistema in test. Poche hanno a che fare con il sistema vero e proprio.
- la più grave è attribuibile ai sistema di carica batteria FOX350; si è riscontrato che il  FOX5350 non prevede di alimentare il carico utilizzando la seconda batteria e non effettua una corretta ricarica della stessa; questo ci ha costretto a ridisegnare parte del funzionamento del STS per bypassare il problema e gestire il carico utilizzando a rotazione tutte le batterie; intervento che è risultato solo parzialmente posigtivo in quanto sono state riscontrate anomalie anche nella logica di ricarica delle batterie secondarie;
- La tensione che viene consegnata al carico oscilla da 13,8/14V (tensione repentinamente variabile in base al sole/nuvole quando le batterie sono in carica) a 10,5V (con le batterie in scarica; tensione a cui vengono tolte dal carico); questa differenza di tensione può essere inaccettabile per alcuni tipi di carico (ad esempio si è dimostrato che il funzionamento del beacon viene influenzato dalla tensione di alimentazione);
- Il sistema di diodi antiricircolo (utilizzato dal STS nella fase di commutazione per permettere di collegare temporaneamente in parallelo 2 batterie al carico), riduce di ulteriore 0,6V la tensione disponibile al carico (per cui con una batteria carica 12,6V all’utilizzatore sono consegnati 12V);
- La tensione delle batterie cala linearmente per cui già circa metà della corrente nominale la tensione raggiunge un livello tale da creare possibili problemi al carico; la potenza disponibile deve essere quindi considerata decisamente inferiore a quella teorica;
- Le batterie secondarie, causa dell’anomalia del FOX350  o per problemi di resistenza interna, si sono scaricate oltre il livello minimo (al controllo risultavano attorno ai 5V), per cui sono risultate danneggiate e non in grado di tenere adeguatamente un carico;
- la frequenza utilizzata per la telegestione (VHF) risulta facilmente disturbabile; nel corso del periodo sono stati riscontrati utilizzi del canale da parte di altri om, che una volta avvertiti hanno gentilmente cambiato frequenza.
I2NOS Giuseppe
3
PROGETTAZIONE SOFTWARE DEL SISTEMA / Descrizione funzionale del software del STSMaster
« Last post by I2NOS on February 09, 2018, 10:18:02 PM »
Architettura del master
STSMaster utilizza ora un core multitasking basato su freertos 9.0.0.
Questo permette di simulare l'esecuzione contemporanea di vari task rendendo più agevole la gestione della logica di sistema e applicativa.
Dopo la sequenza di boot del sistema e l'inizializzazione dei vari driver (che per chiarezza vedremo successivamente) sono avviati i seguenti task:
Service, AX25Level1, vAX25Level2, vApplStsm, vSlave, vWatchdog
che rimangono sempre attivi e hanno tutti lo stesso livello di priorità; sono quindi eseguiti in successione, con un periodo di tempo prestabilito riservato ad ognuno di essi. Nel caso un task sia in attesa di qualche evento, il suo slot di tempo passa al task successivo.
Vediamoli
1) Service - Questo task aggiorna l'orologio di sistema, schedula l'invio dei messaggi sulla porta seriale degli slave, gestisce la messaggistica e i log, analizza lo stato delle batterie e ruota la batteria sotto carico, gestisce la pianificazione giornaliera/oraria dei carichi, aggiorna le variabili per inquiry utente sullo stato della memoria ((il dettaglio sara' trattato nei relativi punti). L'aggiornamento dell'orologio di sistema e delle varie componenti del power system è pilotato da timer che a tempo settano flag per innescare le varie routine;  per i log e messaggi è attivo un sistema di comunicazione  con gli altri trask tramite code e semafori.

2) AX25Level1 - Questo task è responsabile di assemblare i byte ricevuti dalla radio trasformandoli in frame ax25, di ricevere i messaggi dai task di livello superiore e trasformarli in frame ax25 da inviare alla radio, di ricevere i byte dalla driver seriale rs485 (risposte dagli slave) e trasformarli in pacchetti ax25, ricevere i messaggi dai task di livello superiore da inviarli come frame ax25 al driver della seria rs485.
Il colloquio tra i vari task di livello superiore ed inferiore è gestito tramite sistemi di code e semafori.

3) vAX25Level2 - Il task si incarica del colloquio ax25, attraverso la gestione della connessione, la sincronizzazione dei messaggi, cla onferma dei messaggi correttamente ricevuti, la richiesta di ritrasmissione per quelli non ricevuti, la ritrasmissione dei messaggi non ricevuti dalla controparte, disconnessione. Il dialogo prevede la ricezione dei pacchetti ax25 dallo strato inferiore AX25Level1, la notifica al livello applicativo superiore della richiesta di connessione e la consegna all'applicativo del messaggio ripulito. A fronte della risposta dell'applicazione il messaggio viene incapsulato con gli elementi del destinatario e inviato al livello sottostante. Il colloquio tra i vari task di livello superiore ed inferiore è gestito tramite sistemi di code e semafori.

4) vApplStsm - Questo task schedula due applicazioni, la prima è responabile del colloquio con l'utente reagendo alle sue richieste, interrogando se necessario gli strati sottostanti (es. power system); la seconda è responsabile del sistema di broadcasting connectionless su radio (invio telemetria). Il colloquio con i  task di livello inferiore è gestito tramite sistemi di code e semafori.

5) vSlave - Questo task si incarica del colloqui con gli slave. Gestisce il polling con i vari slave (appoggiandosi al livello AX25Level1), raccoglie le risposte e le salva in una apposita struttura; in caso di non risposta degli slave, vengono effettuati retry e al fallimento degli stessi l'azzeramento delle relative strutture. Il programma inoltre riceve dai vari task richieste di informazioni  e comandi relativi agli slave.  Nel caso di interrogazioni, se ha già tutti i dati raccolti nel polling precedente, risponde con questi; nel caso di comandi li inoltra, fuori dalla sequenza di polling, agli slave. Il colloquio con gli altri task è gestito tramite sistemi di code e semafori.

6) vWatchdog - Il controllo del corretto funzionamento di tutti i task è affidato al watchdog hw, che se non viene periodicamente resettato esegue un riavvio del sistema. Questo task periodicamente controlla che ogni singolo task incrementi una sua variabile; il mancato aggiornamento della variabile indica un possibile blocco di quel task e la conseguente necessità di intervenie.

A corollario, oltre ovviamente il freertos,  ci sono una serie di driver che implementano un modem a 1200 bps, gestiscono il colloquio con le seriali, con la EEprom, con la memoria di massa su sd, con il real time clock.
4
PROGETTAZIONE SOFTWARE DEL SISTEMA / Mappa EEPROM
« Last post by I2NOS on February 05, 2018, 10:16:57 AM »
‌In EEprom MAP i sensori hanno base a 0x400, ogni sensore prende 16 bytes quindi
400 Sensore 0 - attualmente punta a Slave 0 Port 0 - connesso al sensore di tensione della batteria 1 
410 Sensore 1 - attualmente punta a Slave 0 Port 1 - connesso al sensore di corrente della batteria 1
420 Sensore 2 - attualmente punta a Slave 0 Port 2 - connesso al sensore di tensione della batteria 2 
430 Sensore 3 - attualmente punta a Slave 0 Port 3 - connesso al sensore di corrente della batteria 2
440 Sensore 4 - attualmente punta a Slave 0 Port 4 - connesso al sensore di tensione del carico totale 
450 Sensore 5 - attualmente punta a Slave 0 Port 5 - connesso al sensore di corrente del carico totale
460 Sensore 6 - attualmente punta a Slave 0 Port 6 - connesso al sensore di temperatura digitale 
470 Sensore 7 - attualmente punta a Slave 0 Port 7 - connesso al sensore di umidità digitale
480 Sensore 8 - attualmente punta a Slave 0 Port 8 - connesso al sensore di contatore di reset slave 1
490 Sensore 9 - attualmente punta a Slave 0 Port 9 - connesso al sensore xxxx
4A0 Sensore 10- attualmente punta a Slave 0 Port 10 - connesso al sensore di comando rele' batteria 1 
4B0 Sensore 11- attualmente punta a Slave 0 Port 11 - connesso al sensore di comando rele' batteria 2 
4C0 Sensore 12- attualmente punta a Slave 0 Port 12 - connesso al sensore di comando rele' batteria 3
4D0 Sensore 13- attualmente punta a Slave 0 Port 13 - connesso al sensore di rele' aperto/chiuso 1
4E0 Sensore 14- attualmente punta a Slave 0 Port 14 - connesso al sensore di rele' aperto/chiuso 2
4F0 Sensore 15- attualmente punta a Slave 0 Port 15 - connesso al sensore di rele' aperto/chiuso carico totale 
500 Sensore 0 - attualmente punta a Slave 1 Port 0 - connesso al sensore di tensione della batteria 3 
510 Sensore 1 - attualmente punta a Slave 1 Port 1 - connesso al sensore di corrente della batteria 3
520 Sensore 2 - attualmente punta a Slave 1 Port 2 - connesso al sensore di tensione della batteria 4 
530 Sensore 3 - attualmente punta a Slave 1 Port 3 - connesso al sensore di corrente della batteria 4
540 Sensore 4 - attualmente punta a Slave 1 Port 4 - connesso al sensore di tensione del carico totale riserva 
550 Sensore 5 - attualmente punta a Slave 1 Port 5 - connesso al sensore di corrente del carico totale riserva
560 Sensore 6 - attualmente punta a Slave 1 Port 6 - connesso al sensore di temperatura digitale secondo
570 Sensore 7 - attualmente punta a Slave 1 Port 7 - connesso al sensore di umidità digitale secondo
580 Sensore 8 - attualmente punta a Slave 1 Port 8 - connesso al sensore di contatore di reset slave 2
590 Sensore 9 - attualmente punta a Slave 1 Port 9 - connesso al sensore xxxx
5A0 Sensore 10- attualmente punta a Slave 1 Port 10 - connesso al sensore di comando rele' batteria 3 
5B0 Sensore 11- attualmente punta a Slave 1 Port 11 - connesso al sensore di comando rele' batteria 4 
5C0 Sensore 12- attualmente punta a Slave 1 Port 12 - connesso al sensore di comando rele' carico totale riserva
5D0 Sensore 13- attualmente punta a Slave 1 Port 13 - connesso al sensore di rele' aperto/chiuso 3
5E0 Sensore 14- attualmente punta a Slave 1 Port 14 - connesso al sensore di rele' aperto/chiuso 4
5F0 Sensore 15- attualmente punta a Slave 1 Port 15 - connesso al sensore di rele' aperto/chiuso carico totale riserva

Per ognuno la posizione:
0 - 1 Sensor type
2 - 3 (port) numero che indica quale porta usare per inviare/ricevere il dato
4 - 5 tensione di riferimento(vref) o digital negate()
6 - 7 valore di r1 nei partitori di tensione, disponibile da codificare nel caso di altri sensori
8 - 9 valore di r2 nei partitori di tensione, disponibile da codificare nel caso di altri sensori
A - B Current offset dell'acs758, disponibile da codificare nel caso di altri sensori
C - D sensibilità dell'acs758, disponibile da codificare nel caso di altri sensori
E - F Disponibile per futura implementazione

Ad esempio per lo slave1 che ho in test per
la porta 0 sensore di tensione sono parametri che influenzano i valori letti
Hex 0404 = 01E0 (480 = 1 bit 4,80mv * 1024 = Vref 4,92V)
Hex 0406 = 26FC (R1 = 9980ohm)
Hex 0408 = 0A46 (R2 = 2630ohm)

la porta 1 sensore di corrente
Hex 0414 = 01E0 (480 equivalente a Vref 4,92V / 1024 bit di risoluzione = 4,80mv = 1 bit di risoluzione)
hex 041A = 01FC (508 equivalente a Voffset 0A dell'acs 2,43V / 4,80mv  = 508 bits )
hex 041C = 0004 (4 equivalente a 4mv per 0,1A)
5
PROGETTAZIONE SOFTWARE DEL SISTEMA / Modifiche e miglioramenti alla logica del master
« Last post by I2NOS on February 03, 2018, 03:21:32 PM »
Ciao Fabio,
dopo aver tribulato un bel po' con la radio frequenza dei baofeng, e non averla ancora vinta, ti metto al corrente delle modifiche fatte che sono abbastanza grosse.

1: I file di descrizione contengono adesso anche parametri (che dopo ti spiego); ho aggiunto anche un altro file (che dopo ti spiego)

2: Ho creato blocchi di controllo per poter gestire meglio i parametri, il flusso del programma e le possibili espansioni. Alcune delle modifiche vanno a sostituirsi alle tue, per cui poi gli dai una occhiata e aggiusti o tagli

3: non esistono più ileggibat, vleggibat e altre funzioni varie sostituite da altre (che dopo ti spiego)

4:ho modificato una serie di pannelli per poter aggiustare alle nuove funzionalita';

5: ho messo una serie di parametri in eeprom.

6:modificato orologio di sistem

E adesso inizio le spiegazioni.
I blocchi di controllo li ho creati per avere una gestione modulare e rispecchiano i vari snodi della parte di power management.
Uno dei concetti che ho tentato di realizzare è quello di separare la parte interattiva via radio dal motore vero e proprio che invece e'
a livello sistema. Per cui da pannello interagisci con lo strato sotto, ma quello è comunque il posto dove stanno le definizioni e le routine che girano.
Ho creato il blocco uAccum che contiene tutte le informazioni relative agli accumulatori (al posto di batterie - dettaglio dopo).
Ho creato il blocco uLoad che contiene tutte le informazioni relative ai carichi (dettaglio dopo).
Ho creato il blocco uSwitch che contiene tutte le informazioni relative agli interruttori (dettaglio dopo).
Ho creato il blocco uSensor che contiene tutte le informazioni per gestire i parametri,formule,porte dei sensori(dettaglio dopo).
Ho creato il blocco uPort che contiene tutte le informazioni relative alle porte(la porta è quella che sta sullo slave da 0 a 15).
Ora la cosa più innovativa è uSensor, in quanto attraverso questo si ottiene una astrazione tra informazioni e dove queste si trovano, mi spiego meglio:
attraverso una chiamata a dreadsensor numero sensore ottengo il valore richiesto, se questo sensore è un sensore di tensione, avro' un valore relativo alla tensione già corretta
d tutti i parametri relativi a quel sensore, se e' di corrente  la stessa cosa, se è un input digitale avro' lo stato, se è temperatura.... etc.
attraverso una chiamata a dwritesensor scrivo sul sensore (in questo caso al momento ho solo switch).
Quindi ho praticamente una tabella di n sensori al momento 16 sensori per 2 slave = 32, ma i sensori non sono necessariamente legati agli slave.
il sensore a sua volta si appoggia, se e' necessario, al blocco uPort per trovare dove richiedere/inviare la richiesta del dato.
I blocchi uAccum, uLoad e uSwitch, contengono al loro interno le informazioni su quali sensori utilizzare per ottenere/dare le informazioni di pertinenza.
Vediamo un po' meglio
 uAccum[4] (definita in pmsycommon.c ) e' una matrice di 4 accumulatori, per ogni accumulatore e' previsto:
0 ovviamente il suo numero di matrice
1 (u8accumid)un ID numero che viene utilizzato per i display (iniziare con 0 non è bello, per cui in generale l'id e' n.matrice + 1) ;
2 (u8Vserviceid) il numero del servizio da passare per ottenere la tensione
3 (u8Iserviceid) il numero del servizio per ottenere la corrente
4 (u8SWid)il numero del servizio dello switch che connette l'accumulatore al carico
5 (u8accumgood) il flag che indica che l'accumulatore è in buone condizioni è deve essere inserito nel ciclo di alimentazione
6 (u8autoserv)il flag che indica la rimessa in servizio automatica dell'accumulatore  (prima era scarico era stato messo fuori servizio automaticamente, se adesso e' carico lo rimetto in servizio automanticamente o aspetto un consenso manuale?)
si possono aggiungere informazioni quali valore tensione minima, massima, carico medio nel periodo, etc.
Questa matrice di parametri di definizione (0,1,2,3,4,5,6), e'caricata in fase di boot dal file ACCDESC.TXT ( tramite vInitAccuValue definita in pmsycommon.c ).
Quando per una batteria voglio saper che tensione c'e' invoco dreadsensor passando u8Vserviceid e ottengo la mia tensione, se vogli sapere lo stato dello switch invoco dreadsensor passando u8SWid e ottengo 1 o 0, etc.
In maniera equivalente ho la tabella dei carichi
uLoad[6] (definita in pmsycommon.c ) con 6 carichi, di cui attivi solo 2. Per ogni load è previsto:
0 ovviamente il suo numero di matrice
1 (u8aloadid)un ID numero che viene utilizzato per i display (iniziare con 0 non è bello, per cui in generale l'id e' n.matrice + 1) ;
2 (u8Vserviceid) il numero del servizio da passare per ottenere la tensione
3 (u8Iserviceid) il numero del servizio per ottenere la corrente
4 (u8SWid)il numero del servizio dello switch che connette l'accumulatore al carico
5 (u8loadgood) il flag che indica che il carico puo' essere attivato.
Anche qui si possono aggiungere altri tipi di informazioni relativi ai carichi.
Questa matrice di parametri di definizione (0,1,2,3,4,5), e'caricata in fase di boot dal file LOADESC.TXT ( tramite vInitLoadValue definita in pmsycommon.c ).

Simili solo gli switch, uSwitch[6] (definita in pmsycommon.c ), che al momento hanno una tabella di 6 elementi. Per ogni switch è previsto
0 ovviamente il suo numero di matrice
1 (u8switchid) un ID numero che viene utilizzato per i display
2 (u8SWWserviceid) il numero del servizio da passare per inviare il comando di switch
3 (u8SWRserviceid) numero da passare per sapere lo stato dello switch
4 (u8SWgood) flag di switch operativo.
Anche qui si possono aggiungere altri tipi di informazioni relativi ai carichi.
Questa matrice di parametri di definizione (0,1,2,3,4), e'caricata in fase di boot dal file SWDESC.TXT ( tramite vInitSwitchValue definita in pmsycommon.c ).

Per sensori la tabella e' più complicata e prevede una serie di parametri di funzionamento aggiustabili in corso d'opera, parte di questi parametri risiedono in eeprom e
vengono caricati in fase di boot 1)da codice la prima volta che viene eseguito (al momento tramite flag nel codice), 2) da eeprom tutte le altre volte.
Questi parametri possono essere modificati da pannello. uSensor[32] (definita in sysservice.c) prevede
0 il suo numero di matrice
1 (stype) con un numero che indica il tipo di sensore
   - SENSV tensione
   - SENSI corrente
   - SENSSW command switch
   - SENSDIG i/o digitale
   - SENSTEMP temperature
   - SENSHUM umidita'
   - SENSRESCNT contatore reset
   si possono aggiungere altri servizi)
2 (port) numero che indica quale porta usare per inviare/ricevere il dato
3 (vref) tensione di riferimento o digital negate
4 (r1) valore di r1 nei partitori di tensione, disponibile da codificare nel caso di altri sensori
5 (r2) valore di r2 nei partitori di tensione, disponibile da codificare nel caso di altri sensori
6 (lvconv) fattore di conversione in caso di tensione(per velocizzare i calcoli);disponibile da codificare nel caso di altri sensori
7 (ioffset) Current offset dell'acs758, disponibile da codificare nel caso di altri sensori
8 (iacs758sens) sensibilità dell'acs758, disponibile da codificare nel caso di altri sensori
le funzioni dreadsensor e dwritesensor utilizzando i dati di cui sopra sono in grado di fare tutti i calcoli per restituire i valori corretti.
I parametri in eeprom sono fissati in EEPROM_MAP.h e inizializzati in fase di boot da vParam_init.

Le porte uPort sono codificate in una tabella di costanti in memoria tramite in sysservice.c e semplicemento hanno
0 numero di matrice
1 slave
2 port

I file parametri non sono più a lunghezza fissa ma campi separati da ;

Le funzioni  impattate dalle modifiche sono state aggiustate per riflettere la nuova logica.
I menu per la consultazione di Accumulatori, Load, switch, e comandi di commutazione switch sono stati aggiornati. Ovviamente se non ti piaciono puoi modificarli.
Il menu per lettura/modifica dei valori eeprom si trova in 3.4
I menu' per la gestione dei parametri degli Accumulatori, Load, Switch sono ancora da implementare, per permettere di impostare i flag di accumulatore good, autoservice, load good, switch good.

L'orologio di sistema adesso è tutto software, ma al boot legge il clock dell'rtc, che nel mio caso si sballa alla velocità della luce, per cui volevo decidere
se sincronizzare l'rtc con quello di sistema o se cambiare l'rtc.

Il ciclo di switch degli accumulatori adesso verifica anche la tensione della batteria e se la tensione è sotto i 10V esclude la batteria dal giro. Devo ancora mettere a posto l'autoservice, ma è una sciocchezza.

Ho inserito il test che volevi per vedere la corrente del carico dopo lo switch e mi sembra che funzioni correttamente.
Non funziona lo switch del log dopo i 10K, forse mi sono mangiato un pezzo di codice. Adesso verifico.

Testiamo il tutto e poi se soddisfatti andiamo avanti con la parte di pianificazione giornaliera.
6
PROGETTAZIONE SOFTWARE DEL SISTEMA / STSMaster - Versione 2 con Freertos
« Last post by I2NOS on April 24, 2017, 09:24:08 PM »
Buona sera,
dopo molto silenzio, che non vuol dire che non ho fatto niente ;) ;) ;), sono partito con lo sviluppo della nuova versione del master con core basato sul sistema mutitasking Freertos. L'intervento permette di coordinare in maniera più organica ed efficace il colloquio tra i vari livelli di protocollo e risolve alcune limitazioni che avevo riscontrato in precedenza (sincronizzazione tra le frame, pacing, parallelismo).
Gli aggiornamenti sono disponibili all'indirizzo
https://sourceforge.net/projects/stsr/?source=directory.
Se avete voglia di partecipare allo sviluppo e ai test fatemelo sapere.
A presto
I2NOS Giuseppe
7
PROGETTAZIONE HARDWARE / Re: Power box
« Last post by i2lqf on April 05, 2017, 08:07:53 PM »
aggiungo una foto dell'HW funzionante.
Attualmente, in una prima versione semplificata del sw, ogni batteria viene collegata al carico per 10 minuti, poi il collegamento passa alla successiva in ordine numerico (ogni batteria e', per il sistema, identificata daun numero, da 1 a 4); c'e' un minimo di sovrapposizione in cui due batterie sono connesse in parallelo sul carico, dietro i diodi anti-riciclo, per avere la sicurezza che il carico sia sempre sotto tensione; questo periodo ora e' di circa 7 secondi.
8
Ciao Fabio,
tutto bene? Spero di si'!!.
Sono andato avanti a fare sviluppo per inserire il trasferimento file su stsmaster.
Ho collateralmente effettuato un po' di modifiche qui e là dove mi sembrava giusto.
In particolare
- Ho aggiunto la funzione ax25SendBlock (in sostituzione di ax25Send) per ottimizzare il tempo di spedizione dei messaggi evitando l'attesa per la conferma di piccoli pacchetti; la funzione aspetta che il pacchetto sia sufficientemente pieno prima di inviarlo.
Per evitare che non venga mai spedito è previsto che quando hai finito il messaggio applicativo con un parametro forzi l'invio.
- per mettere in ordine le varie sezioni del sw in modo di poterlo in un futuro splittare sotto free rtos ho rinominato il file common.h in userax25.h  e ho spostato le include e ci ho messo le define ax25SendBlock
- Aggiunto menu 2.7 per la navigazione sulle directory dell'SD  (vedi i relativi file explorer.c explorer.h)
- aumentato lo stack a 2000
- aumentato i buffer del modem afsk a 1060 (4 frame da 265 byte)
- inserito i files per il trasferimento file zmodem (testato su file seriali, ma da aggiustare su ax25).
Purtroppo mi manca un tnc per poter concludere lo sviluppo sul trasferimento file. Quando sarò a brescia ne prendo uno.
Al momento ho riportato lo start del programma a 8000000 in modo da poter facilmente utilizzare il debugger. Quando il ft funzionerà lo rimetto a posto.
Il sorgente aggiornato è su svn.
Ciao
I2NOS - Giuseppe
9
PRESENTAZIONE PROGETTO & FILES DOWNLOAD / Sensore di corrente e tensione
« Last post by I2NOS on November 12, 2016, 05:07:31 PM »
Giusto per promemoria, altrimenti dopo un po' non ci ricordiamo più, allego la foto del sensore. Il lato con il partitore (quello a destra nella foto) va collegato alla batteria. In questo modo quando la batteria è in carica il programma leggerà un valore negativo e quando eroga corrente leggerà un valore positivo. Anche nel caso del sensore del carico sarà collegato a destra con il + in
uscita del power box e a sx verso il carico.
73 I2NOS Giuseppe
10
Buon Pomeriggio,
allego il sw vers. 1.0.0 del bootloader. Dai primi test dovrebbe funzionare. Se ci sono problemi fatemelo sapere.
I2NOS - Giuseppe
 
Pages: [1] 2 3 ... 10