I/O över nätverk

[cjonash]

Jag tror inte att problemet ligger i mjukvaran (som för övrigt är baserad på interrupts). Anledningen är att det saknas ingen data alls, gentemot protokollet. Inte ett enda byte. Däremot kommer det, då och då, ett extra byte mitt emellan andra, korrekta, bytes.

Klockan som vi lyssnar på skickar data en gång i sekunden, innehållande aktuell tid (oavsett om den står stilla eller räknar). Däremellan kan det komma annan data, men den behöver vi inte gå in på nu. Denna klockdata består av ett antal byte som statar med ett addressbyte (bit 8 = 1), följt av ett antal innehållsbyte och avslutas med ett byte med checksumma. Dessa bytes får jag alltid, och innehållet stämmer. Men ca 1-2 gånger i minuten, så innehåller detta paket ett extra innehållsbyte (som oftast är 0). Det är det som är mitt problem.

Jag har gjort två tester mot klocksystemet. Första gången hade jag mina motstånd monterade korrekt, men hade inte kod för att läsa den 9:e biten. Datat jag fick var korrekt, men det gick inte att använda eftersom det inte gick att säkert identifiera starten på ett paket. Jag har i mina loggar inte kunnat hitta några "extra" bytes i den data jag då läste. Vid samma tillfälle provade jag med en RS485-USB konverter, och fick exakt samma data. Men även där utan den 9:e biten.

Vid det andra tillfället hade jag modifierat koden för att ge stöd för den 9:e biten, men glömde koppla in motstånden. Bortsett från det extra byte som kommer då och då ser all data exakt ut som vid första tillfället (även den data som kommer mellan tidsuppdateringarna). Därav drar jag slutsatsen att min rutin för att läsa data är tillräckligt snabb och även i övrigt åtminstone hyfsat korrekt. Det skall noteras att det extra byte som jag läser kommer också via en interrupt från UART (det är loggat genom att jag räknat antalet interrupts och jämfört med längden på paketen jag har läst, då jag först misstänkte min inläsningsbuffer).

Hade testen varit utförda på samma ställe, hade jag inte varit speciellt tveksam - då torde de utelämnade motstånden på andra testet varit gravt misstänkta. Det som, i min måhända något oerfarna värld, gör att jag inte är lika tvärsäker nu är att det förutom avsaknaden av motstånd också är en annan anläggning. Förvisso med en klocka av samma modell, men det innebär ju inte nödvändigtvis att mjukvaran i den är densamma. Och inte heller att installationen i övrigt är likadan. Det kan ju också vara olika revisioner av hårdvaran.

Jag påstår inte att jag kan utesluta min egen kod som felkälla, men jag förstår inte hur jag i mjukvaran skulle kunna göra så att det kommer ett extra interrupt, samtidigt som all riktig data faktiskt kommer som den borde. Å andra sidan kan jag heller inte förstå hur en störning orsakad av en felaktig RS485 inkoppling kan generera motsvarande ett helt extra byte utan att orsaka korrupt data - det är ju 11 bits som plötsligt dyker upp där (en startbit, 9 databits och en stopbit).

[lillahuset]

Det räcker att UARTen uppfattar en startbit för att du ska få problem med en extra byte. Signaljord och korrekt terminering är modellen för RS485. Jag hade en kund vid Stureplan som hävdade att det inte var så viktigt och hade fungerat förut. När de gjorde som jag sa försvann problemet. Magic? Nej!

[Jan Almqvist]

IDet fungerar fint - så när som att IBLAND kommer ett extra byte in i paketet (oftast 0x00, men inte alltid). Var i paketet det kommer varierar (men det är ju alltid mellan adress och checksumma, annars skulle min inläsningsrutin kasta bort det).

Om man antar att den enhet som sänder paket skickar alla tecken i en följd utan några mellanrum mellan, vilket torde vara det normala, så kan det väl inte komma några extra tecken inuti paketet eller?

[xxargs]

Om jag tolkar inläggen rätt innan så är det bara korta burstar med data med långa vilotider mellan dessa.

Då finns det fönster för skräp och störningar att hitta in - eventuellt att sändande hårdvaran har egna hyss för sig med okänd funktion.

Kommer nyttoinformationen med väldigt exakt intervall så kan man fasa in sig för detta tidmässigt och helt enkelt inte lyssna på linjen mellan utsändningsperioderna. Kommer skräpinformationen i anslutning före och efter den valida datat så är det förstås jobbigare och en mer avancerad felhantering - för det finns väl en sådan, för felaktiga bitsekvenser kommer att hända förr eller senare - även om det tar år mellan tillfällena.

[cjonash]

Om man antar att den enhet som sänder paket skickar alla tecken i en följd utan några mellanrum mellan, vilket torde vara det normala, så kan det väl inte komma några extra tecken inuti paketet eller?

