Rottura argine Fosso Reale Sentinel 2

Immagine RGB  Sentinel 2 del 4 novembre 2023 che mostra l'esondazione delle acque del Fosso Reale a seguito rottura d'argine nell'area di Case Passerini  

Immagine da Consorzio di Bonifica

Golang Milk-V Duo RiscV64

Sto provando la scheda Milk-D Duo con processore RiscV64

La scheda un processore dual core. Sul core primario puo' girare un sistema operativo Linux multi task mentre sul secondo FreeRtos. I due sistema comunicano tramite una porta seriale un po' come funzionava la scheda Intel Galileo

Come immagine disco sto usando quella della ditta ma si pu' montare anche Arch (Debian non ha ancora il supporto di rete e si deve accedere tramite connessione seriale)

Su Linux e' piuttosto facile interagire con la scheda perche' se si collega la porta USB C viene montata in automatico un porta di rete tramite RNDIS all'indirizzo 192.168.42.1 (la scheda rilascia in DHCP un indirizzo della classe 192.168.42.x)

enxf611f7e3617d: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.42.18  netmask 255.255.255.0  broadcast 192.168.42.255
        inet6 fe80::f411:f7ff:fee3:617d  prefixlen 64  scopeid 0x20<link>
        ether f6:11:f7:e3:61:7d  txqueuelen 1000  (Ethernet)
        RX packets 242  bytes 29688 (28.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 311  bytes 43373 (42.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisi

ssh root@192.168.42.1

https://xyzdims.com/3d-printers/misc-hardware-notes/iot-milk-v-duo-risc-v-esbc-running-linux/#References 

La scheda ha 64 Mb di memoria ma con il disco immagine la RAM e' di soli 32 Mb perche' gli altri sono destinati alla connessione della video camera

Mem: 20732K used, 8504K free, 80K shrd, 668K buff, 3260K cached
CPU:   0% usr   1% sys   0% nic  98% idle   0% io   0% irq   0% sirq
Load average: 1.90 0.55 0.19 1/64 385
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
  374   368 root     R     1200   4%   0% top
  155     1 root     S     4740  16%   0% /usr/sbin/ntpd -g -p /var/run/ntpd.pid
  193     1 root     S     1200   4%   0% {S99user} /bin/sh /etc/init.d/S99user start
  361   163 root     S     1008   3%   0% /usr/sbin/dropbear -R
   10     2 root     IW       0   0%   0% [rcu_preempt]
  204     1 root     S     1204   4%   0% -sh

Per usare Go pero' tale memoria non e' sufficiente e si deve attivare la partizione di swap tramite per avere 256 Mb

mkswap /dev/mmcblk0p3
swapon /dev/mmcblk0p3

la dimensione della partizione di swap puo' essere ridimensionata tramite lo script (in questo caso e' 1 Giga)

 

fdisk /dev/mmcblk0 <<EOF
p
d
3
n
p
3

+1G

w
EOF

fdisk -l /dev/mmcblk0

echo "----- resize /dev/mmcblk0p3 for swap completed -----"

a questo punto si puo' fare la build del programma sul desktop facendo cross compilazione

export GOOS=linux 

export GOARCH=riscv64 

export CGO_ENABLED=1 

export CC=riscv64-linux-gnu-gcc

go build programma.go

e si copia sul dispositivo tramite (attenzione allo switch -O)

scp -O ./main  root@192.168.42.1:/root/

https://blog.davidburela.com/2020/11/21/cross-compiling-golang-for-risc-v/

Ho fatto qualche prova e non sembrano funzionare le goroutines

Nel caso il cui si voglia esporre la scheda verso Internet si puo' usare o la scheda di espansione che monta una scheda Ethernet

oppure se il PC Desktop assume un IP del tipo 192.168.42.68 si lancia sul desktop

sysctl net.ipv4.ip_forward=1 

iptables -P FORWARD ACCEPT 

iptables -t nat -A POSTROUTING -o outgoing_if -j MASQUERADE

mentre sulla scheda

ip r add default via 192.168.42.68

echo "nameserver 8.8.8.8" >> /etc/resolv.conf

https://xyzdims.com/3d-printers/misc-hardware-notes/iot-milk-v-duo-risc-v-esbc-running-linux/

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