Archivi categoria: Ricerca

KNX Bus Monitoring a basso costo

Supponiamo che si voglia realizzare un monitor del bus KNX in una installazione domestica con “valore aggiunto” domotico. Le strade possibili sono diverse e variano a seconda del tipo di portafoglio e di installazione realizzata.
Per gli utenti Gewiss che hanno prodotti della serie “easy”, la funzione di monitoraggio è offerta dal software Easy Controller, che tuttavia non registra le informazioni su disco.
Per chi voglia avere un approccio generico, è possibile usare ETS5/6 in modalità “demo” in modo da non dovere pagare la costosissima licenza.
Il limite di questi software è costituito dal fatto che NON nascono per una applicazione di monitoraggio del bus, ma offrono questo servizio a supporto del “debug” delle applicazioni.

In entrambi i casi è necessario disporre di una interfaccia tra bus KNX e calcolatore, con collegamento via rete LAN, seriale o USB. Le interfacce di marche blasonate sono molto costose. Il mercato pullula di interfacce low-cost, da usare direttamente connesse alla Raspberry o che richiedono un collegamento seriale. La maggiore parte sono le tpuart, che sono ampiamente citate negli esempi trovati in rete.
Volendo fare qualche prova con la “valigia domotica Gewiss”, ho acquistato su Aliexpress, una semplice interfaccia USB/KNX (KNX Downloader) al prezzo di 56 euro. Non sono pochi ma sono una frazione rispetto a quanto richiesto dai “big players”.

L’idea è quella di integrare questo dispositivo in ambiente Linux (Ubuntu server) ed associarlo a KNX per potere realizzare un logger. Gli step sono:
– installare Ubuntu server su una macchina virtuale;
– compilare, fare funzionare knxd in modo dignitoso;
– fare comunicare KNXD con l’interfaccia;
– fare in modo che knxd “tiri fuori i dati” dal bus knx in qualche forma.

Complice il fatto che sono un principiante di KNX, questo processo mi ha richiesto un sacco di tempo e per questo vorrei documentarlo al meglio.
KNXD (maggiori informazioni qui) (oppure qui)
Installare questo software con un pacchetto debian o ubuntu significa perdere tempo. knxd DEVE essere ricompilato e per farlo, occorre prima scaricare “qualche” libreria e pacchetto aggiuntivo:
– apt install libtool
– apt install libusb-1.0-0-dev
– apt install libsystemd-dev
– apt install build-essential
– apt install libev-dev
Fatto questo è possibile clonare il repository: git clone https://github.com/knxd/knxd.git e procedere, come indicato sul sito, alla compilazione:
– cd knxd
– git checkout main
– sh bootstrap.sh
– ./configure –your-chosen-options
– make
– make install
Lo step che può dare “grattacapi” è quello che esegue bootstrap.sh, script deputato (anche) al controllo della presenza di tutto il necessario per la compilazione. Il build del software richiede qualche minuto ma termina con successo. Una volta eseguita l’installazione, tutti i binari si trovano al loro posto.

Lo step successivo è dare in pasto a knxd il dispositivo giusto. Il KNX-Downloader viene riconosciuto immediatamente ma occorre rendere l’accesso al device più libertino.
root@knx:~# lsusb
Bus 001 Device 003: ID 0403:6898 Future Technology Devices International, Ltd TSY KNX-USB Data Interface
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root@knx:~#


Usando udevadm: si crea il file /etc/udev/rules.d/70-knxd.rules ed al suo interno si inserisce questa stringa:
SUBSYSTEMS==”usb”, ATTRS{idVendor}==”067b”, ATTRS{idProduct}==”2303″, GROUP=”users”, MODE=”0666″
In questo modo, quando il sistema udev, riconosce il device, così come descritto da idVendor e id Product, associa ad esseo il permission 0666.
Per verificare che knxd possa digerire il dispositivo c’è un comodissimo comando: findknxusb:
root@knx:~# findknxusb
Possible addresses for KNX USB devices:
device: 1:3:1:0:0 (TSY Technology:TSY KNX-USB Data Interface)

