Svenska ElektronikForumet

Jag kör mycket linjelyssning på seriella kommunikationsprotokoll. Lite RS232, men oftast RS485. Använder då program som Realterm, FLL (Fifo Line Listener) etc.

Nu skulle jag behöva lyssna på två baudrater samtidigt. Det är en enhet som ställs om i baudrate med ett konfigkommando och saker blir lite rörigt när man måste lyssna med två olika enheter. Det går inte att se tidsförhållanden mellan dom två loggarna på ett bra sätt.

Det hade varit bra med ett loggprogrogram som kunde logga på två portar samtidigt med olika baudrate. Visst blir det en del skräp i loggarna när det blir fel baudrate, men det är ju lätt att sortera bort när man ändå ser det i "rätt" baudrate samtidigt.

FLL:en som jag kör mest, har support för två samtida linjer som visas färgkodade i realtid. Det är utmärkt, men tyvärr inte med två olika baudrate.

Finns det något sådant program?

Är det asynkronkommunikation utan linjekod. Så är det bitrate, inte baudrate. Den senare indikerar modulation med flera bitar per baud.

> Så är det bitrate, inte baudrate.

Det är i detta fall samma sak. Eller har i alla fall samma värde.

> Den senare indikerar modulation med flera bitar per baud.

Nej, det gör det inte alls. Var och en får läsa på själv :
http://en.wikipedia.org/wiki/Baud

Du bara rör till det...
Både AVR och PIC har "baud rate registers" o.s.v.
I praktiken är det samma som den "bit/sec" som USART använder.

Så länge det är en digital signal, med bara två nivåer, så är baudrate=bitrate.

Det är först om man blandar in flera nivåer eller nån form av modulering som det blir flera bitar per baud. I de flesta fall är det alltså bara när man blandar in "riktiga" modem som det är viktigt att hålla isär dem.

Jag är medveten om skillnaden, men precis som sagts så är det samma sak i dom allra flesta fall. Och begreppet baudrate används i alla UART-sammanhang. Därför är det i högsta grad relavant här.

Till ursprungsfrågan!

> Till ursprungsfrågan!

OK...

> Det är en enhet som ställs om i baudrate med ett konfigkommando och saker
> blir lite rörigt när man måste lyssna med två olika enheter.

OK, så det gäller samtidig loggning av två helt separata RS232 linjer?

> FLL:en som jag kör mest, har support för två samtida linjer som visas färgkodade i realtid.

Dessa "två linjer", är det inte normalt TX/RX men på samma RS232 linje?
De kommer ju alltid att ha samma hastighet. Eller kan den lyssna på två
helt separata RS232 linjer, varje med sina egna TX/RX signaler?

Eftersom det är RS485 i det här fallet, så blir det bara en kommunikationslinje att lyssna på. Men för att kunna lyssna på båda hastigheterna samtidigt (och därmed få dom tidsynkade med varandra) så krävs då lyssning på två portar samtidigt med olika baudrate.

Det som kommer in på porten med "fel" baudrate kommer ju att bli skit. Men om då inputen från port 1 och 2 är tidsynkade med varandra, så är det ju bara att ta bort (eller ignorera) det som är skit. Det finns ju ändå samtidigt läsbart i "rätt" baudrate.

Tack vara samma tidslinje så är det ju lätt att koppla allting till vartannat. Denna möjlighet har man inte alls på samma sätt när man loggar det på två helt olika programinstanser/datorer.

OK. (Inte för att jag har någon lösning, men är lite nyfiklen... )

Det är alltså *en* linje som skiftar baudrate som du vill köra in
i *två* portar (som lyssnar med olika baudrate). Ja, då är jag med.
Jag ar inte sett någon kommersiell linjelyssnare som fixar det, men
å andra sidan har jag inte sett så många heller under de senaste
20 åren...

Precis så! Hela upplägget är lite rörigt, så det är inte helt lätt att förklara på ett sätt så att det blir glasklart. Men med lite frågor och tillhörande klargöranden, så borde vi nu ha en någorlunda uppfattning av vad jag vill uppnå.

Att det skiftar baudrate beror just på att det är en baudratekonfigurering av en slavnod. Den har alltså en baudrate vid uppstart, men ska ställas in med kommandon till en annan baudrate. Detta svaret på baudratekommandot kommer i den gamla baudraten, men sedan skall en upprepning av baudratekommandot skickas på den nya baudraten som en konfirmering. Detta konfirmerande baudratekommando besvaras då förstås på den nya baudraten.

Sedan rörs det hela till ytterligare av att en kommunikationsadress skall konfigureras i samma procedur. Och adressen måste sättas först. Om man då har en enhet som man inte vet vilken baudrate den har vid anslutningen, så måste man först prova ut vilken baudrate den verkligen har, för att först kunna göra adressinställningen och sedan kanske en baudrateändring om det behövs. Men detta är överkurs för den här tråden. Det är mitt problem och redan löst. Men det ger ett visst behov av att kunna se kommunikation i båda baudraterna samtidigt och tidsrelatrerat till vartannat.

Logikanalysator låter passande för detta

Kan du inte köra två instanser av RealTerm?

OK, då är det ju ganska tydligt vad det hela handlar om.

> Tack vara samma tidslinje så är det ju lätt att koppla allting till vartannat. Denna möjlighet har
> man inte alls på samma sätt när man loggar det på två helt olika programinstanser/datorer.

Tja, om det är två programinstanser på *samma* dator så borde det i alla fall
bli jämförbara tidsstämplar, även om de inte hamnar i samma "lista" så att säga.
D.v.a att, även om man får leta lite mer, så är det ingen tvekan i vilken ordning
som olika händelser inträffade.

vfr:
Behöver du kunna se när baudrate ändras?
Om inte, så skulle ett terminalprogram med ABR (Auto Baud Rate) vara till hjälp.
Just nu kommer jag inte på något, men just "ABR" kan vara ett ord att ta med i sökningarna.

Då får du allt med rätt baudrate direkt.


Själv har jag använt logikanalysator (i datorn) till sånt här.
Länk till mjukvaran jag kör.
Men som sagt, man får två olika filer som kan bli lite oöverskådliga att parera ihop rent tidsmässigt.
Det blir alltså som att köra två instanser av t.ex RealTerm.

Finns en loggmjukvara som heter docklight, den tidsstämplar allt som loggats ned på hundradelen (tror jag). Skulle 2 instanser av den och sedan manuellt föra ihop loggarna fungera?

> Då får du allt med rätt baudrate direkt.

Nja, sannolikt inte *allt*, det tar en tid för autobauden att
"svänga in". Det måste ju komma lite trafik som kan mätas.

Och rena terminalemulatorer fungerar ofta lite dåligt för riktig
linjelyssning. Dels villman ha tidsstämpling vilket de flesta saknar,
dels vill man ha det helt transparent utan tolkning av kontrolltecken.
Samt möjligheten att få det i hex...