Svenska ElektronikForumet

Tjena.

Jag har lite problem med att köra min rc522 rfidmodul till en arduino via en cat5e-kabel. När jag kopplar rfid-modulen till min duemilanove på ett kopplingsdäck funkar allt som det ska men när jag kopplar genom min setup så funkar det inte.

Jag har modulen kopplad till en RJ45-hona som sen ska genom en cat-kabel (ca 1m) till arduinon. Så här ser det ut från rfid-modulen:
https://ibb.co/qM55gQv

och så här ser det ut till arduinon:
https://ibb.co/FbS55Nq

Som man kan se så har jag temporärt kopplat allt till en adruino med hjälp av kopplingstrådar men allt ska lödas på en teensy 2++ när jag väl fått det att funka.
För tillfället kommer 3.3v och gnd från en teensy lc. Det är lite dumt kanske men jag lödde fast dem innan jag såg att teensy lc och rc522 inte är kompatibla, men det borde inte skapa problem väl?

Problemet:
När jag kör dumpinfo-exemplet från detta bibliotek: https://github.com/miguelbalboa/rfid så händer inget när jag blippar taggar. Om jag kopplar bort modulen och trycker ner den i ett kopplingsdäck och tar kopplingstrådarna från arduinon och kopplar dem i kopplingsdäcket så funkar det kanon, det är när jag kör genom min setup som det inte händer något. Det konstiga är att jag inte får någon error i serial monitor när jag kör scriptet. Tar jag ur någon av sladdarna (förutom MOSI av nån anledning) står det typ "connection error" i serial monitor när jag kör min setup. Jag har kollat continuity med multimetern med ena mätsladden på rfid-modulen och andra på arduinon (så att den testar genom cat6e-kabeln och alla molex och rj45 osv) och allt verkar ge bra signal så det är ingen koppling som släppt eller så verkar det som.

Nån som har nån idé om vad det kan vara? Jag kör exakt samma kod och pins på arduinon när det funkar på kopplingsdäcket. Cat-kablar är väl gjorda för att skicka data långa sträckor?

Jo, Cat 6 är gjord för snabba signaler. Men hur dessa signaler ser ut spelar stor roll för hur snabbt man kan köra. Signalerna på en nätverkskabel är differentiella och har låg amplitud (1V peak-peak).

Signalnamnet tyder på att det är SPI som RFID läsaren pratar med. SPI är gjort för att vara snabbt (inte lika snabbt som nätverket), men bara mellan två kretsar på samma kretskort. Signalernas amplitud är på logiknivå (typisk 3.3 eller 5 V) och är inte differentiella. Måste du ändå få din RFID läsare att fungera på en lång kabel så tycker jag att du ska börja med att prova:

1. Montera en avkopplingskondensator (100n gärna keramisk) över matningen i ändan på kabeln där RFID läsaren sitter
2. Sänk SPI klockhastigheten

Lycka till!

anders_bzn vilken klippa du är som hjälper mig, uppskattas verkligen!

Utan att ta för mycket av din tid men jag är inte nån stjärna på ellära men vill lära mig mer och har därför några följdfrågor:
Vad händer med SPI-signalen när man skickar den genon en kabel gjord för differentiella signaler? Är det där problemet uppstår eller är det helt enkelt avståndet som ställer till det? Skulle en kortare nätverkskabel/uppgradering till cat6-kabel hjälpa?

Ang avkopplingskondensator: Har jag förstått det hela rätt att kondensatorn i detta fall blir en liten buffert när RFID-läsaren behöver ström snabbare än min nuvarande strömkälla kan bidra med?

Ang SPI klockhastigheten: Är det något man kan göra i kod eller behövs det en komponent? På vilket sätt kan det hjälpa om nätverkskabeln kan hantera snabbare signaler än SPI?

Tack igen för hjälpen, jag håller nämligen på med en julklapp där RFID-modulen ska flyttas till olika tags (därav sladden) och jag blev lite rädd att jag inte skulle hinna klart med den när hela projektet helt plötsligt tvärstannade. Men nu har jag återfått hoppet

