Fjärrskådning i Hallonpajen - Remote med RPi

SM0KBW

Well-Known Member
Hej!

Den gode SA0AZY började ta upp detta i en annan tråd men jag tycker ämnet är väl värt en egen tråd!

Frågeställningen är om det är möjligt att använda 2 Raspberry Pi kort för att åstadkomma fjärruppkoppling via Internet.

Vad krävs, är det möjligt att köra VOIP på en så klen processor, Hur ska hårdvaran se ut?

Det finns de som inte bara funderat t.ex SM0/SM7LCB har en informativ sida som kan vara en start att läsa in sig på vad det innebär och krävs av en sådan lösning.

W4MQ
är en annan sida som är intressant att titta på.


TheLinkbox
är ett VIOP system för radio via Internet. Har tittat på det och programmet kan mycket vilket å andra sidan gör det rätt rörigt att sätta sig in i ;)

Fick tag på några av de här USB-ljudkorten för under hundralappen styck via nätet, RPi har bara audio ut. De stöddes direkt av OS (Debian).
 
Last edited:
Vet inte vilka krav man måste ställa på processorn för att överföra 3kHz VoIP.
A/D-omvandlaren bör väl klara ca 8kHz.

Det finns i alla fall open source VoIP till Rpi.
Elastix - Overview

Tror det finns till Arduino också.

/Micke
 
Vet inte vilka krav man måste ställa på processorn för att överföra 3kHz VoIP.
A/D-omvandlaren bör väl klara ca 8kHz.

Det finns i alla fall open source VoIP till Rpi.
Elastix - Overview

Tror det finns till Arduino också.

/Micke

A/D sker i ljudkortet och bör inte belasta processorn speciellt mycket.

Däremot så ska dataströmmen bearbetas och packas ihop/upp av processorn och det helst med så kort ledtid som det bara är möjligt - det är möjligen där som RPi kan komma tillkorta. Som jag skrev i den gamla tråden så är de flesta "vanliga" mobiler utrustade med samma eller liknande CPUer som klarar av jobbet så RPin kanske klarar det hela galant :)

Ett problem är att de flesta VOIP program är avsedda att köras i visuellt läge.
Gärna med något snyggt interface baserat på Qt eller liknande. Det kommer att ytterligare belasta systemet.

Vad som behövs här är snarare en "command line" applikation då man förmdligen kommer starta upp processen via någon form av script vid uppstart. thelinkbox som jag nämnde är avsett för detta, men tyvärr är det paketet inte så lätt att sätta sig in i. Thelinkbox är ju dessutom avsett att även köra Echolink/IRLP och en framgångsrik portering skulle öppna för att använda RPi för sådana stationer ;)

En annan aspekt är att man ska kunna välja en codec som gör så bra jobb som möjligt vid smal bandbredd. Speex var vettigt förut men nu är det väl Opus som gäller.
 
Last edited:
Googlade lite och såg att AG1LE kört lite olika applikationer, bl.a. fldigi, som enligt hans uppgift konsumerat 80% CPU vid sändning.

@KBW, jag har en RPI ver B. Har precis hämtat den och sitter och bekantar mig lite.

Länk till AG1LE: Ham Radio Blog by AG1LE: Raspberry Pi

Spånar vidare och återkommer.

//AZY
 
Googlade lite och såg att AG1LE kört lite olika applikationer, bl.a. fldigi, som enligt hans uppgift konsumerat 80% CPU vid sändning.

@KBW, jag har en RPI ver B. Har precis hämtat den och sitter och bekantar mig lite.

Länk till AG1LE: Ham Radio Blog by AG1LE: Raspberry Pi

Spånar vidare och återkommer.

//AZY

SKa titta lite på AG1LE, har redan två RPi B och du har lyckats få mig intresserad så nu vill jag se om det skulle kunna gå att använda dem på det här sättet. En fördel för det här projektet är att man inte behöver dra igång någon X-server och på så sätt spara på de knappa resurserna.

Har just uppdaterat mina RPi så det ska gå att genomföra lite tester med dem. Just nu är det thelinkbox som jag tittar på.

Det kommer nog bli en hel spånhög innan ett sådant här projekt är i hamn, ett och annat avslitet hår hamnar nog också i högen ;)
 
