Buggfix Plus
Aktuellt datum och tid: 17.36 2020-03-31

Alla tidsangivelser är UTC + 1 timme




Svara på tråd  [ 103 inlägg ]  Gå till sida Föregående  1, 2, 3, 4, 5, 6, 7  Nästa
Författare Meddelande
InläggPostat: 12.46 2016-02-01 
Användarvisningsbild

Blev medlem: 19.48 2013-10-01
Inlägg: 1160
Ort: Orust
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?


Upp
 Profil  
 
InläggPostat: 00.20 2016-02-02 

Blev medlem: 07.53 2011-05-20
Inlägg: 591
Ort: Göteborg
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.


Upp
 Profil  
 
InläggPostat: 01.25 2016-02-02 

Blev medlem: 21.19 2009-05-06
Inlägg: 7342
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.


Upp
 Profil  
 
InläggPostat: 01.27 2016-02-02 

Blev medlem: 21.19 2009-05-06
Inlägg: 7342
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.


Upp
 Profil  
 
InläggPostat: 08.37 2016-02-02 
Användarvisningsbild

Blev medlem: 19.48 2013-10-01
Inlägg: 1160
Ort: Orust
Jag har svårt att tro på störning inuti själva paketet, nog borde det se ut såhär?

Kod: [Expandera/Minimera] [Hämta] (Untitled.txt)

¯¯¯_012345678S_012345678S_012345678S_012345678S_012345678S_012345678S_012345678S¯¯¯

  t=0        190        380        570        760        950       1140       1330 us

    ¯ = vila mellan tecken, hög.
    _ = startbit, låg.
0...8 = databitar, låg eller hög
    S = stoppbit, hög



Edit: 7 tecken.


Upp
 Profil  
 
InläggPostat: 12.46 2016-02-02 
EF Sponsor
Användarvisningsbild

Blev medlem: 15.29 2005-05-10
Inlägg: 38361
Ort: Söderköping
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?


Upp
 Profil  
 
InläggPostat: 15.18 2016-02-02 
Användarvisningsbild

Blev medlem: 19.48 2013-10-01
Inlägg: 1160
Ort: Orust
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?


Upp
 Profil  
 
InläggPostat: 21.46 2016-02-02 

Blev medlem: 07.53 2011-05-20
Inlägg: 591
Ort: Göteborg
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.


Upp
 Profil  
 
InläggPostat: 23.18 2016-02-02 
EF Sponsor
Användarvisningsbild

Blev medlem: 15.29 2005-05-10
Inlägg: 38361
Ort: Söderköping
> 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.


Upp
 Profil  
 
InläggPostat: 23.48 2016-02-02 

Blev medlem: 21.19 2009-05-06
Inlägg: 7342
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!


Upp
 Profil  
 
InläggPostat: 00.01 2016-02-03 
Gått bort
Användarvisningsbild

Blev medlem: 07.13 2008-07-03
Inlägg: 13969
Ort: Norrköping
Därför lånade jag ut ett av mina oscilloskop till en kund som envisades med att gissa.


Upp
 Profil  
 
InläggPostat: 00.19 2016-02-03 
EF Sponsor
Användarvisningsbild

Blev medlem: 15.29 2005-05-10
Inlägg: 38361
Ort: Söderköping
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.


Upp
 Profil  
 
InläggPostat: 03.44 2016-02-09 

Blev medlem: 07.53 2011-05-20
Inlägg: 591
Ort: Göteborg
Nu har jag testat min seriella inläsning... Och givetvis så låg felet i den. :cry:

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:
Kod: [Expandera/Minimera] [Hämta] (Untitled.txt)
if (serialBufferStart > SERIAL_BUFFER_SIZE) serialBufferStart = 0;

Korrekt, och nu fungerande, kod skall vara:
Kod: [Expandera/Minimera] [Hämta] (Untitled.txt)
if (serialBufferStart >= SERIAL_BUFFER_SIZE) serialBufferStart = 0;


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! :bravo: :tumupp:

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.


Upp
 Profil  
 
InläggPostat: 14.04 2016-02-09 

Blev medlem: 21.19 2009-05-06
Inlägg: 7342
"en gymnastikhall full av högljudda skolungdomar" låter som ett klassiskt copyparty :mrgreen:

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


Upp
 Profil  
 
InläggPostat: 15.50 2016-02-09 

Blev medlem: 07.53 2011-05-20
Inlägg: 591
Ort: Göteborg
Den här lilla kopplingen kommer att ansvara för att det blir en klocka i tvgrafiken ikväll: :)
Bilaga:
produktion.jpg


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.


Logga in för att visa de filer som bifogats till detta inlägg.


Upp
 Profil  
 
Visa inlägg nyare än:  Sortera efter  
Svara på tråd  [ 103 inlägg ]  Gå till sida Föregående  1, 2, 3, 4, 5, 6, 7  Nästa

Alla tidsangivelser är UTC + 1 timme


Vilka är online

Användare som besöker denna kategori: larsolsson och 20 gäster


Du kan inte skapa nya trådar i denna kategori
Du kan inte svara på trådar i denna kategori
Du kan inte redigera dina inlägg i denna kategori
Du kan inte ta bort dina inlägg i denna kategori
Du kan inte bifoga filer i denna kategori

Sök efter:
Hoppa till:  
   
Drivs av phpBB® Forum Software © phpBB Group
Swedish translation by Peetra & phpBB Sweden © 2006-2010