Una volta verificata questa possibilità non rimane altro che configurare knxd, e su questo punto ho impiegato diverso tempo.

Chiariamo che knxd non è altro che un router tra il mondo knx ed il mondo ip, in pratica è possibile configurarlo per fare in modo che ad una PDU KNX corrisponda un pacchetto ip e viceversa. knxd può essere configurato attraverso un file di configurazione (che DEVE avere estensione .ini) o attraverso la riga di comando, passandogli una serie di parametri che, fortunatamente sono molto ben documentati, in questo sito.
Dopo diverse prove e grazie a questo sito, la stringa funzionante è questa:
knxd –trace=5 –error=5 –eibaddr=0.2.118 –client-addrs=0.2.20:20 -D -T -R -S -i -b usb:
Due parole di spiegazione:
– trace ed error: livello di debug e di report durante l’esecuzione del software;
– eibaddr: indirizzo del device softare knxd. Come se fosse l’indirizzo dell’adattore USB;
– client-adds: spazio degli indirizzi dei client che si connettono lato ip.
– D : discover. Consente a knxd di rispondere ai pacchetti di discover;
– T : abilita la funzione di tunneling;
– R: consenti lo scambio di pacchetti multicast, usato da altri router knx;
– S: seleziona l’interfaccia ip, sulla quale è presente la default route;
– i: aggancia knxd su tutti gli indirizzi ip< configurati sul dispositivo;
-b: specifica il dispositivo L2 da usare per la connessione
– usb: nella versione attuale, non richiede di specificare il dispositivo da usare. KNXD cerca tra i dispositivi, quello più adatto ai suoi scopi.
SE tutto va a buon fine:

root@knx:~# knxd –trace=5 –error=5 –eibaddr=0.2.118 –client-addrs=0.2.20:20 -D -T -R -S -i -b usb:
W00000125: [ 1:main] Consider using a config file.
W00000126: [ 1:main] knxd should not run as root
Layer 0 [16:B.usb/USBdr 0.020] starting send_Local
Layer 0 [18:B.usb/usbL 0.020] SendUSB(064): 01 13 09 00 08 00 01 0F 01 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0 [18:B.usb/usbL 0.020] StartSend 5595789896d0
Layer 0 [ 4:server/Server 0.020] Open
Layer 0 [ 4:server/Server 0.020] Opened
N00000127: [22:router.pace_] The ‘pace’ filter without a queue acts globally.
Layer 0 [16:B.usb/USBdr 0.031] send_Local done
Layer 0 [18:B.usb/usbL 0.035] RecvUSB(064): 01 13 0B 00 08 00 03 0F 02 00 00 01 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 2 [16:B.usb/USBdr 0.035] recv_Data(064): 01 13 0B 00 08 00 03 0F 02 00 00 01 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 2 [17:B.usb/Conv 0.035] send_Init 3
Layer 0 [17:B.usb/Conv 0.035] starting send_Local
Layer 0 [18:B.usb/usbL 0.035] SendUSB(064): 01 13 0A 00 08 00 02 0F 03 00 00 05 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0 [18:B.usb/usbL 0.035] StartSend 5595789719a0
Layer 0 [17:B.usb/Conv 0.047] send_Local done
Layer 2 [23:B.usb/CEMI 0.047] OpenL2

A questo punto occorre trovare un software che possa decodificare il traffico knx in modo da poterlo elaborare in modo opportuno.
I candidati sono due:
knxtool e knx-logger.
–knxtool (maggiori informazioni qui ed anche qui)
Programma che consente di interagire con il bus knx. La descrizione in rete non rende giustizia a questo tool, davvero complesso. Invocando il comando con lo switch “list” si ottengono tutte le opzioni di esecuzione:

