Avkoda digital kommunikation

[jadler]

Jag har en ganska ny amatörradio-transceiver, en Yaesu FTM-400DE, som har en basenhet med radiofunktionerna, högtalare och uttag för mikrofon, samt en kontrollenhet med fyra rattar, fem knappar och en resistiv pekskärm.

Kontrollenheten kopplas till basenheten med en fyrtrådig kabel med RJ12-kontakter. Självklart måste man ta reda på hur kommunikationen går till, ett roligt mål vore att kunna styra basenheten med motsvarande kommunikation via en µC kopplad till en dator.

En tråd är jord, såklart, och en är spänningsmatning (oreglerad inspänning till basenheten minus spänningsfallet i kabeln, kan alltså gå upp mot 13,8V och mer). De andra två torde sköta kommunikationen mellan kontrollenhet och basenhet. Utöver den hemsnickrade kabeln med anpassad längd gjorde jag alltså en kabel som underlättar mätning och inkoppling till logikanalysator (Logic, första versionen).

Det är inte en klocksignal på en tråd och data på andra, utan det verkar snarare som att det är en tråd för kommunikation i var riktning, och paketen överlappar varandra delvis. Det är hög nivå mellan paketen, det ser ut att vara knappt 10 kHz grundfrekvens med en grundrytm på 94 µs lågt och 10 µs högt, och ibland tätare pulser med 10, 20 eller 30 µs lågt mellan de höga pulserna på 10 µs. Grundrytmen för de höga pulserna kvarstår. Ibland kommer det höga pulser på 20, 30 eller 40 µs.

Jag tolkar det som att det är en klockpuls som grund och extra pulser av varierande längd och avstånd som förmedlar data. På kanal 0 kommer paket om drygt 20 ms med 5 ms mellanrum, kanal 1 paket om drygt 7 ms med knappt 18 ms mellanrum, alltså omkring 25 ms period från paketstart till paketstart, där paketen på kanal 1 kommer omkring 1,6 ms före de på kanal 0.

Det känns som att det borde gå mer data från kontrollenheten till basenheten, och mer komma bekräftelse och information om aktuella inställningar och styrka på mottagen signal etc från basenhet till kontrollenhet, så jag tippar att kanal 0 är från kontroll till bas, kanal 1 tvärtom.

Har någon några tankar om var jag skall börja för att avkoda kommunikationen? Jag har inte öppnat kontrollenhet eller basenhet än så jag vet inte vad det är för µC i någon av dem.

Jag har en sparad kort session både i logic-format och som csv.

[Klas-Kenny]

"Jag har en sparad kort session både i logic-format och som csv"

Ladda upp det då för tusan..!
Packa det som en zip så tror jag att forumets filuppladdning accepterar det.

[jadler]

"Jag har en sparad kort session både i logic-format och som csv"

Ladda upp det då för tusan..!
Packa det som en zip så tror jag att forumets filuppladdning accepterar det.

OK.

[jadler]

Förresten är det väl minst lika bra, om inte bättre, att bjuda på filen i Logic-format eftersom programmet (Linux/Mac/Windows) finns att hämta utan kostnad och går att använda för att kolla på filen utan att man behöver ha hårdvaran.

[hanzibal]

Har inte kollat filen men på din beskrivning låter det ändå lite som asynkron seriell lina i full duplex på 115200 kanske och att det är start/stopbitar som du ser periodiskt. RJ12 är väl "telefonkontakt" och brukar visst användas för just RS232-nollmodem:

http://pinout.net/pinout-scheme/479/RJ12%20to%20rs232

Antar att du redan kört en sväng med logikanalysatorn?

Såg på hemsidan att det ju verkar finnas en kabel för PC-anslutning. Vet inte vad det gränssnittet låter dig göra men kanske likvärdigt och torde då vara lättare att använda en sådan:
http://www.yaesu.com/downloadFile.cfm?F ... tion%2Fpdf

Läste frasen PL-2303 så verkar vara den gamla vanliga USB/RS232-bryggan från Prolific.

[jadler]

Tack, hanzibal!

Det verkar mycket riktigt vara vanlig asynkron seriell överföring, men med 100 000 bps. Logic kan analysera det som detta och ser inga fel i formatet (jag använder standardinställningen 8N1).

