Svenska ElektronikForumet

Jag har 3st DS18B20 som sitter på ett kort. När jag scannar dem med Micropython får jag följande:

bytearray(b'(\xec\x10\xf6\x03\x00\x00\xaa')
bytearray(b'((\x11\xf6\x03\x00\x00$')
bytearray(b'\x10\x81G/\x00\x08\x00\x02')

2st andra givare av samma typ ser ut så här med annat verktyg:

10.6DAAC7000800
10.ED432F000800

Obs inte samma givare som de tre första. "10." är givartyp resten är id för givaren.
Hur skall jag tolka \xec\x10\xf6\x03\x00\x00\xaa så kan läsa ut id för givarna? Jag prövat med olika endcode(), decode() och argument men inte fått ut något vettigt.

alla "vanliga" tecken är ju samma med ISO-latin1/15 och UTF8, så det borde ju inte påverka.

ID-numret står förmodligen lasergraverat på kretsen, väldigt smått. Läs av det och jämför med vad Du får ut för att se om den läser något, eller det bara är blaj som visas.

Du får iaf samma antal (åtta) bytes för alla tre sensorerna. Får du samma värden varje gång du kör programmet?

Kolla på datan som en hexdump istället, jobbigt att matcha tecken och hexkoder i samma sekvens.

Eh, första googleträffen

Each DS18B20 contains a unique ROM code that is 64-bits long. The first 8 bits are a 1-Wire family code (DS18B20 code is 28h). The next 48 bits are a unique serial number. The last 8 bits are a CRC of the first 56 bits.

28h = 0x28 = vänsterparentes i ASCII. Så de två första är DS18B20 iaf. Voila.

Ja, \x finns inte i den data du läser ut, det bara visas så av python att det inte är ett utskrivbart tecken.
De som är utskrivbara blir helt enkelt ett ascii-tecken.
Ska du skriva ut dem så får du se till att fixa så de presenteras i hex, om du vill ha det.

De tre blir således:

28ec10f6030000aa
282811f603000024
1081473F00080002

Tack, jag blev helt enkelt förvirrad av blandningen av ascii-tecken och hexvärden, som skrevs när det inte fanns något giltigt ascii-tecken.

Jag kan absolut ingenting om python, men om det går att cast:a variabeltyper så skulle jag cast:a den där bytearrayen till en 64-bitars integer, så har du dina 64 bitar och kan t.ex. skriva ut dem i hex-format eller vad du vill göra.

I pseudo-C så hade denna "bytearray" varit array char jox[8] och du hade kunnat skriva ut den med printf("%x",(int 64*)jox); (med reservation för alla syntaxfel jag säkert skrivit nu).

Jag får mecka lite i C. Jag behöver öva C.

Annars hade jag tänkt i python att söka efter \x och suga upp de två nästa hex-nuffrorna och spara dem Om inte \x så tänke jag att använda hex() och ord() för få ut en byte.
Ex hex(ord('$')))

Hm
Det är lite bökigt att parsa.
bytearray(b'((\x11\xf6\x03\x00\x00$')
Här tex kommer två (( efter varandra med ingen tecken-separator mellan ascii-tecknen. Men det går nog bra det är bara kombination \x om blir problem om det kommer för att sombolisera 2 acii-tecken och inte ett hex-värde.

Men detta känns som ett fult hack. Någon som har ett snyggare förslag?

prova print (rom.encode('hex'))

Fungerar perfekt! Tack! Inga problem med att ascii-tecken och ascii-tecken representerande hex-värden (\x..) är blandade. Dock fungerar detta (rom.encode('hex') bara för python2.
För python3 får man använda:Varför man bytt i python3 eller artskillnader mellan codecs och binascii har jag ingen aning om.

edit:
Hittade något annat spännade på resan.
tex rom='ErikÖ' kan man inte skriva i python2 men ok i python3. Detta även om det är inom en kommentar (#rom='ErikÖ'). Lustigt..

edit2:
guckrum: Jag får inte till något vettigt med hexdump

I Python3 är alla strängar unicode, så inte i Python2. Det var det du märkte med "ErikÖ". Att "kolla på datan som en hexdump" är precis det du gjort nu, ledsen att jag utrryckte mig otydligt.

Tänk på att kolla CRCer, det är viktigt i onewire. Förhoppningsvis har lagret som hämtar ID-srrängarna redan gjort det så du slipper.