Tra le tante opzioni sono evidenti i “bus monitor” ed il “vbusmonitor”. In rete ho trovato alcune indicazioni in merito ad un non corretto funzionamento di “busmonitor”, pertanto mi sono concentrato su “vbusmonitor”.
La sintassi di knxtool, prevede che venga invocato indicando l’indirizzo ip dell’interfaccia alla quale si deve collegare:
root@knx:~# knxtool vbusmonitor1 ip:192.168.188.176
L’avvenuta connessione è mostrata anche da knxd:
Layer 0 [24:A.tcp/CConn 3987.870] ReadMessage(002): 00 13
Layer 0 [24:A.tcp/CConn 3987.870] Send(002): 00 13

A questo punto il sistema è “pronto” per interpretare i telegrammi che transitano sul bus knx.
–knxlogger ( maggiori informazioni qui )
Tool essenziale, con una minore configurabilità rispetto al precedente. Per la invocazione richiede solo l’indicazione dell’ip sul quale fare la connessione.
root@knx:~/knx-logger# ./knx-logger ip:192.168.188.176
2022-05-16 07:21:15 Write FROM 0.2.5 TO 24/0/14 VALUE


Fortunatamente sono in una situazione ideale: ho la valigia domotica a disposizione, collegata al calcolatore con una interfaccia USB Gewiss e posso monitorare il traffico KNX con l’applicazione “Easy Controller Software“. Contemporaneamente ho una macchina virtuale che esegue Ubuntu server, ove è in esecuzione knxd ed il logger. Pertanto posso fare un parallelo tra azione (pressione di un pulsante) e modo in cui i due software registrano e visualizzano l’evento.

Configurazione di sistema
Pressione di un pulsante sul dimostratore.

Il modo in cui knxtool mostra il telegramma dipende dallo switch con il quale è stato invocato:
vbusmonitor1:
L_Busmon: BC 02 05 C0 0E E1 00 81 EA :L_Data low from 0.2.5 to 24/0/14 hops: 06 T_Data_Group A_GroupValue_Write (small) 01
vbusmonitor2:
BC 02 05 C0 0E E1 00 81 EA
vbusmonitor3:
(0, f9e953b3) BC 02 05 C0 0E E1 00 81 EA

Nel primo caso le informazioni hanno una componente “human readable”: Il telegramma è stato inviato dal dispositivo 0.2.5 (coerente con l’analizzatore Gewiss) ed ha un determinato payload. L’intepretazione della stringa deve essere fatta attraverso delle funzioni (python ne prevede di native – untested) o riferendosi alla specifica del protocollo.

Come ultimo step, ho voluto fare un monitoraggio del bus anche con ETS5, versione professional. Mi ha colpito il fatto che all’avvio, ETS abbia “visto” anche knxd come interfaccia usabile per la configurazione/monitoraggio del sistema.

Premendo il “solito” pulsante, il risultato di ETS è maggiormente prolisso:

Conclusione:
in questo non breve articolo, ho presentato una soluzione economica per il monitoraggio della bus KNX. I test di funzionamento sono stati svolti utilizzando un dimostratore domotico commerciale ed hanno dato ottimi risultati.

UCCM – GPSDO la coppia

Finalmente è arrivato il GPSDO che attendevo, come rimpiazzo del buon vecchio Trimble che si è (o è sempre stato) rotto. Un paio di giorni per compiere il trapianto di organo e, finalmente, sulla mia Timing-Desk ho due GPSDO up and running.
Anche questo Samsung è passato subito in stato locked con valori di TFOM stabili ad 1. Si tratta di una unità non propriamente “gemella” dell’altra: il quarzo installato è di dimensioni notevolmente maggiori (sempre marcato Samsung).

Lady Heather per il nuovo Samsung.

