Svenska ElektronikForumet

Bygger din hantering av 9 bitar på att du ställer om UARTens paritet mellan Mark och Space under tiden som du tar emot ett paket?

Nej, den bygger på att jag har aktiverat 9-bits datalängd i UART. Vid interrupt läser man först den 9:e biten, därefter bytet med de första 8. Den läsningen nollställer automatiskt interruptflaggan. Dessa två byte (de första maskat så att bara den aktuella biten är kvar) sparas i min buffer som ett Word.

lillahuset skrev: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!

Men en kort störning bör väl ge FF eller liknande snarare än 00?

Däremot om störningen hänger ihop med läget på sinusformen på elnätets 50Hz ihop med något annat så kan det bli sådär.

Om sändutrustningen sänder data med väldigt jämna mellanrum och man skriver mottagningskoden så att man loggar klockslag med exakthet på enstaka millisekunder så bör detta gå att avgöra om man vill reda ut hur det ligger till. Du har väl ethernet vidare om jag förstått rätt - dundra ut inkommande data + klockslag rått som nån slags UDP eller liknande för teständamål, så kan du logga mängder av data att analysera.

Överlägset bäst för att felsöka är förstås att ansluta ett oscilloskop.

xxargs skrev:Prova att angripa problemet med galvaniskt isolerad RS485-krets där denna på dataledningssidan bara bryr sig om ena ledaren är över eller under den andra dataledarens nivå i trådparet för att spegla sin utgång på logiksidan och utan hänsyn vilken potential din logik-jord ligger på.

Om jag förstår rätt av tråden så tar bygget emot RS485 och sänder vidare ut på ethernet, och har lokal display och knappar. Om man undviker skärmade nätverkskablar och driver med en nätadapter som inte läcker så har man redan galvanisk isolation via ethernetinterfacet och nätadaptern.

Säkraste kortet för att få en nätadapter som inte läcker är oftast att använda en hederlig tung trafo.

Jag har svårt att tro på störning inuti själva paketet, nog borde det se ut såhär?
Edit: 7 tecken.

Precis, om sändaren sänder varje "paket" utan extra fördröjning mellan
varje tecken i paketen, så verkar det väldigt underligt med ett extra
tecken. Då skulle ju övriga tecken fördröjas på något sätt "på linjen".

Om det däremot var ett tecken i paketet som blev fel eller korrupt
så vore det naturligare, d.v.s utan att längden ändras.

Det var därför som jag misstänkte någon intern bugg i hanteringen
av mottaget data internt i Arduinon.

Sen var det väl något underligt också med att den mottagna checksumman
stämde överens ifall man antog att sändaren faktiskt sände noll-byten. Och
i så fall är det ju ingen "störning" utan faktiskt sänt!

Eller finns det fall där checksumman inte stämmer om man räknar med
noll-byten?

Sedan är det kanske inte helt utrett om det kanske är en helt naturlig
"feature" i det meddelande protokoll som används på linjen...

Hur viktigt är varje individuellt paket? Kan man inte bara kasta de
paket som har "fel" längd?

cjonash skrev:Nej, den bygger på att jag har aktiverat 9-bits datalängd i UART. Vid interrupt läser man först den 9:e biten, därefter bytet med de första 8. Den läsningen nollställer automatiskt interruptflaggan. Dessa två byte (de första maskat så att bara den aktuella biten är kvar) sparas i min buffer som ett Word.

Du är inte för snabb med att enabla interrupt så att du får ett nytt interrupt innan du har läst båda bytarna?

Interrupten aktiveras automatiskt när man läser dataregistret. Det är därför man måste läsa den 9:e biten först.

Att checksumman stämmer inte alltid när det blir fel. Men det händer att den gör det, och det beror på att checksumman är resultate av multiplikation. Dvs om ett byte, vilket som helst i paketet, är 0x00, så blir checksumman alltid 0x80. Och det är relativt ofta som den riktiga datan innehåller ett värde som är 0.

Det är inget bra att skippa paket, eftersom data (undantaget tiden) bara skickas vid förändring. Även med tiden blir det inget bra, eftersom det inte ser fint ut i Tv med en klocka som hoppar över sekunder...