I MFRC522.h finns
Ändra till typ SPI_CLOCK_DIV32 så får du ordentligt lägre klockfrekvens, se om det hjälper.

Klas-Kenny, tack så mycket!!
Ska kolla så fort jag kommer hem och se om det hjälper!

HIttade ett dokument från TI om att köra SPI över långa transmissionsledningar.
http://www.ti.com/lit/an/slyt441/slyt441.pdf
Det kanske kan vara av intresse.

Tjena!
vaxfan - tack så mycket men tyvärr är det där dokumentet så långt över mitt huvud att jag inte ens vet hur jag kan använda mig av infon

Jag har nu provat att ändra till lägre klockfrekvens som ni föreslog men det fungerade inte heller. Jag provade 32, 16 och 8 för att vara på den säkra sidan men det blev ingen skillnad vad jag kunde se.

En intressant sak jag såg är att när den är kopplad i min setup så står det att firmware version är unknown men inget om att jag kopplat fel. När jag kör via kontaktblocket står det firmware version v2.0. Drar jag ur en kabel så frågar den om jag kopplat något fel. Så det verkar som att den får tillräckligt med info/respons för att inte trigga kopplingsmeddelandet men inte nog för att veta firmware version eller kunna detektera taggen.
https://ibb.co/r3V8tnP

Jag ska prova med en kondensator också men har ingen lämplig hemma (har bara 100uF) så ska jag prova att köpa en kortare cat6-kabel och se om det kan hjälpa. Alla tips är hjärtligt välkomna under tiden!

Hur strömförsörjer du Arduino? Rfid läsaren matar du från annat kort sa du, men har du gemensam jord?

Prova den där 100u kondensatron, inte optimal, men bättre än ingen.

Lösningen i appnoten är ju kanon, den löser problemet och gör om SPI till något eget differentiellt.

Sedan är saken är ju att om flankerna är branta och data hastigheten är hög så är ju sladden inte en sladd längre utan en transmissionsledning. Då uppstår fenomen som gör att signalen inte ser likadan ut efter att den gått i kabeln. Man kan till exempel få reflektioner vilket gör att man får klockringningar, dvs att en klockpuls får överslängar så att det klockas ut två bitar istället för en.

Börja med att koppla en avkopplingskondensaor mellan jord och matningen vi RFID läsaren. Skulle inte detta fungera skulle jag prova att sätta serieterminering i mottagarändan på de snabba signalerna. Ett vanlig 22 ohms motstånd i serie!

För CLK MOSI vid läsaren och vid processorn för MISO.

Fungerar detta inte så får man nog göra något differentiellt!

ludwig_van skrev:Tjena!


Jag har nu provat att ändra till lägre klockfrekvens som ni föreslog men det fungerade inte heller. Jag provade 32, 16 och 8 för att vara på den säkra sidan men det blev ingen skillnad vad jag kunde se.

Har du verifierat att klockfrekvensen verkligen stegat ned med oscilloskop eller liknande, ibland måste man kolla rent fysiskt innan man tex. inser att man bara ändrat i en kommentars-rad i koden och inte den delen som faktiskt gör något... jag säger inte att det är så men 'fysisk' återkoppling är bra....

---

Sedan var det riktiga nystan till dina uttag, sådant får det att höras över mellan ledarna och ingen riktigt bra koll på jordplan etc.

Tvinna åtminstone signalledare och dess återledare i par och att ledarna inom paret är lika långa.

En regel att hålla sig till när man hanterar signaler är alltid ett par som består av själva signalen och med den kabeln tvinnat signalåterledare (i obalanserade system som TTL och CMOS-logik är det jord, i balanserad system så är det 'minus' signalen som alltid är motsatsen/spegelbilden till signalledaren i amplitud ) - det finns inget som heter gemensam gjord när man hanterar högre frekvenser - utan det är alltid paret en signalledare och en signalåterledare oavsett om vi pratar om obalanserad eller balanserad signalering.