La posizione stimata dai due dispositivi è davvero molto “prossima”, visto che usano lo stesso ricevitore GPS (Ublox Lea-6t) e sono nelle stesse condizioni operative:
Samsung 1 (old)
Lat: 43.5866244N Long: 13.5170058E Alt: 226.24
Samsung 2 (new)
Lat: 43.5866200N Long: 13.5170047E Alt: 225.99
Distanza stimata su WG84 di 0.5m, non male.

In modo molto barbaro ho fatto una misura di frequenza, mantenendo il vecchio Samsung (OSM da qui in poi) come riferimento per il counter ed il nuovo come DUT. La misura è incoraggiante.

Misura di frequenza di NSM vs OSM.

Adesso occorre solo aspettare che arrivi il Thunderbolt e qualche accessorio per farlo funzionare:
– amplificatore di distribuzione a 10MHz;
– distributore del segnale GPS a 4 vie (utile anche per una idea futura);
– HUB e convertitori USB-RS232 per il controllo ed il monitoraggio dei sistemi.
Intanto mi godo il monitor!

GPSDO: finalmente stabile

Quasi una settimana di utilizzo dei due GPSDO, tempo di fare qualche considerazione “a caldo”:
1- L’interfacciamento dei due dispositivi con il calcolatore mi ha fatto penare. Avevo preso un convertitore USB seriale su PCB, ma è risultato “non funzionante”, pertanto ho dovuto optare per la classica “frusta” USB-RS232.
2- Devo modificare il circuito di alimentazione: un solo LM317 è poco e la temperatura che raggiunge il dispositivo è decisamente alta. Meglio usarne due in parallelo e montarli sui dissipatori in alluminio che la scatola prevede, possibilmente uno per lato.
3- Il “trimble” viene “digerito” da Linux senza problemi e Lady Heather ne mostra i (pochi) parametri in modo immediato. Più complesso collegare il Samsung: ho dovuto usare un artificio. Esportare la seriale /dev/ttyUSB1 in rete con ser2net e poi collegare Lady Heater via IP:
ser2net -C 3202:raw:0:/dev/ttyUSB1:57600 -l
sudo ./heather -tz=UTC -ip=192.168.1xx.yy:3202
La mia impressione è che il software e l’hardware non si accordino sulla velocità dell’interfaccia.
4- Il Trimble mostra tutta la sua età: stabilizza poco il PPS e ha un valore di TFOM pari a 4. Considerata l’età è tanto che ancora funzioni bene.
5- Adesso che tutto funziona… vorrei uno splitter GPS a 4 porte ed un ThunderBolt da mettere a sistema, per vedere se le performances che promette (e di cui tutti parlano) sono reali.

Sistema funzionante e settato.

Dallo screenshot si nota come, a parità di antenna, cavo e condizioni “al contorno”, i due sistemi rilevino una posizione leggermente differente:
Trimble:
Latitudine: 43.5866217 N – Longitudine: 13.5170019 E- Altezza: 224.19m
Samsung:
Latitudine: 43.5866175 N – Longitudine: 13.5170086 E- Altezza:223.89m
La differenza di altezza è di 30cm, la distanza è di 71.5 cm. In pratica il Trimble è “in alto a sinistra” rispetto al Samsung.

Immagine del setup completamente operativo

Con l’occasione ho riacceso il counter HP 53131A ed il mio EIP 350, almeno si sono un po’ riscaldati. Mi sono divertito a calcolare la deviazione standard del rapporto tra gli intervalli del segnale PPS. IL conteggio è stato fatto su 10k secondi ed ha mostrato un valore molto interessante: 1.09uS.

Valore della deviazione standard del rapporto tra i periodi PPS.

Notare come sia comparso un altro giocattolo: un vecchissimo counter HP 5315B trovato nello scatolone dei cespiti (monnezza). Lo ho accesso a vita persa ed ha funzionato subito. Sicuramente è possibile rimetterlo in riga ed ho trovato un interessante articolo per dotarlo di un ingresso 10MHz esterno. Ne riparleremo.

How to dismantle a PhD Thesis