Men jag ska försöka ikväll eller imorgon att testa min mottagningsrutin, för att se om det är där felet ligger.

> Och det är relativt ofta som den riktiga datan innehåller ett värde som är 0.

OK, så dina observationer ger att checksumman *inte* räknar med den extra
noll-byten. Bra, då är det ju inte sändaren som har lagt till extra tecknet, i alla
fall inte innan den beräknade checksumman.

Man skulle kunna göra ett förenklat testprogram som enbart läser in ett packet
i taget och kollar längd/checksumma utan din "roterande" buffert. D.v.s läs ett
packet och börja sedan direkt om från början av bufferten med nästa.

Jag hävdar fortfarande att det vore bra att logga klockslag med en upplösning på några dussin mikrosekunder, eller titta på signalen med oscilloskop. På så vis så kan du bättre avgöra vad som verkligen hände.


Vi ska väl inte helt säkert utgå från att den sändande enheten verkligen kör så snabbt som länken klarar. Det kan ju hända att den räknar checksumma on the fly och att det görs med inte så jättebra kod så att det blir en paus motsvarande några bitar mellan varje/vissa sända tecken. En sådan paus kan vara tillräcklig för att inrymma en spik som tolkas som startbit.

Men om det nu är så att det är störningar typ mycket kortare spik än en bit vid 57600bps som är problemet så bör man kunna lågpassfiltrera signalen något.

Jag upprepar: Oscilloskop! Att mäta (rätt) är att veta!

Därför lånade jag ut ett av mina oscilloskop till en kund som envisades med att gissa.

Ja visst. Med ett oscilloskop med "pre-trigger memory" och en extern
trigg-ingång kopplat till en pinne på AVR'en som skickar en trigg singnal
då ett felaktigt paket identifieras, så skulle man kunna fånga just det
paket på serie linan som gav upphov till den extra noll-byten...

Kräver lite setup av det hela och att man har ett oscilloskop med
rätt funktioner samt en mindre justering av AVR applikationen.

Nu har jag testat min seriella inläsning... Och givetvis så låg felet i den.

Jag har visserligen inte testat med den riktiga klockan (först imorgon skall jag ut på en produktion där det finns en sådan klocka), men jag satte upp en Arduino till som skickade samma data som klockan skall skicka, och samma fel uppstod. Lite oftare dock, eftersom nu kom ingen annan data emellan utan bara min "rena" tidsdata. Och eftersom de paketen är exakt lika långa så gick det ju snabbt att se kopplingen mellan extra bytes och bufferlängden.

Jag hade skrivit så här: Korrekt, och nu fungerande, kod skall vara: Ett enda litet "=" tecken gjorde hela skillnaden.

Två saker noterar jag då:
1) Sitt inte och programmera mikrokontrollers i en gymnastikhall full av högljudda skolungdomar (det påverkar koncentrationen en del...)
2) Krångla inte till felsökningen (jag borde givetvis gjort det här testet direkt, innan jag började misstänka hårdvaran)

Men igen, ett stort tack till alla tips och råd som ni har kommit med! Jag är mycket tacksam för dessa!

Imorgon blir som sagt ett nytt test i verkligheten - tanken är att klockan faktiskt skall generera tv-grafiken på sändningen imorgon, men det återstår väl fortfarande att se.
Därefter går projektet vidare med konstruktion av kretskort och låda, samt beställning av dessa.

"en gymnastikhall full av högljudda skolungdomar" låter som ett klassiskt copyparty

Det där med att ordna bra testmöjligheter är alltid bra och nog något de flesta av oss slarvar med...

Den här lilla kopplingen kommer att ansvara för att det blir en klocka i tvgrafiken ikväll: Under de första testerna idag så fungerade allt precis som det skulle. Så mycket enklare det blev att hantera protokollet när man faktiskt läser in data korrekt...
Att sedan mer än 80% av det som kommer i den seriella signalen inte finns dokumenterat, är en annan sak. Nu kan man i alla fall göra kvalificerade gissningar baserat på vad den riktiga klockan visar, och jag har hittat allt jag behöver för tvgrafiken.