Det betyder att på en CAT6 så kan du bara koppla 4 signalledare då den andre ledaren i paret för varje signal är signalåterledaren för just den signalen och det spelar ingen roll att alla signalåterledare i slutändan går till samma jordpunkt i respektive ända - signalåterledarna måste fortfarande finnas med varje signalledare för att kurv/pulsformen skall förvanskas så lite det går medans det vandrar fram i ledarparet.

Har du öppnad upp en CAT6-kabel så kanske du strax inser vad du behöver göra åt dina skabo i ändarna.

---

Man kan säga att ledarparen mellan varandra kan vikas ifrån varandra - men man skall aldrig dela upp ledarna i själva paret, utan de alltid skall hållas ihop hela vägen utan större glipor mellan ledarna och tills de i princip går in på sändar/mottagarkretsens IC-pinne och återledarparet skall i princip lödas in i jordpunkten bredvid signalpinnen. Hur strikt man behöver vara med detta beror på frekvensen/datatakten, men ju högre upp, ju mer noga.

En modern dators PCIe-ledare är ett ledarpar - det måste vara så när det är GHz i datatakt på ledaren och varje 'bit' har en utsträckning på bara några cm efter ledarlängden, det betyder också att alla kortkontakter etc. är utformat impedansmässigt för att det inte skall skapa för mycket reflexer etc.


Motorolas SPI-system är inte ett matchat signaleringssytem, förmodligen först TTL-nivåer, sedan HC-logik-nivåer på 5 Volt och idag motsvarande på 3.3 Volt

TTL var inte tänkt att användas i längre sträckors transmissionssystem och inte efterföljarna heller då ledarlängden skulle hållas kort.

Detta gör att TTL-systemen är svåra att impedansmatcha då man inte ens tänkte i dom banorna

Ett system som hantera detta ganska elegant fast man var låst till 'TTL-nivåers' detektionsgränser var det man använde i SCSI med en speciell terminator som var kopplad med 220 Ohm mot VCC och 330 Ohm mot VSS/GND i var ända av kabelns och signal-kabeln kopplad i mitten i motståndsbryggan (lite som termineringsmotstånden i var ända vid användande av RS485 - och av samma orsak)- det gav AC-mässigt en impedans på 132 Ohm - inte allt för långt ifrån karaktäristiska impedansen på en bandkabel (~100-110 Ohm - samma i CAT-kabel)

Med asymmetrin 220/330 Ohm terminatorn så fick man en spänningsdelning med mitten som landade på ca 3 Volt - klart över TTL-världens 2.5 Volts krav för att räknas som '1'

För att dra till '0' så hade man open collektor (senare open drain i CMOS-världen) på ledningen som sänkte till spänning under 0.8 Volt för att vara godkänd TTL '0'.

Med denna teknik kunde man jacka in flera enheter samtidigt på samma 'bus' med TTL-ingångar som 'lyssnare' och open collektor drivers som sänkte när man skulle 'prata'. I och med open collektor så konkurerade man inte om ström eller tvingade i ström i varandra (som totem-pole utgångar på TTL-kretsar och CMOS-utgångar kan göra när ena utgången försöker driva nivån låg och den andre på samma ledare försöker driva utgången hög - samtidigt...) eftersom alla var högimpediva när de skulle vara 'tysta' - det blev ingen 'skada' om mer än en utgång drog samtidigt efter som signalnivå gick till nära 0 Vol oavsett om det bara var en eller flera samtidigt försökte sänka nivån.


På det sättet fick Alan Shugart (som hade företaget bakom SASI som sedemera blev SCSI) en digital överföring i hög takt som klarade minst 10 meter kabel utan för mycket ringningar och med tillräcklig säkerhet i dataöverföring med billiga komponenter från TTL-familjen och samtidigt kunna plugga i upp till 8 enheter parallellt på samman bus (senare 16 med SCSI wide)