Parafrasando gli U2, mi sono dedicato alla distruzione controllata del prodotto del mio Dottorato di Ricerca. Durante lo studio ho sviluppato un sistema trasmettitore – ricevitore operante a 76GHz, per la caratterizzazione del canale in ambiente marino. Per la realizzazione avevo attinto al catalogo dei prodotti di DL2AM (Phillip Prinz) ed avevo speso una fortuna.

Dopo la fine del dottorato, gli apparati sono stati usati da un paio di tesisti e poi sono rimasti sullo scaffale, in attesa che si concretizzasse un progetto che non ha mai visto la luce. Recentemente, complice il fatto che vorrei investire dei soldi in un acquisto “sportivo”, ho deciso di smontare tutto e vendere i componenti di maggiore pregio.

A 3/4 anni di distanza, sono rimasto molto soddisfatto dello stato di conservazione del sistema e del lavoro che avevo fatto.

Alcune foto dei tempi che furono.

Setup alla “lavagna luminosa” per centraggio del lanciatore nella guida circolare:

Incollaggio dei diodi, eseguito a mano libera e con una lente di ingrandimento delle “patatine”. Lavoro poi controllato allo stereomicroscopio.

A sinistra un diodo per microonde incollato sulle sue microstrisce, a destra il diodo pronto per il trattamento. Le dimensioni sono 0.6×0.3 mm.

Lavoro di tesi (Fioritto – Spoletini) eseguito al mare, per caratterizzare il comportamento del canale in base al mutare dell’umidità dell’aria. Il ricevitore era corredato di sensori di temperatura umidità e pressione atmosferica.

Il ricevitore oggi, in fase di “disinnesco”:

Alcuni dettagli del ricevitore:

distributore di alimentazioni e telaio (la scatola gewiss è nera in quanto pitturata in grafite)

raspberry pi (notare tutti i cavi della GPIO con termorestringente) e preamplificatore 144MHz

scheda di controllo con Si570, convertitori A/D per il monitoraggio delle tensioni e del livello del segnale ricevuto

Il lavoro ultimato. Tutti i blocchi sono stati separati ed ora è il momento di recuperare i componenti attivi e passivi.

AIS – OffLine

Due to a server failure, the AIS server is offline. Unfortunately we don’t have any spare hardware to setup a new environment with data backup. We will remain offline till new hardware comes.

Sorry for the inconvenience.

AIS – un aggiornamento

Correzione di un piccolo BUG nel sito web che presenta i dati dell’AIS: se sono presenti delle imbarcazioni che hanno un apostrofo nel nome, la mappa non funziona. Ho corretto il codice, inserendo una piccola funzione che elimina del tutto gli apostrofi dal nome. Il precedente approccio con un escape character non era valido.

Ho aggiunto la funzione di “ricerca” informazioni nel menu a nuvola che si apre cliccando su una stazione. Adesso compare la voce “search” che redirige al sito di MarineTraffic e visualizza il risultato della ricerca di quel particolare MMSI. Interessante potere visualizzare le foto della imbarcazione e i dati aggregati raccolti da MarineTraffic.

Ricordo il sito di riferimento: http://ais.dii.univpm.it/

WebSdr – PmSDR and RTL-SDR configuration Guide

PMSDR is a small, cheap and high quality SDR Receiver. It was conceived by Martin Pernter Iw3AUT some years ago. I have been using it for both hobby and scientific research, loving its stability and ease of use.

After a long time, during which the receiver collected dust on a shelf in my office, I decided to bring it again to life for the WebSDR project. I’ll not give details on the work of PA3FWM, please visit its site to learn about its work.

The WebSDR project is addressed both to hamradio  enthusiast both to students of the University where I work. SDR technologies are wide spread and it’s time to talk about this subject in the telecommunications oriented courses that are held at University. So I think that the possibility to show some real application of SDR can support the learning path of students, trying to catch their curiosity.

