For me it worked with the old Github Repository on Raspberry Pi 5 with latest Pi OS 64bit:

git clone -b r606 https://github.com/vthoang/cgminer.git

and the above listed Build commands
Greetings Olga

I just noticed that there are slight deviations (about half a minute) from the timestamps my cgminer reports from the ones on Blockchain Explorers like "BTC.com".
My time settings should be fine, just counterchecked them with "time.is" and the difference is just a few milliseconds.
Anything I have to worry about? Just wanted to make sure everything runs fine. Would be sad if a found Block is rejected by the network because of a bad time stamp 

I almost have the same setup, just 2 Newpac Miners but with a big passive custom cooler (yeah, yeah there's nothing I have to compensate ;p), therefore clocked higher and it all runs flawlessly.
I start just the miner with a one-line-bash-script that provides the parameters and not with the config-file. For this sort of lottery mining I didnt define any failover pool and seeing my uptime it's imo a bit of an overkill 

As stated in the post above CPU Mining for BTC is really not that advisable. If you want to earn some crypto with your cpu I would advice mining an Altcoin whose mining algorithm favors cpus like Monero or Veruscoin. After collecting some rewards you can exchange them for BTC or you can use hashrate rental services like nicehash (if you trust them) that pays their workers in BTC. But dont expect much profit unless you own a few high end server-grade processors.

And this is why ...

This is why the system is misunderstood - because you think I am wrong on statistical probabilities that are fact, as well as ratios and mathematical facts that you think are incorrect.

All good though, the more you believe you are right, the more those like me seem to be benefittting from the manipulation of these statistical facts. Probability has feeling, so what you believe or feel is right or wrong is irrelevant. It's maths. The probability is based on EVERY block, on EVERY game, on EVERY hash. Whether we like it or not.

It makes no difference anyway guys, as the probabilities are not what we are all dealing with here. A block WILL be hit when the hashrate is there, that is coded into the system, whether 10minutes or so is also (almost) irrelevant, it WILL be hit - it actually HAS to be unless the chain is stopped with no hash driving it.

I don't need to argue these facts with you, look at the probabilities of Lotto for every games played, and the same goes for every block,

All good though. The misconception there is in the world, the better for those that can deal with the way it works.

#crysx
[/quote]



This will be my last post on that topic, because I already believe argueing is kind of senseless here. I didnt put any feeling or emotional expression into my reply. Please provide me the lines of code where the Certainty of solving a block is implemented (and I dont mean the Diff Adjustment based on the average blocktime).
Maybe the following analogy might help:
The probability for a standard dice to roll a 1 is 1/6. But that doesnt mean, that you get a 1 every 6 rolls. It is highly improbable but possible, that you roll a 1 six times in a row but the same is to say for not a single 1 in 30 tries.
Even if you roll 100 or 1000 times you're not guarenteed to get a 1 but the chances for that are ridiculously small, but it is still NOT CERTAIN!
The same goes for BTC Mining and the underlying SHA256 hashing. Although the "dice" here has 2 to the power of 256 sides which is for human beings an incredible huge solution space. Because it is that large there is no specific hash value demanded but every value that fulfills the defined criteria. Sticking to BTC being below a certain threshold that is adjusted every 2016 blocks and corresponds to enough leading zeros in the hashvalue of a solution.
But the principal stays the same, there's no guarentee of finding such solution in a finite timespan.

And this is why ...

This is why the system is misunderstood - because you think I am wrong on statistical probabilities that are fact, as well as ratios and mathematical facts that you think are incorrect.

All good though, the more you believe you are right, the more those like me seem to be benefittting from the manipulation of these statistical facts. Probability has feeling, so what you believe or feel is right or wrong is irrelevant. It's maths. The probability is based on EVERY block, on EVERY game, on EVERY hash. Whether we like it or not.

It makes no difference anyway guys, as the probabilities are not what we are all dealing with here. A block WILL be hit when the hashrate is there, that is coded into the system, whether 10minutes or so is also (almost) irrelevant, it WILL be hit - it actually HAS to be unless the chain is stopped with no hash driving it.

I don't need to argue these facts with you, look at the probabilities of Lotto for every games played, and the same goes for every block,

All good though. The misconception there is in the world, the better for those that can deal with the way it works.

#crysx
[/quote]

This will be my last post on that topic, because I already believe argueing is kind of senseless here. I didnt put any feeling or emotional expression into my reply. Please provide me the lines of code where the Certainty of solving a block is implemented (and I dont mean the Diff Adjustment based on the average blocktime).
Maybe the following analogy might help:
The probability for a standard dice to roll a 1 is 1/6. But that doesnt mean, that you get a 1 every 6 rolls. It is highly improbable but possible, that you roll a 1 six times in a row but the same is to say for not a single 1 in 30 tries.
Even if you roll 100 or 1000 times you're not guarenteed to get a 1 but the chances for that are ridiculously small, but it is still NOT CERTAIN!
The same goes for BTC Mining and the underlying SHA256 hashing. Although the "dice" here has 2 to the power of 256 sides which is for human beings an incredible huge solution space. Because it is that large there is no specific hash value demanded but every value that fulfills the defined criteria. Sticking to BTC being below a certain threshold that is adjusted every 2016 blocks and corresponds to enough leading zeros in the hashvalue of a solution.
But the principal stays the same, there's no guarentee of finding such solution in a finite timespan.

I do not agree on the "Absolute Certainty" Part. It is just an on-average-solution-timespan derived from the Poisson Distribution Probability. There were periods when the time between two blocks found were 3 hours for example.
If you want to calculate the true probability you need to consider every hash value and its chance of beeing below the current difficulty level. Lets go for the 70GH/s. Say the current Diff is 20T and for BTC the Diff Value when 1 corresponds to 8 leading hex numbers which means 2 to the power of 32 in binary. So roughly 4,3 billion hashs in decimal system necessary to find such a value on average. Multiplay this with 20.000 billion (20T) and you get the chance for each single hash calculated of beeing below that threshold. For such small possibilities you can simply sum them up, the deviation is negletable. But please consider this isnt possible anymore for "probable" events. If you would control the complete BTC Hashrate your Chance of finding a Block in 10 mins is around 63% and not 100% when you sum all hashs up (your machines would have calculated the above mentioned amount of hashs in that time) but as stated at the beginning the probabilty is a distribution. To achieve 100% your integral would need to be 1 and that means to integrate to infinity. Which is hard to achieve if we believe our state of the art science that the universe is finite in regard of its lifespan   

For a few months now I receive from time to time the message in cgminer: `missing nonces; toggling ASIC to reset`
After approximately 1.5 secs its hashing again. Does anybody know whether this error is pool sided or caused by my mining hardware?
I have 2 Gekkoscience NewPac Miners on an RPi 4.

Hey, thanks for your reply. A friend gave me the advice after reading the hint with the root rights for the usb devices to put `sudo` in front of the ./cgminer command. Then my newpacs were recognized and the miner is now running successfully
The other possibility to enable usb devices for standard users are the commands provided in the pinned installation guide at page 1. Unfortunately yesterday I believed that the standard "pi user" has those rights, which was a wrong assumption...
Anyway thanks for your reply and have a nice weekend

Hello Guys, Ive got the same problem as "bmoscato" in his post number #1739, the final lines when running the make command are the same.
I read that he managed to solve that issue by unplugging his usb fan. I dont use a fan but the newpac miners are still not recognized by the cgminer.

-I have a 2 NewPac Miners in a Sipolar 10 Port USB 2.0 Hub 5V 20 Amp
-Raspberry Pi 4 B 4GB running Raspberry OS Buster ARM64 bit
-Followed the pinned procedure for debian/RPi installation

Tried on USB 2.0 as well as 3.0 --> No difference
Tried compiling with plugged in miners and with unplugged --> No difference
Checked USB Hub with miners on windows laptop --> no problems at all

Any help appreciated =)

Hello Guys
Is there kind of a technical drawing for the dimensions of the newpac miner especially the Cooler?
Im at home at my parents house and didnt take one with me to measure it myself. I found an old Alu-Cooler in the basement and want to make a more potent one for my USB-Miners