Nej, det är ju det jag inte tycker heller. Icke desto mindre är det så det ser ut.

xxargs: Det är riktigt att det är korta burstar med data. Men skräpdatat kommer inte mellan dessa - där är det helt tyst utan några extra bytes. "Skräpet" kommer mitt inne i en sekvens av i övriga korrekta bytes.

Här är ett exempel (hex-koder, 9 bits):

10A 00C 02F 002 062 026 0C0
10A 00C 02F 002 062 025 0A0
10A 00C 02F 000 002 062 024 080
10A 00C 02F 002 062 023 0E0
10A 00C 02F 002 062 022 0C0
10A 00C 02F 002 062 021 0A0
10A 00C 02F 002 062 020 080

Dessa data har kommit med en sekunds mellanrum. Det tredje paketet är det som är felaktigt, i form av det 4:e bytet - men resten av datan i det paketet är som synes korrekt.
Mellan dessa paket har det kommit andra paket, men jag har utelämnat dem här i syfte att enklare visa problemet (i just denna sekvensen fanns inga andra fel i den utelämnade datan).
Jag kan heller inte filtrera bort allt som kommer mellan dessa paket, eftersom jag behöver en del av dem också. Sedan är det så att klockan ju kan stanna och starta allteftersom matchen pågår, så när jag får ett felaktigt paket kan jag inte gissa mig till innehållet.

Jag ska nog också säga att det extra bytet, de få tillfällen när det kommer, inte alltid är på samma plats i paketet. Därmed går det inte att gissa sig till vad som är felaktigt heller.

Visst skulle det kunna vara den sändande enheten som är problemet - dock hanterar systemets egna mottagare i så fall detta på något sätt, för displayerna i hallen missar inte en uppdatering på det sättet som jag gör när jag får ovanstående data.

[lillahuset]

Och hur har vi med signaljord och bussavslutning?

[cjonash]

Som jag har förklarat, så finns inte signaljord tillgängligt i den anslutning vi har tillgång till.
RS485 bussen som sådan är ju permanent terminerad i en av hallens displaytavlor (eller ska i alla fall vara det).
Så här ser dokumentationen ut från tillverkaren:

anslutning.jpg

Displayerna i hallen är alltså kopplad till samma dsub - vi har gjort en "breakout" kabel i form av 3 dsub på en 10 cm lång flatkabel och på så sätt parallellkopplat oss.
Det ska noteras att man kan köpa ett interface av tillverkaren (det gjorde den föregående grafikleverantören), och det kopplas in på exakt samma sätt. Med den reservationen att de ju såklart vet vad som finns på de övriga 13 stiften i kontakten, och kan ha kopplat in signaljord. Vi vill inte köpa det, eftersom det är förhållandevis dyrt och det fungerar bara med just deras klockor. Vi vill ha ett interface som fungerar i alla (eller åtminstone så många som möjligt) hallar - och av logistiska skäl behöver vi 2-3 stycken. Mitt interface har därför både RS232 och RS422/RS485, och planen är alltså att kunna välja protokoll i mjukvaran (som då också väljer rätt fysiska anslutning).

Vid det första testet, så var även min anslutning terminerad och försedd med bias motstånd. Då har jag inte sett någon skräpdata (inte som jag upptäckt i alla fall).
Schemat för den kopplingen ser ut så här:

schema.jpg

Bussen ansluts till pinne 7+9 på PL6. IC3 och IC5 med tillhörande motstånd och kondensatorer används inte och var heller inte monterade.

Vid det andra tillfället, när jag har fått skräpdata, hade jag missat att sätta dit motstånden (R38-R40).
Detta insåg jag först efter testet när Icecap påpekade det. Min tanke var då att det givetvis var orsaken och jag var hyfsat glad. Där hade det kunnat stanna (fram tills nästa test, som är om en vecka) om det inte varit för att det kom flera förslag om isolerade kontra oisolerade kretsar, samt signaljord.

Då blir jag ju tveksam igen, och frågan som då kvarstår är ju: är det sannolikt att problemet beror på de glömda motstånden (dvs, kan den typ av fel med extra bytes mitt inne i ett i övrigt komplett paket uppstå om dessa motstånd saknas), eller är det sannolikt att det beror på något annat.

[lillahuset]

Vad är det för tomtar som inte har installerat signaljord? Finns den inte tillgänglig och du vill ha något tillförlitligt rekommenderar jag galvaniskt skilt. Är man inte rädd för extra arbete kan man testa utan galvaniskt skilt. Kabeln verkar ju vara ganska kort och fas och nolla är förhoppningsvis samma.

[Jan Almqvist]

"Skräpet" kommer mitt inne i en sekvens av i övriga korrekta bytes.

