Armando47: Difference between revisions

From ciapini
Jump to navigation Jump to search
No edit summary
Line 335: Line 335:
=== arNet ===
=== arNet ===


Il protocollo di comunicazione specifico di armando e' '''arNet'''
Il protocollo di comunicazione specifico di armando e' [[ArNet]]
 
e' un protocollo per lo scambio di piccoli blocchi di dati (da 16 a 1024 byte) tra piccoli gruppi di nodi (massimo 256), connessi da un mezzo fisico:
* condiviso tra i nodi
* half-duplex
* senza meccanismi di collision detect
* con rilevazione di canale occupato (opzionale)
* in condizioni di terminale nascosto
 
usa schemi di modulazione ask, psk o fsk, con costellazioni di dimensione da 2 a 32.
 
per resistere agli errori di trasmissione, gli header e i dati passano attraverso un [[#FEC]].
 
um messagio arNet e' composto da:
* un [[#Blocco start]] di 8 simboli
* uno o piu [[#Blocchi header]] da 4 byte ognuno, con [[#FEC]] e [[#Interleaver]]
* zero o piu [[#Blocco DATA|blocchi dati]] da 16 byte ognuno, con [[#FEC]], [[#Interleaver]] e (opzionalmente) [[#Cifratura]]
 
diversamente dai sistemi a layer, il trasporto dei dati in arNet viene caratterizzato da delle features liberamente combinabili.
 
arNet si preoccupa SOLO (e non sempre) di: addressing, routing, error detecting, error handling, ordering, media access control
 
altre features vanno implementate altrove: datagram/virtual circuit transport, crittografia...
 
i nodi possono essere terminali o router
 
il routing si basa su due livelli di indirizzo:
* un ''indirizzo del terminale'', valido tra i terminali che condividono il canale fisico
* un ''indirizzo del segmento'', che identifica il canale fisico
 
 
 
==== Cifratura ====
 
algoritmo di cifratura: AES-256 (blocco 128 bit, chiave 256 bit)
 
la chiave e' composta di 64 caratteri esadecimali
 
il blocco crittato e' sempre di 16byte
 
*http://www.literatecode.com/aes256 sembra ok, volendo si puo ottimizzare qualcosa per i 16bit
*http://libtom.org/?page=features&newsitems=5&whatfile=crypt se non e' troppo grosso, e' il piu portabile
*http://gladman.plushost.co.uk/oldsite/AES/
*http://axtls.sourceforge.net/
*http://www.matrixssl.org/
*http://polarssl.org/
*http://www.yassl.com/yaSSL/Products-cyassl.html
 
==== FEC ====
 
algoritmo di FEC: [[Hadamard code]]
 
la latenza minima al netto del FEC e' data dal blocco di crittazione (16bytes).
 
anche la granularita della protezione di errore FEC e' data dal blocco di crittazione (16bytes): e' inutile tentare di preservare l'integrita di blocchi di dati piu piccoli di 128bit, il danneggiamento anche di un solo bit si ripercuoterebbe sul contenuto di tutto il blocco di crittazione.
 
se si perde anche un solo bit del segnale al netto del FEC vanno persi 16 caratteri.
 
questo e' tendenzialmente male pensando all'uso con messaggi di testo, i linguaggi naturali hanno una loro ridondanza a livello di parola considerevole. per applicazioni non di testo questo vantaggio non esiste, anche se per messaggi molto piu piccoli di 16byte l'overhead dato dal padding e' comunque considerevole.
 
d'altra parte dimensioni di blocco crittografico piu piccole implicherebbero minore sicurezza (anche se in realta il tutto sarebbe proporzionale alla quantita di dati trasferiti con una determinata chiave). crittare il codice FEC (''n'' = 128bit, se si usano input ''k'' di 8 bit) sembrerebbe allettante dato che si allineerebbe al blocco crittografico, ma:
# crittograficamente e' un inganno, dato che i codici fec trasmessi sono comunque sempre 256 dal punto di vista della ripetitivita sarebbe equivalente ad usare una cifratura con dimensione blocco di 1byte. troppo poco.
# dal punto di vista del FEC e' un inganno, decrittando un blocco danneggiato si avrebbe un codice fec danneggiato in maniera complessa, perdendo il vantaggio della ortogonalita del codice di hadamard.
 
alla luce di questo forse ha senso considerare dei block codes diversi da quello di Hadamrd, che e' non-ottimale per ''k'' maggiore di 7 [http://www.math.unl.edu/~djaffe2/papers/sevens.html].
 
la dimensione del blocco FEC * numero di caratteri del blocco AES sarebbe quindi:
# 2^(8-1) * 16 = 2048 bit nel caso di FEC con input a 8 bit.
# (2 * 2^(4-1)) * 16 = 256 bit nel caso di FEC con input a 4 bit (ogni carattere 2 input).
 
prendendo il secondo caso, con un alfabeto di 16 toni per simbolo, quindi 4 bit, la latenza sarebbe di 64 simboli, che a 32 simboli per secondo farebbe 2 secondi per 16 caratteri.
 
la cosa migliore da fare e' rassegnarsi a questa latenza di blocco e cercare di fare uno spreading piu efficiente possibile, vedi interleaving.
 
letture:
 
* http://www.ece.ualberta.ca/~hcdc/Library/ErrorContrClass/DecodingBasic.pdf
* https://en.wikipedia.org/wiki/FX.25_Forward_Error_Correction
 
 
 
==== Interleaver ====
 
i possibili problemi 'descrivibili' del path di trasmissione sono:
 
problemi di spettro:
* interferenze coerenti (toni sovrapposti a uno dei nostri bin)
* errori della risposta in frequenza (equalizzazione..)
 
entrambi comportano il danneggamiento sistematico di una o piu determinate lettere dell'alfabeto in ogni simbolo
 
problemi nella sequenza di simboli:
* disturbo impulsivo prolungato su tutto lo spettro
* disturbo impulsivo ciclico su tutto lo spettro
 
che comportano la perdita di piu simboli contigui o la perdita sistematica di un determinato simbolo.
 
per mitigare questi problemi puo essere conveniente una qualche forma di interleaving sia in tempo che in frequenza/fase.
 
prendiamo il caso di un blocco da 256 bit formato da 4 sottoblocchi quadrati da 64bit -> 16 simboli*16 toni contenenti ognuno 4 caratteri.
 
con un hadamard code, si possono correggere fino ad 1/4 dei bit del codice.
 
prendiamo come casi peggiori possibili
* la perdita sistematica di 1 bit del simbolo
* la perdita di un intero sottoblocco
 
questo significa che in ogni sottoblocco si possono danneggiare (non contemporaneamente) fino a:
* 4 simboli
* 4 toni ?
 
il sistema piu rudimentale e' l'interleaving elicoidale, ad esempio una rotazione nel senso della sequenza combinata con una rotazione nel senso del simbolo.
l'incremento sarebbe di un bit/simbolo in senso verticale e di un sottoblocco + un simbolo in senso orizzontale
 
<source lang="C">
uint8_t InterleaveBlock(uint8_t *InData, int16_t *DataMatrix, uint8_t *ModulationSymbolsBuffer){
  uint8_t BitPos, SymbolOffset, BitOffset;
  for (uint8_t FECBlock = 0; FECBlock < HadamardCodesPerInterleaverBlock; FECBlock++){
      BlockEncodeChar(DataMatrix, InData[FECBlock]);
      for (uint8_t FECBit = 0; FECBit < HadamardCodeSize; FECBit++){
BitPos = (FECBlock * HadamardCodeSize) + FECBit;
BitOffset = BitPos % BitsPerModulationSymbol;
SymbolOffset = ((FECBit * HadamardCodeSize) + FECBlock) % SymbolsPerInterleaverBlock;
ModulationSymbolsBuffer[SymbolOffset] |= (DataMatrix[FECBit] & 0b1) << BitOffset;
// printf("%u,%u,%u\n", SymbolOffset, BitOffset, BitPos);
      }
//      printf("\n in FEC: ");
//      printbuf(DataMatrix, HadamardCodeSize, 8);
  }
}
</source>
 
che produce una disposizione [http://ciapini.contaminati.net/wiki/images/Interleaver8.png], dove il colore e' l'ordine dei bit in ingresso (dal blu al rosso), la x e' il tempo e la y il simbolo in uscita
 
 
 
==== Soft-Decision ====
 
nella catena di demodulazione si possono ottenere diversi indici di affidabilita
* rapporto tra il tono di picco e la media degli altri toni
* valore del picco carattere nella trasformata di hadamard
 
una cosa MOLTO carina da fare (dato che siamo in uno dei pochi casi in cui le risorse di calcolo sono ben piu grandi della banda) e' avere una qualche strategia di soft-decision pilotata dai valori in uscita dalla fft, magari triggerata da differenze tra l'energia nei bin inferiori a una data soglia.
 
 
 
==== Blocco start ====
 
indica l'inizio di una trasmissione. precede sempre un blocco HEADER.
 
questo riferimento deve avere autocorrelazione tendente a zero, essere abbastanza lungo (raro) da evitare false partenze, abbastanza corto da non creare overhead. viene usato per la sincronizzazione di simbolo e per l'equalizzazione.
 
lunghezza 8 simboli. 4 simboli alla frequenza/fase base e 4 all'estremo opposto della costellazione di simboli (frequenza massima/fase +180).
 
letture:
* http://www.ece.ualberta.ca/~hcdc/Library/NagKhaSchBur06.pdf
* http://www.argreenhouse.com/society/TaCom/papers99/32_5.pdf
* https://en.wikipedia.org/wiki/Gold_code
 
 
 
==== Blocchi header ====
 
sono una serie di almeno 1 blocchi con dimensione sempre 4 bytes che precedono sempre una serie di zero o piu blocchi dati.
 
il primo blocco e' chiamato '''default header''' ed e' sempre presente.
 
i blocchi header successivi sono indicati dall' '''header type'''
 
i blocchi header subiscono tutti block-coding -> interleaving
 
la lunghezza dell'intero messaggio sara sempre 4 + (hnum * 4) + (siz * 16) bytes
 
 
 
===== Default header =====
 
e' l'header di base, sta all'inizio di ogni messaggio e si occupa dell'instradamento locale e dell'ordinamento dei pacchetti
 
dev'essere implementato su ogni nodo
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
|style="color:blue"|8b (src)
|style="color:blue"|8b (dst)
||3b (hnum)
||5b (siz)
||8b (cnt)
|}
 
campi:
* '''hnum''' numero di header da 4 byte che seguono il default header.
* '''siz''' dimensione del blocco dati che segue in multipli di 16byte
* '''src''' indirizzo del mittente
* '''dst''' indirizzo del destinatario
* '''cnt''' contatore incrementale dei pacchetti inviati dal nodo con tupla (src,dst). un salto nella numerazione implica perdita pacchetti.
 
il multicast e' semplicemente un indirizzo di ricezione secondario sui client
 
src e dst sono significativi solo sul canale fisico, e' normale che ci siano client omonimi su due canali diversi
 
l'indirizzo 0 e' broadcast.
 
===== Segment Access Advertisement Header =====
 
il pacchetto viene mandato esclusivamente dai router per istruire i nodi che sono nel segmento di rete sul proprio indirizzo globale e sulle regole di accesso al canale
 
il routing e' un instradamento tra segmenti diversi. ogni segmento ha un indirizzo.
 
un indirizzo globale e' composto dall' ''indirizzo del segmento'' concatenato coll' ''indirizzo del nodo''
 
tutti i nodi che ricevono il pacchetto e vogliono aderire al router devono memorizzare queste impostazioni.
 
i nodi fanno il possibile per non trasmettere durante la trasmissione del SAAH.
 
i router presenti sul segmento devono concordare sulle informazioni contenute in questo pacchetto e trasmetterlo a turno.
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
||8b (tframe)
||8b (segaddr)
||8b (chanload)
||4b (congclient)
|}
 
* '''htype''' tipo header 0x1
* '''tframe''' dimensione timeframe del segmento in multipli di 100msec. il prossimo SAAH verra spedito dopo questo periodo.
* '''segaddr''' indirizzo del segmento di rete
* '''chanload''' numero di client attivi sul canale
* '''congclient''' numero di client che hanno comunicato congestione in output. i client senza congestione in output attenderanno almeno tframe*(congclient/chanload) prima di inviare.
 
il tempo di riferimento del segmento viene resettato all'inizio dello start block di ogni SAAH inviato dal router
 
letture:
 
* https://en.wikipedia.org/wiki/Time-division_multiplexing
* https://en.wikipedia.org/wiki/Time_division_multiple_access
* https://en.wikipedia.org/wiki/Dynamic_TDMA#Dynamic_TDMA
* https://en.wikipedia.org/wiki/Scheduling_algorithm
 
===== Global Routing Advertisement Header =====
 
il pacchetto viene mandato esclusivamente dai router ad altri router per descrivere la topologia della rete
 
===== Global Routed Transport Header =====
 
viene usato dai nodi per mandare dati in maniera routed (di solito a nodi che stanno su un segmento (canale) diverso da quello corrente).
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
|style="color:blue"|4b (ttl)
||1b (fecn)
||1b (becn)
||8b (segsrc)
||8b (segdst)
|}
 
* '''htype''' tipo header 0x2
* '''ttl''' numero di hop massimi di routing. viene decrementato ad ogni hop.
* '''fecn''' forward congestion notification. il nodo ha la coda di output piena e ha bisogno di trasmettere prima possibile. 0 normale, 1 congestionato.
* '''becn''' backward congestion notification. il nodo ha la coda di input piena e chiede che gli si mandino i dati piu tardi possibile. 0 normale, 1 congestionato.
* '''segsrc''' id del segmento di rete del mittente.
* '''segdst''' id del segmento di rete del destinatario.
 
se segsrc e segdst sono entrambi uguali al segaddr, allora il router funge da repeater
 
* i client ignorano i messaggi con segaddr diverso dal proprio
* i router invece li inoltrano
 
letture:
* http://nms.lcs.mit.edu/papers/hbhfc-sensys04.pdf
* http://hondo.informatik.uni-freiburg.de/pubs/MANET-trade_offs.pdf
 
===== CRC header =====
 
per avere conferma che il messaggio e' stato trasportato senza essere danneggiato
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
||4b (crctype)
||24b (crc)
|}
 
* '''htype''' tipo header 0x3
* '''crctype''' tipo crc (0x0000 = CRC-24 di OpenPGP)
* '''crc''' valore crc di TUTTO il blocco dati
 
 
 
===== Transport Reliability header =====
 
quando il FEC non basta...
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
||4b (arqtype)
||8b (cnt)
|}
 
* '''htype''' tipo header 0x4
* '''arqtype''' schema arq: 0x0 = "Stop-and-wait ARQ", 0x1 = "Go-Back-N ARQ", 0x2 = "Selective Repeat ARQ"
* '''arqaction''' arq action (ack, nack, retransmit)
* '''arqvalue''' arq value (cnt, back)
 
letture:
 
http://www.isode.com/whitepapers/stanag-5066.html
 
===== Timing Header =====
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
||11b (date)
||17b (time)
|}
 
* '''htype''' tipo header 0x5
* '''date''' days from epoch
* '''time''' seconds of day
 
===== Media Access Control =====
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
|}
 
* '''htype''' tipo header 0x6
 
==== Blocco DATA ====
 
sempre 16 bytes di dati netti
 
subisce: ''cifratura -> block-coding -> interleaving''
 
letture:
 
https://en.wikipedia.org/wiki/Communications_protocol
 
 
----


=== ANI ===
=== ANI ===

Revision as of 13:46, 16 May 2013

Device crittografico tascabile

modem piccolo, economico e a basso consumo per lo scambio a bassa velocita' di dati cifrati su canali rumorosi half-duplex con banda passante da 1Hz a 5khz.

i mezzi fisici usabili possono essere

chi e' interessato a una parte se la prenoti!

  • gnugo: FEC, interleaver, hardware
  • ciaby: dds
  • ema: aprs



Hardware

PCB

il circuito stampato + componenti avra spessore minimo (6 mm), e dovrebbe essere abbastanza piccolo (8-10 cm2)

Connessioni

sulla scheda si potrebbero mettere semplicemente i vari header


Connettore GPIO

header 8 pin, ad uso generico (radiocomandi)

1 GPIO1
2 GPIO2
3 GPIO3
4 GPIO4
5 GPIO5
6 GPIO6
7 GPIO7
8 GPIO8

Seriale

header 10 pin

si possono esporre una o due UART.

una potrebbe essere per l'in-band (cioe solo ed esclusivamente i dati trasmessi e ricevuti) e l'altra per out-of-band (tutte la gestione, i menu ecc).

per astrarre l'interfaccia e permettere l'uso di terminali piu avanzati, tutta la roba lato lcd e tastiera dovrebbe essere accessibile via seriale (una specie di tty).

se l'alimentazione fosse via usb, verrebbe da se... mettere un ft232 ed esporre una seriale via usb. un ft232rl e' un ssop28 e costa circa due euri. fornisce anche una 3.3v regolata di 50mA, che puo essere ok per alimentare il device dall'esterno.


1 U1_CTS UART1 clear to send.
2 U1_RTS UART1 ready to send.
3 U1_RX UART1 receive.
4 U1_TX UART1 transmit.
5 U1_GND Ground
6 U2_CTS UART2 clear to send.
7 U2_RTS UART2 ready to send.
8 U2_RX UART2 receive.
9 U2_TX UART2 transmit.
10 U2_GND Ground

Connettore modulazione

espone i simboli in maniera digitale

output:

1 OSB0 Out Symbol Bit 0
2 OSB1 Out Symbol Bit 1
3 OSB2 Out Symbol Bit 2
4 OSB3 Out Symbol Bit 3

input:

1 ISB0 Input Symbol Bit 0
2 ISB1 Input Symbol Bit 1
3 ISB2 Input Symbol Bit 2
4 ISB3 Input Symbol Bit 3


Connettore programmazione

Serve per poter programmare il pic una volta installato. Vanno ai rispettivi pin sul uC.

Pin Funzione Nome
1 Abilitazione programmazione ICSP_MCLR
2 Positivo. Dev'essere interrompibile con jumper VDD
3 Negativo VSS
4 Dati programmazione ICSP_DATA
5 Clock programmazione ICSP_CLOCK
6 Non usato Aux

Connettore tastiera

Pin Funzione Nome
1 KBD_ROW1
2 KBD_ROW2
3 KBD_ROW3
4 KBD_ROW4
5 KBD_COL1
6 KBD_COL2
7 KBD_COL3
8 KBD_COL4

Componenti interni

  • processore: dspic33fj128gp802 oppure dsPIC33FJ128GP804 se i piedini non ci bastano
  • 2 regolatori 3.3v
  • quarzo 8mhz
  • quarzo 32khz
  • op-amp filtro antialias 4khz
  • op amp uscita
  • condensatori di livellamento vari
  • condensatore tampone per cambio pile
  • FET di controllo carica batterie


uC

mappa pin dsPIC33FJ128GP804

  • RAM: 16K
  • Flash: 128K
  • Timers: 5
  • UART: 2
Pin Funzione Nome porta sul uC
1 RB9
2 RC6
3 RC7
4 RC8
5 RC9
6 Negativo digitale VSS
7 VCAP
8 RB10
9 RB11
10 Uscita + DAC R DAC1RP DAC1RP
11 Uscita - DAC R DAC1RN DAC1RN
12 RA10
13 RA7
14 Uscita + DAC L DAC1LP DAC1LP
15 Uscita - DAC L DAC1LN DAC1LN
16 Negativo analogico AVSS
17 Positivo analogico AVDD
18 Pin di programmazione MCLR
19 Ingresso audio L AUDIO_L_IN AN0
20 Ingresso audio R AUDIO_R_IN AN1
21 Dati ICSP PGED1
22 Clock ICSP PGEC1
23 Tensione Batteria V_BATT_IN AN4
24 RB3
25 Uscita 0 DAC R DAC1RM DAC1RM
26 Uscita 0 DAC L DAC1LM DAC1LM
27
28 Positivo digitale VDD
29 Negativo digitale VSS
30 Quarzo 8MHz OSC1
31 Quarzo 8MHz OSC2
32
33
34
35
36
37
38
39 Negativo digitale VSS
40 Positivo digitale VDD
41
42
43 INT0
44


Protocolli

armando e' in grado di parlare differenti protocolli


APRS

Automatic Packet Reporting System, e' un sistema di localizzazione a pacchetti che usa un protocollo AX.25 in modalita senza connessione su una modulazione afsk Bell 202 a 1200 bps

sarebbero utili 3 modalita APRS

  • client, che riceve dalla UART stringhe NMEA e le trasmette in aprs
  • digipeater, che ritrasmette i messaggi APRS ricevuti
  • gateway, che manda via UART i messaggi APRS ricevuti

Qui c'è vita morte e miracoli dell'aprs, con relative specifiche:

http://www.aprs.org/

la prima reference: ftp://ftp.tapr.org/aprssig/aprsspec/spec/aprs101/APRS101.pdf

sw da cui è possibile attingere: http://info.aprs.net/index.php?title=Software

Per fortuna ci sono delle bellissime librerie in c++

http://sourceforge.net/projects/libaprs/

http://sourceforge.net/projects/ax25/

https://code.google.com/p/trackuino/ (solo invio) c'e' una versione in gcc-C, progetto vivo

  • nei file trackuino-firmware-1.4/trackuino/ax25.cpp e trackuino-firmware-1.4/trackuino/aprs.cpp sembra esserci quel che serve


https://sites.google.com/site/ki4mcw/Home/arduino-tnc (solo ricezione)

http://aprsdroid.org/ (invia e riceve, codice utilizzabile?) AGH! e' scritto in SCALA.. mi sa di no

arNet

Il protocollo di comunicazione specifico di armando e' ArNet

ANI

client e server Push-To-Talk ID e selective calling.

tipi di ANI

  • Motorola’s MDC-1200
  • Kenwood’s FleetSync
  • Harris’ G-Star (aka GE-Star)
  • DTMF
  • 5-Tone

letture:


Firmware

voci di configurazione

  1. modulazione
    1. tipo di modulazione
      1. fsk
        1. bw in Hz uint16
      2. psk
      3. frequenza centrale uint16
      4. dimensione costellazione uint8
      5. simboli per secondo uint8
  2. ptt
    1. manuale/automatico
    2. tempo di guardia attacco in ms uint8
    3. tempo di guardia stacco in ms uint8
  3. protocollo
    1. arNet
      1. indirizzo uint8
      2. alias ricezione uint8
      3. router bool
        1. priorita uint8
        2. ttl uint8
      4. chiave 256 bit
    2. aprs
  4. interfaccia
    1. auto power off
    2. backlight



generatore OTP

dato che abbiamo un rtc l'apparato potrebbe fare da one time password generator. usiamo la chiave come seme? che implementazioni ci sono?

letteratura:

stringa di configurazione

la configurazione dell'apparato deovrebbe essere importabile ed esportabile come una stringa esadecimale anche la chiave crittografica sara una stringa di 16 caratteri esadecimali


PIN/PUC

quando il device andra in sleep sara necessario un pin di 4 caratteri per risvegliarlo

dopo 5 tentativi sbagliati, il device dimentica la chiave crittografica.


Mezzi fisici

Powerline

Retrieved from "http://ciapini.wiki.esiliati.org/index.php?title=Armando47&oldid=391"