Phase 1 of the projects requires to setup a basic system, using PMSDR and RTL-SDR dongle in order to evaluate performances and get acquainted with WebSDR software.

RTL-SDR.
Configuring the dongle to work in WebSDR is quite easy. It requires the installation of rtl-sdr package in order to provide rtl_tcp command.

After connecting the dongle to the PC, you can check it has been correctly recognised with the lsusb command.

websdr@websdr:~$ lsusb
Bus 002 Device 002: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T

In order to let the dongle receive and forward data, you can use the rtl_tcp program. It will create a socket and stream I/Q samples through it. Put this command in your rc.local file to execute it as a daemon during computer boot.

rtl_tcp -a 127.0.0.1 -p 65144 -f 145000000 -d 0

Remembre that if you want to change the receiving frequency, you have to modify THIS script, otherwise nothing will happen. The command stated shows -p switch, in order to set the streaming port, the -f to set the working frequency and -d to address a specific device in case you have multiple dongles.

WebSDR configuration lines for RTL-SDR are very simple:
#rtl_sdr per i 3cm
band 3cm
device !rtlsdr 127.0.0.1:65144 85
samplerate 2048000
centerfreq 681000
antenna lnb

The “85” shows the amount of ppm correction to apply in the frequency.

PMSDR
Setting up the PMSDR may be a little “tricky”. First of all you have to consider this is a “near-zero IF SDR”: it will provide an audio baseband signal to a sound-card. First of all you have to setup an ALSA sound system. If you (like me) are not very familiar with Linux audio world, well “don’t panic”. The sound-card I use with PMSDR is USB connected. So let’s check it:

websdr@websdr:~$ lsusb
Bus 002 Device 002: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 002: ID 041e:30df Creative Technology, Ltd

Now it’s time to hadle permissions for using the soundcard:
websdr@websdr:~$ cat /etc/udev/
hwdb.d/ rules.d/ udev.conf
websdr@websdr:~$ cat /etc/udev/rules.d/90-creative.rules
ACTION==”add”, SUBSYSTEM==”usb”, SYSFS{idVendor}==”041e”, SYSFS{idProduct}==”30df”, GROUP=”audio”
websdr@websdr:~$

Now you should be able to use the “magic” command:
websdr@websdr:~$ arecord -l
**** List of CAPTURE Hardware Devices ****
(…)
card 1: Pro [SB X-Fi Surround 5.1 Pro], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0

Before trying to go any further is mandatory to check if ALSA can support your hardware. In any other case all your efforts will result in a total loss of time. According to ALSA site, the SB X-Fi in UNSUPPORTED.

So let’s give up and try another Audio Adapter, this time embedded device:

root@websdr:~# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 2: ALC662 rev1 Alt Analog [ALC662 rev1 Alt Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0

WebSDR configuration file wants to know 3 parameters: card,device, subdevice. Using this command we can retrive all data we need, as the card number is “0”, the device is “0” and the device is “0” as well. Write this parameters and  forget them.

Now you need a way to interact with PMSDR internal PIC in order to program the internal oscillators. More over, if your PMSDR is equipped with a Downconverter board, you have to program it as well. There is a small,yet realiable and easy-to-use, client which was written by Andrea Montefusco and is available on sourceforge. You have to build it, so install gcc and read carefully the installation notes. After the program has been built, run it by “pmsdr”. There is an embedded help system.

Linux PMSDR 2.0/2.1 control program, version 2.5.1
Original code by Martin Pernter IW3AUT
Linux porting by Andrea Montefusco IW0HDV
www.obdev.at – DG8SAQ-I2C
Interface 0 claimed.
Firmware reports version 2.5.0
Si570 detected.
CY22393 detected.
Downconverter Board detected.
Si570 on Downconverter Board detected.
Type ‘help’ or ‘?’ for get online help.
/tmp/PMSDRcommands FIFO unavailable [No such file or directory]
Input switched to standard input.
—> help

