DTMF via WT

Berätta om dina pågående projekt.
persika
EF Sponsor
Inlägg: 1336
Blev medlem: 31 juli 2006, 22:14:37
Ort: Österlen, Skåne

DTMF via WT

Inlägg av persika »

Här ett experiment-projekt med att sända DTMF via walkie-talkie (WT).
Är tänkt att användas för att sända till/från-signaler, även talvärden som t.ex temperaturer.
Har byggt två enheter, en stationär och en bärbar med batteridrift.
Har fått ungefär 500m räckvidd i villabebyggelse, ungefär samma som med tal.
När inga signaler skickas, kan walkie-talkina användas som vanligt med röstkommunikation.

Hårdvaran består av:
Pic16F1788 som styrenhet, den läser av 6 bitar som inport och skriver till 6 bitar som utport.
Pic'en sänder dtmf på samma sätt som detta tidigare projekt med nummerpresentatör:
viewtopic.php?t=95744

Pic'en sköter även manövrering av WT genom tjyvkoppling på tangentarna ON och PTT (push to talk).
Mottagen signal från WT tas från högtalaren och går in på HT9170D, som ger 4 bitar + DV (data valid) till pic'en.
Signalen till WT kopplas in på mic-ingång, relä kopplar bort mikrofonen så inga ljud från omgivningen kommer in samtidigt som dtmf-signaler.

Finns även serieport för ev. framtida utökningar.

Hemmagjort dubbelsidigt kretskort, utfräst med v-fräs, ritat dxf.

Data sänds enligt eget protokoll, har återanvänt från annat projekt.

Ett paket: <02>ccss_mmm_aaa_ddddd<0D>
Ascii-tecken.

Kod: Markera allt

<02>, STX, start-tecken
cc, checksumma enligt Fletcher
ss, summa av checksummor, Fletcher
_,  mellanslag, 3 st som ingår i paketet.
mmm, mottagar-adress-sträng, valfri längd
aaa, avsändar-adress-sträng, valfri längd
ddddd, datasträng, kan innehålla mellanslag, valfri längd.
<0D>, vagnretur-tecken
I detta projekt kan datasträng innehålla ex:
"B0FB1T", i utport nollställ bit 0 och ettställ bit 1.

När ett paket tagits emot, skickas en bekräftelse. Om ingen bekräftelse kommer skickas paketet automatiskt om igen, ett antal gånger.

Eftersom ascii-tecken är 8 bitar och dtmf överför 4 bitar, så sänds två dtmf signaler för varje ascii-tecken, grupperade i par. 60ms för dtmf signal, 60 ms pause mellan hög och lågbitar, 120ms pause mellan varje dtmf-par.

Innan jag kopplade in WT'na testade jag kommunikationen via tråd, funkade bra.
När jag sen när jag skulle ha signalerna igenom WT'na funkade det inte.
Se oscillogram 1. Den första dtmf signalen blev förvanskad, troligen var det nåt med förstärkningsreglering i WT'n som ställde till det. Gjorde så att jag lade till en tomgångston, som inte är giltig i dtmf, en tid innan och mellan dtmf-signalerna, se oscillogram 2.

Det tar c:a 10s för att få över ett meddelande och bekräftelse tillbaka.
Frågan är om man skulle valt nån annan modulationsmetod i stället för dtmf för att få det snabbare ?
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Användarvisningsbild
rvl
Inlägg: 5720
Blev medlem: 5 april 2016, 14:58:53
Ort: Helsingfors

Re: DTMF via WT

Inlägg av rvl »

Det finns ju nåt liknande tonprotokoll som brukar användas för radio, för t.ex. selektivanrop? Om det är bättre eller sämre än DTMF vet jag inte.

DTMF har jag i tiderna avkodat med både kretsar specifika för ändamålet och med DSP, men då var det telefonburna signaler.
ELTompa
Inlägg: 375
Blev medlem: 27 februari 2017, 22:13:28
Kontakt:

Re: DTMF via WT

Inlägg av ELTompa »

Coolt projekt. :tumupp:
Användarvisningsbild
JimmyAndersson
Inlägg: 26308
Blev medlem: 6 augusti 2005, 21:23:33
Ort: Oskarshamn (En bit utanför)
Kontakt:

Re: DTMF via WT

Inlägg av JimmyAndersson »

Snyggt! :tumupp:
Jag saknar såna här projekt på forumet.
Extra bonus-poäng för egna etsade kretskort. :tårta:
Akai
Inlägg: 1345
Blev medlem: 21 oktober 2016, 21:14:49
Ort: Västmanland, Norra

