Trimble GeoXT 2005 Series nel 2023

Ho trovato in cassetto dell'ufficio sepolto da qualche mio predecessore un Trimble GeoXT, un dispositivo GPS che usavo all'Universita'. Era una macchina estremamente costosa che includeva un palmare con Pocket PC

Mi e' stato detto che il GPS era stato accantonato perche' non reggeva la batteria....ovviamente la mia domanda e' stata..si potra' usare nel 2023 un dispositivo del 2005 

Primo aspetto: la batteria non e' assolutamente rovinata...il dispositivo e' rimasto acceso per ore (>5) 

Secondo aspetto: Non ho a disposizione l'accessorio che espone la porta seriale quindi l'unico modo di dialogare con il dispositivo sono Active Sync o via Ethernet (il cradle ha una porta Ethernet RJ45). Per usare Active Sync si puo' usare solo Windows XP (non c'e' compatibilita' con le versioni successive). In macchina Virtualbox Active Sync funziona

Terzo aspetto: anche il dispositivo va in rete via RJ45 c'e' da mettere in conto che oramai i certificati SSL nel dispositivo sono scaduti e non possono essere aggiornati. Ci si puo' scordare di navigare il Web ed anche TerraSync non scarica aggiornamenti degli almanacchi delle effemeridi dei satelliti

Quarto aspetto: non sono riuscito a connettere la WiFi all'hotspot. Le autenticazioni sono WEP (ovviamente ...siamo nel 2004) e WPA. Provando WPA non riesco a connettermi con Access Point moderni

A questo punto il dispositivo funziona in acquisizione??

Premesso che l'antenna e' solo una L1 a 12 canali che puo' essere postprocessata (e quindi non so quanta valga la pena perderci tempo avendo a disposizione delle antenne L1+L2 a costo minore e prestazione migliore) i primi tentativi di salvare i dati su TerraSync sono risultati vani.

Il dispositivo era molto lento nell'aggancio dei satelliti ma questo e' abbastanza ovvio dato che usa un almanacco del 2004. Una volta acquisito il fix Terrasync si rifiutava di salvare i dati per un problema sull'orologio

Ho modificato a mano l'orologio di Windows CE. A questo punto il fix e' stato molto piu' veloce ma persisteva il problema. Controllando ho visto che Terrasync riportava automaticamente l'orologio di sistema al 2004

La soluzione (trovata su un forum) e' stata quella di sincronizzare l'ora tramite ActiveSync (in pratica acquisendo la data dal PC Desktop), poi lanciare TerraSync. A questo punto tutto inizia a funzionare in modo corretto

Ne vale la pena??

Per funzionare funziona ma c'e' da dire che i dati di fase per il postprocessing vengono salvati nel formato binario di Trimble e quindi c'e' da fare un ulteriore passaggio per passarli in Rinex peraltro con un software ConverttoRinex che attualmente non riesco a farlo funzionare in macchina virtuale (problemi con le librerie DotNet) 

Eclisse di Luna 28 ottobre 2023

Canon D550 con 300 di ottica 

Samsung ML2160 su Debian testing nel 2023

 Nonostante sia stata dichiarata legacy la mia ML-2160 continua a stampare.

Il problema e' che i driver su Debian sono stati spostati di pacchetto (e mi scordo sempre quali sono)

apt install printer-driver-splix

Small docker for Golang apps

 In ufficio oramai una applicazione non puo' andare in produzione se non e' in in container...anche se e' occupa pochissimo spazio disco...il che vuol dire che si deve cercare di ottimizzare l'occupazione dello spazio disco del container

Nel Dockerfile sottostante viene utilizzato un docker con compilatore per generare un eseguibile che sara' poi copiato in un docker minimale di produzione basato su Alpine

FROM golang as builder

RUN mkdir /app

COPY . /app

WORKDIR /app

RUN https_proxy=http://proxy.toscana.it:8080 go get github.com/go-resty/resty/v2

RUN https_proxy=http://proxy.toscana.it:8080 go get github.com/sijms/go-ora/v2

RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o myapp .

FROM alpine:latest

RUN apk --no-cache add ca-certificates

WORKDIR /root

COPY --from=builder /app/myapp .

NVidia su Debian 12

 Non pensavo che sarei riuscito a montare le librerie NVidia su Debian (di solito usavo Ubuntu per semplicita') ma alla fine con il passare del tempo le cose sono migliorate molto anche in Debian

Come macchina di prova ho utilizzato un Thinkpad 550 con una GeForce 940M (384 cores 1 Gb) 

Per prima cosa si devono modificare i repositories per includere contrib e non-free 

apt install nvidia-driver firmware-misc-nonfree

apt-get install freeglut3-dev build-essential libx11-dev libxmu-dev libxi-dev libgl1-mesa-glx libglu1-mesa libglu1-mesa-dev libglfw3-dev libgles2-mesa-dev

apt -y install nvidia-cuda-toolkit nvidia-cuda-dev

Per testare ho provato a compilare gli esempi delle CUDA libraries

git clone https://github.com/zchee/cuda-sample.git

Per compilare gli esempi si deve modificare il Makefile presente in ogni directory modificando 

CUDA_PATH?=/usr

ed eliminando in SMS ?= tutti i valori ad esclusione di 50 e 52 (20 e 30 sono considerati obsoleti e non compilano piu', i restanti sono indicati come  deprecati)

Si lancia quindi il make aggiungendo prima la GLPATH

GLPATH=/usr/lib make

Il problema finale e' stato che gli esempi che usano le OpenGL non riuscivano ad aprirsi mostrando l'errore code=46(cudaErrorDevicesUnavailable) 

La soluzione e' quella di far precedere al comando le indicazioni

 __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia 

per lanciare Mandelbrot si usera' quindi

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia ./Mandelbrot

Proxy server e Docker

Oramai mi trovo sempre piu' spesso a litigare con il mio proxy a lavoro (telelavorando a casa questo problema nono esiste). Per effettuare il download di una immagine docker da dietro ad un proxy in Linux si deve creare il file 

sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf

inserendo le impostazioni del proxy (settare le variabili di ambiente http_proxy non funziona)

[Service]
Environment="HTTP_PROXY=http://proxy.aaaaa.it:8080"
Environment="HTTPS_PROXY=http://proxy.aaaaa.toscana.it:8080"

e si riavvia il servizio 

sudo systemctl daemon-reload

sudo systemctl restart docker