10W Bitcoin miner mit 450GH/s für Raspberry Pi

[Mampf F. (mampf)]

Markus W. schrieb:
> 2024-04-21 12:27:30,268 - ERROR - Exception in RPC thread: script pubkey
> of our address not found

D.h. dass du nicht für dich selbst sondern für einen Pool minest, der 
dich dann "auszahlt".

Deine Adresse kommt quasi in der Coinbase Transaktion nicht vor.

In diesem Fall musst du "verify_solo" ausschalten.

[Markus W. (dl8mby)]

@Mampf,

ok und danke!
Werde es so versuchen.

PS.: ist Dein 0xaxe Repo schon soweit, dass man es Platinenmäßig
einsetzen kann, oder gibt es noch nachträgliche Mods, die noch 
ausstehen?

[Mampf F. (mampf)]

> PS.: ist Dein 0xaxe Repo schon soweit, dass man es Platinenmäßig
> einsetzen kann, oder gibt es noch nachträgliche Mods, die noch
> ausstehen?

Der aktuelle Stand sollte problemlos funktionieren.

Gerade wird noch gebastelt, um die teuren ADUM digital isolators durch 
günstigere OP Amps zu ersetzen, aber das ist schon eher "massieren".

Kannst loslegen :)

Werd im Repo dann noch Inbetriebnahme Tips einpflegen, beispielsweise 
kannst du auf dem 0xAxe ohne dicke 5V Power Supply die ASICs ohne 
Kühlung testen und verifizieren, ob die Chain geht, bevor du alles mit 
Kühlpaste vollschlonzt und einen Kühler draufschraubst.

Ist viel Wert sowas zu haben / zu wissen!

edit: würde empfehlen mit 1oz Innenlagen zu bestellen. Kann aber nicht 
sagen, ob das wirklich notwendig ist. Mein erster QAxe hatte 0,5oz und 
das hat genauso funktioniert. Der Strom durch die ASICs ist ja quasi der 
gleiche.

[Markus W. (dl8mby)]

@Mampf,

kannst Du mir schreiben, wo in der FW/SW das Abbruchkriterium
für die Temp. des Spannungsreglers von 70°C festgelegt ist.
Ich würde diesen Wert gerne auf 75° festlegen, da mein Aufbau
z.Z. meist um die 68°C hat und bei Spitzen die 70°-Grenze
übersteigt, was zum Abbruch des Miners führt.

Ist der Wert im Miner Python-Skript zu suchen, oder in Deiner FW?

Bis ich den QAXE mit einem weiteren Lüfter über den Fet's kühlen
kann wird es noch etwas dauern. Gehäuse ist noch in der Mache.

Ich musste jetzt die Taktrate von 485MHz auf 400MHz runter setzen
um über die Nacht zu kommen.

LG+Danke

Markus

[Markus W. (dl8mby)]

Habe gerade von Rene ein Gehäuse gedruckt bekommen
und den QAXE darin verbaut, siehe Anhang.

Habe noch mit der Konfiguration vom solo.ckpool.org
zu kämpfen. Bekomme die u.g. Fehler.
Im public-pool.io läuft der QAXE ohne Probleme.

Falls jemend was zur config.zml was sagen kann, dann
bitte schön.

debug_bm1366: false
verify_solo: false    (auch mit true ausprobiert)
miner: qaxe
#suggest_difficulty: 2048 (gesetzt und auch auskommentiert - keine Abhilfe)
#suggest_difficulty: 10000

qaxe:
  name: QAxe
  chips: 4
  fan_speed_1: 1.0
  fan_speed_2: 1.0
  asic_frequency: 450
  extranonce2_interval: 1.9
  serial_port_asic: "/dev/ttyACM0"
  serial_port_ctrl: "/dev/ttyACM1"

für die unterschiedlichen configs, bekomme ich die folgenden
Fehler:

btcmw@BTCMW:/dev/shm> grep ERR qaxe_20240423T142459.log
2024-04-23 14:25:25,037 - ERROR - Exception in RPC thread: not getting all rewards! 519568552 vs 530171991
2024-04-23 14:25:25,038 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:25:29,834 - ERROR - send failed: [Errno 9] Bad file descriptor
2024-04-23 14:25:30,391 - ERROR - Exception in RPC thread: not getting all rewards! 519568552 vs 530171991
2024-04-23 14:25:30,391 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:25:35,734 - ERROR - Exception in RPC thread: not getting all rewards! 519568552 vs 530171991
2024-04-23 14:25:35,735 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:25:41,078 - ERROR - Exception in RPC thread: not getting all rewards! 519568552 vs 530171991
2024-04-23 14:25:41,078 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:25:46,428 - ERROR - Exception in RPC thread: not getting all rewards! 524294632 vs 534994522
2024-04-23 14:25:46,428 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:25:51,764 - ERROR - Exception in RPC thread: not getting all rewards! 524294632 vs 534994522
2024-04-23 14:25:51,764 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:25:57,097 - ERROR - Exception in RPC thread: not getting all rewards! 524294632 vs 534994522
2024-04-23 14:25:57,097 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:26:02,428 - ERROR - Exception in RPC thread: not getting all rewards! 524294632 vs 534994522
2024-04-23 14:26:02,429 - ERROR - error flag set ... ending handle_incoming_rpc thread

