The Bobcat 300* Helium Miner finally has an interface you can use to be able to tell what it’s doing! Better yet, it lets you do a few things like conduct an internet speed test. You can even get a detailed breakdown of which block your miner is on!
In this guide I’ll break down how to access the web interface (easy) and run through some of the features that are available at launch (1.0). The utility started installing on Bobcat 300’s via OTA updates on August 3rd 2021. Let’s begin!
Hardware Used
The Nebra outdoor miner is a Helium miner designed to be installed permanently outdoors. It is powered by a Raspberry Pi Compute Module 3 and uses a eMMC chip for storage via a
Links: Amazon.com*
Finding IP Address
Hopefully you already know what the IP address of the Bobcat 300 is on the network as you will need to know that to get your miner out of relayed status and set up the “port forward”.
If you haven’t set up your port forward yet follow my Getting Out of Relayed Status Helium Mining Guide.
You can find your IP by logging into your router’s web interface / app or you can use the Helium app’s “Diagnostics” feature to get it as well!
Accessing Web Interface
Once you’ve determined your miner’s IP type it in your web browser like this:
http://192.168.X.X
It does not like https (port 443) and will only work with http (port 80).
Diagnoser Utility Options
Let’s cover what you can do using this utility at launch.
Temperature
Temperature is a serious obstacle for Bobcat 300 miners. If they are outside or in a very hot / poorly ventilated place they are well known to overheat. This feature helps you manage this and make sure your miner isn’t getting cooked.
If you choose the temperature option you will get the temperature of your unit (as temp.json in JSON format, useful if you are a developer) like this:
{ "time": "2021-08-07 00:30:51 +0000 UTC", "temp0": 47, "temp1": 49, "unit": "°C" }
This lets you keep an eye on your miner’s temperature. This one is inside an air conditioned building and it’s still nearly 49C or roughly 120F degrees but would be considered a “good” temperature reading!
Sync Status (Update 9/3/2021)
New option added in 1.0.3 that is described as:
Introducing the sync status feature on the Bobcat Diagnoser, which answers the very simple yet important question of whether or not your Bobcat miner is properly synced to the network. Stop incessantly rebooting or waiting for the helium app to update the miner’s status. Now you’ll have access to real time information at the push of a button!
Bobcat Miner 9/2/201 Update
The Helium app really is agonizingly slow to update so this is a useful feature. Here’s an example of how it looks:
{ "status": "synced", "gap": "-2", "miner_height": "995790", "blockchain_height": "995788", "epoch": "25674" }
The “gap” is how many blocks behind you are, so I am 2 blocks behind with a gap of -2. The math adds up with the “blockchain_height” representing the height the entire network is at and “miner_height” representing the block height your miner is at / sync’d to.
Miner
The “Miner” choice gives you an extremely detailed breakdown of your miner. You want to be careful with this option because the menus warn you that this option slows down the Bobcat’s mining (it’s a resource intensive / high CPU operation).
Here’s what it looks like:
{ "time": "2021-08-07 00:11:15 +0000 UTC", "temp0": "48 °C", "temp1": "50 °C", "temp_alert": "normal", "ota_version": "1.0.2.10", "miner": { "State": "running", "Status": "Up About an hour", "Names": [ "/miner" ], "Image": "quay.io/team-helium/miner:miner-arm64_2021.08.02.0_GA", "Created": 1628292218, "Ports": [ { "IP": "0.0.0.0", "PrivatePort": 1680, "PublicPort": 1680, "Type": "udp" }, { "IP": "0.0.0.0", "PrivatePort": 44158, "PublicPort": 44158, "Type": "tcp" } ] }, "miner_alert": "", "miner_desc": "", "pubkey": "1125RGgX5aXXXXX", "animal": "shallow-maroon-xxx", "region": [ "US915", "" ], "height": [ "24468 955285", "" ], "ports": { "1680": "closed", "44158": "open" }, "p2p_status": [ "+---------+------+", "| name |result|", "+---------+------+", "|connected| yes |", "|dialable | yes |", "|nat_type | none |", "| height |955285|", "+---------+------+", "", "" ], "onboarding": [ "", "********************", "General Manufacturing Info", "********************", "", "+-------------+----------------------------------------------------+", "| name | result |", "+-------------+----------------------------------------------------+", "| batch | bobcat_609 |", "| createdAt | 2021-06-09T09:41:12.706Z |", "|heliumSerial | null |", "| id | 82510 |", "| macEth0 | e8:78:29:51:XX:XX |", "| macWlan0 | 48:e7:da:13:XX:XX |", "| makerId | 6 |", "|onboardingKey|112xxxx |", "|publicAddress|1125RGg |", "| rpiSerial | 7cdf8xxx |", "| updatedAt | 2021-06-18T22:30:18.486Z |", "+-------------+----------------------------------------------------+", "", "", "********************", "Manufacturer Info", "********************", "", "+------------------+---------------------------------------------------+", "| name | result |", "+------------------+---------------------------------------------------+", "| address |14sKxxx |", "| createdAt | 2021-02-24T22:16:39.379Z |", "| id | 6 |", "|locationNonceLimit| 1 |", "| name | Bobcat |", "| updatedAt | 2021-02-24T22:16:39.379Z |", "+------------------+---------------------------------------------------+", "", "" ], "errors": null }
I told you it was a lot of information!
We can actually see a lot of stuff that was previously not possible to see on your Bobcat like the enrollment key, various internal components and their serial numbers, etc.
Our P2P connection status (what the light represents on your Bobcat, green yellow etc.) is revealed in great detail as well. Look at this detailed breakdown here:
"p2p_status": [ "+---------+------+", "| name |result|", "+---------+------+", "|connected| yes |", "|dialable | yes |", "|nat_type | none |", "| height |955285|", "+---------+------+",
Explorer
This is just a link to the Helium blockchain explorer. Not very useful!
Helium API
Connects to the Helium API and returns some information in JSON format about your specific miner. This is Helium-specific information that is tracked across all miners and not Bobcat specific.
Onboarding
This one is a little more interesting. It redirects you to your hotspot’s onboarding entry at onboarding.dewi.org. The results are given to you in JSON like the other commands.
I had not seen this site before but sure enough my onboarding entry appeared as expected!
Net Speed (Internet Speed Test) (Update 9/3/2021: Removed, Secret Link Available)
Finally a fun one! This one lets you test your Bobcat 300’s internet connection speed.
I ran the connection test (using WiFi) and this was my output:
{ "DownloadSpeed": "27 Mbit/s", "UploadSpeed": "33 Mbit/s", "Latency": "16.586062ms" }
Those results are actually terrible for my connection speed (gigabit fiber) but not unexpected for WiFi using G/N speeds.
At any rate this is very useful information to have whether you’re using wired / wireless. Having a tool like this lets you test the Bobcat’s connection specifically instead of running a general speed test on your computer. That only diagnoses your internet connection in general and not the Bobcat’s connection specifically so having this tool is a giant leap forward and worth using.
It does make your miner slow down / stop mining for about 30 seconds so don’t overdo it!
UPDATE 9/3/2021: In 1.0.3 this option is no longer in the list of options. It’s still available on the miner as speed.json. To access the option replace the IP in the URL below with your own miner’s IP address and go to:
http://192.168.X.X/speed.json
After a 20 second pause or so you will see the speed test (for now, they removed the menu option but the JSON request is still available/permitted):
{ "DownloadSpeed": "25 Mbit/s", "UploadSpeed": "42 Mbit/s", "Latency": "9.81852ms" }
Resync Miner (Update 9/2/2021)
This is the first really serious troubleshooting option we’ve been given for the Bobcat. It was added in 1.0.2 and the description given by hovering your mouse over the option is “It will delete the miner data, let the miner resync to the blockchain from scratch”.
Basically they’re saying this will wipe the local blockchain data from your miner and let it resync from scratch. You would only want to do this if your miner is completely stuck / corrupted.
Do you remember how long it took to sync your Bobcat when you got it? You definitely don’t want to have to go through that again unless your miner is completely broken and won’t sync and nothing else has worked / troubleshooting has led you to this conclusion.
This finally gives users the ability to clear and resync their Bobcat though which is a fantastic improvement from the launch 1.0.0 version!
Also requires a username / password:
Username: bobcat Password: miner
Reboot (Update 9/2/2021)
This was a new option added in version 1.0.2. It’s as simple as it sounds and allows you to reboot the miner through the web GUI. Very handy!
This option will prompt you for a username and password. Here they are:
Username: bobcat Password: miner
Blockchain Height
Blockchain height just gets the current height of the Blockchain from the official Helium API. This would be useful if you wanted to write a very simple script that wanted to compare if your hotspot’s block matched the current block on the blockchain.
A lot of the other available commands give the blockchain_height already (such as “Sync Status” and “Miner”) so it’s not extremely useful.
Bobcat OTA Update / Troubleshooting (Community Res)
Don’t get too excited about these ones. These are not at all what they sound like. They’re both just web links to community resources (at least at 1.0.0 release).
Fast Sync (Alpha) (Update 9/11/2021)
This new feature was added in 1.0.4. It’s meant to help catch you up quickly to the blockchain. I had the chance to use it today as Bobcat has had a lot of issues with hotspots falling out of sync and mine has been impacted.
The function takes about 30 minutes to sync and you should be at least 400 blocks behind to use it. From Bobcat:
Fast Sync
This is an alpha feature that gives healthy miners a sync boost, so they can quickly catch up to the top of the blockchain from the block they are syncing at.
IMPORTANT: this feature will NOT work for healthy miners whose gap to the blockchain is smaller than 400 blocks.
Bobcat Miner 9/10/2021 Post
As usual the credentials will be:
Username: bobcat Password: miner
Conclusion
The whole time I’ve had my Bobcat it has been a “black box”. Who knows what it’s doing. You can’t log into it with SSH or using the serial console (set your speed to 1,500,000 baud (yes, 1.5 million) and the serial console “data port” does work over USB in something like Putty, this is some kind of security through obscurity baud rate) because all the accounts are either disabled or have a nologin shell.
There’s only a couple of useful “tools” in 1.0.0 release that actually make the Bobcat do anything but it’s so nice to be able to finally see and be able to do *SOMETHING*! I’d imagine that more menu options will continue to be added to the Bobcat 300’s new “Diagnoser” tool over time.
I definitely at least recommend running the “Speed Test” and checking your unit’s temperature to make sure everything is running well!
Other Resources
For the best place to exchange your Helium (HNT) to other tokens like Bitcoin (BTC) check out my Best Altcoin Mining Pools and Exchanges article
If you have a Nebra hotspot check out my getting root and SSH access to the Nebra guide
To understand what is happening with Ethereum mining and when it is ending see my Why GPU / Ethereum Mining Is Toast – Stop Buying GPUs article
Hello.
I bought 2 bobcats 15 days ago. It is 1 feature. but the 2nd bobcat doesn’t sync at all. I bought a new rope, a new internet name. The problem was never over.
The port is open and I rebooted. Try fast. what they should do. the green light is on but the block is continuous. please help me too.
Hey onur,
If I’m understanding correctly you are saying you bought an additional internet line for the second Bobcat? Does it have it’s own IP?
If they are sharing a public IP address (your internet IP) only one of them can have port 44158 port forwarded. If you do indeed have two separate internet connections you’d want to port forward one internet connection to each miner if that makes sense.
That should take care of it. You will end up with 2 port forward entries. One in each one for each of your internet lines to a different Bobcat. Hopefully that helps!
cevap için teşekür ederim.
Ama sorun internet değil. 2 internet bağlantısına sahibim.
benim problemim bloklara uzak olmak..
Belki benim sorunum SD kart arızası düşünmek.
ota_version": "1.0.2.81",
"region": "region_eu868",
"frequency_plan": "eu868",
"hayvan": "kabarcıklı- * * **", "pu bkey": "112efK9Cs1VQAZReZjUCnWzND5Acc9CRyb7J1*****"," :
{ "Durum": "çalışıyor", "Durum": "Yaklaşık bir saat kadar", "Adlar": [ "/miner" ],
"Görüntü": "quay.io/team-helium/miner:miner-
arm64_2022 .02.22.0_GA",
"Oluşturuldu": 1645921355 },
"p2p_status": [ "
"| ad |sonuç |", ",
"|bağlı| evet |",
"|çevrilebilir | evet |",
"|nat_type |bilinmiyor|",
"| yükseklik |1244309|",
" +--------+-------+", "", "" ],
"miner_height": "1244309",
"çağ": "33055",
"ports_desc": "yalnızca 44158 numaralı bağlantı noktası gerekir. 22 için, yalnızca uzaktan desteğe ihtiyaç duyulduğunda. public port açma/kapama burada doğru değil, listen_addr'niz IP adresiyse, sorun yok",
"ports": {
"192.168.1.***:22": "açık",
"192.168.1.***:44158": "açık" ,
"5.26.218.***:22": "açık",
" 5.26.218.***:44158": "açık
yükseklik": [ "33055 1244309", "" ], == ???????????? ____ MY PROBLEM ____
"temp0": "34 °C",
"temp1": "30 °C",
"zaman damgası": "2022-02- 27 06:46:43 +0000 UTC",
"hatalar": ""
Hey onur,
Thanks for explaining and posting your report! I think you are diagnosing this correctly as a SD card / storage issue. We have seen this before. It usually happens when power is lost to the miner during a write to the storage (same as with computers like Windows having the “Checking Disk” startup screen and Linux needing fsck). When something is wrong with the storage it can manifest in a lot of different ways.
The only concerning thing I see on your report is this:
“|nat_type |bilinmiyor|”, or “|nat_type |unknown|”,
My report looks very similar to yours:
{
"ota_version": "1.0.2.81",
"region": "region_us915",
"frequency_plan": "us915",
"animal": "shallow-maroon",
"pubkey": "X",
"miner": {
"State": "running",
"Status": "Up 36 hours",
"Names": [
"/miner"
],
"Image": "quay.io/team-helium/miner:miner-arm64_2022.02.22.0_GA",
"Created": 1645702946
},
"p2p_status": [
"+---------+-------+",
"| name |result |",
"+---------+-------+",
"|connected| yes |",
"|dialable | yes |",
"|nat_type | none |",
"| height |1245325|",
"+---------+-------+",
"",
""
],
"miner_height": "1245325",
"epoch": "33086",
"ports_desc": "only need to port forward 44158. For 22, only when need remote support. public port open/close isn't accurate here, if your listen_addr is IP address, it should be OK",
"ports": {
"174.23.X.X:22": "open",
"174.23.X.X:44158": "open",
"192.168.1.82:22": "open",
"192.168.1.82:44158": "open"
},
"private_ip": "192.168.1.82",
"public_ip": "174.23.X.X",
"height": [
"33086 1245325",
""
],
"temp0": "46 °C",
"temp1": "46 °C",
"timestamp": "2022-02-27 16:49:03 +0000 UTC",
"errors": ""
}
The NAT type of unknown has me wondering if there is still some networking issues going on somehow. It could even be both potentially.
The fix for corrupted storage is to use the “Reset Miner” option that is available when you go to your miner’s IP address in your browser. This will completely wipe the storage (including the Helium software) and download the fresh latest copy from scratch. It will also resync the blockchain from a “snapshot” to your storage (which means it doesn’t have to do the normal slower syncing for most of the blockchain and will just download it from a server). It typically only takes a few hours to complete.
When I was having similar problems this did fix it for me. It was having a lot of trouble keeping up before the reset and afterward it has pretty much never fallen behind since. The only thing that still leaves me wondering is the NAT type but honestly that shouldn’t stop you from syncing correctly. I think the Bobcat Diagnoser “Reset Miner” option is worth a try in this case, especially since you already expect something might be wrong on the storage.
Am I understanding correctly that one of these two points *is* working correctly? One test you could do is switch which internet connection your Bobcats are using. Take the working one and try putting it on the other internet connection and see if this impacts the NAT type or makes it stop syncing correctly. If the point that isn’t working correctly does work when you swap it to the other internet connection then one of your connections might have some NAT restrictions on it (common with 5G, shared internet connections, etc).
I would probably try the reset first but it is quite strange that one of them has that NAT type. It would rule some things out / narrow down the problem to try testing each Bobcat on the other internet connection and see if the issue “follows” the miner or of it might be related to one of the internet lines.
If the same miner is working after swapping the internet connections and the same one is not working properly that points to a miner specific issue. If the issue changes to the other miner as you change internet connections it would point to one of the internet lines having some kind of restriction (usually calling your ISP / service provider can take care of this in most places, they usually have an option or a plan that will remove the NAT restrictions).
Hopefully that helps!
jamesachambers , sen çok iyi bir insansın. cevapların için teşekkür ederim.
daha önce 3 farklı internet bağlantısı ile denedim. ve bir çok defa sıfırladım.
Maksimum blok 50 oldu ve sonradan bloklar arası artmaya devam etti. 100 200 300 herzaman daha fazla 🙁
Benim 5 tane bobcatim var. Ama bu sorun sadece 1 tanesinde ve bu bobcat 15 gün önce yeni aldım. Ve sorunun bobcat de olduğunu düşünüyorum. Sence ne yapmalıyım?
1)Geri iademi etmeliyim?
2)Bu sorunu ben çözebilir miyim?
Not : ben 9 ay önce sipariş verdim ve çok fazla bekledim. tekrar aylarca beklemekten çok korkuyorum.
Hey onur,
It’s a tough case for sure. That does help to know that you have 5 of them and that only one of them is having the problem. That does rule out some of the ideas I had as that definitely points more to the specific miner.
It wouldn’t surprise me if this is a firmware issue as we have seen that in the past. Sometimes this impacts units that have been enrolled more recently. When this is the case usually within a few weeks Helium / Bobcat will release a firmware update that fixes these.
You know what might actually be worth a try in your case? There are notes mentioning that port 22 (SSH) can be used by Bobcat to connect to your miner remotely to fix it. This gives you no risk of having to return it to them and wait forever to get it back. There’s a good chance they might know what is going wrong with it since their support handles likely hundreds of tickets per day from customers. As someone who earlier in my IT career started as IT Technical Support I and worked my way up from there I can say you start to see patterns and get to a point where they may very well be able to fix it remotely in only a few minutes.
So I think the answer to can you solve it yourself is probably eventually (even if it just takes waiting for a firmware update that speeds up syncing problems on certain miners) but I think this is a rare case where it may actually be worth emailing/contacting their support. This won’t necessarily mean returning the unit (they can’t make you) but they may give you a very good reason why you should (maybe they’ll determine there’s some sort of hardware defect like bad flash storage and lots of other possibilities) and if you go this route you won’t have to go to the back of the queue to wait as long as someone ordering a new Bobcat. If you just do a regular return you almost certainly will have to start at the back of the line.
If their technical support determines something is wrong with the miner you would get a replacement pretty quickly as this is a different process/queue that they allocate miners for separately from the main batches being sold (at least that’s my rough understanding and how most companies I’ve worked with / for handled these type of issues). They do this because if the miners actually break that is bad for their reputation if you make them wait another however many months for a replacement (that’s a long time for people to be posting complaints about how unhappy they are their miner broke itself and they’re waiting again all over for it, not a good look any company wants since it’s unfair and can frighten new buyers potentially losing sales).
bobcatminer.zendesk.com is their support desk where you can submit a request to them very easily. I would describe to them that you have 5 of them and that only one is doing it and that you’ve tried multiple internet connections (it will help you skip some steps and get you closer to the part where they remote into the miner and look at it). It also wouldn’t hurt to just request remote support in your ticket and state you would like to avoid having to return it unless they think it’s absolutely necessary. The site should change to the right language for you (mine went to en-us from the main page so it seems to detect your language). Hopefully that helps!
gerçekten çok yardımcı oldun. sana çok teşekkür ederim.
bobcat ile iletişim kurmak. Sonuç belli olduğunda, tekrar burada ne problem olduğunu ve bu problemin nasıl çözüldüğünü yazacağım. Bu bilgiden herkes faydalanır. Ve hızlı çözüm yolu bobcat kullanıcıları için.
Tekrardan çok teşekkür ederim.
No problem at all, I look forward to hearing your update!
henüz hiç kimse ilgilenmedi :/ problem devam ediyor:( bir cevap alınca tekrar gelicem.
Hey onur,
Thanks for the update! I checked to see how their customer service is performing here.
A common sentiment seems to be:
“Excellent service. Took a bit long to start the process but when it was started the replacement went super quickly. Thanks!”
I think this is what will happen with yours (if they aren’t able to fix it remotely). It might take a little bit of time for them to answer but their average score is about 3.8 and a lot of the negative reviews are people upset that their miner took so long to ship when they originally ordered it (not that they had a customer support issue once they had received it).
You will definitely see people who have not received their miners yet in there and they are not happy. Everyone was / is upset about how long it took to get their miners but it sounds like people who had actually received a miner that had an issue didn’t really have any complaints other than it was slow to start the process but once they responded it moved quickly.
It must have moved *very* quickly because nobody really took any stars off their rating despite the miner being broken. I assume this is because they had to originally order that miner and wait and they know how long that took, so when they see the replacement process take a small fraction of the time they are probably relieved / pleased. People basically forgave them in those reviews even though their miner was defective / broken and that says a lot.
This is why I think you’re definitely doing the right approach here as everyone says the replacement process for broken miners is fast and nobody would / did say that about the normal ordering process where you have to wait however X many of months. You do not want to have to go to the back of the line for these for sure.
You can definitely see why the broken device / warranty replacement track is a different one for most companies by reading their reviews at that link. If they didn’t do this I guarantee their average score would be something like a 1-2 instead of a 3.8. They’d be getting hit by both the people waiting to receive it initially AND their customers who had something go wrong. The people who have to wait a second time would only be more upset and leaving more negative reviews than the people waiting for their initial order (as they should be, it’s not fair to wait in that line twice) and I don’t see any of that happening.
It’s practically saved their review score that they have a separate process / track for it. That is money / logistics well spent to maintain their reputation. Once you have a bad reputation you generally can’t just “buy” back a good reputation no matter how much money you throw at it.
I think once they respond things should go fairly easily / quickly from what other people are saying. Definitely keep us updated for sure!
Hey James
Sorunum çözülmedi bu yüzden burada bir açıklama yapamadım. gerçekten Bobcat için çok kötü bir süreç yönetimi. Sorunun nedenini öğrendiğimde tekrar bir açıklama yapacağım.
Saygılar James.
Hey onur,
Thanks for the update! Hopefully things smooth out here, I look forward to hearing how it turns out!
Is there anyway around being able to run 2 hotspots off of one wifi router with the same IP? My property splits two hex’s and I was planning to install two seperate hotspots more than 300m apart. I was hoping to use the same wifi with a long ethernet connection so I didn’t have to pay more for internet to run the second hotspot.
Hey Matt,
Great question! The answer for Helium is basically no. The reason for this is that each Helium hotspot has to connect to other hotspots / receive connections from other hotspots on your IP address at port 44158.
Since you only have one port 44158 and can only choose one miner to forward this port to you basically have to choose which one will be able to receive the incoming connections. The other point will be in relayed status (and we’ve often seen it have even additional connectivity issues “fighting” with the other point).
If Helium supported something like virtual hosts (this is how web servers can share port 80 for multiple servers, it uses the hostname or .com address to figure out which server it’s for) this would be totally possible. They just basically don’t support it and do their networking purely with an IP address and port 44158 and that creates the issues with “splitting” it between points.
It would be like sending a letter to someone’s house but you aren’t allowed to put the person’s name receiving it on it. You would just put the address of the house. That means the best case scenario is that the letter would be delivered to the house and they would have to figure out amongst themselves where it goes. Helium has no mechanism of figuring out that last step though (it doesn’t have a meeting of the minds unfortunately, although some types of devices do support this just not Helium miners).
Basically Helium would need to add support to be able to do this by having some other way to identify the miner via networking that doesn’t exist at the moment. Hopefully that helps!
I run the speed test, it shows 13 mbs of download speed and 0 upload speed. ( I have an ADSL with download speed of 13 and upload of less than 1mb) so is it possible that the miner diagnoser doesn’t show the value if it is less than 1mb? and is this upload speed bad for mining?
Hey tarek,
Welcome! Theoretically it would mean you are getting 0.49 or less, although it can’t actually be 0 or the test wouldn’t have completed if it couldn’t connect.
Is this wireless? It can also mean something is interfering with the wireless signal or it’s too far away. We have had someone in the comments here figure out their fridge was blocking most of the WiFi and they moved it 5 feet in a different direction and their speeds went back to normal. It may be worth trying on wired if it’s wireless too just to compare (it will almost never be as high on WiFi as on wired).
How much do you need? According to Nebra:
Around 200-300Kbps on average, or roughly 0.2-0.3 Mbps. That makes this a little tricky because if you have 0.49 Mbps and it’s rounding down you’re actually fine. If it’s however 0.1 or less that actually would impact your mining.
You could even see this in your earnings theoretically over time if you looked at the graphs from when your network was busier from watching streaming shows or something where it’s squeezed so low that you start getting timeouts on important operations like beacons/witnessing/etc.
It would be good if it’s wireless to see if you move it around a little if you can get it to at least register as one. If you get 1Mbit you’re safe with some safety margin even. Hopefully that helps!
If you’re -2 it means you’re ahead of the blockchain.
Hey Jon,
Welcome! Technically being -1 means you are fully synced and your miner (and the rest of the network) are working on the next block.
Being ahead of the blockchain would be impossible. You can’t have a chain that doesn’t link together. That would be a broken chain at that point.
It happens in some blockchains, but it’s a problem that has to be resolved and someone usually loses (some exceptions to this I’ll mention in a moment). In Bitcoin that is called an orphan block. Someone got “ahead” of the chain but as I was saying earlier, that cannot stand. You cannot have a chain with broken floating links out in the ether. In Bitcoin the blockchain has to decide which chain to go with and it goes with the longer chain (the one that has had more blocks added since this “split”). The other people are screwed.
In Ethereum when this happens they are called uncles. The chain still has to pick one otherwise it would break it completely, but the uncles (the block and chain that is *not* chosen) are at least still rewarded. You can read more about this here (I hate linking to a site like this but honestly the summary is pretty impressive for a corporate outlet).
Those are all proof of work chains though. It’s literally impossible for this to happen in Helium. If it did/has it probably caused a chain halt or some disaster. Helium has always had a consensus group that has to collectively agree before a block is accepted though. It’s how Ethereum is going to work when mining goes away as well. Your miner isn’t “mining” any blocks like proof of work algorithms. In fact, you don’t even get to participate in consensus anymore with a regular Helium hotspot because that was taken away in favor of a dedicated proof-of-stake validator pool (not easy to meet the qualifications for) which is what we have now.
The Helium team thought about having uncles actually. This was way back in the day in their Intro to Helium article here.
Here they are basically explaining how Helium doesn’t work the same way as those ones and they also explain why they decided to do that. It’s all quite confusing and it has changed over time, but the -2 display thing has to be some sort of firmware or display bug. I’ve never even seen it personally but it has come up here. I’m guessing it’s some kind of display glitch or some kind of rolling total that is somehow getting off in edge cases or something like that. It literally cannot be what it says though, that is not possible. Hopefully that helps!
Hey James,
This is a kickass website for info on Helium thank you!
I am having some trouble with my Bobcat 300 and I was hoping to get some knowledge on it.
Currently my bobcat is setup on a building, ~4 stories high connected through PoE into a PoE Hub. Long story short: we are having syncing and relay issues.
Interestingly enough, when I had setup the bobcat originally a month or so ago with just a router inside the building (using PoE), I had been synced & online mining under the “Relayed” status.
I had unplugged the bobcat from the router and plugged it into the new PoE hub (due to compliance issues) and it stopped mining all together. I had setup a Virtual Network for the miner and setup a new IP with port-forwarding 44158. Once that was done, I restarted the miner (bad idea I think) waited 30-45 minutes and tried fast-syncing.
When I checked the panel, it also showed:
Nat_type:symmetrical
instead of
Nat_type:none
Now It has been close to over a week of syncing, but the bluetooth diagnostics show we are accepting ‘Inbound and Outbound’ connection (which i’m confused on since the Nat_type is symmetrical), and it seems to be stuck at 99.85% syncing.
Is this because I setup a virtual network and since Helium mining uses peer-to-peer connectivity, outside miners can’t communicate with mine?
Or am I just lacking the patience to let it sync?! lol
Thanks for the help! Your articles have been a big help to a lot of people and I hope to help others once I figure out this new setup lol!
Hey Derek,
Great questions! Funny enough I just received my Nebra outdoor point YESTERDAY! I haven’t replaced my Bobcat yet (I’m not sure what I’m going to do with it yet, I don’t think I’m going to run both in the same hex). I’m trying to figure out how I’m going to use PoE with it as well but the Nebra point does support it natively so it’s mostly just a question of getting a PoE charged cable where I need it.
This is a pretty tough one but you gave great information. So the NAT type showing as symmetrical is concerning. Symmetrical NAT means that the source port will always match on outgoing connections instead of choosing a random port for outgoing connections. The other main type is a “cone” shaped NAT. None of that is important though for this one.
I think the concerning part is that it is showing a NAT type at all in there. What does your miner think it’s IP address is? We had a commenter a few days or a week or so ago who had their Diagnoser showing an internal IP 10.x.x.x. They could not sync when this was occurring. They had set up a DMZ and some other configuration changes and when they changed it back to the regular port forward and waited that did fix it. Their NAT type was showing as “open” though after reconfiguring the network and then it took an additional several days after that.
The diagnostic reports inside the Bobcat (like the one that tells you if the port is open) do not have nearly the delays as the Helium explorer. If you open the ports it should show fairly quickly in there as I believe as soon as you start receiving inbound connections the local client’s flag immediately flips. It’s updating the rest of the Helium network that takes so long for status changes. Basically, once your report shows as “open” for the NAT status that is when the waiting would begin for the status coming out of relayed. If your own miner thinks it is behind NAT I don’t believe it would gossip anything different.
As for what you should do: we need to figure out if that port is really open. Checking the port checker sites is one way (to make sure if you put your public IP in and 44158 it returns as open). Doing the browser test is another way (go to your public IP like
httx://x.x.x.x:44158
. A successful test would be:This page isn’t working
X.X.X.X sent an invalid response.
ERR_INVALID_HTTP_RESPONSE
That is a code just saying your browser doesn’t know how to understand the Helium point but it was able to connect to it. It’s best to do a test like this on something like your cell phone with the WiFi turned off so it goes over 4G/5G and uses an external connection. If instead you get that the page could not be found that means it wasn’t able to reach your Helium point via public IP.
If it passes the browser test / the other sites say it’s open it might just require waiting but I am concerned that your diagnoser is not seeing it as a clean open NAT. Almost all the ones I have seen lately *did* show open and just took days to update. I think we want to get yours to where it’s also showing “open” though to totally resolve this.
I’m assuming that this virtual network has it’s own public IP (as in internet public IP). This would mean you either have access to or have purchased additional public IP addresses. Is this the case? Otherwise the virtual network *is* actually NAT. It has to be in that case, because you don’t have multiple public IP addresses. It’s an extremely misleading term (at least how it’s traditionally used).
It’s totally normal to virtualize networks though to different public IP leases (almost everything can and is virtualized anymore). I just wanted to mention this and say that virtual networking won’t get around the requirement to have multiple public IPs just in case. A lot of the time when people say “virtualized” network that actually means NAT (meaning it’s your IP(s) that are virtualized and subdivided via network address translation, not your actual hardware or infrastructure).
Virtual networking is for sure a thing though. Here’s a link. You may have access to level of infrastructure (I run this grade of gear in my house, Unifi for me and I even have some virtualized wireless networks for my WiFi-capable ASIC miners to isolate on) but after I finished writing this I realized that it’s actually probably more likely to be some sort of “Virtual Networking” assistant built into an average to upper end consumer router (which will definitely set up NAT).
I’m guessing it has something to do with the virtual network configuration. See if you can find any settings related to NAT or especially symmetrical NAT. That isn’t usually the default NAT setting (I believe the default is usually asymmetrical or cone NAT but this may vary by manufacturer) so it seems like it may be configured in the Virtual Network (maybe automatically by the wizard without even asking). At any rate, I think there’s still some network issues worth investigating. Hopefully that helps!
Hey once again, thank you so much for the insight, I appreciate it and I’m sure it’ll help.
I assume the issues all lead back to this virtual network we had set up (and probably the IP switch), and I assume I will have to call compliance and figure that out – or start from scratch, but I had a few more questions to shoot at you about the relay issue on a Virtual Network (or VLAN) and a block gap issue I noticed when trying to sync a few days ago.
The first question I had was is it possible to only port forward ‘44158’ on a virtual network (both-ways) that the miner is setup on, and not both the ISP & virtual network?
Or do both sides (ISP and VNet) need the ‘44158’ ports to be open for the minner to become un-relayed?
The second question was a block gap issue:
When we initially got things done, and after we ended the call with the ISP I had thought it could’ve been a good idea to let it sit for a few hours then start a fast sync process.
Obviously that didn’t help too much lol but I had tried this sequence from the control panel:
Restart > (wait ~30 minutes) > Fast-Sync > (wait ~30 minutes) > done.
At that moment the explorer wasn’t the most reliable source to tell if it was syncing correctly or picking up the internet from the PoE hub – so I logged into the panel afterwards and got the white light indicating a update was being done and ~30 minutes later a green light was showing on both the panel and bobcat, but a growing block gap regardless of the restart & fast-sync.
I am wondering If the virtual network had somehow blocked the updates done to the bobcat, or if this all goes back to the bobcat maybe not recognizing its IP had changed when we put it on the virtual network.
Currently I am on vacation, and I got a update on the explorer showing ‘Needs Attention’ – so I am confused on how it lost internet over the few days while I let it do its thing, when the panel after doing everything had shown ‘Online’ but with the Nat_Type: symmetrical in the p2p section.
Once I get back home I got a decent amount of work on my hands lol but it’ll be a good setup.
I hope you’re having a good time over the holidays and thank you for the very fast reply, this forum / site is the best lol!
Hope to hear back soon, Thanks.
Hey Derek,
Welcome back! It sounds like you’re working with an Enterprise network (since you have a compliance department/position). From my working experience I would guess that they are giving you just shy of what you need very much intentionally. Not having any open ports without them being extremely restricted/monitored is security practice / compliance practice 101. Most of their solutions are going to try to get you to use some type of NAT (which usually you can) but with this specific case it won’t work with Helium.
You have basically 3 choices to get a point out of relayed status when it comes to networking terminology. From the nowitness network section at nowitness:
There are three ways to open the NAT for mining: UPnP, Port Forwarding and DMZ. You should only use one method to open ports at a time.
These are the 3 technologies you have to work with. They won’t like a single one of them in compliance. They are trying to give you a virtual network / NAT because they *don’t* want to give you a full open unrestricted port. That is exactly what you need though. Nothing else will work. In almost every other case though there are other things that will work and they are just a pain in the butt to configure. This is what they are used to in Compliance and eventually they can get the IT person to spend the additional time configuring it more securely. We simply can’t in this case and they should have procedures in place for when that is the case (because sometimes it is).
Out of those 3 choices though compliance will *definitely* like one more than the others. I’d be shocked if they wanted to use UPnP or even have it enabled. My guess is that they will like the DMZ idea the best. They’re more likely to be familiar with it and probably already have a couple of devices DMZ’d which also can’t take anything like a NAT network and need full open ports. This is what you need.
I would work with the compliance department and see what they’re comfortable with (or most comfortable with). Make it clear that there can’t be any NAT really involved and it needs to be a fully open port.
To answer the more technical question about whether to have the port forward in the ISP / VNet / both the answer should be that it needs to be in your ISP’s gateway device (like a cable/dsl modem, fiber connection etc.) and that port forward needs to go *directly* to the miner. The virtual network is giving you symmetrical NAT which is restricted networking still.
Having two port forward entries is actually impossible. You can’t port forward across two different private networks. If you are on the same private network as your internet gateway and the port forward entry is in there it should be able to carry connections directly to the miner. With symmetrical NAT that won’t be the case unfortunately.
A single port forward entry would be telling a connection to change from your public IP like 24.X.X.X > 10.X.X.X for example. A virtual network would add a second step. Now the address would be translated again from 10.X.X.X to 192.X.X.X for your VNet IP. This replaces the existing IP address each time it happens. So who did the packets originally come from?
The hotspot on 192.X.X.X (the virtual network) would see them as all coming from 10.X.X.X address (your cable modem and whatever network it is on, probably just the normal company network but if it’s a large enterprise or even medium enterprise it could be much more complex than this). Basically your miner would have no clue who is sending the packets. That information is lost once Network Address Translation (NAT) chews up the original IP. You can’t do it twice basically and still know who sent it / be able to find your way back to the internet/the original IP.
So couldn’t the router remember this information and fix it for you by replacing that address? Yes, but then we come full circle. That is called centralized Source Network Address Translation (SNAT). It works great for most things but not for Helium mining because it’s still a type of NAT.
There are lots of other networking technologies that could do something like this (web servers use “virtual hosts” where you have a host name, that helps it figure out where to go in situations like this) but Helium does not currently utilize them. It needs to be supported by the product/service and my understanding is your options are NAT, DMZ or UPNP for Helium. For example jamesachambers.com has several virtual hosts (such as pibenchmarks.com) all hosted on the same IP. How does it know where to send them if everyone connects to the same IP? By host name, the www address. There unfortunately is no www address (or host name) for Helium that Helium could route with the way a web server does.
Helium is using pure “dumb” IP and port based routing. No host names, no additional routing information. That means the networking configuration has to be *perfect* with an actual open port. It doesn’t really support any virtualization. Could it support them? Sure, they could add support for any of these technologies to Helium theoretically. It definitely doesn’t support any of them at the moment though.
Hopefully that helps!
Hey James once again,
Today I went back to the office to work on the hotspot with an IT guy for the building. Essentially, the virtual network was made for compliance reasons like you said.
One thing that I found on the 2018 Helium whitepaper:
“Before launching the Miner, you will want to configure ports on your network to forward two ports:
44158/TCP: the Miner communicates to other Miners over this port. The networking logic knows how to get around a lack of forwarding here, but you will get better performance by forwarding the port
1680/UDP: the radio connects to the Miner over this port. You will not be able to forward packets or participate in Proof of Coverage without this
“Forwarding” on the second port is less relevant if you are running a radio packet forwarder on the same system at the miner (both on a Raspberry Pi, for example). But it is essential if you are running a Miner on the cloud for example.
For AWS, for example, you will want to configure the “Security Group” of your EC2 as so:”
Yes, we are on an enterprise ISP, and created a vNet for security / compliance reasons – but wouldn’t opening port 1680/UDP be essential if I’m running the miner on a vNet or “cloud-like” setup?
The last issue is syncing (big sigh). So today I had gone back without messing with the modem/router/hub since we need to open a ticket in order to get things done (another sigh). I got onto the bobcat diagnoser using an ethernet connection and we have a 3,000+ block gap. Prior it was only a few hundred blocks but I assume over the holidays it had no progress whatsoever.
I went through the process of resyncing > fast syncing and even tried fast syncing with using the CMD prompt or terminal on my mac by doing:
curl --user bobcat:miner --request POST http:///admin/fastsync
And now we are stuck syncing with a slowly growing block gap and nothing really seems to work and not that much information online to help with solving a block-gap issue like this. Is there a step i’m missing? Or is it looking like it’s not possible to do this through a virtual network like this?
Thanks for your time, and sorry to bother.
Hoping we can figure this out.. Location/setup is quite good.
Hey Derek,
That’s an old development document from back when your Helium “radio” could be separate from your miner. Since then they have eliminated anyone hosting any personal miners like that and you have to buy an approved miner. That information no longer applies for sure as all “approved” Helium miners are combo units. The port that 1680 listens on is 127.0.0.1 basically. Here’s a link to the current documentation. It is *solidly* blocked on my connection which has not been relayed for about ~7-8 months or so here.
I don’t think it will be possible to get it out of relayed on a virtual network like that unfortunately unless they assign you your own public IP address. This is the actual issue. It all comes back to you can’t share a single IP address with multiple port 44158s. There’s no way to virtualize around that requirement. Hopefully that helps!
Hey James,
Is Helium App trustworthy for if I’m relayed or not? I don’t see any reason in any of settings or logs that would lead me to believe I’m relayed. I recently had this transferred to me and am finally sync’d “at least in the diagnoser”. Helium still shows sync’ing and relayed. I’m also curious about the onboarding section and what exactly it means. If it means what I think, I’m curious as to why my transfer/new install isn’t stamped. Appreciate any input. Perhaps I just have to wait for the blockchain to catchup.
Hey Dave,
Welcome! So lately the answer to your question of whether you can trust it telling you you are in relayed status the answer lately has been no. In the past it had only taken around 12-16 hours for relayed status to drop (when your hotspot “gossips” with other hotspots). Lately it has been much higher.
We’ve seen it take anywhere from 3-10 (TEN!) days for it to come out of relayed status for some people. I think you are thinking about it the right way because some people did end up making it worse. One person went to a full blown DMZ trying to fix it and ended up breaking things. Once they changed it all back and left it the status did finally drop off.
I would definitely say to let it wait for now. If your port status says “open” on the diagnostic reports (in the Bobcat Diagnoser if it’s a Bobcat) you’re good to go. For other hotspots you can also usually type in your public IP address to a port checker tool at somewhere like portchecker.co. Hopefully that helps!
Hi I cant seem to log in to the tool for bobcatdiagnoser anyone have the same issues?
Ik have over 100 witnisses but only abiuy 350 beacons…..does anyone know why this could be?
Hey Asso,
I’ve actually heard of some people who were having trouble getting in by typing the :80 at the end. So if your IP was 192.168.80.5 for the miner you’d do
httx://192.168.80.5:80/
. The only possible explanation for this would be some sort of browser or DNS cache being stuck or having issues. In that case adding the :80 manually forces it to resolve (because it’s technically a different address even though it says to go to the same place, the string won’t match the existing cached address because you didn’t manually specify port 80 on that one) and download it fresh and then it works.Normally this is redundant, but people in this very post’s comments have told me it has got it for them before when nothing else would. It’s worth a shot at least! Make sure you are trying by private IP and not public IP. It’s actually not good if you can get to it by public IP (from the outside).
If that doesn’t get it then it’s probably time for a power cycle or even to go as far as logging into the miner with Bluetooth and making sure the IP it’s showing in there matches what you’re expecting. The lease may have changed if you didn’t set it to be a static DHCP lease so you may be trying a wrong/old IP.
Hopefully that gets it for you!
Hi there, I was wondering how I’d be able to get transfer packets working on my miner again? It’s been 26 days since the last one. Thank you 🙂
Hey Sam,
Welcome! I believe this is (almost) completely outside your control. One theory/explanation is that nobody is around sending data packets to your point, but most likely the number of devices sending them are nearly identical and that there are just a lot more points in your area than there used to be (my area has been exponentially increasing ever since I got mine and I doubt many areas aren’t) and it’s ending up going through other people’s points. Basically there’s more people competing for what is still a relatively small number of data transfers (Helium still doesn’t have a ton of partners yet but it’s increasing).
Another possible explanation/theory is that your point isn’t in a location that is a good choice for picking up these type of signals. Is it up in the attic behind a wall? That may not block your hotspot from talking to other hotspots but it might be preventing things like dog tags or other LoRa enabled devices from relaying through your point because they don’t have a 6-15dBi antenna on them that can punch through the outer layer of wood/siding/other materials. A lot of those little tags would probably even be stopped by the factory low-e window film put on newer windows. You need pretty much line of sight and as close to possible as “open air” between you and a little tag like that for your point to get selected for the relay.
It’s not a configuration issue at least (but could be a placement issue), but is more to do with the fact that new Helium points are being added much faster than new data transfer packet contracts/customers and that will probably continue for the near future. Several years from now a significant portion of earnings may come from these but I’m guessing the only people earning anything substantial from these are points in extremely dense urban areas and even then they are sharing with so many points they probably still don’t get too many except for in really unusual circumstances like no other points around in an extremely dense area with a lot of tags/devices that might relay a data packet. Hopefully that helps!
Thanks for getting back to me so quickly! I have a lot of hexagons in my area as I’m near to the city centre. I was earning 1 to 1.5 coins a day, now Im earning around 0.5. My antenna is on the chimney, its a 5.8dbi. A friend who lives down the road(next hexagon), is still earning the same amount as he always has done. Its sad seeing 13p and 20p’s compared to the £ haha.
Hey Sam,
That sounds like a pretty good setup to receive these tags. You should have a leg up when data transfers do become more substantial because you have the edge being open-air and line-of-sight by mounting it up on the chimney like that. All of the people keeping them inside the walls will get passed over for your point (assuming everything is working correctly on the Helium network) because they probably won’t even hear the tag since it puts out a much lower power signal.
I have a ton of hexagons in my area too. They’ve closed all around me. The important thing though is do you have a little number inside your Hexagon in the explorer. That means you are splitting your rewards with other people (you will see this as a multiplier, no penalty means you have a multiplier of 1.0). You would definitely “feel” this as it means other people are INSIDE your hexagon and that hurts your earnings. The more there are the more it will hurt them if that makes sense. I’ve seen as low as a 0.2 multiplier (your earnings would be 20% of normal) and I’m sure it can get much worse.
I think you’re well positioned though here and that nothing is wrong. Your placement is as good as it really gets. As Helium mining matures I’d expect the data transfers to play an increasingly bigger part in earnings although they are negligible now. It was exactly the same with Bitcoin and mining fees (or a lot of younger cryptos and mining fees). The fees seem so small they almost seem pointless but today fees are a gigantic % of your earnings for both Bitcoin and Ethereum mining. That’s kind of how the data credits seem now (like fees for Bitcoin in the early early days) but if Helium continues to be successful these will become significant for sure!
To see what the tags are if you don’t know what I’m talking about here’s a link with some more info. They even hate on Helium at the end of the article for being a crypto just like you’d expect from a mainstream tech article! The information / pictures near the beginning are worth checking out though to find out more about it. It’s not just these Helium official LoRa tags that get relayed though, theoretically any company can buy data credits to piggyback off the Helium network and that’s kind of the idea for the data market. A lot of giant mining trucks/equipment have these types of tags for example routinely for tracking/inventory.
It’s all just still very new, especially to these older non-technology companies that are slow/resistant to change. It’s coming though. Dish Network started relaying some of their business/commercial (non-consumer) data in October of this year so there is more data traffic coming. Note this is also/mainly a 5G/CBRS partnership but companies are warming up to Helium and starting to partner is the point. As big companies like Dish partner (and nothing explodes or backfires terribly) the little guys won’t be as timid about trying it and a lot of them will end up using LoRa data credits for their products where appropriate.
Definitely take care and let us know if the situation changes/improves!
i have a bobcat 300 it worked for about a month and then it stopped.
when i check to see what was going on it shows peer connection in and out have no signal
miner led is yellow
ports are closed no matter what i try and i just switch isp i have shaw blu curve even when it worked it still said port was closed then after about 25 days it all stop
i went and bought a router to bridge it and use the router to try and portforward a still nothing
so today i switched to bell isp and im stuck in the same boat ports are still closed
whatem i doing wrong i dont understand and is port 22 on my main ip is open and when i go check my bobcat ip 22 is closed and i put in port forwarding 22 443 and 44158
why is this happening
i dont know what to do please help
Hey Steven,
We’ve had a few similar reports to this recently. It’s definitely been going around for sure.
The first thing I would try for it is the “Reset Miner” option from the Bobcat Diagnoser you get when you type the IP address of your miner into your web browser. The reason this can help is that a lot of the time (especially if it had been working before and broke for seemingly no reason like this) it’s due to something getting corrupted on the miner’s storage. The reset miner will wipe the blockchain and Helium software and resync a fresh copy. This typically takes a few hours.
This has fixed it for a lot of people but not for everyone. The next thing I would do is to restore your network connection to how it was when it was working. This would be something like a single port forward entry in your router to the miner. You shouldn’t need bridge mode unless you know the miner is on a different network than your main internet connection. If it was working for almost a month before then in the past almost all cases like that have ended up being something not networking related (which makes sense, once you have the working networking configuration in place it should not break).
We want to get your miner to where if you run those external port tests on 44158 they will say “open” when it is configured correctly. Even if the Helium chain isn’t recognizing/respecting it we do want the external tools to show it is open and then we can deal with getting the miner fixed up.
It takes a long time to come out of relayed status even when it’s fixed. A minimum of I would say 16 hours and we’ve seen it take as long as a few days (that is unusual but we have plenty of examples of it at this point in the comments here). Port 44158 is the big one to have open. Port 22 is only used by Bobcat support and I don’t think 443 is used for the Bobcat (I only have 44158 forwarded and nothing else for mine).
Did it used to say it was in relayed status when it was working (yellow status) or did you have full green status during that time? Let’s try the reset first and setting your networking back to where external port checking tools are showing 44158 at your public IP address as open.
Once it’s there if it’s still having trouble you can definitely feel free to post your miner’s status report (just blank out your public IP and any identifying details but there’s only a few of them and I edit them out if people forget). Some other people have also had pretty similar issues in the recent past that commented on here you might be able to get some useful information as well from. We can definitely take a look at the status report to find out more!