Re: DTMF via WT

Inlägg av Akai »

Ett kul projekt, komplettera med stöd för CCIR så låter det som gamla polisradion :D
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: DTMF via WT

Inlägg av xxargs »

persika skrev: 15 november 2020, 21:49:54
Frågan är om man skulle valt nån annan modulationsmetod i stället för dtmf för att få det snabbare ?
Komplexiteten ökar fort med snabbare protokoll och högre krav på felupptäcktsförmåga och hur fel skall hanteras snabbt och utan att käka för mycket av tillgängliga sänd-tiden.

Du kan alltid prova att korta ned tontiderna och mellanrummen men det är lätt att man börja få osäkra överföringar då.

CCIR användes förr och med mottagare med analoga korrelatorer som CMR FX003 så kunde plocka toner som knappt ens var hörbara i bruset men med modernare versioner skippade man den analoga delen och dessa blev betydligt sämre att plocka toner i dåliga och brusiga överföringar. - har för mig att det gick att få ned tonlängden till 30 ms innan innan det börjande bli problematiskt med överföringsfel.

CCIR är tänkt att köra över radio medans DTMF är inte det och märks på dynamikomfånget på mottagarkretsen då en FX003 kunde nå några dB under brusmattan och ändå fånga toner medans DTMF-krets behöver > 10 dB S/N för att detektera säkert och tillräckligt snabbt.

Ytterligare variant är att titta på FSK och en variant som kallades FFSK med 1200 Baud datatakt med skift mellan 1200 Hz och 1800 Hz med skifte i nollgenomgång (helperiod (2 halvperioder) 1200 Hz för '0' och 1.5 period (3 halvperioder) 1800 Hz för '1' och nya halvperioden fortsätter alltid i samma 'riktning' som den förra halvperioden slutade med för att undvika snabba envelopp-ändringar ) - att man bytte i nollgenomgången är för att minska bredbandiga nycklings-splattret vid växling mellan tonerna som lätt annars blir om man byter slumpmässigt över perioden i modulation mellan två toner i tidigare vanlig använda FSK-standarder.

1200 Baud FFSK ger förvisso också sidband när man modulera och dessa är det som bär datat och kör man tex. bitföljden 10101010 så finns det inget kvar av 1200 och 1800 Hz utan all signalenergi ligger i det fallet på 900, 1500 och 2100 Hz

sedan har man i Amatörradio-världen en hel bunt med olika modulationsmetoder - somliga kommersiellt drivna från såld utrustning - kan vara värt att kika där och se om något passar.

---

Protokollmässigt har du satt checksumman/checkvärdet fel plats i datagrammet - den skall alltid vara sist i varje informationsblock - tex. headern har en CRC efter sig och datadelen har en CRC efter sig, har man bara 1 CRC skall den täcka in allt även headern och CRC skall vara allra sist i meddelande-sekvensen, inte i början eller mitten. Att i ditt fall ha en checksumma för meddelandet och sedan en checksumma som skyddar checksumman direkt efter ger inte den ökade skydd du tänkte dig - och kan du kosta på dig en CRC32-beräkning med bra polynom rent processortidsmässigt så skulle du öka dataskyddet _väldigt_ mycket även med bara en enda 8-bits CRC-värde sist i meddelandet i jämförelse med dina nuvarande fletchersummor.

Ordningen i var man placerar checksumma/CRC har stor betydelse när det gäller upptäcksförmåga och robusthet att hitta bitfel i meddelandet (och i sig själv) och är vanligt misstag när man skriver överföringsprotokoll. Samma sak om datat är skriven med little end och checksumman är skriven med big end i meddelandet (eller tvärt om) så kan man tappa mycket robusthet. - det finns några berömda fel i protokoll där man i princip har slängt bort all kontrollförmåga i avseende Hammingdistans bara för att missat några detaljer i protokollet eller skrivit ut i fel ordning (omvänd bitordning) - tex. i CAN-bussen är inte 'LEN' skyddad av CRC-summa och därmed kan en bitflip där göra att den tror att paketet är mycket kortare och sist i datadelen tror den att det är checkvärdet för paketet men pekar på innehåll i datadelen istället...