oder

btcmw@BTCMW:/dev/shm> grep ERR qaxe_20240423T142828.log
2024-04-23 14:28:53,484 - ERROR - Exception in RPC thread: tcp connection closed ...
2024-04-23 14:28:53,485 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:28:58,718 - ERROR - Exception in RPC thread: tcp connection closed ...
2024-04-23 14:28:58,718 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:29:03,940 - ERROR - Exception in RPC thread: tcp connection closed ...
2024-04-23 14:29:03,940 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:29:09,168 - ERROR - Exception in RPC thread: tcp connection closed ...
2024-04-23 14:29:09,168 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:29:14,394 - ERROR - Exception in RPC thread: tcp connection closed ...
2024-04-23 14:29:14,394 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:29:19,618 - ERROR - Exception in RPC thread: tcp connection closed ...
2024-04-23 14:29:19,618 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:29:24,844 - ERROR - Exception in RPC thread: tcp connection closed ...
2024-04-23 14:29:24,845 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:29:30,074 - ERROR - Exception in RPC thread: tcp connection closed ...
2024-04-23 14:29:30,074 - ERROR - error flag set ... ending handle_incoming_rpc thread
2024-04-23 14:29:35,295 - ERROR - Exception in RPC thread: tcp connection closed ...
2024-04-23 14:29:35,296 - ERROR - error flag set ... ending handle_incoming_rpc thread

was bedeutet die u.g. Meldung?

2024-04-23 14:39:24,064 - INFO - cleaning jobs ...
2024-04-23 14:39:24,064 - INFO - starting new job 64851638000eaaba
2024-04-23 14:39:24,065 - ERROR - Exception in RPC thread: not getting all rewards! 572577967 vs 584263231
2024-04-23 14:39:24,065 - ERROR - error flag set ... ending handle_incoming_rpc thread

Danke für sachdienliche Hinweise.

Markus

[Mampf F. (mampf)]

Markus W. schrieb:
> Ist der Wert im Miner Python-Skript zu suchen, oder in Deiner FW?

Das ist an dieser Stelle:

https://github.com/shufps/piaxe-miner/blob/master/piaxe/miner.py#L718

Sollte man vlt mal konfigurierbar machen 🤔

Markus W. schrieb:
> Habe noch mit der Konfiguration vom solo.ckpool.org
> zu kämpfen. Bekomme die u.g. Fehler.
> Im public-pool.io läuft der QAXE ohne Probleme.

Muss ich mal mit ckpool testen, hatte noch keine Zeit dafür.

[Markus W. (dl8mby)]

@Mampf,

danke habe ich nun angepasst.

if temp["temp"][i] > 75.0:

Markus

[Markus W. (dl8mby)]

@Mampf

zur Info

>Hmm, vlt sollte ich das irgendwie anders machen, damit man durch die
>0-Werte nicht verunsichert wird

2024-04-26 08:11:23,453 - INFO - temperature and voltage: {'temp': [28.375, 58.875, 0, 0]}


L#335 .../piaxe/miner.py
def read_temperature_and_voltage(self):

      return {
                "temp": [status.temp1 * 0.0625, status.temp2 * 0.0625, 0, 0],
                #"voltage": [0, 0, 0, 0],  <== disable line 335 to disable voltage output
            }

LG
Markus

[Mampf F. (mampf)]

Markus W. schrieb:
> zur Info

Das ist keine besonders saubere Lösung, weil man dann Hardware-Varianten 
hat, die unterschiedliche Results zurückliefern und es wird an ein paar 
Stellen davon ausgegangen, dass es immer ein Array mit 4 Elementen ist.

In einem Arbeits-Branch hab ich die 0 Werte durch "None" ersetzt, ist 
evtl weniger verwirrend^^

Könnte ich mal in meinen Main Branch mergen, support für den BM1368 
kommt dann quasi auch dazu.

[Markus W. (dl8mby)]

@Mampf,