Jag är dock inte insatt i hur 3.3V logiken har sina gränser för '0' respektive '1', ej om driverkretsarna i SPI-kretsarna är av open collektor-typ (önskade versionen av drivsteg) eller om de tvingande driver högt eller lågt (tyvärr gör dom nog det) - har man problem med drivande utgång som antingen tvingar spänningen upp mot VCC eller mot VSS/GND och ej är högimpedivt så kan man prova med en bufferkrets som 74HC07 med open collector eller open drain-utgång på varje utgång - Ja, om man funderar på byggsätt på samma sätt som SCSI-bussen med spänningsdelar-termineringar i ändarna.


När man inte tänkte i dom lösningar som ovan utan drev direkt med en drivare och en ingång så fick man en lösning som sedemera blev känd som PATA (och man gjorde samma misstag med USB1 och USB1.1...) ja, ju den 80-trådars breda och korta bandkabeln mellan modekortet och hårddisken och alltid var lite för kort för att kunna läggas undan snyggt - och förlängde man den, så slutade skiten att fungera eller vart fall börja ge för många fel i dataöverföringen mellan hårddisk och moderkort för att det skulle vara hälsosamt inom företagsvärlden ... med SCSI kunde man köra 10 meter - och dubbla datatakten per dataledare (SCSI var till en början bara 8 DATA-ledare medans PATA hade 16 dataledare)

bobobo skrev:har du gemensam jord?

Enligt bilderna i första inlägget har han inte det. (2:a från vänster bortre raden är gnd) Ganska troligt att det är felet.

Tjena, tack för alla svar!

Jag har fått min teensy 2++ nu så jag kommer köra allt genom den ikl 3.3v och jord Jag tror däremot inte att det är problemet i det här fallet då jag provat att köra så på kopplingsdäcket utan att det fungerade.

xxargs - Låter som en bra idé att köra twisted pairs, ska tvinna och se till att det är samma längd på alla kablar. Jag har inget oscilloskop hemma men om de "enkla" fixarna inte fungerar, dvs de som jag förstår mig på någorlunda, ska jag kolla om någon vänlig själ på makerspace sthlm kan förbarma sig över mig några timmar och där har de oscilloskop och andra spännande instrument. Tack för all info, jag har lärt mig mycket!

Jag ska som sagt testa lite mer i helgen och försöka eliminera så mycket av slarvet och funkar inte det får jag kolla om nån kan sitta med och hjälpa mig. Jag trodde att det bara skulle vara att koppa och köra men verkar tagit mig lite vatten över huvudet så jag är väldigt tacksam för alla tips och hjälp!

Alla har vi gjort nystan av sladdarna och anslutningar i börja på elektronik-konstruktions-karrären - det är ett naturligt steg sas. och det märks inte när svängningstakten/datahastigheten är långsam - Men är man uppemot MHz och högre så blir det allt viktigare att tänka 'transmissionsledarpar' för alla ledare som skakar data i hög takt om det skall vara begripligt i mottagaren i andra ändan samt inte störa grann-dataledarna mer än nödvändigt.

idag verkar det har blivit standard med 1-par (USB1,2), 2-par (USB3, SATA, SAS), 4 par (PCIe/NVMe, SAS med dual-port, förmodligen också framtida SATA express - tror att det finns dual-port på denna definierad också, med stiften på andra sidan gentemot dual-port-stiften för SAS i klacken mellan data och spänningsförsörjning (klacken finns ej på en standard SATA med separat spännings och datakontakt)

Varför inte köra pwr+rs 485 och placera NFC+arduinon på samma ställe?

Tjena!
Jag tänkte bara komma med en liten uppdatering.
Jag tvinnade kablarna enligt förslag och var noga med att löda så att de tvinnade paren höll sig tvinnade genom cat5-kabeln och helt plötsligt funkade allt som jag tänkt mig. Jag kör fortfarande med min arduino på kopplingsdäck då jag inte hade komponenter för att fixa en spänningsregulator så jag får ut 3.3v från teensy ++2.0 så jag vill inte ropa hej ännu men skulle det inte funka med teensyn så kan jag i värsta fall köra arduinon och bli klar till jul.

Grymt tack till alla som hjälpte till och kom med info och tips! Även om det i slutändan var kablarna som ställde till det så har jag lärt mig mycket av alla inlägg.