Här är ett exempel (hex-koder, 9 bits):

10A 00C 02F 002 062 026 0C0
10A 00C 02F 002 062 025 0A0
10A 00C 02F 000 002 062 024 080

Jag har svårt att tro att detta är en störning. Antingen är det något som skickas, med eller utan avsikt, eller också är det fel i mottagningsfunktionen.

Lyssna med något annat och/eller mät med oscilloskop.

[xxargs]

Jag instämmer - och tänker man inte försöka reda ut varför och hur den befintliga anläggningen gör detta, så är det att köpa läget och hantera situationen när det uppstår. kort sagt släng alla bytes du inte förstår eller förväntar dig.

[cjonash]

Jag hade ju helst av allt velat reda ut hur det är gjort i de existerande anläggningarna. Men eftersom tillverkaren inte är intresserade av att hjälpa till (de vill ju såklart hellre sälja sitt eget interface), och vi inte gärna kan börja skruva isär hallarnas klockor (de är ju inte våra kunder - vi arbetar för tv-kanalerna) så blir det svårt att göra det.

Det är inte heller så enkelt att göra seriösa mätningar - de tillfällen vi får tillgång till systemen är begränsade, och oftast då i samband med matcher. Då finns varken plats eller lugn för att börja rigga upp större labb. Hallarna används ju till annat när det inte är matcher där.

Det här blev ju ett litet sidospår i projektet. Jag känner mig förhållandevis trygg i den hårdvara jag använder (även om den inte är isolerad) när det gäller övriga användningsområden för mitt interface. Med motstånden monterade, såklart. Jag har använt samma design under många år i broadcastsammanhang, utan problem. Och i samtliga andra sammanhang har det funnits en signalnord att ansluta - det här är första gången jag själv råkat ut för att det inte finns. Men då verkar jag ju också i en relativt liten bransch.

Dock ska jag bygga en testgenerator som skickar känt data, så att jag kan få 100% verifierat att min mottagarrutin fungerar. Eftersom den också ändrades mellan testerna, så finns ju såklart risken att det trots allt är något fel där. Även om den absoluta merparten av datan läses korrekt.

Sedan skall jag vid nästa testtillfälle se om det blir tillfälle att montera isär en av de befintliga kablarna i anläggningen, för att se om det går att hitta en signaljord där. Det är en tredje hall, så det återstår ju att se om det kommer andra överraskningar där. Jag vet att tillverkaren har olika versioner av mjukvaran, så det kan ju finnas andra varianter av protokollet som jag inte har tillgång till...

Men jag är tacksam för alla tips och råd!

[Jan Almqvist]

Men ca 1-2 gånger i minuten, så innehåller detta paket ett extra innehållsbyte (som oftast är 0). Det är det som är mitt problem.

Om felet kommer 1-2 gånger per minut och paketen består av 6 tecken som skickas varje sekund så verkar det ju finnas ett system.

(1/1,5) * 6 * 60 = 240.

Har du en mottagningsbuffert som är 256 tecken?

Kanske felaktig hantering av någon pekare när de slår runt?

Edit: Räknefel.

[Icecap]

cjonash: om du har DC-bias motstånden men slingan redan är terminerat korrekt ska du såklart inte terminera den ytterligare en gång!
DC-bias bör ge dig ett virtuellt nollpunkt men du kanske måste offsetta detta en aning!

[sodjan]

Om det är som Jan Almqvist föreslår (ingen dum idé) så skulle man kanske kunna
se något system i hur de extra nollorna roterar mellan de olika positionerna.
D.v.s. som en funktion av resten av buffertlängd / meddelandelängd.
Det borde alltså med andra ord inte vara helt slumpmässigt...

[cjonash]

Ja, det enda som skiljer min mjukvara mellan de två testen är ju just mottagningen av seriella bytes. Så det finns ju en risk (eller möjlighet) att det är där felet finns.
Därav min tanke om att bygga en enkel seriell generator som skickar kända data (snabbt).

Min läsbuffer är på 200 bytes - men det som krånglar till det lite är att det ju kommer annan data också (som inte har samma paketlängd) mellan de som jag har listat. Och de kommer oregelbundet (alltså inte en gång i sekunden). Vissa av de paketen finns inte med i det protokoll jag har, så jag kan heller inte se om de också innehåller "extra" data.

Men en test med en sekvens av helt kända data, borde snabbt kunna visa om det hela beror på att jag har kodat mottagningen fel. Det är en ringbuffer, så om det är fel där borde det kunna ge just den här sortens fel. MEN - eftersom jag också räknade antalet interrupts och jämförde med antalet faktiskt utlästa bytes (och de stämde), så är jag inte helt säker. Ett fel i buffern borde ha gjort att antalet lästa byte blev högre än antalet interrupts.