sauber wollte ich es nicht sofort machen, sondern 'quick and dirty'
Für mich passt es soweit. War ein Hüftschuß heute morgen.
Wo die config.yml gelesen wird habe ich nicht im einzelnen eruiert.
Sollte das Wochenende es hergeben, dann versuche ich mich daran.
Du kannst es ja dann ins git übernehmen, sofern Dir mein Ansatz
zusagt.

LG
Markus

PS.: gibt es was Neues zum solo.ckpool.org?

[Roland (r_fischer)]

@Markus, ich bin noch da, hatte nur keine Zeit. Gehäuse sende ich 
hoffentlich Morgen raus.

Zitat:
was bedeutet die u.g. Meldung?
2024-04-23 14:39:24,064 - INFO - cleaning jobs ...
2024-04-23 14:39:24,064 - INFO - starting new job 64851638000eaaba
2024-04-23 14:39:24,065 - ERROR - Exception in RPC thread: not getting 
all rewards! 572577967 vs 584263231
2024-04-23 14:39:24,065 - ERROR - error flag set ... ending 
handle_incoming_rpc thread
Danke für sachdienliche Hinweise.
Zitat Ende

Das kommt daher das wenn du auf dem solo.ckpool minest, der Reward 
geteilt wird. 2% gehen an den Pool, der Rest + Fees für dich.
Du bist entweder im echten solo mode, oder der Code berücksichtigt das 
nicht das es zwei Output Adressen gibt.

Die Adresse vom solo.ckpool ist 
bc1q28kkr5hk4gnqe3evma6runjrd2pvqyp8fpwfzu
Die steht zuerst im script. Deine Adresse bekommt dann den Rest 98%.

Du kannst dir das mal im btc explorer Ansehen:
https://explorer.btc.com/de/btc/block/841286
Das war der Block der gestern im solo.ckpool gefunden wurde.

Roland

[Markus W. (dl8mby)]

Hallo Roland,

danke für den Hinweis zum solo.ckpool.org

Im Miner gibt es nur einen Parameter für
den user, der der öffentlichen btc Adr.
entspricht.

Ich bin noch nicht tief in der Materie drin
um die btc api von pools zu verstehen.

Hoffe bald diese Wissenslücke zu stopfen.

Gerade nehme ich den zweiten Qaxe in Betrieb.
Zickt noch etwas rum, aber ich hoffe es heute
Abend noch hin zu bekommen.

LG
Markus

[Markus W. (dl8mby)]

Hallo Mampf,

ich krieg einen Vogel.
Wollte den zweiten QAXE flashen (mit dem Binary, welches
ich schon in den ersten QAXE übertragen hatte)

Auch ein Neubau der FW hat nicht geholfen.

2024-04-29 22:21:48,612 - DEBUG - rx len: b'\x02'
2024-04-29 22:21:48,612 - DEBUG - <- 0802
2024-04-29 22:21:54,113 - DEBUG - -> 55aa510900a49000ffff1c
2024-04-29 22:21:54,114 - DEBUG - -> 55aa510900a49000ffff1c
2024-04-29 22:21:54,115 - DEBUG - -> 55aa510900a49000ffff1c
2024-04-29 22:21:54,115 - DEBUG - -> 55aa520500000a
2024-04-29 22:21:55,117 - DEBUG - -> 55aa5305000003
2024-04-29 22:21:55,118 - ERROR - Uncaught exception
Traceback (most recent call last):
  File "/dev/shm/qaxe-miner-mw-py-env/./pyminer.py", line 566, in <module>
    qaxeMiner.init()
  File "/dev/shm/qaxe-miner-mw-py-env/qaxe/miner.py", line 293, in init
    chip_counter = bm1366.init(self.hardware.get_asic_frequency(), self.hardware.get_chip_count(), chips_enabled)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/dev/shm/qaxe-miner-mw-py-env/qaxe/bm1366.py", line 310, in init
    return send_init(frequency, expected, chips_enabled)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/dev/shm/qaxe-miner-mw-py-env/qaxe/bm1366.py", line 257, in send_init
    raise Exception(f"chips mismatch. expected: {expected}, actual: {chip_counter}")
Exception: chips mismatch. expected: 4, actual: 0

und schon wieder bekomme ich den selben Fehler, wie beim
ersten mal.

DEFMT_LOG=info cargo objcopy --release -- -O binary qaxe-fw-L151C8.bin
   Compiling embassy-stm32l1-examples v0.1.0 (/dev/shm/qaxe/firmware/fw-L151C8)
    Finished release [optimized + debuginfo] target(s) in 1.17s