Jag skrev fel tidigare, det är RJ10-kontakter, fyra trådar -- två med signal på TTL-nivå (gissar jag, inte kollat om det är +3,3V eller +5V), GND och VDD (13,8V på ett ungefär, beroende på inspänning till basenheten).

Det finns en datakabel, ja, och jag har en sådan, med PL2303 inuti. Den kopplas till en mini-DIN-liknande kontakt med 10 stift som dels har linor för seriekommunikation med basenheten, dels olika linor för packet data. Datakabeln har bara stöd för seriekommunikation, och kan bara användas för att ta emot GPS-position, waypoints (positioner för mottagna APRS-paket) eller packet data. Den används också för att uppgradera firmware (basenhetens grund-fw och DSP-fw, och sannolikt även kontrollenhetens fw). För att uppgradera basenhetens grund-fw måste man öppna den och ställa om en switch så att den bootar i annat läge.

Det jag tänkte analysera här är kommunikationen mellan kontrollenheten, som jag använder för att styra basenheten och läsa av information från basenheten, och själva basenheten. Kan jag få kläm på protokollet och informationen som utbyts kommer jag att kunna styra radion helt från en dator, över nätverk om jag så önskar.

Det handlar alltså om en kontrollenhet, användargränssnittet, som dels har en pekskärm, dels två volymkontroller (vridpot), fem knappar, två stegande rattar som man också kan trycka in (fjädrar ut direkt), inbyggd GPS och anslutning för extern GPS. Den används både för att styra basenheten (själva radiodelen) och för att visa information från densamma. Jag gissar att den lina som har längre datapaket, större datamängd per tidsenhet, är data från kontrollenhet till basenhet, det borde vara större mängd information som behöver färdas i den riktningen.

Det lär sitta (minst) en µC i varje enhet, kanske en i mikrofonen också, och jag tror inte att det är helt banalt att ta reda på hur informationen överförs, hur protokollet ser ut på nästa högre nivå. Nu blir väl nästa steg att koppla in en egen µC, kanske en Arduino, och lyssna av kommunikationen och försöka hitta ett mönster.

Andra amatörradioriggar, oftast dyrare, har särskilda kontakter för styrning från dator. Det vore lite skoj att kunna skapa något liknande för denna.


Ljud med mera

Det finns inga in- eller utgångar för ljud på linjenivå, vad jag vet, men jag bör väl kunna använda högtalarutgången (3,5 mm tele, stereo, en kanal per VFO) och mikrofoningången (RJ12, 6 trådar som skall överföra dels mikrofonsignal, PTT, 16 DTMF-knappar och 4 användardefinierade knappar samt knappar för "upp" och "ned", så jag gissar på minst en serielina, spänning och jord, mikrofon och kanske PTT separat).

Det finns förresten en sekundär mikrofonkontakt som ser ut som en modifierad USB mini-B hona, som utöver de vanliga 5 USB-linorna även har 6 andra kontaktbleck (lika många som till standardmikrofonen -- sammanträffande? ). Denna kontakt används för att ansluta en dyr mikrofon med inbyggd kamera som tar bilder med 320 x 240 eller 160 x 120 pixlar, som man sedan kan sända till andra som har en likadan radio. Skulle jag implementera detta skulle jag använda vanligt USB-gränssnitt för kamera, så att jag kunde återanvända befintlig mjukvara och slippa uppfinna ett eget protokoll, och jag gissar att Yaesu har gjort detsamma, så att de har kombinerat samma sex linor som till standardmikrofonen med en vanlig USB-kontakt, mikrofonfunktionerna går över de sex vanliga linorna, bildöverföring över USB. Kameramikrofonen har färre knappar, bara PTT, en knapp för att ta en bild och en för att sända bilden. Det finns högtalare i den, men denna radio stöder inte ljudöverföring dit.

[sodjan]

> Nu blir väl nästa steg att koppla in en egen µC,

Jag skulle först koppla in en vanlig terminalemulator, PuTTY eller liknande,
för att se om det alls går att se något systematiskt i det hela. Om det nu
faktiskt är 100 Kb/s så behöver man ju även kunna ställa lite udda baudrates...

[jadler]