Last edited:
SM0KBW, om du orkar, håll den här tråden uppdaterad med dina framsteg. Det skulle vara kul att följa. Speciellt voip delen där jag haft problem med att bygga något bra.

73 de SM0RVV
 
SM0KBW, om du orkar, håll den här tråden uppdaterad med dina framsteg. Det skulle vara kul att följa. Speciellt voip delen där jag haft problem med att bygga något bra.

73 de SM0RVV

Jo det man behöver för ett sådant här projekt är ju egentligen bara en audiokabel via Internet, de flesta VOIP program har för mycket "overhead" för uppkoppling/uppringning, och det med grafik som drar med sig extra libbar och kräver att X-servern snurrar.

För egen del så har vi i stugan bara en ice.net/net1 450MHz förbindelse och det med ett ganska lågt flöde. kan ibland vara 150 Kb/s uppströms. Dessutom kostar det extra om man förbrukar för mycket bandbredd :)mad:)

Det gör att jag måste hitta en VOIP som drar minsta möjliga bandbredd, har tidigare testat med IHU, som använder sig av Speex, med ganska goda resultat. För något halvår sedan kom Opus som tydligen är ännu bättre än Speex vid låg bandbredd, Speex gänget slutade med sin utveckling för att Opus var så pass mycket bättre. Men då Opus det är så pass nytt har det knappt dykt upp i några applikationer än.

Visst ska vi försöka hålla liv i tråden, det här är det bästa med Internet, att kunna jämföra, få tips och så småningom få fram något som fungerar. Om RPi fungerar som plattform är även det mumma :)D)
 
Min tanke när jag började spåna var att använda så minimalt resurskrävande mjukvara som möjligt, helst utan GUI, iaf på remoten

Sen sitter jag på en radio med delad front, vilket innebär att jag "bara" vill skicka själva signalerna via nätet.

Men, det ena ger nog det andra.

//AZY
 
Min tanke när jag började spåna var att använda så minimalt resurskrävande mjukvara som möjligt, helst utan GUI, iaf på remoten

Sen sitter jag på en radio med delad front, vilket innebär att jag "bara" vill skicka själva signalerna via nätet.

Men, det ena ger nog det andra.

//AZY

Jo, det finns ingen större vinst att ha grafiken uppe i RPi-erna, vill man kan man tänka sig en webb-server där man kan läsa av status göra ändringar, ungefär som i en router.

Vad som behövs är väl:

En bra audioförbindelse, med så små krav på bandbredd som möjligt

En överföring av kontrollsignaler, i ditt fall de mellan front och basenhet.

Något sätt att hantera IP-adresser, där är väl dyndns vanligt och vissa routrar har den funktionen inbyggd.

CW problemet måste lösas, det är ogörligt att skicka styrning/medhörning via nätet. En lokal bugg och tystad medhörning från fjärrenheten är en lösning.

RPi har ett antal GPIO pinnar som man kunde använda till att slå av och på enheter remote som slutsteg, extern ATU eller rotor ....



När det gäller vilken radio som ska användas så har jag för min del flera idéer. En är min gamla TS-940s som bara står och samlar damm.

En annan är att anpassa ett tidigare projekt där jag konstruerade en CI-V styrd kontrollenhet med en PIC-processor för styra ombyggda NMT-stationer, denna skulle kunna byggas om för styra äldre riggar som inte har möjlighet till riggstyrning. Det är förmodligen den mest tidskrävande lösningen, dessutom är jag inte säker på de rättsliga aspekterna på att släppa en CI-V baserad tolk under GPL om man skulle vilja dela med sig av lösningen.

Dessa två lösningar bygger på att antingen köra ett program som HRD i datorn eller att man bygger en egen front ihop med RPin som skickar de rätta signalerna och presenterar status på en display.

Till sist den tidsmässigt enklaste lösningen att köpa en TS-480 eller en IC706, men det ger inte samma "DIY" känsla, dessutom kostar det pengar som kan användas till annat ;)

Vilken version man än väljer så blir det i.a.f att överföra styrsignalerna och de kommer förmodligen i seriellt format, precis som i front/basenhet lösningen.