>st-flash --connect-under-reset write /dev/shm/qaxe/firmware/fw-L151C8/qaxe-fw-L151C8.bin 0x8000000
st-flash 1.8.0-13-g40ee5f4
2024-04-29T22:18:02 WARN common.c: NRST is not connected
2024-04-29T22:18:02 INFO common.c: STM32L1xx_Cat_2: 32 KiB SRAM, 64 KiB flash in at least 256 byte pages.
file /dev/shm/qaxe/firmware/fw-L151C8/qaxe-fw-L151C8.bin md5 checksum: 75984add1d8269e8a991796ccf7c184, stlink checksum: 0x005a004d
2024-04-29T22:18:02 INFO common_flash.c: Attempting to write 57264 (0xdfb0) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8000000 erased (size: 0x100)
-> Flash page at 0x8000100 erased (size: 0x100)
...
-> Flash page at 0x800de00 erased (size: 0x100)
-> Flash page at 0x800df00 erased (size: 0x100)

2024-04-29T22:18:03 INFO flash_loader.c: Starting Flash write for L0
2024-04-29T22:18:03 INFO flash_loader.c: Successfully loaded flash loader in sram
2024-04-29T22:18:03 INFO flash_loader.c: Clear DFSR
  1/447 halfpages written
  2/447 halfpages written
...
446/447 halfpages written
447/447 halfpages written

2024-04-29T22:18:12 INFO common_flash.c: Starting verification of write complete
2024-04-29T22:18:13 INFO common_flash.c: Flash written and verified! jolly good!

Hast Du so was ähnliches bei anderen qaxe bemerkt?

Im Anhang mein FW bin. Hast Du die Möglichkeit es mit Deiner FW
zu vergleichen?

Markus

[Mampf F. (mampf)]

Markus W. schrieb:
> und schon wieder bekomme ich den selben Fehler, wie beim
> ersten mal.

Nö ist nicht der selbe Fehler, du bekommst garkeine Antwort von den 
ASICs.

Bei deinem Problem zuvor war die Antwort "nur" verstümmelt.

Die Firmaware passt sicherlich, das wurde richtig als .bin exportiert.

Da musst du evtl nochmal ASICs nachlöten 🙈

Oder Sachen wie 1,8V und 0,8V checken, die Level-Shifter prüfen und 
sowas

[Markus W. (dl8mby)]

Ich werde am WE den dritten QAXE in Betrieb nehmen
und mal schauen, ob dieser nach dem Flashen sofort
anläuft. Wenn ja, dann weiß ich zumindest, dass ich
an meiner Rust-Installation keinen Wurm habe.
Ich habe nämlich zwischenzeitlich bei meinem Rolling
OS Release einen Update gemacht, so daß ich nicht
ausschließen kann, dass da nicht was faul ist.

Der Miner bekommt in der ASIC-Prüfprocedure ein None
zurück, soweit konnte ich den Fehler bereits eingrenzen.
Auch habe ich diese Meldung in die Debug-Ausgabe eingebaut,
damit man das im Log auch findet.

def count_asic_chips():
    send_BM1366(TYPE_CMD | GROUP_ALL | CMD_READ, [0x00, 0x00])

    chip_counter = 0
    while True:
        data = serial_rx_func(11, 1000)

        if data is None:
            logging.debug("Initializing BM1366 => count_asic_chips() serial_rx_func() returns None value!")
            break

        # only count chip id responses
        if "aa5513660000" not in binascii.hexlify(data).decode('utf8'):
            continue

        chip_counter += 1

    send_BM1366(TYPE_CMD | GROUP_ALL | CMD_INACTIVE, [0x00, 0x00])

    return chip_counter

Melde mich am WE wieder.

Markus


PS.: serial_rx_func(11, 1000) ich nehme an die 1000 sind ein Timeout in 
ms?

[Mampf F. (mampf)]

Markus W. schrieb:
> PS.: serial_rx_func(11, 1000) ich nehme an die 1000 sind ein Timeout in
> ms?

Jap genau, wenn für 1s keine chip ID responses mehr kommen, nimmt man 
an, es kommen keine weiteren mehr.

[Markus W. (dl8mby)]

Kleiner Statusupdate,

nachdem ich heute QAXE#3 mit der FW in Betrieb nehmen konnte,
weiß ich, dass meine RUST Entwicklerumgebung soweit ok ist.
D.h. QAXE#2 hat noch ein Aufbauproblem.

Jetzt muss ich die Platine sichten und nach Brücken oder anderen
Fehlern durchsuchen.

Die Spannungen passen soweit. AM Wochenende sehe ich mir die
seriellen Signale zu den ASICs an, ob sie richtig durchgeschleift
werden.

Platine vier ist auch schon in Wartestellung, da fehlen mir nur
noch die ASICs. Falls jemand welche günstig (d.h. <15€/St.,
 BM1366 AL od. AG) abzugeben hat, dann bitte eine PM an mich.

Markus