Armando47: Difference between revisions

From ciapini
Jump to navigation Jump to search
No edit summary
 
(311 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Device crittografico tascabile
[[Category:Telecom]]
[[File:Aardvark2 (PSF).png]]
''modem tascabile''


device piccolo ed economico per lo scambio di messagi di testo cifrati su canali audio.
modem piccolo, economico e a basso consumo per la comunicazione digitale a bassa velocita' su canali rumorosi half-duplex con banda passante da 1Hz a 5khz.


chi e' interessato a una parte se la prenoti
{{Special:PrefixIndex/{{FULLPAGENAME}}/}}


* gnugo: FEC, interleaver, hardware
== Caratteristiche del mezzo trasmissivo ==
* ciaby: dds
* ema: aprs


* sempre broadcast
* banda 1 Hz - 5 kHz
* puo avere SNR infimi
* e' half-duplex
* puo' avere tempi di commutazione R/T lunghi
* non ha meccanismi di collision detect
* puo' non essere possibile la rilevazione di canale occupato
* puo' presentare condizioni di terminale nascosto
* puo contenere uno o piu' canali


== Interfaccia utente ==
esempi di mezzi fisici usabili possono essere:
* radio(pmr, cb, vhf, hf)
* rame
** RS485
** Powerline
* ottico
** fibra
** in aria
* acustico
* idroacustico
* induzione magnetica
* neutroni
* neutrini
* onde gravitazionali
* piccioni, topi, cani, blatte


* keypad 4x4 microswitch, con tasti da 0 a 9 e A/su B/giu C/sinistra D/destra E/enter F/exit
== Caratteristiche ==
=== Alimentazione ===
3.3v DC


=== lcd ===
=== Porte audio ===
input e output sbilanciati standard consumer line-level −10 dBV con impedenza 10kohm


per una serie di ragioni sarebbe meglio un GLCD (piu modelli a 3.3, piu compatto, piu economico) ma sembra che nessuno voglia prendersi lo sbattimento di implementare una grafica
=== Modulazione ===
quindi forse, per ora, si va su un display a caratteri


* lcd
Implementa squalsiasi combinazione di ASK, PSK, e FSK, con costellazioni di dimensione da 2 a 16, frequenza massima 5khz (campionamento a 20khz).
** http://www.ebay.com/itm/1-8-Serial-SPI-Interface-TFT-Color-LCD-Module-Display-128-x-160Dots-/170856821451?pt=LH_DefaultDomain_0&hash=item27c7dc32cb


un fet controlla l'accensione della backlight
Il symbol rate va da 1 a 1200 baud/s


== Contenitore ==
=== UART ===
2 seriali UART 9600N1 con livelli TTL 3.3v


se il device e' capace di caricarle, volendo si puo fare a meno dello scompartimento batterie apribile. si mettono dentro le batterie e si avvita. piu semplice e compatto, ma si perde la possibilita di poter aver dietro piu batterie e sostituirle.
=== GPIO ===
 
8 GPIO con acquisizione analogica e output PWM
c'e' poca roba per 4 stilo, volendo si puo andare a 2 o 3 stilo.
 
il circuito stampato avra spessore minimo (6 mm), e dovrebbe essere abbastanza piccolo (8-10 cm2)
 
* http://www.pactecenclosures.com/product-models.php?classid=27&seriesId=58
* http://www.serpac.com/h-series.aspx
* http://www.takachi-enclosure.com/data/p_01plastic.html
* http://www.polycase.com/
* http://www.all-boxes.com/index.shtml
* http://www.budind.com/plastic_boxes.php
* http://www.boxenclosures.com/
* http://www.newageenclosures.com/
* http://www.okw.co.uk/enclosures/plastic_enclosures.htm
* http://www.maplin.co.uk/components/enclosures/plastic-enclosures
 
possibili candidati
* http://www.newageenclosures.com/cart.php?m=product_detail&p=94&c=11
 
== Connettori esterni ==
 
=== Jack audio ===
 
Saranno due jack stereo da 3.5mm. idealmente il pinout dovrebbe essere piu simile possibile a quello degli rtx piu diffusi, in modo da poter collegare le radio con semplici cavi maschio-maschio jack
 
purtroppo i pinout degli rtx in circolazione sono una giungla. bisogna vedere sopprattutto i tipi di PTT in circolazione.
da armando si puo avere sia una tensione per TX che una chiusura contatto.
 
 
* gli intek mt-5050 sembra seguano lo standard icom
* il wouxun uv1d http://www.worldwidedx.com/amateur-radio-modifications/68013-wouxun-ht-spkr-mic-cable-pinout.html
* brondi http://www.rogerk.net/forum/index.php?topic=19946.0
 
letture:
* http://www.dl8kdl.net/articles/projects/electronics/pinouts
* http://www.wa4bpj.com/Ham_Radio/RARS/RARS_News_Hour/RARS_News_Hour.htm
 
=== Connettore digitale ===
{|style="color:blue; background-color:#eeeeee;" cellpadding="10" cellspacing="0" border="1"
||GND||Massa del device
|-
||digital V+||Uscita 3.3v regolati
|-
||UART_RX||
|-
||UART_TX||
|-
||UART_CTS||
|-
||UART_RTS||
|-
||OutSymbolBit0||
|-
||OutSymbolBit1||
|-
||OutSymbolBit2||
|-
||OutSymbolBit3||
|-
||PTT in||
|-
||PTT out||
|-
||SQUELCH in||
|-
|}
 
=== Connettore alimentazione ===
 
== 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
 
== Protocolli ==
 
armando e' in grado di parlare differenti protocolli
 
letteratura:
 
https://en.wikipedia.org/wiki/Gold_code
https://en.wikipedia.org/wiki/FX.25_Forward_Error_Correction
 
=== 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
 
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'''
 
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:
* half-duplex
* senza meccanismi di collision detect
* con rilevazione di canale occupato opzionale
 
usa schemi di modulazione 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 di start di 8 simboli
* uno o piu header da 4 byte ognuno, con FEC e interleaver
* zero o piu blocchi dati da 16 byte ognuno, con FEC, interleaver e (opzionalmente) [[#Cifratura]]
 
 
==== Cifratura ====
 
algoritmo di cifratura: AES-256
 
*http://www.literatecode.com/aes256 sembra ok
*http://gladman.plushost.co.uk/oldsite/AES/
*http://axtls.sourceforge.net/
 
==== 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.
 
==== indice di affidabilita ====
 
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
 
==== path di trasmissione ====
 
 
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 determinata lettera del 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.
 
==== Interleaver ====
 
per mitigare questi problemi puo essere conveniente una qualche forma di interleaving sia in tempo che in frequenza.
 
prendiamo il caso di un blocco da 256 bit formato da 4 sottoblocchi quadrati da 64bit -> 16 simboli*16 toni contenenti ognuno 4 caratteri.
sarebbe ottimale anche per eventuali caratteri di controllo.
 
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
 
questo [http://ciapini.contaminati.net/wiki/images/Interleaver8.png] e' lo schema di interleaving usato
 
==== Soft-Decision ====
 
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.
 
lunghezza 8 simboli. 4 simboli che rappresentao bit0 e 4 che rappresentano il bit massimo.
 
==== Blocchi header ====
 
sono una serie di almeno 1 blocchi con dimensione sempre 4 bytes che precedono sempre una serie di uno 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 ====
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
|style="color:blue"|8b (src)
|style="color:blue"|8b (dst)
||2b (hnum)
||6b (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/indirizzo del gruppo destinatario
* '''cnt''' contatore incrementale dei pacchetti inviati dal nodo con tupla (src,dst/grp). un salto nella numerazione implica perdita pacchetti.
 
il multicast e' semplicemente un indirizzo di ricezione secondario sui client
 
==== Routing header ====
 
il routing deve essere pensato per i tempi di commutazione lunghi e l'assenza di collision detect
 
si potrebbe fare che il router torna degli ack di quel che e' riuscito a ricevere senza danni
 
opppure che il router esplicitamente dice chi deve trasmettere e quando
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
|style="color:blue"|4b (ttl)
|style="color:blue"|2b (pri)
||1b (fcn)
||1b (router)
||8b (tframe)
|}
 
* '''htype''' tipo header 0x1
* '''ttl''' numero di hop massimi di routing. viene decrementato ad ogni hop.
* '''pri''' priorita. 0 alta, 4 bassa.
* '''fcn''' forward congestion notification. 0 normale, 1 congestionato.
* '''tframe''' dimensione timeframe del router in multipli di 10msec, copiato dai router e ripetuto
* '''router''' il sender e' un router
 
==== CRC header ====
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
||4b (htype)
||4b (crctype)
||24b (crc)
|}
 
* '''htype''' tipo header 0x2
* '''crctype''' tipo crc (0x0000 = CRC-24 di OpenPGP)
* '''crc''' valore crc
 
==== ARQ header ====
 
letture:
 
http://www.isode.com/whitepapers/stanag-5066.html
 
==== Blocco DATA ====
 
sempre 16 bytes di dati netti
 
subisce: ''cifratura -> block-coding -> interleaving''
 
 
 
== voci di configurazione ==
 
# modulazione
## tipo di modulazione
### fsk
#### bw in Hz uint16
### psk
### frequenza centrale ''uint16''
### dimensione costellazione ''uint8''
### simboli per secondo ''uint8''
# ptt
## manuale/automatico
## tempo di guardia attacco in ms ''uint8''
## tempo di guardia stacco in ms ''uint8''
# protocollo
## arNet
### indirizzo ''uint8''
### alias ricezione ''uint8''
### router ''bool''
#### priorita ''uint8''
#### ttl ''uint8''
### chiave 256 bit
## aprs
# interfaccia
## auto power off
## backlight
 
== uC ==
 
mappa pin:
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
!Pin
!Funzione
!Nome
!porta
|-
|1|| ||MCLR||
|-
|2||Ingresso audio. sbilanciato 3.3v||AUDIO_IN||RA0
|-
|3||Livello batteria/2||BATT_IN||RA1
|-
|4||Pulse 1 matrice tasti/PGED1||KEY_PULSE_1||RB0
|-
|5||Pulse 2 matrice tasti/PGEC1||KEY_PULSE_2||RB1
|-
|6||Pulse 3 matrice tasti||KEY_PULSE_3||RB2
|-
|7||Pulse 4 matrice tasti||KEY_PULSE_4||RB3
|-
|8|| ||VSS||
|-
|9||Xtal 8mhz||OSC1||RA2
|-
|10||Xtal 8mhz||OSC2||RA3
|-
|11||Ptt in||PTT_IN||RB4
|-
|12||Ptt out||PTT_OUT||RA4
|-
|13|| ||VDD||
|-
|14|| || ||RB5
|-
|15||Display SDO|| ||RB6
|-
|16||Display SCL|| ||RB7
|-
|17||UART Tx|| ||RB8
|-
|18||UART Rx|| ||RB9
|-
|19|| ||VSS||
|-
|20|| ||VCAP||
|-
|21||Ritorno 1 matrice tasti||KEY_RETURN_1||RB10
|-
|22||Ritorno 2 matrice tasti||KEY_RETURN_2||RB11
|-
|23||Ritorno 3 matrice tasti||KEY_RETURN_3||RB12
|-
|24||Ritorno 4 matrice tasti||KEY_RETURN_4||RB13
|-
|25||Uscita + DAC||DAC1LP||RB14
|-
|26||Uscita - DAC||DAC1LN||RB15
|-
|27|| ||AVSS||
|-
|28|| ||AVDD||
|}
 
 
{|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
!Pin
!Funzione
!Nome
!porta
|-
|1|| || ||
|-
|2|| || ||
|-
|3|| || ||
|-
|4|| || ||
|-
|5|| || ||
|-
|6|| ||VSS||
|-
|7|| ||VCAP||
|-
|8|| || ||
|-
|9|| || ||
|-
|10|| || ||
|-
|11|| || ||
|-
|12|| || ||
|-
|13|| || ||
|-
|14|| || ||
|-
|15|| || ||
|-
|16|| ||AVSS||
|-
|17|| ||AVDD||
|-
|18|| ||MCLR||
|-
|19||Ingresso audio||AUDIO_IN||AN0
|-
|20||V batteria/2||VBATT_IN||AN1
|-
|21|| ||PGED1||
|-
|22|| ||PGEC1||
|-
|23|| || ||
|-
|24|| || ||
|-
|25|| || ||
|-
|26|| || ||
|-
|27|| || ||
|-
|28|| ||VDD||
|-
|29|| ||VSS||
|-
|30||Quarzo 8MHz||OSC1||
|-
|31||Quarzo 8MHz||OSC2||
|-
|32|| || ||
|-
|33|| || ||
|-
|34|| || ||
|-
|35|| || ||
|-
|36|| || ||
|-
|37|| || ||
|-
|38|| || ||
|-
|39|| ||VSS||
|-
|40|| ||VDD||
|-
|41|| || ||
|-
|42|| || ||
|-
|43|| || ||
|-
|44|| || ||
 
|}
 
 
 
== 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:
* https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm
* https://otpd.googlecode.com/svn-history/r77/trunk/cardops/totp.c
 
== 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.
 
 
 
 
== Alimentazione ==
=== regolatori ===
 
step-up:
* http://www.linear.com/product/LTC3525D-3.3
 
charge-pump
* http://www.ti.com/product/tps60205
 
power manager:
* http://www.linear.com/product/LTC3456
 
=== batterie ===
 
4 stilo o ministilo Ni-Mh o alkaline (la tensione va da 4.5 a 6v)
 
se 4 stilo e' scomodo per altri motivi, si puo andare con 2 stilo e regolatore step-up. di buono c'e' che si puo caricare da usb.
 
la tensione batteria a monte dei regolatori viene campionata a valle di un partitore 1/2
quando la tensione scende sotto il livello critico, il device va in sleep.
 
=== ricarica batterie ===
 
il device deve poter ricaricare le batterie da una alimentazione esterna, con controllo dV della carica.
 
questo significa che l'alimentazione esterna sara' di almeno 4*1.27*1.5 = 7.62 v
 
=== tampone ===
 
il device deve poter conservare le impostazioni anche dopo brevi interruzioni dell'alimentazione (cambio pile o alimentazione esterna)
se il uP e' in sleep mode dovrebbe bastare un condensatore elettrolitico
 
== ANI ==
 
tipi di ANI
 
* Motorola’s MDC-1200
* Kenwood’s FleetSync
* Harris’ G-Star (aka GE-Star)
* DTMF
* 5-Tone

Latest revision as of 19:41, 28 September 2016

Aardvark2 (PSF).png modem tascabile

modem piccolo, economico e a basso consumo per la comunicazione digitale a bassa velocita' su canali rumorosi half-duplex con banda passante da 1Hz a 5khz.

Caratteristiche del mezzo trasmissivo

  • sempre broadcast
  • banda 1 Hz - 5 kHz
  • puo avere SNR infimi
  • e' half-duplex
  • puo' avere tempi di commutazione R/T lunghi
  • non ha meccanismi di collision detect
  • puo' non essere possibile la rilevazione di canale occupato
  • puo' presentare condizioni di terminale nascosto
  • puo contenere uno o piu' canali

esempi di mezzi fisici usabili possono essere:

  • radio(pmr, cb, vhf, hf)
  • rame
    • RS485
    • Powerline
  • ottico
    • fibra
    • in aria
  • acustico
  • idroacustico
  • induzione magnetica
  • neutroni
  • neutrini
  • onde gravitazionali
  • piccioni, topi, cani, blatte

Caratteristiche

Alimentazione

3.3v DC

Porte audio

input e output sbilanciati standard consumer line-level −10 dBV con impedenza 10kohm

Modulazione

Implementa squalsiasi combinazione di ASK, PSK, e FSK, con costellazioni di dimensione da 2 a 16, frequenza massima 5khz (campionamento a 20khz).

Il symbol rate va da 1 a 1200 baud/s

UART

2 seriali UART 9600N1 con livelli TTL 3.3v

GPIO

8 GPIO con acquisizione analogica e output PWM

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