Val av polynom för CRC är också viktigt, finns bra sådana och det finns jättedåliga sådana. För 8-bit CRC är 0xEA vanligast för meddelande upp till 85 bit längd för Hammingdistans (HD) 4 och vill man ha längre meddelande upp till 119 bit med HD 4 så är 0x97 lämpligt val - med Hammingdistans så avser det felupptäcksförmågan i antal bit med 100% detektionsgrad oavsett vilka bitar i meddelandets som flippas inklusive checksumman själv.

För kanal störd med vitt brus till BER 1*10^-6 feltakt så pratar vi om 1*10^-26 i risk att missa ett felaktigt meddelande med CRC-värde med polynomvärde 0xEA upp till 85 bitar eller 0x97 upp till 119 bitar med HD 4

För 8 bitars Fletcher med vitt brus kanal störd till BER 1*10^-5 så ligger missade fel-risken runt 6*10^-9 i BER - dvs per ~ 60000 fel så kommer 1 fel slippa igenom oupptäckt i genomsnitt medans med CRC-8 ovan så pratar vi om antal fel med 20 siffror långt tal innan ett fel slipper igenom oupptäckt och då för att av vita bruset som ger bitflip i meddelandet då och då ger betydligt mer än 4 bitars bitflipp samtidigt i datapaketet.

CRC tar alla (100%) bitfel upp till 4 bit med de meddelandelängder som angett, CRC tar även i fall med fler bitar fel men det blir större 'sprickor och hål' i nätet med allt fler bitar fel med möjliga kombinationer som kan ge korrekt CRC-värde och som gör att det inte upptäcks.

Fletcher å andra sidan finns det ingen 100% skydd ens vid 1-2 bitfel utan det handlar bara att fånga "många nog" dvs. en utglesning av fel med en faktor från tusental till några tiotusental och mycket beroende på bitmönster då långa rader med bara '1' eller '0' ger större chans till oupptäckta fel än om bitmönstret hålls alltid hyfsat slumpmässigt.

Med andra ord att använda CRC-8 med polynom 0xEA eller 0x97 istället för fletcher 8 bit ger väldigt stor förbättring i att upptäcka överföringsfel.

Det finns historiska misstag med 8 bitars polynom för CRC som tex. DARC med polynom 0x9C och i princip i en smäll tappar nära hela sin upptäcksförmåga av fel redan vid 10 bitar och uppåt i meddelandet medans vid 9 bitar och under har skyddverkan av HD 5.

Att kolla vilka polynomer som är bra eller inte för CRC är i stort sett samma jobb som att försöka knäcka hash-algoritmer och se vilken som tål attacken längst tid innan genombrott vid olika meddelandelängder och bitfelsmönster vilket gör att gamla polynomer som finns i många CRC-standarder är inte alltid dom bästa vid använda meddelandelängder (typexempel är IEEE 802.3 CRC för SATA ersattes med CRC-32C i SAS och fick ~ 10000 ggr bättre dataskydd med samma antal bitar i CRC-värdet) då dessa togs fram historiskt med ganska stor portion "antagande" av matematiker av just anledningen att det var så svårt att kontrollera och därför fick sådan fall som 0x9C (DARC) igenomsläppta utan att någon reagerade - idag med motsvarande datatuggar som bitcoin-riggar så kan man verkligen testa mycket hårdare än tidigare - men arbetet är liknande som när man knäckte SHA1-hashalgoritmen och visade sig bara var 63 bitar starkt fast det borde vara 80-bitar starkt...
persika
EF Sponsor
Inlägg: 1336
Blev medlem: 31 juli 2006, 22:14:37
Ort: Österlen, Skåne

Re: DTMF via WT

Inlägg av persika »

Tack för alla svar!
Jag är bara glad amatör. Glad för när det man gjort funkar att använda.
Men, det är alltid intressant att höra synpunkter, som man ev. kan ta som förbättringar.

Får se om jag får tid att experimentera med olika modulationsformer, FFSK verkar intressant.
En fördel med DTMF är ju att man får över 4 bitar åt gången.
Jag har provat med att korta tider för dtmf signal till 40 ms, då började det bli osäkert, så 60ms tyckte jag var lagom.
Men jag skulle kunna prova att korta in pauserna, men på det stora hela gör det troligen inte så stor skillnad.

Jag googlade en del om checksummor då innan jag börja använda Fletcher.
Vad jag kunde förstå så var Fletcher nästan lika bra som CRC, men mindre beräkningskrävande.

xxargs, En fråga:
På vilket vis har platsen för checksumman betydelse ?
Borde inte störningarna slå blint ? De vet ju inte vad de stör ut.
Skriv svar