<command> [<value>] //
FREQUENCY : f <d> // f 7050000 == ( 7.050,000 kHz)
F3Harmonic : f3 <d> // f3 100300000 == ( 100.300 MHz)
FREQUENCY Dc : fd <d> // down converter conversion frequency in Hz
FILTER : filter <d> // 0 (no filter),1 (2-6MHz),2 (5-12MHz),3 (10-24MHz), 4 (<2MHz)
DFILTER : dfilter <d> // 0 (down converter bypass), 1 (VHF filter), 2 (UHF filter), 3 (unfiltered)
QSDbias : qsdbias <d> // qsdbias 512 (default), 346-692 (interval allowed)
QSDmute : qsdmute <on,off> // qsdmute on, qsd off (i.e. 0,1
STOREfreq : memf <d> // store init freq into PMSDR EEPROM f 585000 == (585,000 kHz)
STOREfreq3 : memf3 <d> // store init f3/3 into PMSDR EEPROM
RESTORE freq : rmemf // restore init freq from PMSDR EEPROM
PRINTlcd : plcd <col> <row> <message_text> // print the message text at specified coord on the LCD
QUIT : quit // exit from pmsdr
HELP : help // this help!

INPUT-SEQUENCE-example:
->help,filter 4,f 1611000,f 585000,memf 585000,filter 0,f3 100300000,quit

In order to set PMSDR for 2m reception you need to program downconverter first:
dfilter 1
fd 116000000
In this way 144MHz is downconverted to 28MHz. So the next step is
filter 0
f 28000000
save it!
memf 28000000.

Now let’s go back to WebSDR and let’s write some configuration for PMSDR as well:
#pmsdr per i 2m
band 2m
#alsa devices are: card/dev/subdev
device $hw:0,0,0
samplerate 96000
centerfreq 144320

Some screenshot taken with lab equipment, showing the receiver busy in demodulating a carrier at 144.290 MHz (frequency choosen where the waterfall was clean).

So the work is over. Everything should be fine and you should be able to run the server. I’m still very disappointed that I was unable to use a better soundcard. I did some testing with a PCI M-Audio Audiophile 2496 but I was unable to let it work.

AirSpy

Finalmente è arrivata!!!
(questo articolo è in attesa di essere pubblicato dal 3 ottobre 2016)

Packaging minimale, ottima imbottitura, grande protezione  e dentro la chiavetta! Completamente in alluminio, con un bel connettore SMA femmina installato. Il tempo di collegarla al PC e già funziona. Non richiede driver o procedure perverse di installazione. Davvero un dispositivo Plug ‘n Play.

img_20161003_122946

Ho scaricato l’ultima versione di SDR# ed ho avviato la ricezione: eccellente! Il front-end è meno predisposto alla intermodulazione, lo spettro visualizzato è pulito ed i segnali si vedono decisamente peggio.

Forse lascia sul terreno qualche cosa in termini di guadagno: le conversazioni su satelliti MIL a 256 MHz non riesco a riceverle, ma sono piccoli dettagli.

La possibilità di visualizzare una porzione molto ampia di spettro è fantastica ed apre la scena a numerose applicazioni, anche in ambito didattico. Ecco qualche screenshot di SDR# della simpatica applicazione “analizzatore di spettro” che vedo molto bene in congiunzione con il generatore di rumore ad ampio spettro per fare qualche prova sui filtri in cavità. Antenna televisiva, in paese. La prima con 100MHz di span e la seconda in full Bandwidth.

Costa… vero… ma ne vale davvero la pena!!!

AIS Maintenance

The AIS decoder system has been up and running since March 2012. Since then database table have been growing up at a good rate. This year I decided to clean up the system before everything goes bananas.

The ais_stat_data table was really huge and it was really mandatory to cut some lines and make it lighter and faster.

Some old and unuseful tables were removed and data was stored in a safe place. After the cleaning database looks more “fit” and light.

The system is now up ‘n running and is ready to face 2017 AIS messages. Stay tuned!