Det verkar inte vara text som överförs utan något binärt protokoll, så att kika på det med terminalemulator ger nog inte så mycket. Dessutom vill jag lyssna på två linor, och inte sända på någon, så det är antingen två USB-serie-interface eller en µC som lyssnar på båda linorna och rapporterar till dator över USB. För mig känns det senare smidigare.

Informationen sänds i paket med fast längd, i båda riktningarna, så ett steg borde vara att jämföra paketen med varandra över tid.

Basenheten slås på från kontrollenheten, och verkar slås av om den inte har kontakt med kontrollenheten. Ett sätt att ta reda på i vilken riktning trafiken går vore att låta en µC reläa trafiken, ta emot på en sida och sända detsamma på andra sidan. De µC jag är mest van vid har hårdvarustöd för en serieport och kan bitbanga fler med mjukvara, så det borde gå att ordna. Dock minns jag inte hur höga hastigheter man kan köra mot USB, om det räcker till för 2 x 100 kbps. Jag har ett kort från Adafruit med en ATmega 32U4, får kolla om den har separat serieport vid sidan om USB, till skillnad från traditionell Arduino. I annat fall blir det ju tre serieportar som den skall hantera för att både reläa och rapportera till dator.

[hanzibal]

Kontrollenheten lär vara en ganska dum terminal så jag tror att protokollet är tämligen banalt.

Jag hade väntat med uC och använt PCn till att kartlägga protokollet, initialt i en riktning i taget.

Troligen kan du använda den Prolific-kabel (kolla spänningsnivåerna först) du redan har men då ansluten parallellt med kontrollenheten istället. Hade börjat med att avslyssna data i riktning från kontrollenheten till basenheten. Första testet vore att öppna COM-porten med vanligt terminalprogram som Sodjan föreslår (betänk det där om ev. icke-standard datahastighet). Programmet kan visa binära data, t.ex. i hexadecimal eller binär form. Kolla först grundläggande egenskaper, t.ex. att datat är tidsoberoende, att en viss knapp alltid ger samma data.

Personligen tror jag att du då ganska snabbt har "knäckt" protokollet. Sedan gör du samma sak med i andra riktningen och där kan du dessutom jämföra med med vad som händer på skärmen.

Förmodligen pratar basenheten på ganska hög nivå, och i respons till viss knapp säger den kanske "Tänd symbol för blabla" eller "Visa frekvensen XXX Hz", varpå kontrollenheten blint utför dessa saker.

EDIT: Riktningen kan du nog mäta dig fram till, bryt en signalkabel och kolla vilken ände som tystnar.

[jadler]

Jag har visst inte använt µC på lite för länge nu. En vanlig *duino Mega har ju tre serieportar i hårdvara, problemet löst.

Jag gillar inte PL2303, men har en bunt FTDI-kort som gör samma sak men bättre. Jag funderar på att klippa sladden som följde med radion och göra en kontakt för just FTDI istället. Till min Wouxun KG-UV6D har jag byggt en sådan adapter så att jag slipper använda kabeln som följde med, som också innehåller en PL2303.

För att avgöra riktningen känns det för mig enklast att låta t ex en *duino reläa trafiken, testa i ena riktningen först, om det fungerar har jag hittat rätt på första försöket, annars testar jag i andra riktningen.

Det verkar som att vi pratar förbi varandra här. Min avsikt är just att låta datorn analysera trafiken, men att använda en µC för att lyssna på trafiken och skicka den till datorn. En *duino som ersätter två serieinterface och dessutom kan reläa trafiken istället för att bara lyssna. Visst, det blir en klart underutnyttjad µC, men det gör livet lättare för mig så det kan jag leva med.

För mig känns det också rimligare och enklare att använda ett enkelt program i Python eller Perl för att analysera trafiken, hellre än att använda en terminalemulator. Jag kan snabbt slänga ihop ett program, och det kan ge samma information som en dum terminalemulator och mycket mer därtill. Jag förstår inte riktigt vad fördelen med en terminalemulator skulle vara, förklara gärna.

[sodjan]

> Jag förstår inte riktigt vad fördelen med en terminalemulator skulle vara, förklara gärna.