Det var en utvikning, tillbaks till vår virtuella audiokabel :)))

Thelinkbox kompilerade utan bekymmer, några varningar om oanvända variabler bara. Nu håller jag på att editera konfigfilerna. Sedan är det dags att göra likadant på den andra RPin innan det blir möjligt att testa hur bra thelinkbox fungerar.
 
Last edited:
En annan aspekt är att man ska kunna välja en codec som gör så bra jobb som möjligt vid smal bandbredd. Speex var vettigt förut men nu är det väl Opus som gäller.

Vad händer med en PSK31-signal eller annan digital signal när den "manglas" genom en CODEC avsedd för röst? Kanske inget problem i ditt fall men intressant fråga tycker jag. Vilken bithastighet krävs annars för få garanterat förlustfri överföring? 8 kHz sampling bör ju räcka till men räcker 8 bitars upplösning t.ex.?

SA6APZ
 
@Fredrik:

Det enklaste vore om man kunde ha BPSK31 programmet lokalt i datorn vid stationen och sedan bara överförde textströmmarna via ledningen ;)

Någon mer driven får svara på vad som krävs för förlustfri överföring eller om det går överföra signalen med en "lossy" CODEC.

Har du hört med de som redan kör remote om deras erfarenheter?

Kommer ihåg att jag för ett par år sedan tog emot BPSK31 från websdr, dessutom var det audiolänk mellan laptopshögtalarna och den inbyggda micken som BPSK31 programmet tog sin input från!

Det är lite doomsday kvalitet på BPSK31 så kanske det även överlever CODECS :)))
 
Last edited:
Framstegsrapport?

Allmänt:
Använder det trevliga programmet Mobaxterm i laptoppen och loggar med SSH-terminal in mig på de två RPierna, en ganska smutt lösning där jag har kontroll på båda från en och samma dator. Kompilerar "native" på respektive RPi.

Att få igång USB-ljudkorten tillsammans med ALSA tog ett tag ;)


Ljudöverföring:
Har testat med Thelinkbox och återigen tröttnat på den massiva konfigureringen som dessutom är dåligt dokumenterad.

Fick gå ut på nätet igen och Googla på alla tänkbara och otänkbara sökord.

Två paket har fångat mitt intresse, Baresip och sscall. Båda använder den nya Opus "codecen".

Tyvärr har sscall bara en readme fil som sin dokumentation. Men det paketet skulle vara perfekt för detta projekt. Har lyckats kompilera upp det men det kommer med någon sorts motorboating i överföringen. Har hackat lite och frekvensen på detta oljud följer storleken på buffrarna. Ska fortsätta att leka med koden och se om det går att fixa bort problemet.

Baresip ska även det gå att köra "command line", och vad jag förstått utan någon dedicerad SIP-server. Kan egentligen inte mycket om SIP-protokollet så det är lite skakigt att hålla på med. Har dock lyckats få uppkoppling men den ena sidan core-dumpar direkt.

Återkommer med ny rapport senare.
 
Last edited:
Riktigt intressanta paket du hittat. Kommer definitivt bli något att prova framöver.

73 de SM0RVV

I synnerhet tycker jag om sscall vars intentioner sammanfaller helt med vårt behov. Funderar faktiskt att ta kontakt med dem via IRC för att höra med dem om de har några tips/idéer kring att få paket att fungera på RPi.

Det här är verkligen retro, att köra command line med Makefile separat editor och förmodar jag, några vändor med GDB. Var väl en 15 år sedan man arbetade så arkaiskt sist ;)
 
Det här är verkligen retro, att köra command line med Makefile separat editor och förmodar jag, några vändor med GDB. Var väl en 15 år sedan man arbetade så arkaiskt sist ;)
He he, kul! Då är det bäst man lägger på emacs, etags och andra fina verktyg på sin Paj alltså? *förlorad i minnen*

73 de SM0RVV
 
Emacs är lite resurskrävande så jag använder oftast JED i såna här sammanhang.

Det är lustigt hur bra "fingerminnet" för Emacs-bindningarna fortfarande fungerar!

Undrar om man ska skriva ut bilder på RMS och Linus och sätta upp dem på väggen? :)))
 
Last edited:
Back
Top