Beaconing and data issues in Australia Since the changes #1669
Replies: 19 comments
-
|
Yes... Same here with our SenseCapM1 unit to the north of Brisbane. |
Beta Was this translation helpful? Give feedback.
-
|
I am having a similar issue also. Sometimes I am lucky to even get 1 beacon a day. I run a linxdot with a 6dbi McGill's antenna about 5m high with Lmr400 cable. Looks like it is across more the 2 brands, so you would assume a possible issue on the blockchain. I am going to be hosting out more hotspots soon but hard to sell the idea when currently only earning $3 to $4 a day. Please fix this Helium. |
Beta Was this translation helpful? Give feedback.
-
|
I have been having the same issue since the change came into effect. I was previously sending out 2 beacons per day consistently, and now am lucky to send out 1 per day. There have been several days where my unit doesn't send a beacon at all, and has even gone up to 3 days without sending a single beacon. Very disheartening for those of us that have done all we can to support the network to be getting such poor results. Please fix this issue. |
Beta Was this translation helpful? Give feedback.
-
|
Same issue with my 3 Heltec miner. Only One or sometimes 2 never reached to 3. |
Beta Was this translation helpful? Give feedback.
-
|
Same issue with my Sensecap in Australia, Petite Ash Snail. I logged a ticket with Sensecap tech support, they could not find any issue. I will beacon and have 0 witnesses, then the next day I beacon and get 13 valid 1 invalid (too close) witnesses. I've done a bit more digging, my latest 0 witness beacon was issued by Broad Linen Lion (a Cal-Chip in Germany). I checked his activity, in the last 23 days he has challenged 20 hotspots and 19 had 0 witnesses to those beacons. that's a 95% fail rate I checked a miner in an adjacent hex Magic Lead Kookaburra (Bobcat) and in the same last 23 days he challenged 32 hotspots and only 3 had 0 witnesses so that's a 9% fail rate. |
Beta Was this translation helpful? Give feedback.
-
|
Also having the same issues in South Australia, have multiple locations with multiple brands (Heltec and Sensecap) all locations using top quality equipment, cable and antennas. Have seen a dramatic reduction in both beaconing and witnessing, lucky to send 1 beacon per day and witnessing spaced out over hours instead of previously, minutes. This coupled with the terrible hex locations in Adelaide South Australia has seen a huge drop in earnings across my hotspots and is making me think twice about recommending Helium to new miners/users/industries and or adding more of my own hotspots |
Beta Was this translation helpful? Give feedback.
-
|
Same here in Melbourne, SenseCap m1. Good thing is that I finally start to beacon, 3 in the last 24 hours. Hopefully it is fixed now.🤞 |
Beta Was this translation helpful? Give feedback.
-
|
Yes same here in Perth. New gear great SNR but only beacons 2 times per day |
Beta Was this translation helpful? Give feedback.
-
|
I live in Brisbane and have the same issue. Been running my Sensecap M1 hotspot for about 30 days, prior to the update on 29th Jan I was averaging 2 beacons per day. Since the 29th its dropped to just over 1.5. Prior to upgrade the best day was been 5 (happened once) post update best day has been 4 (happened once) I've only achieved 3 beacons in a day on 2 occasions since the update.
|
Beta Was this translation helpful? Give feedback.
-
|
If your miner manufacture is using containers , official image , and docs say to bind 1680/UDP for radio / concentrator device , which binds to the radio (packet forwarder), but it looks like that is for incoming messages to the container ( RX ) , but I notice TX which is out bound from the container is bound to port 31341/UDP, I know some container systems are not picky for out bound connections , but it may be something to look into depending on your setups , try binding 31341/UDP to the container either directly out , or to 1680 if possible , if you notice also your packet forwarder local / global_conf file the ports in there are 1680 rx and 1680 tx , but the json rpc running in the image binds tx to 31341, for whatever reason. So theirs a mis match there where the radio is expecting the data gram on 1680, but if it’s being sent on 31341 it might not Be able to send the data gram out, but since 1680 is open it can receive data grams in . That’s why you notice witnessing (rx) rewards and no beaconing rewards (tx) I have one miner so I can not confirm this is your issue, but look into it, takes 2 seconds to bind that with docker cli 1680:1680/udp and if container can do 2 binds to one port then 1680:31341/udp if not then 1680:1680/udp 31341:31341/udp but that may still be problematic since global_conf is expecting RX and TX on 1680, so you would need to change that in the concentrator or packet forwarder accordingly |
Beta Was this translation helpful? Give feedback.
-
On our account we have 45 units which all display the same actions one beacon every two or three days, the powers are aware of an issue of other ports being ignored when a beacon is being sent but this seems to be a problem across the whole of Australia and not just limited to a single manufacturer. we will see what the outcome of their investigations are when they have finished with them and see what the solution is to get all Australian units beaconing the same as other countries which was changed recently from 4 to 3 per day with also a witness drop as well from 18 down to 14 but sadly these changes affected our earnings here in some cases up to 80 percent decrease. lets keep our fingers crossed for a fix shortly and get back to where we should be in line with the rest of the world |
Beta Was this translation helpful? Give feedback.
-
|
Yes I have a friend with 20 helium OG miners, and he has same issue one beacon every so often, it is US915, from what I remember AUS global_conf for packet forwarder has been the only file recently updated, so their might be a difference in that global_conf file , but , helium OG miners were not running in containers, untill recently ( correct me if I’m wrong) but I saw that helium mentioned they were moving the systems into containers, but , I run custom setup, using helium documentation, but i always bound the 31341 to the container. I mention this, because if I’m running exact same image and documentation, and the only difference is that port binding, which I know for a fact, if you look at console.log when miner is “STARTING” you will notice a json string that binds the TX to 31341 and rx to 1680, but that’s not how it’s setup in local or global_conf you can change it in local_conf and it will override global_conf in case / when new images are upgraded , it will keep your settings correct in local_conf. Besides the string from the Miner starting up, the string with ack up / down shows 100% received, but look at where it says mac=xxx and ip=xxx port=xxxxx << port is never 1680 or 31341, maybe that helps their investigation. the containers are picky like that especially if not in -privledged mode when talking to GPIO ( spi ) i2c etc.. some issue with like /dev/gpiomem or the sort, for ebus users etc … also something to note for investigation in sys.conf file you can bind an override / overlay file also, similar to how local_conf overrides global_conf but in sys.conf radio has two bind addresses 1680 and 31341 , but manufacturer software may be diffrent in the way it runs its system and firmware so even if helium changes it on their official image, manufacture will need to make sure they account for the change in their firmware
no where does it mention in that about ports and forwarding ports, because that’s the end of their responsibility , the packet forwarder and the hardware specific stuff is left to the manufacture, so if your manufacture knows what they are doing, they will have it set up right. If they are relying on the helium image to do all the work for them as far as port forwarding etc… it’s not going to work the same as their hardware etc… that’s the price tag on the miner what it represents is support, if they don’t maintain their software properly and just push you “miner” image updates , then your going to be stuck until the issue is addressed by them. If they think Im wrong then , I’m wrong. |
Beta Was this translation helpful? Give feedback.
-
|
Just a side note after an experiment, I changed the ports on the server down link to 31341 and restarted the packet forwarder. It fails to PULL_ACK so don’t mess with those settings it will fail. So regardless of the jrpc binding tx to 31341 it still has a destination address of 1680 . I haven’t tried removing the containers port 31341 , since it’s working for me. So just try adding the 31341 to the containers port and leave the rest alone, just make sure that they are the same 1680 port and not different like a 1680 and a 1681 , that will fail. But like I said even if the destination of the packet is to 1680, if the container is blocking 31341 from exiting or moving from one container to another, it may cause that tunnel to not be created or established properly to the packet forwarder remember UDP is “stateless” connection , so any modification to the timing intervals in the LoRa packet forwarder config can cause you issues as well , thus the required “pull_ack” every so often to verify the connection is still available and routeable, even if it’s not since the “stateless” nature of it, it will still send out the packet with no need to receive a confirmation that it was sent or received. The LoRa packet forwarder accounts for that in its software with the push pull ack , and so does the miner image. Another random thing to note, is raspberry pi organization Officially released a 64bit OS for ARM64 bullseye, previous miners were using an unofficial image , if your miner some how updated it’s kernel headers or whatever , that would be a good starting point to diagnose issues, between the image and the local OS here’s an IF example of the 31341 issue, |
Beta Was this translation helpful? Give feedback.
-
|
Can confirm this issue in Australia, some of my hotspots have sent zero beacons for about 10+days , others the beacon amount has dropped significantly from 3 beacons a day to 0-1 daily. Hopefully they can address this issue soon , it also seems to affect both sensecap and nebra units. |
Beta Was this translation helpful? Give feedback.
-
|
Having the same issue with my SenseCAP unit. Beaconing is very unpredictable... Zero to one most days and multiple instances of none for 1 to 2 days. |
Beta Was this translation helpful? Give feedback.
-
|
Confirm issue with Milesight UG65. Witnessing about 1 per hour on average with 24 hotspots visible. That would average 1 per day for each visible hotspot. I routinely will go 2-3 days without a beacon. Ironically when first setup a couple of weeks ago the antenna had a long cable and attempted to beacon 2-3 times per day with no witnesses. Now the antenna cable is very short and height good, with clear witnessing and 14 witnesses when it does beacon - but the beaconing happens so rarely now. |
Beta Was this translation helpful? Give feedback.
-
|
Similar experience and numbers with my UG65 here in PerthOn 18 Mar 2022 6:37 pm, vanteer ***@***.***> wrote:
Confirm issue with Milesight UG65.
Witnessing about 1 per hour on average with 24 hotspots visible. That would average 1 per day for each visible hotspot. I routinely will go 2-3 days without a beacon. Ironically when first setup a couple of weeks ago the antenna had a long cable and attempted to beacon 2-3 times per day with no witnesses. Now the antenna cable is very short and height good, with clear witnessing and 14 witnesses when it does beacon - but the beaconing happens so rarely now.
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Selam arkadaşlar, Antalya / Türkiye'den hepinize selamlar, iyi geceler dilerim. Ben de aynı sorunları yaşıyorum, 3 Adet Milesight_UG65 ve 6 Adet Sensecap_M1 Madencim var bazı SenseCap_M1'de kazançlar düşse de günlük 4, ile 5 dolar bırakıyor, Milesiht_UG65 madencilerim maalesef çok kötü durumda, iyi çalışan cihazlarım ile yer değiştirdim acaba anten ve kablo kazanç kaybı mı var denedim, iyi çalışan cihaz her yerde iyi çalıştı, kötü çalışan cihazlarım da nereye koyduysam hangi iyi çalışan sistem internet ve antenlerini kullanarak çalıştırdıysam yine kötü sonuçlar aldım. Son durum itibarı ile sistemde sıkıntı var ve bazı cihazlar biraz bu durumda bile daha başarılı, ya yazılımsal, ya da donanımsal olarak daha başarılılar, Milesight_UG65'in Ayarlar menüsünde birkaç ayar var fakat anlamıyorum, bana yardımcı olabilecek birileri varsa çok sevinirim. |
Beta Was this translation helpful? Give feedback.
-
|
@AdilCtn this is for Australia my friend you will need to start your own Github request for Turkey bud. have a good day |
Beta Was this translation helpful? Give feedback.
-
For the last few weeks now, we have noticed that a beaconing issue has occurred on our group of units in Australia. we have spoken directly to the Manufacturer in case there was an issue with an update being missed. However we knew the issue would not be just with one set of units as we have units from two different manufacturers and the same thing is happening.
On average the beacons sent per unit is now ONE a day if we are lucky sometimes it is a number of days between a single beacon.
With the changes made recently from an average of 4 beacons down to 3 it is becoming disturbing to see multiple units which have not beacon for a few days.
there is a secondary issue behind these single beacons which is often a beacon is sent over the last two weeks or so and no witnesses will receive the beacon sent in a very populated city such as Sydney the likelihood of zero witnesses receiving your beacon is extremely low all of this has been since the witness numbers were reduced a couple of weeks back.
This leads us to the second issue of sensors not sending the data via the network, even though console is showing activity the Hot spot is not in fact often it is missing data for a number of days. we have raised this directly with our sensor suppliers whom have no idea as to why the data transfer packets are missing.
I have posted screen shots of the two single beacons sent over 2 days from a single unit when my understanding when the beacons and witness amounts were changed a unit would beacon on average every 480 minutes as often the case over the last few weeks in Australia its 19 to 43 hours sometimes even longer
Beta Was this translation helpful? Give feedback.
All reactions