För det första tar det nästan ingen tid alls att testa.
Sen så kan det väldigt snabbt ge en del "hintar" om hur
datat ser ut, det beror ju på *hur* det ser ut. I många
fall så säger det allt om kommunikationen och andra verktyg
skulle inte tillföra ett smack. Det beror på...

Men visst, det kan vara så pass rörigt så att det krävs
programkod i t.ex Python eller liknande för att "plocka isär" det.

> men att använda en µC för att lyssna på trafiken och skicka den till datorn.

Ja, speciellt som baudraten verkar vara icke-standard och det kanske
är enklare att få uC att lyssna i rätt hastighet.

[vfr]

Som terminalemulator kan man använda t.ex Realterm som har stöd för visning i hex-mode. Smidigt om det handlar om binära protokoll. Och den har en massa andra användbara inställningar...

[hanzibal]

Jag har visst inte använt µC på lite för länge nu. En vanlig *duino Mega har ju tre serieportar i hårdvara, problemet löst.

Med "uC" menade jag t.ex. Arduino och liknande.

Du gör såklart som du själv finner för gott men det verkar onekligen betydligt mer komplicerat att blanda in uC i detta tidiga skede. Tar längre tid och du får fler potentiella felkällor som riskerar att förvirra.

För att avgöra riktningen känns det för mig enklast att låta t ex en *duino reläa trafiken, testa i ena riktningen först, om det fungerar har jag hittat rätt på första försöket, annars testar jag i andra riktningen.

Ser inte hur det kan vara enklare än att bara "kapa" linan och mäta med voltmetern på resp trådände. Du kommer ju ändå att bryta ut trådarna på eget kort eller liknande för att koppla in dig.

Jag tror mig vara väl införstådd med vad du vill åstadkomma - i princip vill du skriva en emulator för PC som helt kan ersätta kontrollenheten. Där kan du t.ex. ha snabbkommandon/makron som utför hela serier av kommandon och presentera informationen på vilket sätt du vill.

[jadler]

Mer komplicerat att låta en *duino sköta seriekommunikationen och rapportera till datorn än att använda två serieinterface och lyssna på båda med något program på datorn? OK, jag håller inte med, men det kan vara en smaksak.

Mitt första stycke, som du citerade, syftade på att jag hade glömt att *duino Mega ju har hårdvarustöd för tre serieportar, så jag behöver inte bry mig om att köra mjukvaru-UART eller börja lära mig detaljerna kring ATmega 32u4. En *duino Mega skall klara av att reläa två seriella linor och samtidigt prata med datorn på en tredje. Jag har pysslat med annat än att programmera µC på sistone, så jag har glömt vissa självklarheter.

Basenheten verkar kräva kommunikation med kontrollenheten för att vara aktiv, som jag skrev tidigare. Kapar jag en lina är sannolikheten stor att basenheten (och kanske kontrollenheten) helt enkelt stängs av, och då blir det svårt att mäta något alls. Eftersom jag ändå har för avsikt att koppla in en *duino kommer det inte att ta mig mycket extra tid att testa en extra relä-riktning för att avgöra åt vilket håll trafiken går. Ett annat enkelt alternativ vore väl att koppla in en diod och bara låta kommunikationen gå åt ett håll.

Korrekt där, tanken, eller drömmen, är att på sikt kunna ersätta kontrollenheten med ett gränssnitt för datorn, sannolikt då via en µC, för att kunna fjärrstyra radion som man kan göra med dyrare burkar. Inte för att jag själv har något behov av detta i dagsläget, utan mer för att det borde gå att göra och det vore "ett snyggt hack".

Egentligen borde jag nog fokusera mer på att lägga till stöd för denna radio i Chirp, vilket jag har påbörjat men inte avslutat. Det är lite samma sak där, jag kan leva utan det, men det vore kul att göra det, andra kan ha glädje av det, och även det vore "ett snyggt hack".

Vad gäller terminalemulator heter min just nu xfce4-terminal. Jag kör Linux, grunden är kommandoraden (därav mitt val av anropssignal, SA0CLI, där CLI ju står för command line interface), och när jag kör GUI är det någon släkting till xterm som får agera terminalemulator, men annars behöver jag ingen emulator. För seriekommunikation brukar jag använda minicom.

[sodjan]

OK, och hur såg et ut när du testade med det (minicom)?