Alcune funzioni e compatibilità di Satsagen sotto Linux Wine sono state migliorate a partire dalla versione 0.9.3.5:
Semplificata la connessione a Pluto correggendo l’indirizzo pluto.local che il sistema non riesce a risolvere
Le porte COMx seriali ora funzionano, quindi sono ora disponibili all’uso i Simple Spectrum Analyzer, i sintetizzatori PLL, i log detector, i dispositivi GPIB e gli spettrometri.
Le console dei terminali Pluto e GPIB ora funzionano.
Ecco una guida passo passo per sfruttare questi miglioramenti:
Questa guida è stata testata su Ubuntu 25.04 e Wine 9.0 layer. Alcuni comandi potrebbero dover essere adattati per le diverse versioni del sistema operativo/distribuzione.
Rimuovi la vecchia versione di Satsagen se è inferiore a 0.9.3.5. Apri un terminale, digita wine control e scegli l’icona Add/Remove programs per rimuovere la vecchia applicazione Satsagen
Chiudere il pannello di controllo di Wine. Scarica l’ultima versione di Satsagen dalla pagina di download e decomprimi il file alla fine.
Ritorna alla finestra del terminale e digita wine $HOME/Downloads/satsagen_9_3_5_setup.exe (o il nome della versione che avevi scaricato) ed eseguilo.
Completa il setup e fai clic sull’icona SATSAGEN da Show Apps per eseguire il programma. Alla prima esecuzione dovrebbe essere visualizzato un messaggio
Chiudi la finestra e l’applicazione. Riattiva la finestra del terminale e digita groups iltuonomeutente
Se il tuo nome utente non appartiene al gruppo dialout, aggiungilo eseguendo sudo usermod -aG dialout iltuonomeutente
Riavvia Wine digitando winserver -k al prompt del terminale
Quindi, collega ad esempio un dispositivo Pluto al PC e fai nuovamente clic sull’icona SATSAGEN per eseguire l’applicazione
Attendi qualche secondo per permettere che il dispositivo USB venga rilevato dal sistema operativo e fai clic sul menu View-> Open terminal, dovrebbe apparire una finestra di dialogo con un dispositivo disponibile sulla porta COM seriale, confermando che la procedura di cui sopra è andata a buon fine
Chiudi la finestra di cui sopra e per verificare la connessione Pluto, vai su Settings, scheda Devices
Un Pluto dovrebbe essere elencato nella casella di riepilogo SDR Device
Chiudi la finestra Settings e fai clic sul pulsante Power.
Il mio amico Gianni IW1EPY ha scoperto un insidioso problema in alcuni ADALM-PLUTO utilizzati oltre le specifiche. Ecco il suo rapporto:
Queste informazioni sono per gli utenti di ADALM-PLUTO che riscontrano questo strano comportamento. Durante l’inserimento in un contenitore metallico di un ADALM-PLUTO Rev C di un mio amico, ho scoperto un problema.
Collegandolo a un LMX2595 per testare le 5 armoniche.
A sinistra una scatoletta contenente la scheda LMX2595 con le doppie transizioni coassiali in WR42 per annullare la fondamentale, e a destra, il Pluto in prova.
È apparso un terribile notch!
Senza segnale in ingresso, il rumore di Pluto è a circa -70, quindi il notch sopprime tutto intorno ai 22,3 GHz.
Dopo aver esaminato attentamente la board di Pluto, ho scoperto una saldatura SMA difettosa.
Il pin centrale è stato saldato sul pad, ma una lunghezza di circa 1,5 mm a partire dal bordo del PCB non è stata saldata.
La mancanza di saldatura è dovuta principalmente ad una non planarità dell’SMA rispetto al PCB.
La RF entra nel PCB, non al bordo del PB, e vede due linee, una delle quali è il percorso corretto per il balun e una seconda linea che si estende per 1,5 mm fino al bordo della scheda.
La seconda linea funge da stub con un’estremità aperta, applicando un corto alla frequenza della risonanza lambda-quarto.
Risaldando l’intera lunghezza del pin centrale SMA, il problema è scomparso.
Questo è il comportamento normale di un ADALM-PLUTO senza calibrazione, che offre poco più di 20 dB di dinamica nella banda a 24 GHz.
Da questa versione si può configurare un terzo dispositivo SDR nella scheda Devices in Settings allo scopo di estendere le funzionalità del VNA di Satsagen:
Impostare Three devices con un click sul corrispondente radio button e nella tab RX 2 device impostare il device SDR che si vuole utilizzare come terzo dispositivo.
Infine nella scheda SNA/VNA Mode selezionare la voce VNA dalla lista Mode e Dual RX-Device dalla lista Dual Port Interface.
Con la suddetta configurazione, il VNA utilizzerà il terzo dispositivo come secondo ricevitore e sarà possibile effettuare misure S11 ed S21 in tempo reale senza dover intervenire manualmente sulle connessioni del DUT.
Le condizioni mandatorie per il corretto funzionamento della configurazione a tre dispositivi sono:
Una sorgente comune di clock di riferimento, nello schema CLK Source. In alternativa, la sorgente di clock esterna alimenta il primo device e il riferimento agli altri due è fornito con un collegamento in cascata (daisy chain).
I dispositivi 1 e 3 designati al ruolo RX devono avere due canali RX sincronizzati, quindi con l’attuale versione 0.9.3.3 sono compatibili solo i dispositivi Pluto rev. C/D.
Il dispositivo 2 designato come TX può anche avere un solo canale TX, sono necessarie però due porte TX+ e TX- o l’aggiunta di uno splitter. Per il dispositivo TX sono compatibili diversi device, tra i quali i Pluto e i sintetizzatori PLL LMX2595, ADF4251 ed altri.
Supporto LMX2595
Collegando una board LMX2595 a Satsagen, l’applicazione è in grado di funzionare come Generatore/sweeper e generatore di tracciamento in operazioni SNA/VNA da circa 100MHz fino e oltre 20GHz con una potenza di output in grado di ottenere una dinamica più che sufficiente per le esigenze di caratterizzazione di filtri e altri DUT.
Con Satsagen e in abbinamento ad un dispositivo di ricezione ADALM-PLUTO in modalità in quinta armonica, si sono ottenuti in laboratorio circa 40dB di dinamica a 24GHz!
Un esempio di realizzazione di Gianni IW1EPY con un ADALM-PLUTO in contenitore metallico, board LMX2595 e Pi Pico.
Per migliorare le misure oltre i 20GHz, occorre utilizzare un filtro in cavità per abbattere la fondamentale del LMX2595 (a frequenze superiori a 15GHz si attiva un duplicatore interno al chip) perché può diventare “importante” e saturare i primi stadi del dispositivo RX. Si può utilizzare come filtro anche due transazioni in guida accoppiate.
Un esempio di filtro con due transizioni N-guida-N
Il supporto delle board con il sintetizzatore PLL LMX2595 è fornito mediante un’interfaccia USB costituita da un microcontrollore Arduino o un Raspberry Pi Pico, vedere la pagina relativa a questa interfaccia multifunzione USBDAALBFER per gli schemi, sorgenti e binari che si possono utilizzare.
Alcuni consigli per l’utilizzo di tale board PLL:
L’utilizzo di un Raspberry Pi Pico (e Pi Pico 2) è preferibile in quanto l’input e l’output è funzionante allo stesso livello 3,3V del LMX2595 per cui non servono i componenti per l’adattamento dei livelli di tensione. Inoltre il caricamento del firmware sul Pi Pico può ridursi semplicemente alla copia del file binario fornito qui sul disco del Pi Pico che si attiva tenendo premuto il pulsantino e inserendo la USB al PC, quindi non è necessario attrezzarsi con l’ambiente di compilazione Arduino.
Su alcune board LMX2595 provenienti dalla Cina, parte della serigrafia dei pin del connettore è riportata sul retro della scheda:
L’alimentazione a 5V della board LMX2595 andrebbe fornita tramite una porta USB dedicata o con un alimentatore separato, in quanto la scheda durante il funzionamento può raggiungere picchi di assorbimento di 400mA ed oltre, non è consigliato quindi alimentarla tramite il pin 5V del microcontrollore che sia un Arduino o un Raspberry.
Anche la connessione GND tra la board LMX2595 e il microcontrollore è importante per garantire il corretto funzionamento del SPI, andrebbe eseguita con collegamenti corti e utilizzando preferibilmente più pin GND del microcontroller e “vicini” ai pin dedicati alla SPI.
Infine, è altamente consigliato inscatolare in contenitori metallici sia la board LMX2595 sia il dispositivo di ricezione (ADALM-PLUTO).
Avvio in stand-alone dei sintetizzatori PLL
Da questa versione, è presente una funzione in Satsagen che permette di programmare l’interfaccia Arduino o Pico abbinata ad un sintetizzatore PLL supportato, come il LMX2595 appena visto, per l’utilizzo in stand-alone, cioè l’interfaccia e i PLL potranno funzionare come generatori CW ad una frequenza e potenza prefissata semplicemente alimentandoli, anche scollegati da Satsagen. Questa funzionalità per esempio può essere utile se abbiamo necessità di un oscillatore locale provvisorio per i nostri progetti di down o up converter.
Per sfruttare la suddetta funzionalità è sufficiente avviare Satsagen con i dispositivi collegati, far partire il Generator ed impostare frequenza e potenza desiderati, quindi, mantenendo il Generator avviato, fare click sul menu Settings->Device stored settings alla voce Save the Generator state to the device. A questo punto si può spegnere Satsagen e scollegare i dispositivi di interfaccia e PLL dal PC. Successivamente se le interfacce con i PLL saranno alimentati tramite USB o con una alimentazione a parte, si avvieranno automaticamente alla frequenza e potenza di uscita prefissate, senza l’ausilio di Satsagen come pilota.
Per azzerare l’impostazione sull’interfaccia, in modo che non si avvii più automaticamente e smetta di far funzionare i PLL come generatori CW in stand-alone, è sufficiente ripetere la suddetta procedura con il Generator spento: avviare Satsagen con i dispositivi collegati, lasciare spento il Generator e fare click sul menu Settings->Device stored settings alla voce Save the Generator state to the device. A questo punto si può spegnere Satsagen e scollegare i dispositivi di interfaccia e PLL dal PC, l’impostazione di funzionamento in stand-alone è stata azzerata.
Harmonic Extended Filter
Nelle scansioni in SNA con generatore di tracciamento, soprattutto in modalità armonica, abbiamo riscontrato la presenza di “picchi” indesiderati, per esempio intorno ai 24 GHz, dovuti alla concomitanza dell’alta impostazione di RX Gain necessaria e alla presenza di armoniche del oscillatore locale di RX cadenti proprio nell’intervallo di IF.
Da questa versione di Satsagen si può attivare un filtro EF, simile nel funzionamento a quello già presente da tempo nello Spectrum Analyzer, anche per le operazioni TSA/SNA, mediante un click sul pulsante EF presente nel pannello centrale dell’applicazione:
Il filtro EF eliminerà i suddetti artefatti durante la scansione effettuando due letture distinte per ogni punto, spostando di poco la frequenza dell’oscillatore locale RX. Il filtro confronterà la coppia di letture eliminando i segnali presenti alla stessa frequenza solo su una delle due letture, segno inequivocabile di artefatti dovuti al oscillatore locale di RX.
Per contro, l’utilizzo del filtro EF determinerà un leggero rallentamento nelle scansioni SNA.
Mediante l’utilizzo di un adattatore GPIB->USB seriale come il progetto AR488, Satsagen può pilotare dispositivi dotati di interfaccia IEEE488 GPIB/HP-IB.
La versione 0.9.3.3 permette di pilotare generatori sintetizzati e power meter come rispettivamente device TX ed RX di Satsagen.
Alcuni antichi dispositivi sono direttamente supportati e sono elencati tra i dispositivi utilizzabili in Settings->Devices, mentre è possibile configurare mediante due modelli di template altri generatori sintetizzati e power meter conoscendone la sintassi dei comandi.
Perché utilizzare Satsagen per pilotare dispositivi dotati di GPIB/HP-IB?
Oltre a poter agire semplicemente come un comando remoto dei dispositivi, Satsagen può funzionare come anello di congiunzione tra più dispositivi eterogenei per creare strumenti SNA/VNA, per esempio Satsagen diventa uno strumento scalare SNA connettendo un generatore e un power meter entrambi in GPIB/HP-IB, oppure un SNA/VNA abbinando un generatore GPIB/HP-IB e un ricevitore SDR come ADALM-PLUTO.
E’ consentito con Satsagen pilotare più dispositivi GPIB/HP-IB mediante un’interfaccia dedicata per ogni dispositivo o con una singola interfaccia collegata su un BUS GPIB/HP-IB dove sono attestati i dispositivi da controllare con indirizzi diversi, ma non è permesso utilizzare contemporaneamente due dispositivi dello stesso BUS GPIB/HP-IB.
GPIB template
I GPIB template sono file di configurazione in formato .ini che permettono a Satsagen di pilotare dispositivi su bus GPIB.
In Satsagen versione 0.9.3.3 sono previsti due modelli di configurazione, uno per pilotare generatori sintetizzati e un altro per i power meter.
Nella directory Documenti\Satsagen\Settings si trovano due file modelli da copiare e modificare in base alle proprie esigenze per generare i template finali da importare in Satsagen: templatePLL_commented.ini per i generatori sintetizzati e templatePM_commented.ini per i power meter.
Copiare quindi i modelli con un nome a piacimento nella stessa directory Documenti\Satsagen\Settings e modificarli con blocco note.
Template PLL
I template PLL consentono a Satsagen di pilotare generatori sintetizzati su bus GPIB. Hanno una unica sezione chiamata CUSTOMGPIBPLL.
I campi mandatori che occorre personalizzare per poter pilotare i generatori sintetizzati su GPIB sono:
DeviceAddr: indirizzo GPIB
fGEN: frequenza iniziale in Hz. Potrà essere modificata dal pannello Generatore di Satsagen. Mettere per esempio una frequenza a piacimento nel range del dispositivo.
TXAttGEN: impostazione attenuatore iniziale in dBm. Anche questo parametro potrà essere modificato dal pannello del Generatore. Mettere per esempio un valore per ottenere una potenza in output iniziale più bassa possibile.
XO_FREQUENCY: frequenza di riferimento in Hz del dispositivo. Buona parte dei dispositivi utilizza una frequenza di riferimento di 10 MHz, quindi compilare con 10000000. Questo parametro verrà utilizzato da Satsagen per calcolare l’offset sulla frequenza da generare in base ad una eventuale correzione da apportare.
REFTXPWR: compilare con la potenza massima in output del dispositivo espressa in dBm
MINFREQTX: compilare con la minima frequenza in Hz consentita dal dispositivo
MAXFREQTX: compilare con la massima frequenza in Hz consentita dal dispositivo
MINTXATT: compilare con il valore in dB dell’attenuatore del dispositivo per ottenere la minima potenza in uscita. Per esempio -110
MAXTXATT: compilare con il valore in dB dell’attenuatore del dispositivo per ottenere la massima potenza in uscita. Solitamente va posto a 0
TXATTNSTEP: compilare con la granularità in dB dell’attenuatore del dispositivo, solitamente 10, 1 o 0.1
CmdCWON: comando per attivare l’output, per esempio RF1
CmdCWOFF: comando per disattivare l’output, per esempio RF0
CmdDefSetPwrOut: comando per impostare il livello in uscita del dispositivo. Per esempio PL seguito da una delle seguenti variabili di Satsagen e terminato solitamente dal suffisso DB: %PWRDBMDEC% verrà sostituita con il valore in dBm compreso di segno e un decimale, %PWRDBMINT% verrò sostituita con il valore intero in dBm compreso di segno o %PWRDBMSIGN% che verrà sostituita solo dal carattere di segno. Un esempio di comando potrà essere PL%PWRDBMDEC%DB, Satsagen quindi invierà al dispositivo per impostare un valore di uscita per esempio di -30dBm il comando PL-30.0DB in questo caso.
CmdDefSetVFO: comando per impostare la frequenza in Hz del dispositivo. Per esempio CW seguito da una delle seguenti variabili di Satsagen e terminato solitamente dal suffisso HZ: %FREQGHZDEC% frequenza completa in GHz con decimali, per esempio 10,368200125. %FREQGHZ% frequenza solo in GHz, per esempio 10. %FREQMHZDEC% frequenza completa in MHz con decimali, per esempio 10368,200125. %FREQMHZ% frequenza in MHz senza decimali, per esempio 10368. %FREQMHZONLY% rappresenta solo la porzione in MHz, per esempio 368 se la frequenza completa in GHz è 10,368200125. %FREQKHZDEC% frequenza completa in kHz con decimali, per esempio 10368200,125. %FREQKHZ% frequenza espressa in kHz senza decimali, per esempio 10368200. %FREQKHZONLY% solo la porzione in kHz, per esempio 200. %FREQHZ% frequenza completa espressa in Hz, per esempio 10368200125. %FREQHZONLY% solo la porzione in Hz, per esempio 125. Un esempio di comando potrà essere: CW%FREQHZ%HZ, Satsagen quindi per impostare la frequenza nell’esempio 10368200125 Hz la seguente stringa: CW10368200125HZ.
Un file INI di template minimale per il funzionamento con generatori sintetizzati quindi potrebbe risultare come il seguente:
Per rendere operativa la configurazione template, occorre importare il file appena creato nella memoria di Satsagen.
Dalla scheda Devices in Settings scegliere dalla lista Model la voce GPIB/Custom PLL Synthesizer e importare il file .ini tramite il pulsante Load Template.
Se il controllo della sintassi avrà avuto esito positivo, un messaggio di conferma dell’importazione verrà visualizzato da Satsagen e da quel momento il device GPIB/Custom PLL Synthesizer potrà essere utilizzato con la configurazione appena creata anche nelle sessioni successive.
Una nuova importazione di un altro file tramite il pulsante Load Template provocherà la sovrascrittura in memoria della configurazione.
E’ possibile esportare in un file .ini la configurazione attiva in memoria tramite il pulsante Export Template. E’ anche possibile esportare il contenuto della configurazione in memoria su un file .ini esistente, questo può essere utile per conservare eventuali commenti non presenti in memoria e che andrebbero persi se si esportasse la configurazione in un nuovo file.
Molti altri campi possono essere utilizzati nella configurazione di un template per ottimizzare il funzionamento di controllo del dispositivo GPIB ed aggiungere delle funzionalità.
Campi di controllo stato dispositivo
In ordine di importanza, se il dispositivo lo permette, andrebbero aggiunti i campi che verificano lo stato di lock del PLL del generatore sintetizzato che si vuole controllare. Tale verifica è necessaria se in seguito all’invio dei comandi quali ON e OFF del CW, impostazione della potenza di uscita e della frequenza, il dispositivo non preveda un controllo automatico del lock in conferma dei comandi ricevuti. In tali condizioni, il controllo potrebbe non funzionare correttamente, generando errori o blocchi dell’applicazione durante l’utilizzo.
Solitamente il metodo più comune per la verifica del lock è offerto tramite il test di un bit dello status byte (o word) del dispositivo.
I campi PhaseLockedStatusMask e PhaseLockedStatusBitNegate definiscono come testare il bit dello status per la verifica del lock PLL.
Il campo PhaseLockedStatusMask definisce la maschera per “estrarre” il bit dallo status. Se per esempio, il bit che indica il lock del PLL è quello con peso 16 allora la maschera dovrà essere impostata a PhaseLockedStatusMask=16 (o 0x10 in esadecimale). Se il dispositivo indica che il lock del PLL avviene quando il suddetto bit è a zero, quindi con una logica negata, allora dovremmo impostare PhaseLockedStatusBitNegate=1.
Una metodologia alternativa per testare il lock del PLL offerta da Satsagen nel caso lo status byte (o word) del dispositivo non lo prevede, è l’invio di un comando e l’analisi del risultato a tale comando. Con il campo CmdGetPhaseLocked definiamo il comando da inviare al dispositivo e con RegEx2MatchMessagePhaseLocked definiamo l’espressione regolare da utilizzare per effettuare il match sul risultato quando il lock del PLL avviene. Per esempio, se il dispositivo prevede di testare il lock mediante il comando LOCK? allora impostiamo CmdGetPhaseLocked=LOCK? e se la risposta è semplicemente il numero 1 per il lock e 0 per l’unlock, allora dovremo impostare RegEx2MatchMessagePhaseLocked=[1]. Se CmdGetPhaseLocked è definito, la maschera sullo status byte vista in precedenza non avrà effetto.
E’ possibile inoltre regolare nelle tempistiche il suddetto meccanismo di verifica del lock, sia se si utilizza lo status byte che un comando. Mediante il campo timeoutPhaseLock definiamo il timeout in millisecondi scaduto il quale se i suddetti metodi non hanno riscontrato il lock, la procedura va in errore e l’applicazione si ferma informando l’utente. Con usSleepPhaseLockWaitCycle definiamo l’attesa in microsecondi tra un test e l’altro fino a quando non si riceve una risposta positiva o scade il timeout visto prima. Questo parametro è utile per non sovracaricare inutilmente il dispositivo di richieste.
Nel caso peggiore che il dispositivo non preveda nessun metodo per verificare lo stato del lock, è possibile inserire un’attesa fissa in millisecondi in seguito all’invio dei comandi, quantificabile in base a verifiche che andrebbero eseguite manualmente, per esempio inviando i comandi con il terminale GPIB a disposizione nell’applicazione Satsagen. Tali ritardi è possibile specificarli con i seguenti campi:
msSleepAfterCWTurnONOFF attesa in millisecondi in seguito all’invio del comando di CW ON o OFF
msSleepAfterSetPwrOut attesa in millisecondi in seguito all’invio del comando di potenza di uscita
msSleepAfterSetVFO attesa in millisecondi in seguito all’invio del comando di impostazione della frequenza
Identici nella sintassi del controllo del lock appena visto, sono disponibili altrettanti campi per la verifica dello stato di pronto (ready) del dispositivo, utili da testare soprattutto prima di inviare nuovi comandi. Nell’ordine, DeviceReadyStatusMask, DeviceReadyStatusBitNegate, CmdGetDeviceReady, RegEx2MatchMessageDeviceReady, timeoutDeviceBusy e usSleepDeviceBusyWaitCycle.
Sempre simili nella sintassi, sono anche disponibili i seguenti campi per la verifica di presenza di errori: ErrorStatusMask, ErrorStatusBitNegate, CmdTestError e RegExTestError. In questo caso, i parametri relativi ai timeout e attese non sono necessari, mentre sono disponibili due campi che consentono di leggere dal dispositivo una descrizione dell’errore appena riscontrato: CmdGetError e RegExGetError.
Per far sì che la definizione dei suddetti campi di controllo di lock, device ready e presenza di errori diventino operativi occorre attivarli dove serve, nelle “sezioni” relative ai comandi principali di CW ON e OFF, impostazione della potenza di uscita e della impostazione della frequenza. Questo lo si fa impostando a 1 i campi testPhaseLockedxxx, testDeviceReadyBeforexxx e testDeviceReadyAfterxxx e testErrorxxx.
L’esempio di configurazione per un template PLL visto in precedenza diventerà il seguente completo di campi di controllo lock, ready ed error:
[CUSTOMGPIBPLL]
;;;Definizione generale del dispositivo
DeviceAddr=19
fGEN=2000000000
TXAttGEN=-60
XO_FREQUENCY=10000000
REFTXPWR=12
MINFREQTX=2000000000
MAXFREQTX=18000000000
MINTXATT=-110
MAXTXATT=0
TXATTNSTEP=1
;;;Definizione dei test su lock PLL, device ready ed error
PhaseLockedStatusMask=16
PhaseLockedStatusBitNegate=1
timeoutPhaseLock=3000
usSleepPhaseLockWaitCycle=20000
;;;-------------------------------------------------------
DeviceReadyStatusMask=8
DeviceReadyStatusBitNegate=0
timeoutDeviceBusy=3000
usSleepDeviceBusyWaitCycle=20000
;;;-------------------------------------------------------
ErrorStatusMask=2
ErrorStatusBitNegate=0
;;;Definizione dei comandi principali e attivazione dei test
testDeviceReadyBeforeCWONOFF=1
CmdCWON=RF1
CmdCWOFF=RF0
testErrorCWONOFF=1
testDeviceReadyAfterCWONOFF=1
testPhaseLockedCWONOFF=1
;;;---------------------------------------------------------
testDeviceReadyBeforeSetPwrOut=1
CmdDefSetPwrOut=PL%PWRDBMDEC%DB
testErrorSetPwrOut=1
testDeviceReadyAfterSetPwrOut=1
testPhaseLockedSetPwrOut=1
;;;---------------------------------------------------------
testDeviceReadyBeforeSetVFO=1
CmdDefSetVFO=CW%FREQHZ%HZ
testErrorSetVFO=1
testDeviceReadyAfterSetVFO=1
testPhaseLockedSetVFO=1
Infine, tra i campi di controllo di stato dispositivo, ma che hanno solo una funzione visiva, sono quelli che permettono di leggere la temperatura o di monitorare l’oven del cristallo di riferimento del dispositivo, aggiornando nella finestra principale di Satsagen il colore e le informazioni tramite il LED posto accanto al pulsante Power On.
Specificare con CmdReadTemp il comando da inviare per ottenere la temperatura del dispositivo, per esempio CmdReadTemp=TEMP?. Nel contempo specificare RegEx2DecodeMessageReadTemp con l’espressione regolare che permette di estrarre dalla risposta al comando precedente il valore della temperatura comprensivo di segno e parte decimale, per esempio RegEx2DecodeMessageReadTemp=([-+]?\d+(?:.\d+)?)
Se il dispositivo non prevede un comando di lettura di temperatura, ma tramite un bit dello status byte se l’oven del cristallo di riferimento ha raggiunto la temperatura di esercizio, allora con OvenStatusMask specificare la maschera del bit in questione, per esempio se è il bit con peso 4, OvenStatusMask=4 e nel caso sia negato, cioè a zero quando l’oven è in temperatura, aggiungere OvenStatusBitNegate=1.
Comandi di inizio, fine connessione e modo alternativo al serial poll status byte
Con i campi CmdInit e CmdEndConn è possibile specificare eventuali comandi da inviare al dispositivo rispettivamente all’atto della connessione e disconnessione di Satsagen. Con CmdInitResponseToTrace=1 si attiva l’invio della risposta al comando CmdInit sulla trace log, può essere utile se con CmdInit inviamo per esempio un comando per interrogare la versione del dispositivo, la quale potrà poi essere letta nella trace di Satsagen.
Infine è possibile far usare da Satsagen un metodo alternativo al GPIB serial poll per la lettura dello status byte (o word), se previsto dal dispositivo. Con il campo CmdGetDeviceStatus si definisce il comando da inviare per ottenere lo status byte e con RegEx2DecodeDeviceStatus l’espressione regolare da utilizzarsi per fare il match sul valore numerico dello status byte, per esempio semplicemente con RegEx2DecodeDeviceStatus=\d?
Template Power Meter
I template Power Meter consentono a Satsagen di pilotare i Power Meter su BUS GPIB. Hanno una unica sezione chiamata CUSTOMGPIBPM.
I campi mandatori che occorre personalizzare per poter pilotare i Power Meter su BUS GPIB sono:
DeviceAddr: indirizzo GPIB
REFGAIN0: offset rispetto alla lettura. Con questo campo possiamo specificare un offset in dB che Satsagen apporterà alla lettura prima della visualizzazione. Di norma va messo a zero REFGAIN0=0, ma può essere utile specificare un valore in offset per la calibrazione del dispositivo, se quest’ultimo non la prevede internamente.
MINFREQRX: specificare con questo campo la frequenza minima in Hz del dispositivo Power Meter.
MAXFREQRX: specificare con questo campo la frequenza massima in Hz del dispositivo Power Meter.
MAXINPUT: indica la potenza massima ammessa dal Power Meter espressa in dBm
DYNAMICRANGE: specificare con questo campo la dinamica del Power Meter espressa in dB. Per esempio con DYNAMICRANGE=106 e il precedente campo MAXINPUT=6, il Power Meter può misurare da -100 dBm a +6 dBm.
nreadsmeanTSA: è il numero di letture per il calcolo della media per ogni punto di scansione TSA se il Power Meter lo si utilizza come dispositivo RX in una configurazione SNA, cioè abbinato con un secondo device con ruolo di TX, generatore di tracking.
CmdReadPwr: è il comando da inviare al dipositivo per effettuare la lettura di potenza.
RegEx2DecodeMessageReadPwr: è l’espressione regolare da utilizzare per estrarre (fare il match) dalla risposta del comando precedente (CmdReadPwr) il valore della lettura.
Un file INI di template minimale per il funzionamento con i Power Meter quindi potrebbe risultare come il seguente:
I campi di controllo CmdGetDeviceReady, DeviceReadyStatusMask, CmdTestError e CmdGetError già visti nel precedente capitolo del template PLL, possono essere utilizzati con la stessa sintassi anche nella configurazione per i Power Meter. I campi che attivano i controlli per i Power Meter sono: testDeviceReadyBeforeRead, testErrorRead e testDeviceReadyAfterFailedRead.
Il suddetto esempio di configurazione diventerà quindi il seguente se completato dei campi di controllo:
;;;Definizione generale del dispositivo
DeviceAddr=8
REFGAIN0=0
MINFREQRX=1000000
MAXFREQRX=200000000
MAXINPUT=6
DYNAMICRANGE=106
nreadsmeanTSA=1
;;;Definizione dei test su device ready ed error
DeviceReadyStatusMask=8
DeviceReadyStatusBitNegate=0
timeoutDeviceBusy=3000
usSleepDeviceBusyWaitCycle=20000
;;;-------------------------------------------------------
ErrorStatusMask=2
ErrorStatusBitNegate=0
;;;Definizione del comando principale e attivazione dei test
testDeviceReadyBeforeRead=1
CmdReadPwr=IPW,TRG
testErrorRead=1
RegEx2DecodeMessageReadPwr=([-+]?\d+(?:\.\d+)?)
testDeviceReadyAfterFailedRead=1
Infine è possibile utilizzare anche i seguenti campi, identici nella sintassi a quelli già visti nel capitolo precedente Template PLL:
CmdInit, comando inviato nel momento della connessione e CmdInitResponseToTrace, se è 1 invia la risposta del CmdInit sulla trace log. CmdEndConn, comando inviato alla disconnessione. CmdGetDeviceStatus, comando alternativo al serial poll status byte e RegEx2DecodeDeviceStatus, espressione regolare per fare il match sul valore numerico dello status. CmdReadTemp, comando per leggere la temperatura del device e RegEx2DecodeMessageReadTemp per estrarre il valore double della temperatura con un espressione regolare. OvenStatusMask, in alternativa al comando precedente, bit dello status che determina se l’oven è in temperatura e OvenStatusBitNegate per negarlo.
Terminale GPIB
Satsagen include un terminale con il quale è possibile “dialogare” con il dispositivo collegato in GPIB a scopo di debug/troubleshooting.
Per aprire il terminale fare un click su Open GPIB terminal dal menu View, anche con Satsagen in Power Off.
A questo punto l’applicazione presenterà una lista delle interfacce disponibili:
Selezionare l’interfaccia desiderata e fare doppio-click o click su Ok.
A connessione avvenuta si aprirà un terminale in modalità verbose da dove è possibile inviare comandi sia all’interfaccia (preceduti da ++) o direttamente sul dispositivo all’indirizzo di default, 1.
Per cambiare l’indirizzo in uso dare il comando ++addr x, dove x è il numero del dispositivo GPIB. Con ++help otteniamo l’elenco e descrizione dei comandi dell’interfaccia preceduti da ++. Per una descrizione completa fare riferimento alla documentazione AR488.
Ricordarsi al termine delle operazioni, di chiudere il terminale in modo da liberare la porta seriale perché possa essere utilizzata da Satsagen per eventualmente connettersi al dispositivo e controllarlo.
Funzionamento del backspace nel terminale GPIB
Probabilmente riscontrerai che il tasto backspace non ha effetto durante l’utilizzo del terminale, o meglio, il cursore sembra retrocedere, però nella memoria buffer della riga questo non avviene, per cui se lo utilizzi per correggere un comando, questo comunque verrà inviato al dispositivo in modo errato.
Per risolvere tale problema, occorre modificare il file AR488.ino nei sorgenti del AR488 ed aggiungere le seguenti righe che permettono il funzionamento del backspace.
// handle the backspace in verbose mode - albfer 21/12/2024
case 0x7f:
case 'x8:
if(isVerb && pbPtr)
pbPtr--;
else
{
addPbuf(c);
isEsc = false;
}
break;
Le suddette righe vanno inserite all’interno della funzione parseInput(char c), dalla riga seguente a switch(c){ in modo da ottenere le prime righe di tale funzione in questo modo:
uint8_t parseInput(char c) {
uint8_t r = 0;
// Read until buffer full
if (pbPtr < PBSIZE) {
if (isVerb && c!=LF) dataPort.print(c); // Humans like to see what they are typing...
// Actions on specific characters
switch (c) {
// handle the backspace in verbose mode - albfer 21/12/2024
case 0x7f:
case 'x8:
if(isVerb && pbPtr)
pbPtr--;
else
{
addPbuf(c);
isEsc = false;
}
break;
// Carriage return or newline? Then process the line
case CR:
case LF:
.
.
.
Ricompilare con l’ambiente Arduino e ricaricare sull’interfaccia.
